Subject: Re: IPv6 Fragment Retransmission

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 10 Nov 2021 15:07:57 +0000

Roland, thank you for these truly useful observations. Please see below for responses:

> -----Original Message-----
> From: Bless, Roland (TM) [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2021 4:26 AM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]
> Subject: Re: IPv6 Fragment Retransmission 
> 
> 
> Hi Fred,
> 
> On 09.11.21 at 19:42 Templin (US), Fred L wrote:
> > I would like to now invite a discussion of any other comments/questions/concerns
> > anyone might have here on the list. The draft can be found here:
> >
> > https://datatracker.ietf.org/doc/draft-templin-6man-fragrep/
> 
> Unfortunately, I had no time to fully read your draft yet, but saw your
> presentation yesterday. A few observations from my side:
> 
> 1) fragmentation could be a "packet loss multiplier"
>     (see the "Fragmentation Considered Harmful" paper from
>      Kent and Mogul, https://dl.acm.org/doi/10.1145/205447.205456)
>     and that's what you'd like to address I guess.

Yes, the goal is to - whenever possible - satisfy loss through the retransmission of
individual fragments so that the original source can avoid having to retransmit the
entire packet. For example, a 64KB original packet may require as many as 50 or
even more fragments. If only one or a few fragments are lost, it would be much
better if only those fragments were retransmitted. The goal therefore is to make
the loss unit match the retransmission unit so that fragments that were received
successfully need not be retransmitted over and over again to no avail.

> 2) there are good arguments for application level framing
>     (https://dl.acm.org/doi/10.1145/99517.99553), i.e.,
>     the application knows best how to split data into
>     logical data units (LDU) and how to react to a
>     missing LDU.

Application-layer framing is important, but we are also seeing techniques such
as sendmmsg() and Generic Segment Offload that show benefits for pushing
segmentation down to the lowest possible layers. Those techniques in conjunction
with responsible application of IP fragmentation can be shown to provide the
greatest performance multiplier.

> 3) fragmentation may cause micro-bursts in switches and
>     routers, because fragments are sent back-to-back unless paced,
>     causing higher buffer utilization if not packet loss.
>     So my guess is that fragment loss will be highly correlated
>     for tail-drop buffers and that then multiple segments need
>     to be retransmitted.

This brgs the question of how many fragments is too many = 16? 32? 64? more?
This is precisely why the draft also proposes a new type of Packet Too Big (PTB)
message known as a "PTB Soft Error". So that, if the source or destination are
experiencing excessive fragment loss, they can return a "PTB Soft Error" to
request the original source to start sending smaller packets that would result
in fewer fragments. But, the original packet is still delivered (if possible) instead
of being dropped as in the classic "PTB Hard Error" case.

> 4) the added complexity at the sender side by requiring a
>     buffer for sent packets/fragments is only a start. For how long
>     should these be kept (i.e., suitable timeout values or
>     just until overwritten in a circular buffer)?
>     Usually, you also need timers for ARQ at the sender side.
>     However, in your proposal it seems that the sender only
>     reacts to a NACK from the receiver side, which is different
>     from typical ARQ, where the sender automatically
>     retransmits non-acknowledged packets after a timeout.
>     It should be explicitly mentioned if the latter is not the
>     case in your proposal. What happens if the FRAGREP
>     is lost? I guess nothing, since you don't want a
>     reliable service.

The service we are after is a link-layer ARQ service in the spirit of RFC3366. It
can be considered a "best effort" service, and does not attempt to provide true
end-to-end reliability which is the job of transports. RFC3366 defines a "link
persistence interval", and it is this interval that determines the length of time
the sender should retain recently-transmitted fragments before releasing them.
And, loss of a FRAGREP is simply a lost opportunity for an optimization and not
the end of the world.

> So all in all, I guess that (modern) transport protocols
> probably do a much better and more complete job
> (e.g., what about flow control problems and additional
> latencies by queuing) for all of the implied related
> problems and that a closer analysis where the supposed
> speedup comes from would be helpful.

Again, this is a link-layer service that works the same as for any link in the
spirit of RFC3366. It provides a useful optimization that in many cases can
relieve end-to-end transport protocols from having to retransmit. And,
again, it is one element in a service that allows sources to dynamically tune
the size of packets they are sending to achieve the greatest performance
in harmony with the dynamically changing network path conditions.

If you have read this far, I would now encourage you to go have a look at
AERO and OMNI where all elements of the service are discussed in harmony
with one another. They provide a blueprint for true MTU diversity and high
performance in the Internet.

Thanks - Fred

> Regards,
>   Roland