Subject: Re: IPv6 Fragment Retransmission

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 27 Oct 2021 15:32:28 +0000

Hi, there were many good discussion points raised - too many to respond to each in
detail - so I will offer a few additional perspectives. First, one of the main drawbacks
of IP fragmentation is that the loss unit (a single fragment) is smaller than the
retransmission unit (the entire packet). So, the whole point of this approach is to
make the loss unit be equal to the retransmission unit whenever possible.

Additionally, some applications will see better performance by sending packets
larger than the path MTU and thereby leveraging IPv6 fragmentation, e.g., see:

https://datatracker.ietf.org/doc/draft-templin-dtn-ltpfrag/

In that study, it has also been shown that sending very large packets that require
fragmentation (e.g., up to 64KB) can provide an order of magnitude performance
increase over sending only MTU-sized packets for typical path MTUs (e.g., 1500).

IPv6 tunnel endpoints may also be located an appreciable distance from the
original source and/or final destination, and having the tunnel egress request
retransmission of missing fragments can often result in complete reassembly
without the source or destination ever becoming aware that any loss had occurred.
Since the tunnel is a "link", RFC3366 applies and the ingress and egress get to
decide the level of "link persistence" they will apply. Since fragments often arrive
in "bursts", the egress should be able to tell right away if one or a few are missing
and can send the Fragrep without delay. Then, if the ingress retains recently
transmitted fragments for a short time (e.g., 2*RTT) it can retransmit if it
receives a Fragrep before cached fragments are discarded.

There was some discussion about layering, and I think the answer is simply that
this is to be instrumented at the IP layer in both the IP fragmentation and IP
reassembly routines. The IP fragmentation routine caches recently-transmitted
fragments, and the IP reassembly routine maintains fragment checklists and
issues Fragrep messages if it detects missing fragments. All of this happens
at a layer below the transports and is invisible to them. The transports may
detect some delay variance and/or reordering, but that is a normal course
of affairs in the network.

There was some discussion about the need for an "Ordinal" number when the
fragment already includes an offset and length, but it should be clear that
IP fragments are not necessarily produced uniformly with each fragment
of equal length and so having a small integer ordinal can provide in a single
bit what would otherwise require transmission of a list of offsets and lengths.
Also, by setting a non-zero Ordinal, the fragmenting node is asserting that it
will retransmit fragments if asked and the reassembling node can determine
whether returning a Fragrep might be useful. And, if a middlebox reassembles
and refragments, it can either set the Ordinals to 0 or set them to new non-
zero values meaningful to itself and retransmit if it receives any Fragreps.

So again, the goal is to as often as possible satisfy reassemblies through the
retransmission of one or a few missing fragments instead of requiring the
original source to always retransmit the entire packet. This can have an
appreciable savings for example if the original packet was 64KB and only
one or a couple of 1280B or shorter fragments were lost (imagine the
case when only a 1B final fragment is lost, for example).

Fred