Internet DRAFT - draft-nandakumar-moq-arch

draft-nandakumar-moq-arch







Network Working Group                                      S. Nandakumar
Internet-Draft                                                     Cisco
Intended status: Informational                               C. Jennings
Expires: 14 September 2023                                         cisco
                                                           13 March 2023


            Media Over QUIC Media and Security Architecture
                      draft-nandakumar-moq-arch-00

Abstract

   This document defines the media and security architecture for Media
   Over QUIC, a protocol suite intended to run in browsers and other
   non-browser endpoints and support unified architecture and protocol
   for data delivery that enables a wide range of media applications
   with different resiliency and latency needs without compromising the
   scalability and cost effectiveness associated with content delivery
   networks.

   Note to readers: This document as it stands might not reflect
   accurately all decisions that are in active discussions in the WG,
   but it lays out a foundation for expected architectural requirements.
   The specification will be updated based on the decision made in the
   WG.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 September 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Nandakumar & Jennings   Expires 14 September 2023               [Page 1]

Internet-Draft              MoQ Architecture                  March 2023


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Advantages of MoQ Media Transport Protocol  . . . . . . .   4
   2.  Entity Roles and Trust Model  . . . . . . . . . . . . . . . .   5
     2.1.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  Emitter . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  Publisher . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.3.  Subscriber  . . . . . . . . . . . . . . . . . . . . .   6
       2.1.4.  Relay . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.5.  Catalog Maker . . . . . . . . . . . . . . . . . . . .   6
       2.1.6.  Receiver  . . . . . . . . . . . . . . . . . . . . . .   7
       2.1.7.  Key Manager . . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Media Transformer . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Provider  . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   7
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Streaming Architectures . . . . . . . . . . . . . . . . .   8
     4.2.  Interactive/Conferencing Architectures  . . . . . . . . .   9
   5.  Tracks, Objects and Groups  . . . . . . . . . . . . . . . . .  10
   6.  Relays and Scalability  . . . . . . . . . . . . . . . . . . .  11
   7.  MoQ Transport Usage Patterns  . . . . . . . . . . . . . . . .  12
     7.1.  Catalog Objects . . . . . . . . . . . . . . . . . . . . .  12
     7.2.  MOQ Video Objects . . . . . . . . . . . . . . . . . . . .  12
     7.3.  MoQ Audio Objects . . . . . . . . . . . . . . . . . . . .  12
     7.4.  MOQ Game Moves Objects  . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  Protocol Design Considerations  . . . . . . . . . . . . . . .  13
     9.1.  HTTP/3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.2.  QUIC Streams and Datagrams  . . . . . . . . . . . . . . .  14
     9.3.  QUIC Congestion Control . . . . . . . . . . . . . . . . .  14
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14









Nandakumar & Jennings   Expires 14 September 2023               [Page 2]

Internet-Draft              MoQ Architecture                  March 2023


1.  Introduction

   Recently new use cases have emerged requiring higher scalability of
   delivery for interactive realtime applications and much lower latency
   for streaming applications and a combination thereof.  On one side
   are use cases such as normal web conferences wanting to distribute
   out to millions of viewers and allow viewers to instantly move to
   being a presenter.  On the other side are uses cases such as
   streaming a soccer game to millions of people including people in the
   stadium watching the game live.  Viewers watching an e-sports event
   want to be able to comment with minimal latency to ensure the
   interactivity aspects between what different viewers are seeing is
   preserved.  All of these uses cases push towards latencies that are
   in the order of 100ms over the natural latency the network causes.

   Interactive realtime applications, such as web conferencing systems,
   require ultra low latency (< 150ms) delivery.  Such applications
   create their own application specific delivery network over which
   latency requirements can be met.  Realtime transport protocols such
   as RTP over UDP provide the basic elements needed for realtime
   communication, both contribution and distribution, while leaving
   aspects such as resiliency and congestion control to be provided by
   each application.  On the other hand, media streaming applications
   are much more tolerant to latency and require highly scalable media
   distribution.  Such applications leverage existing CDN networks, used
   for optimizing web delivery, to distribute media.  Streaming
   protocols such as HLS and MPEG-DASH operates on top of HTTP and gets
   transport-level resiliency and congestion control provided by TCP.

   The architecture defines and uses a unified media delivery protocol
   that is based on a publish/subscribe metaphor where client endpoints
   publish and subscribe to named objects that is sent to, and received
   from relays, that forms an overlay delivery network similar to what
   CDN provides today.  Objects are named such that it is unique for the
   relay/delivery network and scoped to an application.

   The MoQ transport protocol provides services based on application
   requirements (with the support of underlying transport, where
   necessary) such as estimation of available bandwidth, resiliency,
   congestion control and prioritization of data delivery based on data
   lifetime and importance of data.  It is designed to be NAT and
   firewall traversal friendly and can be fronted with load balancers.

   In a sample deployment, Relays can be thought of as arranged in a
   logical tree (as shown below) where, for a given application, there
   is an origin Relay at root of the tree that controls the namespace
   for the objects.  Publish messages are sent towards the root of the
   tree and down the path of any subscribers to that named object.  It



