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