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

["C. M. Heard" <[e-mail]>]

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.

Mike Heard