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

[Kaippallimalil John <[e-mail]>]

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.




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