Re: [tsvwg] Comments on recent UDP options work

[Gorry Fairhurst <[e-mail]>]

On 25/11/2018, 16:16, Joe Touch wrote:
> One question (and clarification):
>
>> On Nov 25, 2018, at 8:03 AM, C. M. Heard <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>  1. In the thread on "UDP Options Implementation Update," Tom Jones
>>     said "The current spec puts data in the UDP payload, which does
>>     not seem correct.”
>>
> I didn’t understand that either.
Where is the data portion of the fragment carried?
> No variant of UDP options adds anything to the *UDP* payload; they all 
> use space in the *IP* payload that extends beyond that of the UDP 
> payload. That includes LITE.
If it is always OK to return a UDP Options packet that has had the 
options area stripped (without the receiver knowing) - then I think the 
operation is correct. If that could result in an incomplete or incorrect 
datagram payload then I think the deisgn may be wrong.
>>
>>  1. If I understand this comment correctly, I think the issue is
>>     addressed by using it in combination with LITE. If in the end we
>>     don't retain LITE, it would still be possible to re-specify the
>>     FRAG option to get the same effect (i.e., make all data in the
>>     fragment part of the option); in this case, we would need a
>>     separate option to signal that FRAG is understood, in order to
>>     support (3) above.
>>
> It my be possible that FRAG is not useful without LITE, but remember 
> that LITE may be useful without FRAG.
>
I think the point I saw was that LITE is complicated to implement, and 
also it is quite unlikely to work on many paths, because it is not 
possible to have LITE semantics and a CCO.
> As to determining which options are understood, we currently infer 
> that from the options received (i.e., if you send an option, you 
> indicate you can receive it too). The receipt of ANY of the core 
> options implies support for all of them.
I really do not think this should include FRAG. Support for fragments at 
the IP-layer is very much in doubt in other WGs, and the requirement 
that an endpoint "must" support FRAG, if a sender uses any options does 
seem worrying.
>
> Joe
Gorry