On Mon, Nov 13, 2023, 4:41 PM Templin (US), Fred L < fred.l.temp...@boeing.com> 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. > Fred, > 0 is valid CRC value, so this can't work. I'm not sure how this could work without fundamentally changing the Ethernet standard. In any case, this is part of an IEEE standard outside the purview of IETF. You might want to post the idea on an IEEE list. > > > 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. > Take a look at RFC6363 and probably other RFCs on FEC. My understanding is that these send extra packets for erasure coding such that when packets are dropped in the network the original packet can still be derived from what was received. I don't believe these try to repair individual packets that are corrupted (CRC error). Reducing retransmissions is achieved by increasing the number of packets with redundant information. Tom > 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
