Re: [tsvwg] Comments on recent UDP options work

[Tom Herbert <[e-mail]>]

On Sun, Nov 25, 2018 at 8:37 AM Joe Touch <[e-mail]> 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.
>
> >> 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”….

But, the protocol does need to be correct. In the case of LITE, the
draft allows that receivers may interpret the same packet from a
sender in two very different ways. One receiver may see a UDP packet
with non-zero payload, but the other way is for an application to
receive a zero length UDP message. I don't know if this can be
considered correct. It's implicit in the the draft that receiving a
well formed zero length UDP message is innocuous to applications, but
I don't believe this has been proven. There should be more discussion
and supporting evidence for this.

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