Re: [Moq] New Version Notification for draft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt

["Shihang(Vincent)" <[e-mail]>]

Metadata is a broad term. In the context of MoQ, I can think of three layers of metadata:

1.      Session level such as media resource name to indicate which content do a client subscribe? Relay need it to do forwarding. QUICR[1] is a good example to leverage the object URL to form a pub/sub tree.

2.      Stream level such as audio/video/base layer in SVC. In the same session there usually exists multiple streams such as audio stream and video stream. If the video stream is using SVC, it can be further split into base layer stream and enhancement layer streams.  Each stream may have different priorities and can be selective dropped. draft-pardue-masque-dgram-priority[2] can be used to indicate this level of metadata.

3.      Packet (set) level such as I frame/P frame. Each frame may have different priorities and will be carried in multiple packets (a packet set). IIUC, draft-defoy-moq-relay-network-handling-00[3] and draft-kaippallimalil-tsvwg-media-hdr-wireless-00[4] requires this level of metadata which need to be carried in every packet. In the context of MASQUE, CONNECT UDP payload can also be extended to carry additional information for each packet (an example is shown in draft-schinazi-masque-connect-udp-ecn[5]).

Where to put those metadata is a key design choice which I discuss very briefly in section 5 of draft-shi-moq-design-space-analysis-of-moq [6]. Encrypt and transport the metadata and content separately may improve the relay performance compared to everything-inside-QUIC-encryption approach.

[1]: https://datatracker.ietf.org/doc/draft-jennings-moq-quicr-proto/
[2]: https://datatracker.ietf.org/doc/draft-pardue-masque-dgram-priority/
[3]: https://datatracker.ietf.org/doc/draft-defoy-moq-relay-network-handling/
[4]: https://datatracker.ietf.org/doc/html/draft-kaippallimalil-tsvwg-media-hdr-wireless-00
[5]: https://datatracker.ietf.org/doc/html/draft-schinazi-masque-connect-udp-ecn-02
[6]: https://datatracker.ietf.org/doc/draft-shi-moq-design-space-analysis-of-moq/

Cheers,
Hang Shi

From: Moq <[e-mail]> On Behalf Of Lucas Pardue
Sent: Saturday, October 22, 2022 10:54 PM
To: Kaippallimalil John <[e-mail]>
Cc: Ted Hardie <[e-mail]>; Alan Frindell <afrind=[e-mail]>; MOQ Mailing List <[e-mail]>; Sri Gundavelli (sgundave) <[e-mail]>
Subject: Re: [Moq] New Version Notification for draft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt

Hi,

Not trying to pick on this particular proposal, but commenting on the solution space in general.

An end-to-end application protocol with, let's call them 1st party explicit relays, is something that's common; see HTTP intermediation as it works today, which Will Law explained well in another thread. Where I struggle to follow is how something in the network, that isn't strictly part of the end-to-end chain, can actually work.

MASQUE is a WG that is defining approaches. Really we should just call a spade a spade, we now have HTTP CONNECT plus capsules. And HTTP CONNECT has been around for ages. Generally a CONNECT proxy is known to a client and never a server. And the semantic of the data that is exchanged via the proxy, a logical end-to-end bytestream, is known to the client and server, but never the proxy.  So if we use the UDP proxying over HTTP spec, to carry end-to-end QUIC, the finest element of differentiation is most likely the encapsulated UDP datagram flow. I.e, expressing the preferences for QUIC packet forwarding, and never revealing the actual packet contents. So what might be sufficient is to define an interaction model between client and proxy that can have differential prioritization of datagrams. That's what I wrote up in draft-pardue-masque-dgram-priority [1], a proposal that integrates with the HTTP stream prioritization scheme defined in RFC 9218. It uses a mix of frames and capsules to achieve needs. However, it still wouldn't address anything outside the HTTP proxying boundary.

I tend to agree with Alan in so far as the ability to interact with a proxy to help optimise the behaviour of MoQ, is just a subset of the ability to optimise any traffic between a client and an explicit proxy. The amount of information that can be shared to achieve this is limited by types and by actors in the chain.

