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

[Kaippallimalil John <[e-mail]>]

Hi,

Split the discussion into 2 subsets - one tagged: metadata; and a second tagged: transport in the subject header.

There was a lot of discussion on the transport, and very useful to have this kind of detailed and informative feedback  - thanks, Tom, Joe, Sebastian, Mike, and Alex.
The authors discussed on transport needed for MED and decided to keep it simple by supporting only MED in outer packet UDP option  in section 5.

-  support UDP option MED in UDP outer  packet header (update section 5 - Metadata Transport in draft accordingly)
   Covers IPv6, IPv4, UDP and non-UDP media payloads. May require programmable processors (that’s not a show stopper though).

- Add an Appendix C to describe the NETWORK options -
   i.e., IPv6 HBH to support metadata handling in the draft. i.e., server in Provider-A produces packet with IPv6 HBH MED; sends to wireless node and endpoint in Provider-B.
       Packet drops yet to be seen, but significant improvements in RFC 8200, draft-ietf-6man-hbh-processing, draft-ietf-6man-eh-limits.
   Same mechanics for UDP NETWORK option: however, the question here is whether there is interest in the group extend/define this in udp-options.


Detailed responses tagged with [JK]:

> Can you clarify what "inserted" means in this context? (the word has
> confusingly been used in different contexts). For instance, there are three
> uses I know of:
> 
> 1) A packet was created by a hosts with the data ("inserted" probably isn't
> the best term for this)
> 2) A packet is encapsulated inflight and the data is attached to the outer
> headers
> 3) The data is inserted into a packet while it's inflight with (no
> encapsulation)
> 
> #1 and #2 are generally acceptable (technically, in both cases a host is
> creating the packets so HBH options or UDP options can be set in the packet
> safely). #3 is a bit more controversial, but there have been proposals for this
> like inserting a segment routing header in packets in flight.

	[JK] Its either 1) or 2) based on encapsulation or NETWORK mode. We're taking out the option with 3) as it is problematic.
The authors' preference is to keep it simple with just MED in outer UDP header that is encapsulated by the server (since only the server knows what put in MED). So #1.

> Please also clarify the processing of the wireless node.
> 
> 1) Is the wireless always the destination endpoint of UDP encapsulation? If
> so then it would be appropriate for it to process UDP options in the
> encapsulation since it's the destination of the encapsulated packet
> 2) Does the wireless node is inspect the UDP options in flight as an
> anonymous router in the path that forwards packets and isn't the destination
> of the packet? In that case, I think using UDP Options is problematic (or
> putting the information into the UDP payload like SPUD
> proposed)
> 
> > The data in MED is sent per packet and
> 
> FAST allows data to be changed on a per packet basis for flow. If the
> modifiable variant of the FAST HBH option is used then intermediate nodes
> can change the data inflight.
> 
> > Every router on path is going to read/process the IPv6 HBH option. This is
> also not what is intended.
> 
> RFC8200 has relaxed the requirements of RFC2460 so that routers may or
> may not process Hop-by-Hop OPtions. draft-ietf-6man-hbh-processing and
> draft-ietf-6man-eh-limits make further clarifications to make HBH practical.
> 
> > Only the wireless router acting on behalf on the client, with explicit
> provisioning (session setup, policy in figure) needs to read.
> 
> That's the same expectation we have in FAST. Only an ingress router into a
> network is expected to process a ticket in HBH options.

	[JK] "Processing" at the wireless node meant to convey that the wireless node reads the metadata. It is used it for further (QoS) classification which is beyond the scope of the draft.
The metadata should only be sent one way (forward path). It must not be reflected.
Will change the "inserts" and "processing" and change the text to:
"Service to send metadata is triggered following creation of a media session between host in Provider-A (server) and Provider-B (endpoint). 
Server in Provider-B produces packet with MED in outer UDP header and sends to wireless node in Provider-A. Wireless node reads MED and uses it for MDU classification."
-- Note the producer of the metadata is in Provider-A (server) and the consumer is  Provider-B (wireless node), i.e., the egress router, not ingress.

> Just like UDP Options, FAST and IPv6 HBH are just carriers of information.
> There's no semantics enforced on the content. So any data that is carried in
> UDP Options could just as easily be in HBH options.
> The difference is about who is permitted to process the information:
> UDP Options can only be processed by the destination, HBH options can be
> processed by any, all, one, or no nodes in the path.

	[JK] Agree that transport should be a carrier of information.
I would note that in FAST, host2net, " ...Provider A may provide services and service agreements for users in its network including User 1; ...." (section 2.1)
Whereas with MED,   "Server in Provider-B produces packet with MED to be consumed by wireless node in Provider-A.
(its still host to network, but not the same provider)

> > The key aspect in the draft is the metadata (MED) and how it should be
> processed on path.
> 
> Yes, I like those aspects, and the sentiment that a draft like this should focus
> on the semantics and processing of the data aligns with my view. This draft  is
> a good use case of host to network signaling, but there are others like draft-
> reddy-tsvwg-explcit-signal (which also proposes to use UDP options as the
> carrier) and draft-ravi-ippm-csig (which proposes using L2 to carry the signal).
> With the potential benefits of collaboration between applications or hosts
> and the network, I believe we are going to see even more proposals. In host
> to network signaling, there are two parts: the carrier of the signal, and the
> content of the signal. IMO, if we define a common generic and extensible
> carrier for host to network signaling, then the various proposals in the area
> could focus on the semantics and processing of the content and not worry so
> much about the carrier protocol.

	[JK] Agree in general.
I actually like the host2net (and net2host) service models. 
There are some current discussions popping up in 3GPP about measurements, encrypted packets like QUIC, etc.
The use case and model is a bit different from MED /the discussion here, I will reach out to you separately.




> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Saturday, October 28, 2023 6:25 PM
> To: C. M. Heard <[e-mail]>
> Cc: Sebastian Moeller <[e-mail]>; Alex Burr
> <[e-mail]>; Kaippallimalil John
> <[e-mail]>; Sri Gundavelli
> <[e-mail]>; Spencer Dawkins at IETF
> <[e-mail]>; Joe Touch <[e-mail]>;
> TSVWG <[e-mail]>
> Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for adoption
> of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
> 
> On Sat, Oct 28, 2023 at 3:57 PM C. M. Heard <[e-mail]> wrote:
> >
> > On Sat, Oct 28, 2023 at 3:15 PM Sebastian Moeller wrote:
> >>
> >> I would leverage the fact that it seems to 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.
> >
> >
> > If it's true that network operators are mostly the ones that want stuff like
> MED, that's a very strong argument for saying to them "clean up your house
> and make IPv6 HbH work in your domain."
> 
> Mike,
> 
> I think this is the key! If network operators want the nice features like MED,
> or congestion signaling, or fine grained differentiated services (especially if
> they can monetize them) then they'll be motivated to support HBH options.
> This also probably means that HBH options are only ever going to be useful in
> limited domains however large they may be.
> 
> Tom
> 
> >
> > Mike Heard