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

[Sebastian Moeller <[e-mail]>]

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?


> - The spec for this 'HBH header encapsulation  option' could recommend that
> network nodes which processes HBH options inside  it, SHOULD also process the 
> same options if found in an unencapsulated HBH extension header. In this way,
> those nodes would be ready if  HBH options end up being transmissible over the
> internet.

	[SM] Any SHOULD that is not exercised and/or enforced really is not likely to result in robust and reliable capabilities, "use it or loose it"...


> 
> - It would consume only one UDP option type, instead of one per function. All
> 'network options' would be enumerated in one place, in the HBH options list.

	[SM] Yeah, 255 network options should be enough (what was that argument for 640KB memory again ;) )


> - If the HBH header sees greater  use in this way, it would provide an 
> argument for enabling  it to pass unencapsulated.

	[SM] Why? IN that case we would have a solution that works for both IPv4 and IPv6 and that does not require networks to change...


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

Sebastian

> 
> Alex
>