[tsvwg] (metadata) 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.

Thanks, Sebastian, for the feedback on the metadata which is a big part of the draft.
From the comments so far, metadata (chapters 1 - 4)  need only a few updates.
Transport (chapter 5, 6) needs more revision based on the comments (see responses tagged: transport).

Regarding sending metadata to the endpoint:
> > The figure UC2 MED in outer tunnel – in this case, MED is sent in an outer
> tunnel between the server (UDP source) and wireless node (UDP
> destination) only.
> 
> 	[SM] This however I am not convinced I want to see. IMHO the MED
> option should to be visible end to end, and using that only for an outer
> tunnel that is stripped away will not really retain that visibility*. However i
> accept that I look at this from an end-user perspective only, I am sure there
> are alternative perspectives from the network operator side...

	[JK] The rationale for sending metadata to the user/endpoint was about collecting the data and sending in the feedback path (i.e., RTCP).
However, it is also possible for the user/endpoint to simply send raw packet information about what was received /dropped/delayed back to the server.
And the server would need to use this data, factor in drops/delays of an MDU in adjusting the sending rate, etc.
Given that UDP NETWORK options need further discussions, for the short term it looks like MED in outer packet UDP option may be a good option.
(more in the other responses tagged: transport).

BR,
John  


> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: Saturday, October 28, 2023 4:43 AM
> To: Kaippallimalil John <[e-mail]>
> Cc: [e-mail]; Tom Herbert
> <tom=[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
> 
> Hi John,
> 
> first thank you very much for reconsidering the relative sizes of the different
> fields in the MED packet. Sad that instead of reaching size 16 that ended up
> at 18, but I think even is better than odd here and using the NTP time format
> is IMHO worth that single byte increase all by itself.
> 
> 
> > On Oct 28, 2023, at 01:41, Kaippallimalil John
> <[e-mail]> wrote:
> >
> > Hi,
> >
> > And I forgot to add another important update in the draft.
> > see slide 4 in
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fmeeting%2F118%2Fmaterials%2Fslides-118-tsvwg-
> sessa-
> > 92-media-header-extensions-for-wireless-
> networks&data=05%7C01%7Cjohn.k
> >
> aippallimalil%40futurewei.com%7C0a434e87cf5c4300c79508dbd79a3fb0%7C0
> fe
> >
> e8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638340829741199302%7CUnk
> nown%7
> >
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXV
> >
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=jtEvq%2BNvtaQbGBQ%2BnDJCvZY
> vhw9DaZVpEG
> > q4cbSlUg8%3D&reserved=0
> >
> > The figure UC2 MED in outer tunnel – in this case, MED is sent in an outer
> tunnel between the server (UDP source) and wireless node (UDP
> destination) only.
> 
> 	[SM] This however I am not convinced I want to see. IMHO the MED
> option should to be visible end to end, and using that only for an outer
> tunnel that is stripped away will not really retain that visibility*. However i
> accept that I look at this from an end-user perspective only, I am sure there
> are alternative perspectives from the network operator side...
> 
> 
> Regards
> 	Sebastian
> 
> 
> *) I would guess that as end-user looking at the UDP payload size distribution
> would likely still reveal an 18 byte in-IP header somehow, unless the network
> operator manages to use "baby-jumbo-frames" between wireless node and
> server, but the exact nature of what used that space would be
> unknowable...
> 
> >
> > But even for the other use case (UC1), it doesn’t look like the behavior of
> UDP options is altered in any distinguishable way (but we can debate that).
> >
> > BR,
> > John
> >
> >
> > From: tsvwg <[e-mail]> On Behalf Of Kaippallimalil John
> > Sent: Friday, October 27, 2023 6:35 PM
> > To: [e-mail]; Tom Herbert
> > <tom=[e-mail]>
> > Cc: tsvwg <[e-mail]>
> > Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for
> > adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
> >
> > Hi Tom, Joe,
> >
> > With regard to the concerns from Tom and Joe, the behavior needed is
> > outlined in slide 3 of:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fmeeting%2F118%2Fmaterials%2Fslides-118-tsvwg-
> sessa-
> > 92-media-header-extensions-for-wireless-
> networks&data=05%7C01%7Cjohn.k
> >
> aippallimalil%40futurewei.com%7C0a434e87cf5c4300c79508dbd79a3fb0%7C0
> fe
> >
> e8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638340829741199302%7CUnk
> nown%7
> >
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXV
> >
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=jtEvq%2BNvtaQbGBQ%2BnDJCvZY
> vhw9DaZVpEG
> > q4cbSlUg8%3D&reserved=0
> >
> > IPv6 HBP does not currently provide the capability needed:
> > 	• IPv6 HBH (MED in this case) is provisioned in the “Application
> > Provider” (AP) domain. And the service provided in the same domain (AP
> domain in this case) But that is not what we want. MED is inserted by AP
> domain, and read in the wireless provider domain.
> > 	• The data in MED is sent per packet and changing for each packet –
> also not the way FAST /IPv6 HBH is designed to be used.
> > 	• Every router on path is going to read/process the IPv6 HBH option.
> This is also not what is intended.
> > Only the wireless router acting on behalf on the client, with explicit
> provisioning (session setup, policy in figure) needs to read.
> >
> > The difference will be more obvious when (if) we need to consider
> encrypted metadata.
> > (PS: In this draft, we don’t see the need to encrypt the metadata as
> > the signals are purely advisory and does not leak content or user
> information.) However, if we decided that encryption was needed:
> > 	• With FAST/ IPv6 HBH, the key management is for the Application
> Domain (AP) to read, not the wireless domain. (otherwise involves complex
> multi-domain key agreements).
> > 	• With MED, the client to Wireless-CP/Policy signaling can install
> > the MED keys in a simple manner (in 3GPP domain, that would just be
> > small extensions)
> >
> > But just to be clear, in the draft, the metadata (MED) and its handling is
> completely separated from the container/transport (UDP options).
> > If IPv6 HBH  or other transport can evolve to support this kind of handling
> needed, then the draft can be updated to use MED and that (other)
> transport.
> > The key aspect in the draft is the metadata (MED) and how it should be
> processed on path.
> >
> > Regards,
> > John
> >
> >
> > From: tsvwg <[e-mail]> On Behalf Of
> [e-mail]
> > Sent: Friday, October 27, 2023 5:44 PM
> > To: Tom Herbert <tom=[e-mail]>
> > Cc: tsvwg <[e-mail]>
> > Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for
> > adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
> >
> > +1 ;-)
> > —
> > Dr. Joe Touch, temporal epistemologist
> >
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> .s
> >
> trayalpha.com%2F&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com
> %7C
> >
> 0a434e87cf5c4300c79508dbd79a3fb0%7C0fee8ff2a3b240189c753a1d5591fedc
> %7C
> >
> 1%7C0%7C638340829741199302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDA
> >
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> data=
> > K7uUJkMOJoEeKJtBshAekr4WIOIn01ZBATJTe0oaiSc%3D&reserved=0
> >
> >
> > On Oct 27, 2023, at 2:55 PM, Tom Herbert
> <tom=[e-mail]> wrote:
> >
> > On Fri, Oct 27, 2023 at 2:26 PM Spencer Dawkins at IETF
> > <[e-mail]> wrote:
> >
> >
> > Dear TSVWG,
> >
> > We have requested a slot during the IETF 118 meeting to propose that the
> co-chairs poll the working group for adoption
> ofhttps://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-
> wireless/, as a basis for further work.
> >
> > The chairs have given us a 15-minute slot during the Thursday TSVWG
> session.
> >
> > Face-to-face meeting time is precious, so we thought it would be helpful if
> we invited people to look over the draft, and let us know if you see
> significant impediments to adopting this draft. That would reduce the time
> we need in the meeting itself.
> >
> > Hi Spencer,
> >
> > I believe that the use of UDP Options to carry information that is
> > processed by intermediate nodes is a significant impediment to
> > adoption.
> >
> > From the draft: "The Wireless Node is responsible for forwarding
> > packets to the Client over the Wireless Network.  The Wireless Node
> > inspects metadata but does not alter the UDP option."
> >
> > There was discussion on the list and I believe that there is general
> > consensus that UDP Options are neither designed nor intended to carry
> > network layer information like this. They are for carrying End-to-End
> > transport layer information.
> >
> > IMO the proper alternative for carrying network layer information is
> > Hop-by-Hop Options like in FAST
> >
> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Farchive%2Fid%2Fdraft-herbert-fast-
> 04.txt&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C0a434e87
> cf5c4300c79508dbd79a3fb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C
> 0%7C638340829741199302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=xGkUnY7SkByZCzOK2wLvO8FfWeCLBYbAjWFxUPaVXNs%3D&
> reserved=0).
> >
> > Tom
> >
> >
> >
> >
> >
> >
> > As a reminder,
> >
> > This draft has been presented at IETF 116, 117 and now 118 We had
> > considerable discussion at previous IETF meetings and on the TSVWG
> > mailing list That feedback has been uniformly helpful, and we've taken it
> into consideration in the -03 update.
> > Adoption has been discussed previously at IETF 117
> >
> > The updated draft (-03) is described in slides that are uploaded at
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-kaippallimalil-tsvwg-media-hdr-wireless
> >
> %2F&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C0a434e87cf
> 5c4
> >
> 300c79508dbd79a3fb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C63834
> >
> 0829741199302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2lu
> >
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z0NM1
> VjfRJn5M
> > F319s9sJjswIet%2Bmo0g80oOZ7y7YKs%3D&reserved=0
> >
> > A diff from version -02, discussed at IETF 117, is here:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-kaippallimalil-tsvwg-media-hdr-wireless
> >
> %2F&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C0a434e87cf
> 5c4
> >
> 300c79508dbd79a3fb0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C63834
> >
> 0829741199302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2lu
> >
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z0NM1
> VjfRJn5M
> > F319s9sJjswIet%2Bmo0g80oOZ7y7YKs%3D&reserved=0
> >
> > Please feel free to follow up on this mailing list, or privately with the
> document authors.
> >
> > Best,
> >
> > Spencer