Cheers
Lucas


[1] - https://datatracker.ietf.org/doc/draft-pardue-masque-dgram-priority/

On Sat, 22 Oct 2022, 15:20 Kaippallimalil John, <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alan, Ted,
Thanks for the feedback. I remember the PLUS BoF and agree that unencrypted information would be a non-starter.

The intention in the draft was not for metadata to be sent in cleartext, but rather to use similar mechanisms that MoQ proposes to share metadata between the application and relays.
In this case, the MoQ ‘relay’ would be at a wireless operator.
I see that the text in the current draft can be misleading or incomplete, and we will work to address that (in section 4 of the draft).

An equally, or perhaps more important question is the ability of an application to give the kind of information that is of interest for the wireless networks (in section 3 in the draft).
And (assuming that the metadata can be secured), we’re interested in understanding the views of the group on the metadata aspects.

Regards,
John


From: Ted Hardie <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, October 22, 2022 9:00 AM
To: Alan Frindell <afrind=[e-mail]<mailto:[e-mail]>>
Cc: Kaippallimalil John <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Moq] New Version Notification for draft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt

In addition to Alan's points below, you may wish to check the proceedings (https://www.ietf.org/proceedings/96/plus.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F96%2Fplus.html&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sOk9orH%2FQCH0CGsInT65Zln5eVww53XPgZxyXjmc%2BpE%3D&reserved=0>) for the outcome of the PLUS BoF at the IETF which, coincidentally, occurred at the same meeting as the BoF for QUIC.  Folding this directly into UDP is likely to be a non-starter unless the community opinion has shifted a great deal since then.

regards,

Ted

On Fri, Oct 21, 2022 at 9:37 PM Alan Frindell <afrind=[e-mail]<mailto:[e-mail]>> wrote:
Hi John, thanks for sharing your draft.

As I read it, it sounds like the proposal is for moq to include metadata in UDP packets but outside of QUIC's encryption envelope.

This is a relatively generic transport mechanism, which by itself need not be moq specific -- as you point out it could be used for HTTP/3 as well.

Our charter says:

"This working group will not propose changes to the underlying QUIC transport, but may propose requirements for QUIC extensions to the QUIC WG".

Perhaps you should raise the need for an extension to provide this kind of operator visible metadata to the QUIC WG.  If such a transport extension were available, it could be interesting to apply it in moq.  I suspect having the metadata unprotected by encryption will be a non-starter for some folks though.  In this way, something more along the lines of masque may be more viable, though I am concerned about the performance impact of double-encryption.


Thanks

-Alan


