Re: [tsvwg] Comments on recent UDP options work

[Joe Touch <[e-mail]>]

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

>> 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 deisgn may be wrong.

The design is not intended to overcome the arbitrary behavior of all intermediate devices. Again, “more robust” doesn’t mean “right”….

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

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

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.

Joe