Re: [tsvwg] Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03

[Tom Herbert <[e-mail]>]

On Sat, Oct 28, 2023 at 10:53 AM C. M. Heard <[e-mail]> wrote:
>
> On Sat, Oct 28, 2023 at 9:50 AM Tom Herbert wrote:
> > On Sat, Oct 28, 2023 at 9:18 AM Sebastian Moeller wrote:
> > > Unless the respective layer's data is encrypted, intermediate nodes
> > > obviously can look into packets at every level they desire, and
> > > since they do not need to ask for permission there is really nothing
> > > stopping them... Given that fact, it seems academic to claim there
> > > is a practical difference in usability of UDP options and IPv6 HBH.
> >
> > I think there are material differences. UDP Options only work with
> > UDP, UDP options are in protocol trailers which would be problematic
> > to support in router hardware data path, and there's no distinction
> > between transport layer options and network layer options (i.e. last
> > thing we want is for some router to burn cycles parsing and skip over
> > a bunch of transport layer options to find the network layer options
> > they're interested in).
>
> I'd like to answer these points.
>
> 1. UDP Options only work with UDP.
>
> Correct.
>
> On the other hand, IPv6 HbH options work only with IPv6 and by all
> accounts suffer from an egregious drop rate in today's open Internet.
> There is some empirical evidence that the Internet is much more
> tolerant of UDP options; however, the measurements didn't test what
> happens when UDP Length == 8 (which would be required by the potential
> fixes in 2 and 3 below).
>
> 2. UDP options are in protocol trailers which would be problematic to
> support in a router's [or any middlebox's] hardware data path.
>
> Correct but potentially fixable: draft-ietf-tsvwg-udp-options defines
> per-fragment options, which do not have that disadvantage. Moreover,
> any host to network signalling in a packet that uses UDP fragmentation
> would necessarily have to put such signals in the per-fragment options
> area, not in the trailer (which cannot in principle be located until
> the packet is reassembled). There is some waste of space by using an
> atomic FRAG option, but that could in principle be mitigated by
> introducing a third format that omits the Identification, Frag.
> Offset, and Reass DgOpt Start fields (this would be useful in any
> situation where an endpoint wants to hide one or more UNSAFE options).
>
> 3. There's no distinction between transport layer options and network
> layer options.
>
> Again, correct but potentially fixable: add a proviso to the spec that
> any option intended for the endpoint use  only SHOULD be in the trailer.
>
> My intent here is not to advocate for the changes, but rather to point
> out that they are likely to be NECESSARY to turn UDP options into a
> suitable carrier for host-to-network signalling. I brought these
> points up before, but I didn't see them addressed in
> draft-kaippallimalil-tsvwg-media-hdr-wireless-03.
>
> But the big elephant in the room is that draft-ietf-tsvwg-udp-options
> exclusively defines TRANSPORT options designed to be consumed by
> endpoints, not NETWORK options designed to be inspected by routers or
> other middleboxes. If draft-kaippallimalil-tsvwg-media-hdr-wireless-03
> is to be adopted as a basis for future work, then in my opinion one of
> the adoption questions should be whether the WG would be willing to
> make this change of direction to draft-ietf-tsvwg-udp-options.
>
> The rather lengthy previous discussion pretty much left this last point
> up in the air, but I came away with the conclusion that trying to fix
> IPv6 HbH options is probably the better alternative in the long run.

Hi Mike,

That has been my conclusion as well. But even so, I believe it was
important to give the idea of conveying network layer options in UDP
Options a fair hearing. I believe those discussions have occured on
the list. It would be good if we can establish consensus that UDP
Options aren't the right solution to carry network layer options.

Tom

>
> Mike Heard