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

[Lucas Pardue <[e-mail]>]

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
>