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

[Joseph Touch <[e-mail]>]

Notes below...

> On Jun 26, 2021, at 1:32 PM, C. M. Heard <[e-mail]> wrote:
> 
> 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.

The only way to *know*, yes. But we don’t want to prevent an endpoint from sending messages ‘opportunistically’, i.e., in the hopes that the options are supported. UDP is not a stateful protocol, so we do not want to require a stateful handshake before using options that could be ignored. 

That’s another reason why I think it is important to allow at least some minimal fragmentation and reassembly prior to getting ’soft’ information that allows it to be larger.

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

Reassembly isn’t anywhere near the same as handshake state. It’s local to each side.

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

Although I agree that size is the issue, the number of fragments can and should also be bounded as well. RFC 815 was useful at the time, but even the smallest IOT devices have capabilities far in excess of what was available in desktop devices of 1982. Just as IPv6 requires 1280B packets with 1500B reassembled IP, it should not be too much to assume UDP options can support something up in that range.

Joe