Hi Tom, On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L <[email protected]> wrote: > > Hi Tom, see below for responses: > > > -----Original Message----- > > From: Int-area <[email protected]> On Behalf Of Tom Herbert > > Sent: Monday, November 13, 2023 12:39 PM > > To: Templin (US), Fred L <[email protected]> > > Cc: [email protected] > > 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 > > <[email protected]> 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > _______________________________________________ > > > Int-area mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
