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

[Kaippallimalil John <[e-mail]>]

Hi Tom, Mike,

I did go through the architecture sections (but not the full draft) and I’m familiar with the FAST ticket concept from previous versions of the draft (when Tom presented it several years ago).
And we did consider IPv6 HBH options (and various others – application layer tunnels, GTP-U (a 3GPP protocol), etc.) when writing the media-hdr-wireless-extn draft.

MED UDP options still seem to be the more reasonable  approach for the wireless media problem:

  1.  Media metadata crosses at least 2 domains – application provider network (inserts metadata) and wireless provider network (inspection, metadata delivered to endpoint in wireless network) .

UDP header extension is not likely to be dropped on path, while there is concern that IP HBH options will be, especially with these multidomain scenarios.

  1.  The metadata should be supported in IPv6 and IPv4 for the 3GPP use case.
IPv6 HBH will be quite a challenge to convince people. IPv4 will be even harder considering that the IETF is not too keen on handling new work for IPv4.
  2.  Some of the UDP MED option data is dynamic by nature due to the variability during content capture, sending rate changes, variable encoding, packetizing.
Implementing dynamic data using FAST/tickets would mean that tickets would have to be generated per packet in many cases.

BR,
John


From: tsvwg <[e-mail]> On Behalf Of Tom Herbert
Sent: Monday, August 7, 2023 7:11 AM
To: C. M. Heard <[e-mail]>
Cc: tsvwg <[e-mail]>
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-06.txt


On Mon, Aug 7, 2023, 12:08 AM C. M. Heard <[e-mail]<mailto:[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