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

[Christian Huitema <[e-mail]>]

In the QUICR prototype, we demonstrated how to implement a simple 
priority scheme inside the QUIC protection envelope. The transport 
notices the onset of congestion, and starts selectively dropping media 
frames marked both as "droppable" and "lower priority". Doing that does 
not require exposing priority information in clear text in the packet 
headers.

-- Christian Huitema

On 10/22/2022 10:00 AM, Lucas Pardue wrote:
> Right. But exposing any information outside of the QUIC protection 
> envelope is probably unpalatable no matter how much it much it might 
> potential it might have to improve performance. Pervasive monitoring 
> is an attack that IETF protocols should attempt to address. I'm 
> skeptical that performance optimisation is a strong enough trade off, 
> especially given the intended Internet deployment of MoQ.
>
> Cheers
> Lucas
>
> On Sat, 22 Oct 2022, 19:04 Shihang(Vincent), <[e-mail]> wrote:
>
>     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]> 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]>
>     *Sent:* Saturday, October 22, 2022 9:00 AM
>     *To:* Alan Frindell <afrind=[e-mail]>
>     *Cc:* Kaippallimalil John <[e-mail]>;
>     [e-mail]; Sri Gundavelli (sgundave) <[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]> 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] on behalf of
>         [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] <[e-mail]>
>             Sent: Thursday, October 20, 2022 9:19 AM
>             To: Kaippallimalil John
>         <[e-mail]>; Sri Gundavelli
>         <[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]
>         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]
>         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]
>     https://www.ietf.org/mailman/listinfo/moq
>
>