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
