Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)

["Templin (US), Fred L" <[e-mail]>]

Tom, I have come around to a more balanced way of thinking about this. The Stone/Partridge
paper "When the CRC and TCP Checksum Disagree" provides good background:

http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf

This would tend to support requiring each parcel segment having *both* an end-to-end
CRC and per-segment Checksum since there will be many cases where the CRC appears
to be correct while the Checksum calculation fails. Note that even with the two checks
included the transport and application would do well to apply additional upper layer
integrity checks per the Stone/Partridge recommendations.

Fred

> -----Original Message-----
> From: Int-area <[e-mail]> On Behalf Of Templin (US), Fred L
> Sent: Tuesday, November 14, 2023 2:33 PM
> To: Tom Herbert <tom=[e-mail]>
> Cc: Joel Halpern <[e-mail]>; int-area <[e-mail]>
> Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the Internet (IP Parcels and Advanced Jumbos)
> 
> Tom, with IP parcels and advanced jumbos I do want to avoid coverage of the whole transport
> layer payload with the {TCP,UDP} checksum. IP parcels in particular can have their contents
> shifted around significantly in-flight so that the original packaging at the source ends up at
> the destination with completely different packaging which would invalidate any checksum
> of the whole transport layer payload. Instead, each transport segment has its own CRC that
> travels with the segment wherever it goes, and the final destination eventually uses it to
> validate the segment.
> 
> In short, the {TCP,UDP} checksums would not be used to cover the whole transport layer
> payload. So, better to make some use out of those fields to carry header-only checksums.
> 
> Fred
> 
> > -----Original Message-----
> > From: Tom Herbert <tom=[e-mail]>
> > Sent: Tuesday, November 14, 2023 1:57 PM
> > To: Templin (US), Fred L <[e-mail]>
> > Cc: Joel Halpern <[e-mail]>; int-area <[e-mail]>
> > 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 1:33 PM Templin (US), Fred L
> > <Fred.L.Templin=[e-mail]> wrote:
> > >
> > > Tom, RFC2675 was able to set different requirements for UDP checksums for classic jumbograms;
> > > using that precedent, why can't we set different requirements for IP parcels and advanced jumbos?
> >
> > Fred,
> >
> > That only changed the requirements for how the length field in the
> > pseudo header is computed. As RFC793 states it "is not an explicitly
> > transmitted quantity, but is computed". Your proposal would eliminate
> > the coverage of the whole transport layer payload which has been an
> > integral part of TCP and UDP checksum from the beginning.
> >
> > >
> > > I get what you are saying about tucking a checksum into an IP option/extension header field. But,
> > > the problem with that is every time you extend an IP option/extension you have to normalize the
> > > field on an even 4-octet or 8-octet boundary. So, it eats up space you would rather not have to use.
> >
> > Given a choice between repurposing a field in a standard widely
> > deployed protocol for a narrow use case that potentially risks
> > interoperability versus wasting a couple of bytes to avoid doing
> > that-- I would choose the latter.
> >
> > Tom
> >
> > >
> > > Thank you - Fred
> > >
> > > > -----Original Message-----
> > > > From: Tom Herbert <tom=[e-mail]>
> > > > Sent: Tuesday, November 14, 2023 12:55 PM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: Templin (US), Fred L <[e-mail]>; Joel Halpern <[e-mail]>; int-area <[e-mail]>
> > > > 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 12:17 PM Templin (US), Fred L
> > > > <[e-mail]> wrote:
> > > > >
> > > > > Tom, what it means is that for IP parcels and advanced jumbos the rule for calculating the TCP and
> > > > > UDP checksums is different.
> > > >
> > > > Fred,
> > > >
> > > > Repurposing the TCP and UDP checksum fields is going to get a lot of
> > > > pushback and is probably a non-starter. Maybe the parcel option could
> > > > contain the checksum value.
> > > >
> > > > Tom
> > > >
> > > > > The rule is that the {TCP,UDP} checksum is calculated over the headers
> > > > > only while pretending that the payload following the headers is 0 octets. Meanwhile, each segment
> > > > > of the payload that follows the {TCP,UDP}/IP headers has its own CRC which is better integrity
> > > > > protection than had the segment been included in the {TCP,UDP} checksum.
> > > > >
> > > > > So, this is asking routers to check the integrity of the {TCP,UDP}/IP headers only - if there is an
> > > > > error at that level, mis-delivery is possible and so probably better to detect it as early as possible.
> > > > >
> > > > > Fred
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Tom Herbert <[e-mail]>
> > > > > > Sent: Tuesday, November 14, 2023 12:00 PM
> > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > Cc: Templin (US), Fred L <Fred.L.Templin=[e-mail]>; Joel Halpern <[e-mail]>; int-area
> > <int-
> > > > > > [e-mail]>
> > > > > > 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 11:51 AM Templin (US), Fred L
> > > > > > <[e-mail]> wrote:
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > Fred,
> > > > > >
> > > > > > Sorry, I don't follow. The UDP and TCP checksum fields are set and
> > > > > > processed per RFC768 and RFC793. These are checksums over the pseudo
> > > > > > header, transport header, and transport payload. That's standard and
> > > > > > not something we can change. So I don't understand when you say "the
> > > > > > checksum does not extend to cover the parcel/jumbo body"
> > > > > >
> > > > > > Tom
> > > > > >
> > > > > > >
> > > > > > > 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 <[e-mail]>
> > > > > > > > Sent: Tuesday, November 14, 2023 11:02 AM
> > > > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > > > Cc: Templin (US), Fred L <Fred.L.Templin=[e-mail]>; Joel Halpern <[e-mail]>; int-
> area
> > > > <int-
> > > > > > > > [e-mail]>
> > > > > > > > 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
> > > > > > > > <[e-mail]> 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 <[e-mail]>
> > > > > > > > > > Sent: Tuesday, November 14, 2023 10:02 AM
> > > > > > > > > > To: Templin (US), Fred L <Fred.L.Templin=[e-mail]>
> > > > > > > > > > Cc: Templin (US), Fred L <[e-mail]>; Joel Halpern <[e-mail]>; int-area <int-
> > > > [e-mail]>
> > > > > > > > > > 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=[e-mail]> 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 <[e-mail]> On Behalf Of Templin (US), Fred L
> > > > > > > > > > > Sent: Tuesday, November 14, 2023 7:28 AM
> > > > > > > > > > > To: Tom Herbert <tom=[e-mail]>
> > > > > > > > > > > Cc: Joel Halpern <[e-mail]>; int-area <[e-mail]>
> > > > > > > > > > > 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=[e-mail]>
> > > > > > > > > > > Sent: Monday, November 13, 2023 3:38 PM
> > > > > > > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > > > > > > Cc: Joel Halpern <[e-mail]>; int-area <[e-mail]>
> > > > > > > > > > > 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=[e-mail]> 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 <[e-mail]>
> > > > > > > > > > > > Sent: Monday, November 13, 2023 2:53 PM
> > > > > > > > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > > > > > > > Cc: [e-mail]
> > > > > > > > > > > > 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 <[e-mail]>
> > > > > > > > > > > > >> Sent: Monday, November 13, 2023 1:59 PM
> > > > > > > > > > > > >> To: Templin (US), Fred L <[e-mail]>
> > > > > > > > > > > > >> Cc: [e-mail]
> > > > > > > > > > > > >> 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=[e-mail]> wrote:
> > > > > > > > > > > > >>>> Hi Tom, see below for responses:
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>>> -----Original Message-----
> > > > > > > > > > > > >>>>> From: Int-area <[e-mail]> On Behalf Of Tom Herbert
> > > > > > > > > > > > >>>>> Sent: Monday, November 13, 2023 12:39 PM
> > > > > > > > > > > > >>>>> To: Templin (US), Fred L <Fred.L.Templin=[e-mail]>
> > > > > > > > > > > > >>>>> Cc: [e-mail]
> > > > > > > > > > > > >>>>> 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=[e-mail]> 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
> > > > > > > > > > > > >>>>>>> [e-mail]
> > > > > > > > > > > > >>>>>>> https://www.ietf.org/mailman/listinfo/int-area
> > > > > > > > > > > > >>>>>> _______________________________________________
> > > > > > > > > > > > >>>>>> Int-area mailing list
> > > > > > > > > > > > >>>>>> [e-mail]
> > > > > > > > > > > > >>>>>> https://www.ietf.org/mailman/listinfo/int-area
> > > > > > > > > > > > >>> _______________________________________________
> > > > > > > > > > > > >>> Int-area mailing list
> > > > > > > > > > > > >>> [e-mail]
> > > > > > > > > > > > >>> https://www.ietf.org/mailman/listinfo/int-area
> > > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Int-area mailing list
> > > > > > > > > > > [e-mail]
> > > > > > > > > > > https://www.ietf.org/mailman/listinfo/int-area
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area