On 10/21/22, 12:16 PM, "Moq on behalf of Kaippallimalil John" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

    !-------------------------------------------------------------------|
      This Message Is From an External Sender

    |-------------------------------------------------------------------!

    Hi,

    We wrote a draft on carrying metadata about a media packet in a QUIC/transport header (extension) so that a wireless network can use it to optimize handling during congestion or variation in radio conditions.

    This was posted in tsvwg due to the close relation to transport layer mechanisms but also has aspects of metadata that may be handled in MoQ (section 3).
    The draft also outlines MoQ extended header as one possible means to transport the metadata in section 4.1.

    Would like to get feedback on the draft.

    Thanks,
    John


    -----Original Message-----
    From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
    Sent: Thursday, October 20, 2022 9:19 AM
    To: Kaippallimalil John <[e-mail]<mailto:[e-mail]>>; Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
    Subject: New Version Notification for draft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt


    A new version of I-D, draft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt
    has been successfully submitted by John Kaippallimalil and posted to the IETF repository.

    Name:               draft-kaippallimalil-tsvwg-media-hdr-wireless
    Revision:   00
    Title:              Media Header Extensions for Wireless Networks
    Document date:      2022-10-20
    Group:              Individual Submission
    Pages:              8
    URL:            https://nam11.safelinks.protection.outlook.com/?url=https://www.ietf.org/archive/id/draft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt&amp;data=05|01|[e-mail]|70d1f864070d4bd0798f08dab2a6016a|0fee8ff2a3b240189c753a1d5591fedc|1|0|638018723331982455|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|3000|||&amp;sdata=x/z+Gsoz2MhAPCsTQUSTKucEUn8xeJw2gD4S1mgHE/Q=&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kaippallimalil-tsvwg-media-hdr-wireless-00.txt&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AClEvxJkbXdGbLffBuIsO79eR5QMNZCF0bOdFPmUwJs%3D&reserved=0>
    Status:         https://nam11.safelinks.protection.outlook.com/?url=https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/&amp;data=05|01|[e-mail]|70d1f864070d4bd0798f08dab2a6016a|0fee8ff2a3b240189c753a1d5591fedc|1|0|638018723331982455|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|3000|||&amp;sdata=V59/xd/3sOQrpWwEnJUejLQzY+9chJC98YduKcZXysk=&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kaippallimalil-tsvwg-media-hdr-wireless%2F&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dQar7yRDZlchChiqx%2Faf2oiSLBcY62QDfVQ0WmbdtGc%3D&reserved=0>
    Html:           https://nam11.safelinks.protection.outlook.com/?url=https://www.ietf.org/archive/id/draft-kaippallimalil-tsvwg-media-hdr-wireless-00.html&amp;data=05|01|[e-mail]|70d1f864070d4bd0798f08dab2a6016a|0fee8ff2a3b240189c753a1d5591fedc|1|0|638018723331982455|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|3000|||&amp;sdata=4ftKgXFpub6PrAEoxry8lMhd0Wth44Ey4SQL9jfgp0M=&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kaippallimalil-tsvwg-media-hdr-wireless-00.html&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XyNInPeS8JzcxYiGN2TyEGFgkdc%2FEnPmgmnJHk6MYas%3D&reserved=0>
    Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https://datatracker.ietf.org/doc/html/draft-kaippallimalil-tsvwg-media-hdr-wireless&amp;data=05|01|[e-mail]|70d1f864070d4bd0798f08dab2a6016a|0fee8ff2a3b240189c753a1d5591fedc|1|0|638018723331982455|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|3000|||&amp;sdata=bl2h21WvSWZTf6RXoXVfYT8zLZ9HCaaXm4CPx6x6/tk=&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kaippallimalil-tsvwg-media-hdr-wireless&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J5uJXUWE%2BlkhckMwDhrts3wKPUHjgWmVLSKbAzsXsJk%3D&reserved=0>


    Abstract:
       Wireless networks like 5G cellular or Wi-Fi experience significant
       variations in link capacity over short intervals due to wireless
       channel conditions, interference, or the end-user's movement.  These
       variations in capacity take place in the order of hundreds of
       milliseconds and is much too fast for end-to-end congestion signaling
       by itself to convey the changes.  Media applications on the other
       hand demand both high throughput and low latency, and are able to
       dynamically adjust the size and quality of a stream to match
       available network bandwidth.  However, catering to such media flows
       over a radio link where the capacity changes rapidly requires the
       buffers to be managed carefully.  This draft proposes additional
       information about the media transported in each packet to manage the
       buffers and optimize the scheduling of radio resources.  The set of
       information proposed here includes relative importance of the packet,
       burst length and timestamp to be conveyed by the media application in
       a header extension.  This can be used to provide the wireless network
       the flexibility to prioritize packets that are essential when the
       radio capacity is temporarily low, defer packets that can tolerate
       some additional delay, or even drop packets selectively in more
       extreme conditions.

       Another aspect considered here is the means by which the media packet
       information is transported.  Potential solutions include carrying
       this information in Media over QUIC extension headers, UDP options,
       or in a MASQUE encapsulation between the application server and
       wireless network entity.




    The IETF Secretariat


    --
    Moq mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/moq<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmoq&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CicpswR5oBCMNuqU0tDoBLyWUo3kE2coGyblPRVVErM%3D&reserved=0>

--
Moq mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/moq<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmoq&data=05%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cb23f3a18064e4d5c40eb08dab435c112%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638020440227444522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CicpswR5oBCMNuqU0tDoBLyWUo3kE2coGyblPRVVErM%3D&reserved=0>
--
Moq mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/moq