Nandakumar & Jennings   Expires 14 September 2023               [Page 3]

Internet-Draft              MoQ Architecture                  March 2023


   is designed to make it easy to implement relays so that fail over
   could happen between relays with minimal impact to the clients and
   relays can redirect a client to a different relay.

                 ┌────────────┐
                 │            │
                 │            ▼
                 │       ┌────────┐
                 │   ▬ ▬▶│Relay-0 │ ◀▬▬ ▬▬ ▬▮
             pub │  ▮    │ Orgin  ├┐        ▮
                 │  ▮    └────────┘│        ▮
                 │  ▮ sub          │        ▮ sub
                 │  ▮          pub │        ▮
                 │  ▮              │        ▮
            ┌───────▮┐ ◀▬▮         │  ┌─────▮──┐
        ┌──▶│ Relay-1│   ▮         └─▶│ Relay-2│◀▮▮
        │   └─────┬──┘   ▮             ▲──┬────┤  ▮
    pub │         │      ▮ sub     sub ▮  │    │  ▮ sub
        │      pub│      ▮             ▮  │pub ▼  ▮
       ┌┴─────┐   │ ┌────▮─┐     ┌─────▮┐ │   ┌───▮──┐
       │Alice │   └▶│ Bob  │     │ Carl │◀┘   │Derek │
       └──────┘     └──────┘     └──────┘     └──────┘

                          Figure 1: Delivery Tree

   The design supports sending named objects between a set of
   participants in a game or video call with under a hundred
   milliseconds of latency and meets the needs of conferencing systems.
   The design can also be used for large scale streaming to millions of
   participants with latency ranging from a few seconds to under a
   hundred milliseconds based on applications needs.

1.1.  Advantages of MoQ Media Transport Protocol

   The architecture for MoQ uses similar concepts and delivery
   mechanisms to those used by streaming standards such as HLS and MPEG-
   DASH.  Specifically the use of a CDN-like delivery network, the use
   of named objects and the receiver-triggered media/data delivery.
   However, there are fundamental characteristics that the MoQ Transport
   provides to enable ultra low latency delivery for interactive
   applications such as conferencing and gaming.










Nandakumar & Jennings   Expires 14 September 2023               [Page 4]

Internet-Draft              MoQ Architecture                  March 2023


   *  To support low latency the granularity of the delivered objects,
      in terms of time duration, need to be quite small making it
      complicated for clients to request each object individually.  MoQ
      Transport protocol uses a publish and subscription semantic to
      simplify and speed object delivery for low latency applications.
      For latency-tolerant applications, larger granularity of data, aka
      group of objects, can be individually requested and delivered
      without instantiating state in the backend.

   *  Some realtime applications operating in ultra low latency mode
      require objects delivered as and when they are available without
      having to wait for previous objects due to network loss or out of
      order network delivery.  Pipelining of object delivery with
      delivering media bitstream as and when they appear is supported,
      for this purpose.

   *  Published objects have associated max-age that specifies the
      validity of such objects. max-age influences relay's drop
      decisions and can also be used by the underlying QUIC transport to
      cease retransmissions associated with the named object.

   *  Unlike traditional streaming architectures where media
      contribution and media distribution are treated differently, MoQ
      Transport can be used for both object contribution/publishing and
      distribution/subscribing as the split does not exist for
      interactive communications.

   *  "Aggregation of subscriptions" at the relay functions allows
      "short-circuited" delivery of published objects when there is a
      match at a given relay function.  This further enables local error
      recovery where applicable.

   *  Publishers can associate a priority with objects.  These can help
      the delivery network and the subscribers to make decisions about
      resiliency, latency, drops etc.  Priorities can be used to set
      relative importance between different qualities for layered video
      encoding, for example.

   *  MoQ Transport is designed so that objects are encrypted end-to-end
      and will pass transparently through the delivery network.  Any
      information required by the delivery network, will be included as
      part of the metadata that is accessible to the delivery network
      for further processing as appropriate.

