Re: [tsvwg] Comments on recent UDP options work

[Tom Herbert <[e-mail]>]

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