Re: [tsvwg] Comments on recent UDP options work

[Gorry Fairhurst <[e-mail]>]

On 25/11/2018, 16:36, Joe Touch wrote:
>
>> On Nov 25, 2018, at 8:28 AM, Gorry Fairhurst<[e-mail]>  wrote:
>>
>> 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?
> It depends on whether it’s FRAG+LITE or FRAG only; the former puts it in the option area,
> the latter leaves it in the UDP payload.
The latter would really concern me.
>>> 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.
> I don’t think that’s “OK” - i.e., that should NEVER be a legitimate function of any intermediate device. However, being robust to that behavior might be a consideration...
>
>> If that could result in an incomplete or incorrect datagram payload then I think the design may be wrong.
> The design is not intended to overcome the arbitrary behavior of all intermediate devices. Again, “more robust” doesn’t mean “right”….
>
Who would implement something that currently does not work on many paths?
>>>> 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.
> We can leave that to the user, with the appropriate caveats.
We could - but there again I do not understand yet why it would be 
helpful to require conformant stacks to implement something that mostly 
isn't deployable at the moment.
>>> 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.
> FRAG is part of the core of UDP options; if an endpoint supports any of that core, it can be assumed to support the entire core.
Personally, I disagree with this position.
> Support for fragments at the IP layer does interfere with the profit and effort model of vendors and operators but what we’re seeing “in other WGs” are the shopping around of ideas until they find a home. Let’s not confuse that with a groundswell.
There are memory and processing implications of needing to hold onto 
fragments waiting for reassembly and what to do with rogue packets 
containing fragments that you don't know whether they should be 
reassembled.

My comment conerned doubts that this functionality should be provided by 
UDP-Optiona and a suggestion it may be better provided by an application 
(perhaps e.g. a tunnel protocol endpoint?). I don't see how adding this 
as a UDP-Option function helps eliminate complexity or to manage 
fragments better.
> Joe
Gorry