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

[Alex Burr <[e-mail]>]

Hi Sebastian,

see inline [AB]


------- Original Message -------
On Saturday, 28 October 2023 at 23:15, Sebastian Moeller <[e-mail]> wrote:


>
>
> Hi Alex,
>
>
> > On Oct 28, 2023, at 23:35, Alex Burr [e-mail] wrote:
> >
> > Hi all,
> >
> > What if, instead of implementing network options
> > piecemeal as UDP options, there were instead defined a UDP option which
> > just encapsulates the whole HBH extension header, to get it past nodes that
> > would drop it?
>
>
> [SM] If I understand RFC8200 correctly the actual HBH header is only two octets anyway... and both the HBH and the default UDP option TLV format uses 1 byte each for "T" and "L" so that could be made to work...
>
> > This would have the following advantages:
> >
> > - rather than taking away energy from getting HBH options to work, it would
> > add to it.
>
>
> [SM] Not sure I understand that, if (ab)using UDP options will actually work, I am sure people would likely ignore the 2 additional byte saving switching to IPv6 HBH would gain... The only thing that gets HBH working is offering network operators something that is worth doing the work, and offering them a way to avoid that work like UDP options (assuming they work well enough) would IMHO not contribute making HBH options any more likely to pass through the internet un-dropped, no?


[AB] My theory as to why this would be an incentive: as I understand it currently
UDP options would need to be processed via more-expensive fully programmable kit.
Whereas 'configurable' kit, or kit that can only process only the first N bytes of a packet
is likely to be cheaper and/or more scalable. At the scale of a network operator, cost
is always a factor. So, once they have got it working with expensive kit, they will
want to get it working with cheaper kit, which means enabling HBH options.
But it's true that this is a hypothesis. The scenario you describe could play out instead.
Perhaps others with familiarity with the incentives of network operators will comment.


> > NB I don't specifically have an opinion on whether the media header should be an HBH
> > option. But if it should be, maybe this is a useful way of resolving the difficulty of
> > avoiding packets containing it being dropped.
>
>
> [SM] I would leverage the fact that it seems t be network operators that want stuff like MED so it could be possible to strike a deal that ends up with interested operators enabling HBH passage in their part of the internet... Sure there needs to be something in it for them, but if I understand the justification of e.g. the MED option we might have the required "carrot" at hand.


This may well be the best route to getting HBH options enabled. However, if it turns out that the 
consensus is that UDP options need to be used to enable faster deployment, then encapsulating HBH 
options seems preferable to just diverging.

Alex