2.  Entity Roles and Trust Model

   This section specifies various roles that make up an application
   architecture using MoQ Transport.



Nandakumar & Jennings   Expires 14 September 2023               [Page 5]

Internet-Draft              MoQ Architecture                  March 2023


2.1.  Roles

   This section defines various roles that can exist within the MoQ
   Architecture and the associated trust model.  A given MoQ entity
   (physical or logic component) can play one or more roles depending on
   their utility within the architecture.

2.1.1.  Emitter

   Entities that perform Emitter role are trusted with E2E encryption
   keys for the media and operate on one or more uncompressed and
   unencrypted media.  They compress and possibly encrypt and transmit
   over one or more Data Streams.

   Each such encoded and/or encrypted stream corresponds to a Track
   within the MoQ transport protocol.

2.1.2.  Publisher

   Entities with Publisher role publish MoQ Objects belonging to a given
   track using the MoQ Transport Protocol.

2.1.3.  Subscriber

   Entities with Subscribe role subscribe to receive MoQ Objects
   corresponding to a track using the MoQ Transport Protocol.

2.1.4.  Relay

   Entities performing the Relay role are not trusted with E2E
   encryption keys.

   Entities performing Relay role implement store and forward behavior.
   Such entities receives subscriptions and publishes data to the other
   endpoints that have subscribed to the named data.  They may cache the
   data as well for optimizing the delivery experience.  Since these
   entities are not trusted with the E2E keys, they cannot access
   unencrypted MoQ Object Payload, however they are allowed to access
   the MoQ Object Header.

2.1.5.  Catalog Maker

   Entities performing Catalog Maker role compose or aggregate tracks
   from multiple emissions to form a new emission.  Akin to the role of
   entities with the Relay role, Catalog Maker role entities are not
   trusted with the E2E keys and they perform publisher and subscriber
   roles.  Catalog Makers are allowed to publish tracks with a new name
   without changing the media content of the received tracks.



Nandakumar & Jennings   Expires 14 September 2023               [Page 6]

Internet-Draft              MoQ Architecture                  March 2023


2.1.6.  Receiver

   Entities performing the Receiver role are trusted with E2E keys and
   can transform the Encrypted Stream into Encoded Stream and decode the
   encoded stream to source stream for further consumptions

2.1.7.  Key Manager

   Entities with Key Manager role are responsbile for setting up the
   needed protocol machinery for distributing keys needed for end to end
   encryption.  Key Manager role doesn't provide access to the E2E
   encryption keys.

2.2.  Media Transformer

   Entities with Media Transformer roles are trusted with E2E encryption
   keys and thus have access to the media.  They combine the following
   roles - Subscriber, Receiver, Emitter and publisher.  They subscribe
   to media tracks, decrypt and transform the received media, encrypt
   and publish the transformed media as new media tracks.

2.3.  Provider

   TODO

3.  Reference Architecture

   Below picture depicts reference architecture involving entities
   playing various roles.






















Nandakumar & Jennings   Expires 14 September 2023               [Page 7]

Internet-Draft              MoQ Architecture                  March 2023


                           ┌──────────────────┐
    ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│    Provider      │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
                           └──────────────────┘
    │                                                                    │
                          ┌─────────────────┐
    │    ┌ ─ ─ ─ ─ ─ ─ ─ ─│  Key Manager    ├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐  │
                          └─────────────────┘
    │    │                                                            │  │

    │    │                                                            │  │
                    ┌───────────────┐     ┌───────────────┐
    │    │          │   Catalog     │     │   Media       │           │  │
                    │    Maker      │─ ─ ─│  Transformer  │
    │    │          └───────┬───────┘     └───────┬───────┘           │  │
                            │                     │
    │    │                  │                     │                   │  │
                            │                     │
  .─┴────┴.             ┌───┴─────┐         ┌─────┴───┐              .┴──┴───.
 ╱         ╲           ┌┴────────┐│────────┬┴────────┐│             ╱         ╲
