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

[Tom Herbert <[e-mail]>]

On Tue, Oct 31, 2023 at 7:20 AM Kaippallimalil John
<[e-mail]> wrote:
>
> Hi,
>
> Thanks for this feedback. Much of it has been factored into the proposed revision to use MED in outer packet UDP option for now.
>
> Further responses tagged with [JK]:
>
> > 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.
>
>         [JK] The authors discussed this and related notes from Alex with the various trade-offs of each of the transports.
> For this draft, MED in outer UDP packet option from server (Provider-A) to wireless node (Provider-B) is sufficient.
> The only potential drawback may be that the option at the end of the packet may affect performance, or may not depending on the implementation.

Hi John,

Is there significance to referring to the "outer UDP packet" instead
of just the "UDP packet"? Are you assuming a UDP tunnel is always
used?

Since this makes the information end-to-end, how does it interact with
or complement the data in a UDP transport layer protocol such as QUIC?
For example, would MED data in a UDP Option be useful with RTP/QUIC? I
would also point out that QUIC endeavours to encrypt the end-to-end
information, do you believe that MED data in a UDP Option would be
similarly encrypted (that would ensure that the network won't try to
read or modify the data)?

Tom

>
>
>
>
> > -----Original Message-----
> > From: C. M. Heard <[e-mail]>
> > Sent: Saturday, October 28, 2023 12:53 PM
> > To: Kaippallimalil John <[e-mail]>; Sri Gundavelli
> > <[e-mail]>; Spencer Dawkins at IETF
> > <[e-mail]>
> > Cc: Tom Herbert <[e-mail]>; Sebastian Moeller
> > <[e-mail]>; Joe Touch <[e-mail]>; TSVWG
> > <[e-mail]>
> > Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for adoption
> > of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
> >
> > 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