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

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

On Sun, Jun 20, 2021 at 12:36 PM Joseph Touch  wrote:

> FWIW, on this point:
>
> On Jun 20, 2021, at 11:28 AM, C. M. Heard  wrote:
>
> 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.
>
>
> Agreed, but that doesn’t help the client send a bigger request, which
> should also be possible, up to the minimums we specify.
>

But this doesn't help unless the client knows a priori that the server
accepts UDP options in general and fragments in particular. AFAICT The only
way to know a priori is via explicit configuration, in which case the
relevant limits (MRSS, and possibly number of fragments) can be configured
too.


> I’m wondering if we can say:
>
> - MUST support reassembly of at least (somewhere between 3 and 10),
> unless considered a constrained instance, which MUST support at least 2
>
> This allows for minimal IoT-style instances but doesn’t open the door too
> widely.
>

I remain unconvinced that it would be good for adoption of the spec to
require anything beyond the ability to accept a datagram consisting of a
single UDP fragment (one that is both initial and terminal). Based on the
implementation experience that I have had, the difficulty is NOT how many
fragments one must reassemble but rather the requirement to implement
stateful reassembly machinery in an otherwise stateless protocol. Despite
its age, RFC 815 remains still a good read and IMO its main lesson -- that
the maximum reassembled size is what needs to be bounded, not the number of
fragments -- remains relevant.

Thanks,

Mike Heard