( Emitters  ──────────▶│  Relay  ├┘        │  Relay  ├┘───────────▶( Receivers )
 `.       ,'           └──────┬──┘         └─────┬───┘              `.       ,'
   `─────'                    │   ┌─────────┐    │          Tracks    `─────'
             Tracks           │  ┌┴────────┐│    │
                              └──│  Relay  ├┴────┘
                                 └─────────┘

4.  Overview

4.1.  Streaming Architectures

   Streaming scenarios typically separate "content ingestion" and
   "content distribution".  In a reference live streaming architecture
   shown below, the emitter live streams on or more tracks as part of
   the application operated under a provider domain, which gets
   eventually distributed to multiple clients by some form of
   distribution server operating under the provider domain, over a
   content distribution network.














Nandakumar & Jennings   Expires 14 September 2023               [Page 8]

Internet-Draft              MoQ Architecture                  March 2023


                          +-------------+
                          |Relay        |
       +----------------> |Orgin:tw.com |-----+
       |                  +-------------+     |
       |                                ^     |
       |pub:tw.com/ch22/audio-1         |     |
       |pub:tw.com/ch22/audio-2         |     |
       |        sub:tw.com/ch22/audio-1 |     |
       |                                |     |pub:tw.com/ch22/audio-1
       |                                |     v
   +-----------+                      +----------+
   | Emitter   |                      | Receiver |
   +-----------+                      +----------+

   The above picture shows MoQ Transport based delivery network for an
   hypothetical streaming architecture rooted at the Origin Relay, akin
   to Ingest server/Distribution Server (for the domain tw.com).  In
   this architecture, the media contribution is done by publishing named
   tracks for audio corresponding to channel-22, at 2 different
   qualities, to the ingest server at the Origin Relay.  Media
   consumption happens via subscribes sent to the Origin Relay to the
   name (tw.com/ch22/audio-1) to receive the right quality track.

4.2.  Interactive/Conferencing Architectures

   A interactive conference typically works with the expected operating
   glass-to-glass latency to be around 200ms and is made up of
   multiplicity of participant with varying capabilities and operating
   under varying network conditions.

   A typical conferencing session comprises of:

   *  Multiple emitters, publishing on multiple tracks (audio, video
      tracks and at different qualities)

   *  A media switch, sourcing tracks that represent a subset of tracks
      from across all the emitters.  Such subset may represent tracks
      representing top 5 speakers at higher qualities and lot of other
      tracks for rest of the emitters at lower qualities.

   *  Multiple receivers, with varied receiving capacity (bandwidth
      limited), subscribing to subset of the tracks









Nandakumar & Jennings   Expires 14 September 2023               [Page 9]

Internet-Draft              MoQ Architecture                  March 2023


                     +--------+
              +----> |   SFU  | <----------------+
              |      +--------+                  |
              |       ^       |                  |sub:alice-low
    pub:alice-hi      |       pub:alice-hi       |sub:alice-hi
    pub:alice-low     |       pub:alice-low      |
              | sub:alice-low |                  |
              |       |       |                  |
             +---------+      |  +------------------------+
     +------>| Relay-A |      +->|    Relay-B             |
     |       +---------+         +------------------------+
     |           |  ^              |    ^          |    ^
    pub1:alice-hi|  |              |    |          |    |
    pub2:alice-low  |              |    |          |    |
     |           |  |              |    |          |    |
     |          pub:alice-low     pub:alice-hi,low pub:alice-hi,low
     |           |  |              |    |          |    |
     |           | sub:alice-low   |   sub:alice.. |   sub:alice..
     |           v  |              v    |          v    |
     +------+    +---+              +----+         +-----+
     | Alice|    |Bob|              |Carl|         |Derek|
     +------+    +---+              +----+         +-----+

   The above picture shows a MoQ Transport based media delivery tree
   formed with multiple relays in the network.  The example has 4
   participants with Alice being the publisher and rest being the
   subscribers.  Alice's is capable of publishing video streams at 2
   qualities identified by their appropriate names.  Bob subscribes to a
   low resolution video track from alice, whereas Carl/Derek subscribe
   to all the qualities of video feed published by Alice.  All the
   subscribes are sent to the Origin Relay and are saved at the on-path
   Relays, this allowing for "short-circuited" delivery of published
   data at the relays.  In the above example, Bob gets Alice's published
   data directly from Relay-A instead of hair pinning from the Origin
   Relay.  Carl and Derek, however get their video stream relayed from
   Alice via Origin Relay and Relay-B.

5.  Tracks, Objects and Groups

   Tracks form the central concept within the MoQ Transport protocol for
   delivering media.  A Track identifies the namespace and the
   authorization scope under which MoQTransport objects are delivered.

   A track is a transform of a uncompressed media using a specific
   encoding process, a set of parameters for that encoding, and possibly
   an encryption process.

   The MoQTransport is designed to transport tracks.



Nandakumar & Jennings   Expires 14 September 2023              [Page 10]

Internet-Draft              MoQ Architecture                  March 2023


   The binary content of a track is composed of a sequence of objects.
   An Object is the smallest unit that makes sense to decode and may not
   be independently decodable.  An Object MUST belong to a group.

   Objects MUST be uniquely identifiable within the MoQ delivery system.
   Objects carry associated header/metadata containing priority, time to
   live, and other information aiding the caching/forwarding decision at
   the Relays.  Objects MAY be optionally cached at Relays.  The content
   of the Objects are opaque to Relays and delivered on the strict
   priority order.

   An Object MUST belong to a group.  Groups are composition of objects
   and the objects within the group carry the necessary dependency
   information needed to process the objects in the group.

   A typical example would be a group of pictures/video frames or group
   of audio samples that represent synchronization point in the video
   conferencing example.

6.  Relays and Scalability

   The Relays play an important role for enabling low latency media
   delivery within the MoQ architecture.  This specification allows for
   a delivery protocol based on a publish/subscribe metaphor where some
   endpoints, called publishers, publish media objects and some
   endpoints, called subscribers, consume those media objects.  Some
   relays can leverage this publish/subscribe metaphor to form an
   overlay delivery network similar/in-parallel to what CDN provides
   today.  While this type of overlay is expected to be a major
   application of relays, other types of relays can also be defined to
   offer various types of services.

   Relays provide several benefits including

   *  Scalability – (U+2013) Relays provide the fan-out necessary to
      scale up streams to production levels (millions) of concurrent
      subscribers.

   *  Reliability - relays can improve the overall reliability of the
      delivery system by providing alternate paths for routing content.

   *  Performance – (U+2013) Relays are usually positioned as close to
      the edge of a network as possible and are well-connected to each
      other and to the Origin via high capacity managed networks.  This
      topography minimizes the RTT over the unmanaged last mile to the
      end-user, improving the latency and throughput compared to the
      client connecting directly to the origin.'




Nandakumar & Jennings   Expires 14 September 2023              [Page 11]

Internet-Draft              MoQ Architecture                  March 2023


   *  Security – (U+2013) Relays act to shield the origin from DDOS and
      other

   In order to keep the latencies low, Relays don't wait until the
   entire object is received but rather forward the bitstream/fragments
   as they are received to downstream subscribers.

7.  MoQ Transport Usage Patterns

   This section explains usage patterns that can be used to build
   applications on top of MoQ Transport

7.1.  Catalog Objects

   TODO

7.2.  MOQ Video Objects

   Most video applications would use the data identifier component to
   identity the video stream, as well as the encoding point such as
   resolution and bitrate.  Each independently decodable set of frames
   would go in a single group, and each frame inside that group would go
   in a separate named object inside the group.  This allows an
   application to receive a given encoding of the video by subscribing
   just to the data identifier component of the Name with a wildcard for
   group and object IDs.

   This also allows a subscription to get all the frames in the current
   group if it joins later, or wait until the next group before starting
   to get data, based on the subscription options.  Changing to a
   different bitrate or resolution would use a new subscription to the
   appropriate Name.

   The QUIC transport that QuicR is running on provides the congestion
   control but the application can see what objects are received and
   determine if it should change it's subscription to a different
   bitrate data identifier component.

   Today's video is often encoded with I-frames at a fixed interval but
   this can result in pulsing video quality.  Future system may want to
   insert I-frames at each change of scene resulting in groups with a
   variable number of frames.  QuicR easily supports that.

7.3.  MoQ Audio Objects

   TODO





Nandakumar & Jennings   Expires 14 September 2023              [Page 12]

Internet-Draft              MoQ Architecture                  March 2023


7.4.  MOQ Game Moves Objects

   Some games send out a base set of state information then incremental
   deltas to it.  Each time a new base set is sent, a new group can be
   formed and each increment change as an Object in the group.  When new
   players join, they can subscribe to sync up to the latest state by
   subscribing to the current group and the incremental changes that
   follow.

8.  Security Considerations

   The links between Relay and other Relays or Clients can be encrypted,
   however, this does not protect the content from Relays.  To mitigate
   this, all the objects need to be end-to-end encrypted with a keying
   mechanism outside the scope of this protocol.  For may applications,
   simply getting the keys over HTTPS for a particular object/group from
   the origin server will be adequate.  For other applicants keying
   based on MLS may be more appropriate.  Many applications can leverage
   the existing key managed schemes used in HLS and DASH for DRM
   protected content.

   Relays reachable on the Internet are assumed to have a burstiness
   relationship with the Origin and the protocol provides a way to
   verify that any data moved is on behalf of a given Origin.

   Relays in a local network may choose to process content for any
   Origin but since only local users can access them, there is a way to
   manage which applications use them.

   Subscriptions need to be refreshed at least every 5 seconds to ensure
   liveness and consent for the client to continue receiving data.

9.  Protocol Design Considerations

9.1.  HTTP/3

   It is tempting to base this on HTTP but there are a few high level
   architectural mismatches.  HTTP is largely designed for a stateless
   server in a client server architecture.  The whole concept of the
   PUB/SUB is that the relays are _not_ stateless and keep the
   subscription information and this is what allows for low latency and
   high throughput on the relays.

   In today's CDN, the CDN nodes end up faking the credentials of the
   origin server and this limits how and where they can be deployed.  A
   design with explicitly designed relays that do not need to do this,
   while still assuming an end-to-end encrypted model so the relays did
   not have access to the content makes for a better design.



Nandakumar & Jennings   Expires 14 September 2023              [Page 13]

Internet-Draft              MoQ Architecture                  March 2023


   It would be possible to start with something that looked like HTTP as
   the protocol between the relays with special conventions for
   wildcards in URLs of a GET and ways to stream non final responses for
   any responses perhaps using something like multipart MIME.  However,
   most of the existing code and logic for HTTP would not really be
   usable with the low latency streaming of data.  It is probably much
   simpler and more scalable to simply define a PUB/SUB protocol
   directly on top of QUIC.

9.2.  QUIC Streams and Datagrams

   There are pro and cons to mapping object transport on top of streams
   or on top of QUIC datagrams.  The working group would need to sort
   this out and consider the possibility of using both for different
   types of data and if there should be support for a semi-reliable
   transport of data.  Some objects, for example the manifest
   {{#manifest} would always want to be received in a reliable way while
   other objects may have to be realtime.

9.3.  QUIC Congestion Control

   The basic idea in BBR of speeding up to probe then slowing down to
   drain the queue build up caused during probe can work fine with real
   time applications.  However, the current implementations in QUIC do
   not appear optimized for real-time applications, resulting in higher
   jitter (under certain conditions).  In order to avoid play-out drops,
   the jitter buffers add latency to compensate for this.  Probing for
   the RTT has been one of the phases that causes particular problems
   for this.  To reduce the latency of QUIC, this work should coordinate
   with the QUIC working group to have the QUIC working group develop
   congestion control optimizations for low latency use of QUIC.

Appendix A.  Acknowledgments

   TODO

Authors' Addresses

   Suhas Nandakumar
   Cisco

   Email: snandaku@cisco.com


   Cullen Jennings
   cisco
   Canada




Nandakumar & Jennings   Expires 14 September 2023              [Page 14]

Internet-Draft              MoQ Architecture                  March 2023


   Email: fluffy@iii.ca


















































Nandakumar & Jennings   Expires 14 September 2023              [Page 15]