Tom, the checksum value gets written into the TCP or UDP header checksum field,
so if it did not
cover the TCP/UDP header fields in addition to the IP pseudo-header then there
would be nowhere
to place an integrity check for the transport layer port numbers.
It is a good point that checking integrity of layer 4 information at
intermediate layer 3 hops may
be crossing layers. But, the IP pseudo-header integrity check needs to go
somewhere and IPv6
does not include a checksum field in the IPv6 header.
Thank you - Fred
> -----Original Message-----
> From: Tom Herbert <t...@herbertland.com>
> Sent: Tuesday, November 14, 2023 11:02 AM
> To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> Cc: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org>; Joel
> Halpern <jmh.dir...@joelhalpern.com>; int-area <int-
> a...@ietf.org>
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> Internet (IP Parcels and Advanced Jumbos)
>
> EXT email: be mindful of links/attachments.
>
>
>
> On Tue, Nov 14, 2023 at 10:36 AM Templin (US), Fred L
> <fred.l.temp...@boeing.com> wrote:
> >
> > Tom, for IP parcels and advanced jumbos, the {TCP, UDP} checksums cover
> > only the pseudo-header
> > of the IP header followed by the fields of the {TCP, UDP} header itself;
> > the checksum does not extend
> > to cover the parcel/jumbo body. In this way, it is very much like the IPv4
> > header checksum and covers
> > only header fields and no data octets. The reason for this is that the IP
> > parcel and advanced jumbo
> > data segments each have their own CRCs for integrity verification.
>
> Fred,
>
> So this is a type of new checksum of L4 checksum, not the TCP/UDP
> checksum defined in RFC793/RFC768? Do you really need this checksum to
> cover the transport layer header, could it just be over pseudo header?
> (that would greatly simplify router operations)
>
> Tom
>
>
> >
> > Fred
> >
> > > -----Original Message-----
> > > From: Tom Herbert <t...@herbertland.com>
> > > Sent: Tuesday, November 14, 2023 10:02 AM
> > > To: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org>
> > > Cc: Templin (US), Fred L <fred.l.temp...@boeing.com>; Joel Halpern
> > > <jmh.dir...@joelhalpern.com>; int-area <int-area@ietf.org>
> > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > Internet (IP Parcels and Advanced Jumbos)
> > >
> > > EXT email: be mindful of links/attachments.
> > >
> > >
> > >
> > > On Tue, Nov 14, 2023 at 8:11 AM Templin (US), Fred L
> > > <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote:
> > > >
> > > > Tom, thinking more about this IPv6 does not verify header checksums at
> > > > every hop – only at the
> > > >
> > > > final destination. So, how would it be if we simply made header
> > > > checksum verification a SHOULD
> > > >
> > > > at intermediate hops but a MUST at the final destination?
> > >
> > > Fred,
> > >
> > > So if I understand correctly, this would be validating the TCP and UDP
> > > checksum at intermediate hops? Frankly, that's going to be a hard sell
> > > to router vendors, they don't generally have the capability to compute
> > > those checksums. Also, it's not guaranteed that a TCP and UDP checksum
> > > are guaranteed to be maintained to be correct while the packet is
> > > inflight. I believe in current specifications this For instance,
> > > draft-mizrahi-spring-l4-checksum-srv6-00 would potentially make
> > > checksums incorrect while packets are inflight.
> > >
> > > Tom
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Thanks - Fred
> > > >
> > > >
> > > >
> > > > From: Int-area <int-area-boun...@ietf.org> On Behalf Of Templin (US),
> > > > Fred L
> > > > Sent: Tuesday, November 14, 2023 7:28 AM
> > > > To: Tom Herbert <tom=40herbertland....@dmarc.ietf.org>
> > > > Cc: Joel Halpern <jmh.dir...@joelhalpern.com>; int-area
> > > > <int-area@ietf.org>
> > > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > > Internet (IP Parcels and Advanced Jumbos)
> > > >
> > > >
> > > >
> > > > Tom, the IP parcel / advanced jumbo header checksum is on the same
> > > > order of complexity as the
> > > >
> > > > IPv4 header checksum and covers a similar amount of header data – the
> > > > checksum does not run
> > > >
> > > > over the entire length of the parcel/jumbo. Routers that accept IP
> > > > parcels and advanced jumbos
> > > >
> > > > would need to verify the IP addresses and {TCP,UDP} port numbers if
> > > > they receive a parcel that
> > > >
> > > > was flagged as a CRC error by lower layers – that is all.
> > > >
> > > >
> > > >
> > > > Thanks - Fred
> > > >
> > > >
> > > >
> > > > From: Tom Herbert <tom=40herbertland....@dmarc.ietf.org>
> > > > Sent: Monday, November 13, 2023 3:38 PM
> > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> > > > Cc: Joel Halpern <jmh.dir...@joelhalpern.com>; int-area
> > > > <int-area@ietf.org>
> > > > Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
> > > > Internet (IP Parcels and Advanced Jumbos)
> > > >
> > > >
> > > >
> > > > EXT email: be mindful of links/attachments.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L
> > > > <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote:
> > > >
> > > > Joel, I am asking this only for IP parcels and advanced jumbos over
> > > > links that support them natively.
> > > > When a router with a link that supports IP parcels and advanced jumbos
> > > > natively receives an
> > > > ethernet frame with bad CRC, it first checks to see if it is an IP
> > > > parcel/advanced jumbo. If so, the
> > > > router performs an integrity check on the {TCP,UDP}/IP headers and
> > > > discards the frame if the
> > > > header checksum is incorrect. Only if the {TCP,UD}/IP header checksum
> > > > is correct does the
> > > > router forward the (errored) frame. This procedure is repeated at every
> > > > IP forwarding hop
> > > > along the parcel/jumbo-capable path to the final destination.
> > > >
> > > >
> > > >
> > > > Fred,
> > > >
> > > >
> > > >
> > > > This would mean that routers would not only have process L4 headers in
> > > > flight which is already an architectural abomination they
> often
> > > do, they'd also have to compute header checksums on L4. It's unlikely
> > > router vendors are going to be excited to do that. IMO, it would
> be
> > > better to avoid having routers dabble in L4 at all for this.
> > > >
> > > >
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > >
> > > > Fred
> > > >
> > > > > -----Original Message-----
> > > > > From: Joel Halpern <jmh.dir...@joelhalpern.com>
> > > > > Sent: Monday, November 13, 2023 2:53 PM
> > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> > > > > Cc: int-area@ietf.org
> > > > > Subject: [EXTERNAL] Re: [Int-area] A new link service model for the
> > > > > Internet (IP Parcels and Advanced Jumbos)
> > > > >
> > > > > EXT email: be mindful of links/attachments.
> > > > >
> > > > >
> > > > >
> > > > > You seem to be asking that every router in the Internet deliver frames
> > > > > with bad Ethernet CRCs.(which may have bad destination addresses,
> > > > > since
> > > > > routers do not check upper layer checksums) This is asking every
> > > > > router
> > > > > and eveyr link to pay a significant in the hope that sometimes someone
> > > > > may be able to safely reconstruct the frame.
> > > > >
> > > > > Or are you proposing this for some other network that is not IETF
> > > > > business?
> > > > >
> > > > > Yours,
> > > > >
> > > > > Joel
> > > > >
> > > > > On 11/13/2023 5:43 PM, Templin (US), Fred L wrote:
> > > > > > Joel, I don't mind leaving the IEEE specs alone and allowing the
> > > > > > receiver to deliver errored
> > > > > > frames to upper layers along with a CRC error flag. The CRC error
> > > > > > flag would also make for
> > > > > > a good indication to the IP layer of when the IP addresses and port
> > > > > > numbers should be
> > > > > > checked for consistency so there is value in continuing to let the
> > > > > > CRC do its work.
> > > > > >
> > > > > > About delay and disruption tolerance, IP parcels and advanced
> > > > > > jumbos present a ready-made
> > > > > > vehicle for supporting performance maximization, carrying FEC data,
> > > > > > etc. And, this will be
> > > > > > important for more than just space systems with their long delay
> > > > > > links - it will become more
> > > > > > and more important for all air/land/sea/space mobility scenarios as
> > > > > > the Internet becomes
> > > > > > more and more mobile and more and more interplanetary. I think that
> > > > > > should already be
> > > > > > of interest to Intarea.
> > > > > >
> > > > > > Fred
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Joel Halpern <j...@joelhalpern.com>
> > > > > >> Sent: Monday, November 13, 2023 1:59 PM
> > > > > >> To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> > > > > >> Cc: int-area@ietf.org
> > > > > >> Subject: [EXTERNAL] Re: [Int-area] A new link service model for
> > > > > >> the Internet (IP Parcels and Advanced Jumbos)
> > > > > >>
> > > > > >> EXT email: be mindful of links/attachments.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Top posting two small but important points to Fred:
> > > > > >>
> > > > > >> 1) Changing Ethernet CRC behavior is up to IEEE. IETF is not free
> > > > > >> to
> > > > > >> redefine that.
> > > > > >>
> > > > > >> 2) There are approaches for links with long delays (sometimes even
> > > > > >> longer than the 8 minutes to which you refer). If you want to
> > > > > >> propose
> > > > > >> different mechanisms, have the discussion with the delay tolerant
> > > > > >> networking working group. It would be rather odd to change IPv6
> > > > > >> for
> > > > > >> that case, and even odder to do without their making a request for
> > > > > >> a change.
> > > > > >>
> > > > > >> Yours,
> > > > > >>
> > > > > >> Joel
> > > > > >>
> > > > > >> On 11/13/2023 4:40 PM, Templin (US), Fred L wrote:
> > > > > >>> Hi Tom,
> > > > > >>>
> > > > > >>> On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
> > > > > >>> <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote:
> > > > > >>>> Hi Tom, see below for responses:
> > > > > >>>>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: Int-area <int-area-boun...@ietf.org> On Behalf Of Tom
> > > > > >>>>> Herbert
> > > > > >>>>> Sent: Monday, November 13, 2023 12:39 PM
> > > > > >>>>> To: Templin (US), Fred L
> > > > > >>>>> <Fred.L.Templin=40boeing....@dmarc.ietf.org>
> > > > > >>>>> Cc: int-area@ietf.org
> > > > > >>>>> Subject: [EXTERNAL] Re: [Int-area] A new link service model for
> > > > > >>>>> the Internet (IP Parcels and Advanced Jumbos)
> > > > > >>>>>
> > > > > >>>>> EXT email: be mindful of links/attachments.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> On Mon, Nov 13, 2023 at 11:58 AM Templin (US), Fred L
> > > > > >>>>> <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote:
> > > > > >>>>>> Here is something everyone should read and become familiar
> > > > > >>>>>> with taken from Section 5 of the latest
> > > > > >>>>>> version of "IP Parcels and Advanced Jumbos":
> > > > > >>>>>>
> > > > > >>>>>> https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/
> > > > > >>>>>>
> > > > > >>>>>> A new link service model is offered that will be essential for
> > > > > >>>>>> supporting air/land/sea/space mobile
> > > > > >>>>>> Internetworking. IP Parcels and Advanced Jumbos are the
> > > > > >>>>>> vehicles that support end-to-end as
> > > > > >>>>>> opposed to hop-by-hop link error detection in the new model.
> > > > > >>>>>>
> > > > > >>>>>> This is a truly transformational concept for the Internet -
> > > > > >>>>>> many may already know about it, but
> > > > > >>>>>> everyone should become aware of it.
> > > > > >>>>> Hi Fred,
> > > > > >>>>>
> > > > > >>>>> Some comments in line.
> > > > > >>>>>
> > > > > >>>>>> Fred
> > > > > >>>>>> ---
> > > > > >>>>>> 5. IP Parcel and Advanced Jumbo Link Service Model
> > > > > >>>>>>
> > > > > >>>>>> The classical Internetworking link service model requires
> > > > > >>>>>> each link
> > > > > >>>>>> in the path to apply a link-layer packet integrity check
> > > > > >>>>>> often termed
> > > > > >>>>>> a "Cyclic Redundancy Check (CRC)". The link near-end
> > > > > >>>>>> calculates and
> > > > > >>>>>> appends a CRC code value (often 4 octets) to each packet
> > > > > >>>>>> pending
> > > > > >>>>>> transmission, and the link far-end verifies the CRC upon
> > > > > >>>>>> packet
> > > > > >>>>>> receipt. If the CRC is incorrect, the link far-end
> > > > > >>>>>> unconditionally
> > > > > >>>>>> discards the packet. This process is repeated for each
> > > > > >>>>>> link in the
> > > > > >>>>>> path so that only packets that pass all link-layer CRC
> > > > > >>>>>> checks are
> > > > > >>>>>> delivered to the final destination.
> > > > > >>>>>>
> > > > > >>>>>> While this link service model has contributed to the
> > > > > >>>>>> unparalleled
> > > > > >>>>>> success of terrestrial Internetworks (including the
> > > > > >>>>>> global public
> > > > > >>>>>> Internet), new uses in which significant delays or
> > > > > >>>>>> disruptions can
> > > > > >>>>>> occur are not as well supported. For example, a path
> > > > > >>>>>> that contains
> > > > > >>>>>> links with significant bit errors may be challenged to
> > > > > >>>>>> pass a
> > > > > >>>>>> majority percentage of packets since loss due to CRC
> > > > > >>>>>> failures can
> > > > > >>>>>> occur at any hop while each packet lost must be
> > > > > >>>>>> retransmitted. With
> > > > > >>>>>> the advent of space-domain Internetworking, the long
> > > > > >>>>>> delays
> > > > > >>>>>> associated with interplanetary signal propagation can
> > > > > >>>>>> also often
> > > > > >>>>>> render any retransmissions useless especially when
> > > > > >>>>>> communications
> > > > > >>>>>> latency is critical.
> > > > > >>>>> How would this compare to an L2 reliable protocol that is able
> > > > > >>>>> to
> > > > > >>>>> retransmit over links in the path that are particularly lossy?
> > > > > >>>>> If
> > > > > >>>>> latency is critical then we probably can't do any better than
> > > > > >>>>> retransmitting at L2.
> > > > > >>>> Link-layer retransmissions are still beneficial on low-delay
> > > > > >>>> links yes. But, if
> > > > > >>>> slightly errored data is still received after N tries, the
> > > > > >>>> errored data should be
> > > > > >>>> forwarded to the next hop toward the final destination instead
> > > > > >>>> of simply
> > > > > >>>> dropped. Link-layer retransmissions on long-delay links (like
> > > > > >>>> 4min OWLT
> > > > > >>>> from earth to mars) might not be as beneficial.
> > > > > >>>>
> > > > > >>>>>> IP parcels and advanced jumbos now offer a new link
> > > > > >>>>>> service model;
> > > > > >>>>>> instead of requiring an independent CRC at each
> > > > > >>>>>> intermediate link
> > > > > >>>>>> hop, IP parcels and advanced jumbos include a CRC code
> > > > > >>>>>> with each
> > > > > >>>>>> segment that is calculated and inserted by the original
> > > > > >>>>>> source and
> > > > > >>>>>> verified by the final destination.
> > > > > >>>>> So basically this is an end to end CRC and we'd have to disable
> > > > > >>>>> the L2
> > > > > >>>>> CRC, like Ethernet CRC, everywhere along the path for it to
> > > > > >>>>> work?
> > > > > >>>> It would still work with Ethernet CRC enabled along the path,
> > > > > >>>> but the Ethernet
> > > > > >>>> CRCs would be redundant with the parcel/advanced jumbo segment
> > > > > >>>> CRCs. It
> > > > > >>>> might be OK to leave Ethernet CRCs in place, but have the link
> > > > > >>>> far end forward
> > > > > >>>> any packets with link errors instead of dropping - but, then the
> > > > > >>>> Ethernet CRC
> > > > > >>>> operations would essentially be wasted energy so better to
> > > > > >>>> disable them.
> > > > > >>>>
> > > > > >>>>>> Each intermediate hop must
> > > > > >>>>>> therefore pass IP parcels and advanced jumbos without
> > > > > >>>>>> applying
> > > > > >>>>>> traditional link layer CRC checks and/or discarding
> > > > > >>>>>> packets that
> > > > > >>>>>> contain errors. This relaxes the burden on intermediate
> > > > > >>>>>> systems and
> > > > > >>>>>> delivers all data that transits the path to the
> > > > > >>>>>> destination end
> > > > > >>>>>> system which is uniquely positioned to coordinate
> > > > > >>>>>> recovery of any
> > > > > >>>>>> data that was either lost or corrupted in transit.
> > > > > >>>>> "Burden on intermediate" systems is relative. If this refers to
> > > > > >>>>> Ethernet routers then the burden of CRC has long been assumed.
> > > > > >>>>> It will
> > > > > >>>>> be more trouble to undo that. Getting the bad packets to the
> > > > > >>>>> transport
> > > > > >>>>> layer might be helpful, assuming that the packet isn't
> > > > > >>>>> corrupted so
> > > > > >>>>> much that the receiver can identify the flow. I would point out
> > > > > >>>>> that
> > > > > >>>>> if the addresses of the packet and probably some other fields
> > > > > >>>>> are
> > > > > >>>>> corrupted and the packet isn't not dropped by the network then
> > > > > >>>>> this
> > > > > >>>>> increases the chances of packet misdelivery-- there may be some
> > > > > >>>>> security ramifications there.
> > > > > >>>> Right, I should have said that there is still hop-by-hop
> > > > > >>>> integrity checking done
> > > > > >>>> on the IP parcel and advanced jumbo headers (including addresses
> > > > > >>>> and port
> > > > > >>>> numbers) to avoid mis-delivery as you say. But, that is with an
> > > > > >>>> Internet layer
> > > > > >>>> checksum and not an L2 CRC.
> > > > > >>>>
> > > > > >>>>>> Each IP parcel and/or advanced jumbo-capable hop along
> > > > > >>>>>> the path from
> > > > > >>>>>> the original source to the final destination must
> > > > > >>>>>> therefore provide
> > > > > >>>>>> an API primitive to inform the link ingress to disable
> > > > > >>>>>> link-layer
> > > > > >>>>>> integrity checks for the current IP parcel or advanced
> > > > > >>>>>> jumbo payload.
> > > > > >>>>>> The parcel/advanced jumbo may therefore collect
> > > > > >>>>>> cumulative link
> > > > > >>>>>> errors along the path, but these will be detected by the
> > > > > >>>>>> per segment
> > > > > >>>>>> CRC checks performed by the final destination. The final
> > > > > >>>>>> destination
> > > > > >>>>>> in turn delivers each segment to the local transport
> > > > > >>>>>> layer along with
> > > > > >>>>>> a "CRC error" flag that is set if a CRC error was
> > > > > >>>>>> detected or clear
> > > > > >>>>>> otherwise. The CRC indication is then taken under
> > > > > >>>>>> advisement by the
> > > > > >>>>>> transport layer, which should consult any transport or
> > > > > >>>>>> higher-layer
> > > > > >>>>>> integrity checks to pursue corrective actions.
> > > > > >>>>>>
> > > > > >>>>>> IP parcels and advanced jumbos therefore provide a
> > > > > >>>>>> revolutionary
> > > > > >>>>>> advancement for delay/disruption tolerance in
> > > > > >>>>>> air/land/sea/space
> > > > > >>>>>> mobile Internetworking applications. As the Internet
> > > > > >>>>>> continues to
> > > > > >>>>>> evolve from its more stable fixed terrestrial network
> > > > > >>>>>> origins to one
> > > > > >>>>>> where more and more nodes operate in the mobile edge,
> > > > > >>>>>> this new link
> > > > > >>>>>> service model relocates error detection and correction
> > > > > >>>>>> responsibilities from intermediate systems to the end
> > > > > >>>>>> systems that
> > > > > >>>>>> are best positioned to take corrective actions.
> > > > > >>>>>>
> > > > > >>>>>> Note: To be verified, IP parcels and advanced jumbos may
> > > > > >>>>>> be realized
> > > > > >>>>>> through simple software updates for widely-deployed link
> > > > > >>>>>> types such
> > > > > >>>>>> as 1/10/100-Gbps Ethernet. If the network driver API
> > > > > >>>>>> provides a
> > > > > >>>>>> primitive allowing the IP layer to disable link layer
> > > > > >>>>>> integrity
> > > > > >>>>>> checks on a per-"packet" basis, even very large IP
> > > > > >>>>>> parcels and
> > > > > >>>>>> advanced jumbos should be capable of transiting the link
> > > > > >>>>>> since
> > > > > >>>>>> Ethernet link transmission unit sizes are bounded by
> > > > > >>>>>> software and not
> > > > > >>>>>> hardware constraints.
> > > > > >>>>> I don't believe disabling the Ethernet CRC is feasible. AFAIK
> > > > > >>>>> IEEE
> > > > > >>>>> 802.3 standards don't allow the Ethernet CRC to be optional.
> > > > > >>>>> Even if
> > > > > >>>>> it were, I doubt any existing NIC hardware or router hardware
> > > > > >>>>> would
> > > > > >>>>> have an API to disable CRC.
> > > > > >>>>> That may well be true for current-day hardware, but I can
> > > > > >>>>> easily imagine future
> > > > > >>>>> hardware that presents such an API - or, maybe we need to
> > > > > >>>>> define a new
> > > > > >>>>> EtherType for which the future hardware omits the CRC checks.
> > > > > >>>> Fred,
> > > > > >>>>
> > > > > >>>> A new EtherType wouldn't help. The CRC is an integral part of the
> > > > > >>>> Ethernet frame. To make it optional would probably require
> > > > > >>>> standards
> > > > > >>>> action in IEEE (or appropriate SDO for other L2 technologies).
> > > > > >>> OK, then what about set the Ethernet CRC to 0 on transmit and
> > > > > >>> ignore on receipt?
> > > > > >>> Which is a behavior that could be keyed off of EtherType.
> > > > > >>>
> > > > > >>>>> By the way, this is the only way feasible I see for making
> > > > > >>>>> Internet-like protocols work
> > > > > >>>>> over long-delay space-domain links or mobile network edge links
> > > > > >>>>> that are subject to
> > > > > >>>>> significant disruption. Better to deliver (slightly) errored
> > > > > >>>>> data to the final destination
> > > > > >>>>> instead of no data, especially when retransmission delays are
> > > > > >>>>> intolerable. The final
> > > > > >>>>> destination will find a way to make sense out of as much of the
> > > > > >>>>> received data as
> > > > > >>>>> possible, which is way better than nothing.
> > > > > >>>> Well, it's not like we are starting from nothing. For instance,
> > > > > >>>> TCP
> > > > > >>>> selective ACKs allow a receiver to basically tell the sender what
> > > > > >>>> segments were received (and implicitly what segments were
> > > > > >>>> dropped) and
> > > > > >>>> need to be retransmitted. This doesn't work if the drops are at
> > > > > >>>> the
> > > > > >>>> tail of a communication, and in that case it might be useful to
> > > > > >>>> send
> > > > > >>>> some sort of selective NAK back to the sender which I imagine is
> > > > > >>>> what
> > > > > >>>> your proposal might facilitate.
> > > > > >>> TCP selective ACK is not helpful over links with 8 minute
> > > > > >>> round-trip times. Also
> > > > > >>> probably not great over links with high BERs. Better to get as
> > > > > >>> much data through
> > > > > >>> to the destination as possible in the first try whether/not it
> > > > > >>> has errors and let the
> > > > > >>> destination either accept it as-is or repair it if it is able to.
> > > > > >>> Forward error correction
> > > > > >>> at the destination should be helpful - retransmission requests
> > > > > >>> should be a low
> > > > > >>> preference last resort.
> > > > > >>>
> > > > > >>> Thank you - Fred
> > > > > >>>
> > > > > >>>> Tom
> > > > > >>>>
> > > > > >>>>> Thank you - Fred
> > > > > >>>>>
> > > > > >>>>>> Tom
> > > > > >>>>>>> _______________________________________________
> > > > > >>>>>>> Int-area mailing list
> > > > > >>>>>>> Int-area@ietf.org
> > > > > >>>>>>> https://www.ietf.org/mailman/listinfo/int-area
> > > > > >>>>>> _______________________________________________
> > > > > >>>>>> Int-area mailing list
> > > > > >>>>>> Int-area@ietf.org
> > > > > >>>>>> https://www.ietf.org/mailman/listinfo/int-area
> > > > > >>> _______________________________________________
> > > > > >>> Int-area mailing list
> > > > > >>> Int-area@ietf.org
> > > > > >>> https://www.ietf.org/mailman/listinfo/int-area
> > > >
> > > > _______________________________________________
> > > > Int-area mailing list
> > > > Int-area@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/int-area
> >
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
