Re: [tsvwg] Comments on recent UDP options work

[Joe Touch <[e-mail]>]

UDP options do bring soft state into UDP, for at least some types of options.

See Section 10.

Joe

> On Nov 25, 2018, at 10:42 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Nov 25, 2018 at 10:11 AM C. M. Heard <[e-mail]> wrote:
>> 
>> On Sun, Nov 25, 2018 at 9:50 AM Tom Herbert wrote:
>>>> Do you mean LITE, or FRAG? That is definitely true of FRAG
>>>> without LITE (and IMHO a good reason not to use FRAG
>>>> without LITE).
>>>> 
>>> LITE+FRAG is the obvious case that leads to ambiguity on how a
>>> reciever processes a packet.
>> 
>> OK, you are fixated on the empty datagram case. A legacy receiver sees
>> a sequence of empty datagrams; a receiver that implements LITE+FRAG
>> will see a single reassembled datagram. Agreed that it's an open
>> question whether the sequence of empty datagrams is harmless. If
>> it is not, it is necessary to ensure that LITE+FRAG is not sent without
>> prior negotiation or out-of-band arrangement. Oh, wait, the spec already
>> says to do that.
>> 
> The draft states:
> 
> "the LITE UDP option can safely provide that service only between
> endpoints that negotiate that capability in advance".
> 
> That is not a normative requirement. Maybe this should read "Use of
> UDP LITE option MUST be negotiated between endpoints before use". But
> if negotiation is required and authoritative, then there should be no
> legacy receivers of such negotiated options. However, a mechanism for
> negotiation of UDP options has yet to be defined, it will be
> interesting to see if that can be done in a robust way without bring
> state into UDP.
> 
> Tom
> 
>> FRAG without LITE can of course create an ambiguity that is
>> demonstrably harmful. A legacy receiver sees a sequence of
>> non-empty datagrams that are acually fragments. Easy to come
>> up with scenarios where those apparent datagrams will be
>> misinterpreted. So be sure to pick on that case too; indeed,
>> emphasize it; but again, if the spec is followed, naked fragments
>> won't be sent to an unsuspecting receiver, either.
>> 
>> --cmh