Re: [tsvwg] Comments on recent UDP options work

[Joe Touch <[e-mail]>]

> On Nov 25, 2018, at 10:34 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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.

The latter should not occur unless the receiver confirms anyway.

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

So no IPv6, got it.

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

But the same was true for the original UDP Lite too. We deploy things to change the Internet.

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

It’s there for a reason - the primary motivating case for the options in the first place. 

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

Yes, and there are memory and processing implications of processing UDP at all, so let’s ditch that. And TCP. And SCTP.

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

Everything CAN be implemented st the app layer; your argument basically deprecates all transport protocols. I disagree with that. UDP needs these options - esp. fragmentation support - exactly because we don’t want to reinvent it repeatedly at the app layer and it’s useful to provide it at the transport.

Anyone who doesn’t WANT to use it is free to not turn it on, of course.

Joe