Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[Joseph Touch <[e-mail]>]

> On Jun 13, 2021, at 12:28 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Fri, Jun 11, 2021 at 4:43 AM  Mohamed Boucadair wrote:
> Hi Joe, all,
> 
> Regarding the FRAG option, I'm not sure there was a consensus this is a MUST to implement/support. 
> 
> Unless I'm mistaken, I didn't even remember a conclusion for one of the main threads when FRAG and other "design assumptions" were discussed back in 07/2019.
> 
> As indicated in https://mailarchive.ietf.org/arch/msg/tsvwg/rfh1wBYzlIHIzeVQruT5BVd8BRA/ <https://mailarchive.ietf.org/arch/msg/tsvwg/rfh1wBYzlIHIzeVQruT5BVd8BRA/>, I do still think that we would better focus on key foundations and build over them. FRAG can be defined properly in a separate document. It can be tagged as unsafe but it does not need to be mandatory to implement. 
> 
>  
> Indeed, as far as I can tell, that discussion never did achieve consensus on the matter of whether fragmentation is a requirement.

Agreed, but that’s because support for fragmentation was a design goal from the start (e.g., to support DNSSEC that spans multiple UDP packets).

If we remove that requirement, what is the driving use case?

I agree with you that we need all UDP-option-capable variants to recognize FRAG, which means single-frag as a minimum.

However, if we do not require reassembly beyond that, we’ll likely be stuck. To drive use of this option for the only currently known use case, we need to support reassembly of at least 2 fragments.

That effectively limits us to between 1K and 3K.

We already know that a reasonable upper bound would be 9K anyway. That argues for between 6 and 18 segments.

However, I think we could knock this down to either 1500B - the reassembly minimum for IPv6 anyway.

That would suggest:
	- RMSS should never be below 1500B
	- reassembly MUST support as many fragments as that requires, e.g., either 2 (in IPv6 stacks) or 4 (IPv4 stacks - supporting the IPv4 and some UDP headers).

Requiring support for reassembling 4 doesn’t seem like a huge burden. Any endpoint that can’t do that, IMO, should not be supporting UDP options.

And no, I do not think we should rely on RMSS to indicate that this is available. Note that a receiver would have to indicate RMSS and know the path MTU to know how many fragments it would actually take; we don’t require path MTU discovery for UDP options, so that’s an undue burden. Besides again injecting state into UDP.

Joe