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

[Kaippallimalil John <[e-mail]>]

A quick response on a couple of points:

>>  MED UDP options still seem to be the more reasonable  approach for the wireless media problem:
>  Maybe, but that would be a point solution as opposed to solving that more general problem.

[John] The procedure itself is generally applicable for all use cases spanning multiple provider networks that want to convey QoS handling optimization for UDP flows.
The current data (MED with Profile = 1) is specific to the wireless media handling for high throughput/low latency, but that is just one out of 2^5 Profile options in MED.
So for example, another use cases for satellite networks could use a different set of parameters in, e.g., MED Profile =2, but use the same procedures, constraints in this draft.

>>  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.
> It's not a problem. The same data carried in UDP can be carried in a Hop-by-Hop Option.

[John]  The IP HBH options with FAST ticket can apply to several IP flows that carry a FAST ticket and its "stateful".
My view is that it’s a great proposal for requesting/granting a "service/ policy" in the network.
However, the procedures and data in media handling draft is for QoS handling optimizations, applying within a single flow, and is basically "stateless".

BR,
John


-----Original Message-----
From: Tom Herbert <[e-mail]> 
Sent: Monday, August 7, 2023 11:19 PM
To: Kaippallimalil John <[e-mail]>
Cc: C. M. Heard <[e-mail]>; tsvwg <[e-mail]>
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-06.txt

On Mon, Aug 7, 2023 at 8:06 PM Kaippallimalil John <[e-mail]> wrote:
>
> 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:

Maybe, but that would be a point solution as opposed to solving that more general problem.

>
> 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.
>
Have you run UDP Options and IP HBH options to confirm this and get the data?

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

Yes, that is an issue. But it's also an issue that UDP Options can only work with UDP and not TCP or any other transport. IMO, it's equally problematic if IETF has a host to network signaling that isn't generic and only works one transport protocol.

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

It's not a problem. The same data carried in UDP can be carried in a Hop-by-Hop Option.

Can you comment on the requirements and pragmatics of network devices to process UDP Options. As I mentioned, high performance network devices process protocol _headers_, it's going to be difficult to teach them to process trailers efficiently. If we use fragment options to force the UDP Options into headers then the problem becomes that we have to change all end hosts to support that. There's also potential problems mixing transport and network options, and in particular this could affect security and DoS considerations.

One important thing to note. UDP Options currently is designed to only carry transport layer options. A while back, I did propose that the surplus area could have a header that allows a header chain to support other protocols and more that one protocol in the surplus space, this would allow transport options, network options as discrete headers-- that would have made this much easier. It may be possible to put network options in UDP Options, however if changes are required (like allowing a protocol chain in the surplus space) then I suggest those need to be proposed and defined quickly-- once UDP Options are published and deployed it's really not going to be possible to retroactively change how the surplus space is used!

Thanks,
Tom


>
>
>
> 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]> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> archive.ietf.org%2Farch%2Fmsg%2Ftsvwg%2FSpcVd6EB1Zi6FUhhyn2-o6nxuq4%2F
> &data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C1cdff968105e4ed8
> a78108db97c6abb4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63827065
> 1785709699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Q9Lc97f9uUfw6RyD
> NqAcvf6RqXMafTCbf8gCkb%2FjJLg%3D&reserved=0
>
>
>
> 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