Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt

["C. M. Heard" <[e-mail]>]

On Sun, Jun 20, 2021 at 10:20 AM Jonathan Morton wrote:

> I think a crucial point here is that TCP only sends as much data as the
> receiver has positively indicated as it is ready to accept (ie. the rwnd),
> *regardless* of congestion control considerations.  It's entirely feasible
> to have a TCP receiver that can only handle 4KB outstanding at a time, and
> support for that was baked into TCP from the beginning.
>
> The fragmentation handling is analogous to that, but due to the nature of
> UDP, the sender might not have information about the receiver's
> capabilities at send time.  So the question is about how much data and what
> complexity of fragmentation the sender may assume the receiver has
> a-priori.  I would suggest that this assumption should be conservative due
> to the interoperability principle.
>

An option-aware client can and should include the UDP MRSS (Maximum
Reassembled Segment Size) option in its request to indicate to the remote
server the largest fragmented UDP datagram that it can reassemble. It can
also include the UDP MSS option to indicate the largest single UDP segment
(unfragmented datagram or single segment) that it can receive (this may be
further limited by path MTU, of course). This can be done in a
backward-compatible way by transmitting the request as an ordinary
(unfragmented) UDP packet with all options in the trailer. At present the
draft does not include an option to indicate how many fragments can be
reassembled; perhaps it should.

Whether or not every implementation of UDP options should be required to
reassemble fragments at all is still under debate, but even I end up in the
rough on that point, the fact remains that many stacks won't support UDP
options at all. In the absence either of explicit information to the
contrary, either via negotiation (as in the example sketched above) or by
manual configuration, a sender should not assume that the remote end offers
any support for UDP options and should have the capability to fall back on
UDP without options.

Mike Heard