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
> -----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
