Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-06.txt

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

On Fri, Aug 4, 2023 at 12:02 PM Tom Herbert wrote:
> At IETF117, there were a number of proposals to do host network
> signaling, and they are using various protocol mechanisms to
> annotate packets with the signals. I think this indicates a growing
> interest in finding a solution.
>
> Signaling requires a carrier and content. This draft focuses on the
> carrier and proposes a Hop-by-Hop option to be the common carrier of
> per packet host to network signaling. The typical concern raised with
> Hop-by-Hop options is that they are undeployable. The draft surveys
> other proposed methods and suggests mitigations for issues with
> Hop-by-Hop options. Despite the issues, the conclusion of this draft
> is that Hop-by-Hop options is the best option for an extensible,
> generic, transport stateless, and standardizable method for host to
> network signaling compared to any of the known alternatives.

I read the draft with interest, and I see that this version cites
both draft-kaippallimalil-tsvwg-media-hdr-wireless and
draft-reddy-tsvwg-explcit-signal, which were presented at IETF 117
and propose to use UDP options for network signalling.

Were it not for the well-known deployability issues associated with
Hop-by-Hop options in the general Internet, I would consider it the
method of choice, and for certain limited domain scenarios (like that
envisaged by draft-kaippallimalil-tsvwg-media-hdr-wireless in the short
term) it might well be viable today. But I think it's fair to ask
when -- if ever -- the ongoing efforts to fix the Hop-by-Hop option
deployability problems in the general Internet will bear fruit. That's
very much an open question. Perhaps, then, it's not unreasonable for
proponents of host-to-network signaling to look for methods that have
a less uncertain path to deployability.

Regarding the solution using UDP options: I do not disagree with the
draft's premise that asking network devices  to look for signals in
options that reside in a trailer and are (at least potentially)
intermixed with transport options is asking for a very heavy lift.
However, it is possible to get around that, if the WG wants to pursue
this use of UDP options, and that is to co-opt per-fragment options
for network signalling. I proposed that in

https://mailarchive.ietf.org/arch/msg/tsvwg/SpcVd6EB1Zi6FUhhyn2-o6nxuq4/

This isn't within the goals the UDP options specification set out to
achieve -- its title, after all, is "Transport Options for UDP" -- and
it does go against the grain by adding network signaling to a transport
protocol. On the other hand, some folks think we crossed that bridge a
long time ago; consider this 2015 quote from Brian Trammell on the SPUD
mailing list (that was the precursor to the PLUS effort):

On Fri, Jul 10, 2015 at 3:44 AM, Brian Trammell wrote:
> Coming back to the layering question:
>
> It does seem to me that what we're (the we that wrote the two
> documents starting this thread) trying to do is explicitly reinforce
> the boundary between the network layer and the transport layer, where
> this is defined as "things the path needs to see versus things only
> endpoints need to see". Asking nicely (i.e., publishing RFCs) did not
> work in this case: the transport ports are de facto part of the
> network layer now, and short of blowing the Internet up and starting
> over I can't see a way to get them back. So now we are left with
> enforcing the boundary cryptographically, leaving some space in the
> "new network layer" (in this case, IP + UDP (for ports) + SPUD) for
> those things now commonly done within the network.

I think it's incumbent on the advocates of the use of UDP options for
host to network signaling to speak up if they want to see the WG make
this change of direction.

Thanks,

Mike Heard