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

[Tom Herbert <[e-mail]>]

On Mon, Aug 7, 2023, 12:08 AM C. M. Heard <[e-mail]> wrote:

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

Mike,

>
Thanks for the comments!

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

I believe they are bearing fruit. There are some fantastic efforts underway
being discussed is v6ops to fix them (more generally to fix problems
affecting deployability of IPv6).

I'll also point out that UDP Options has no real world, Internet scale
deployment yet. Maybe their more deployable in the real, maybe they're
not... we don't really know at this point (there's an old saying here that
may be apropos: "the grass is always greener on the other side")


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

One concern I have is that use of the fragment approach requires end hosts
to change. That's a heavy lift, especially if they're changing just for
purposes of host to network signaling. For example, QUIC doesn't need
transport Layer options, but could benefit from host to network signaling
for network QoS

To contrast, Hop-by-Hop Options are implemented by all conformant host
stacks. The perceived issues are in some network paths and network device
implementation s, not in the protocol nor host stacks.

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

Right, but there was push back on SPUD exactly because it breaks the end to
end model, and I don't believe there is consensus that UDP is or should be
the "new network layer". I'm not even sure what that would mean. For
instance, it's still unclear how SPUD or UDP Options could work with TCP.
However, TCP works perfectly well with IPv4, IPv6, and IPv6 extension
headers which are established network layer protocols.

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

Agreed.

Tom


> Thanks,
>
> Mike Heard
>