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?
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.
Thank you - Fred
> -----Original Message-----
> From: Tom Herbert <tom=40herbertland....@dmarc.ietf.org>
> Sent: Tuesday, November 14, 2023 12:55 PM
> To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> 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 12:17 PM Templin (US), Fred L
> <fred.l.temp...@boeing.com> 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 <t...@herbertland.com>
> > > Sent: Tuesday, November 14, 2023 12:00 PM
> > > 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 11:51 AM Templin (US), Fred L
> > > <fred.l.temp...@boeing.com> 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 <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-
> 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 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
