Internet DRAFT - draft-jennings-moq-quicr-proto
draft-jennings-moq-quicr-proto
Network Working Group C. Jennings
Internet-Draft cisco
Intended status: Informational S. Nandakumar
Expires: 12 January 2023 Cisco
C. Huitema
Private Octopus Inc.
11 July 2022
QuicR - Media Delivery Protocol over QUIC
draft-jennings-moq-quicr-proto-01
Abstract
Recently new use cases have emerged requiring higher scalability of
media delivery for interactive realtime applications and much lower
latency for streaming applications and a combination thereof.
draft-jennings-moq-arch specifies architectural aspects of QuicR, a
media delivery protocol based on publish/subscribe metaphor and Relay
based delivery tree, that enables a wide range of realtime
applications with different resiliency and latency needs.
This specification defines the protocol aspects of the QuicR media
delivery architecture.
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 12 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jennings, et al. Expires 12 January 2023 [Page 1]
Internet-Draft QuicR Media July 2022
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
2. Contributing . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Typical Publish/Subscribe Message Exchange . . . . . . . 5
4.2. Origin Server . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Names and Named Objects . . . . . . . . . . . . . . . . . . . 8
5.1. Named Objects . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Wildcarding with Names . . . . . . . . . . . . . . . . . 9
6. QuicR Manifest . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Scope of the manifest . . . . . . . . . . . . . . . . . . 11
7. QuicR Protocol Design . . . . . . . . . . . . . . . . . . . . 13
7.1. Control Channel . . . . . . . . . . . . . . . . . . . . . 13
7.2. QuicR Control Messages . . . . . . . . . . . . . . . . . 13
7.2.1. Subscribe Message . . . . . . . . . . . . . . . . . . 14
7.2.2. SUBSCRIBE_REPLY Message . . . . . . . . . . . . . . . 15
7.2.3. PUBLISH_INTENT Message. . . . . . . . . . . . . . . . 16
7.2.4. Start Point Message . . . . . . . . . . . . . . . . . 17
7.2.5. Fragment Message . . . . . . . . . . . . . . . . . . 18
7.2.6. Fin Message . . . . . . . . . . . . . . . . . . . . . 18
7.2.7. SUBSCRIBE_CANCEL Message . . . . . . . . . . . . . . 19
7.2.8. RELAY_REDIRECT MESSAGE . . . . . . . . . . . . . . . 19
7.3. Sending Media as Datagrams . . . . . . . . . . . . . . . 19
7.3.1. Datagram Header . . . . . . . . . . . . . . . . . . . 19
8. Relay Function and Relays . . . . . . . . . . . . . . . . . . 21
8.1. Cache and Relaying . . . . . . . . . . . . . . . . . . . 21
8.2. Out of order relaying . . . . . . . . . . . . . . . . . . 22
8.3. Relay or Cache or Drop Decisions . . . . . . . . . . . . 23
8.4. Cache cleanup . . . . . . . . . . . . . . . . . . . . . . 23
8.5. Relay fail over . . . . . . . . . . . . . . . . . . . . . 23
8.6. Relay Discovery . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Appendix B. TODO Items . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Jennings, et al. Expires 12 January 2023 [Page 2]
Internet-Draft QuicR Media July 2022
1. Introduction
This specification defines QuicR, a publish and subscribe based media
delivery protocol over QUIC.
Recently new use cases have emerged requiring higher scalability of
media 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 (a.k.a active participant). On the other
side are use 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
low latency to ensure the interactivity aspects between what
different viewers are preserved. All of these use cases push towards
latencies that are in the order of 100ms over the natural latency the
network causes.
The architecture for this specification is outlined in draft-
jennings-moq-arch, where the principal idea is 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.
The architecture specification, draft-jennings-moq-arch, is a
perquisite to read this specification.
This specification defines the protocol specifics of the QuicR Media
Delivery Architecture.
2. Contributing
All significant discussion of development of this protocol is in the
GitHub issue tracker at: "https://github.com/Quicr/quicr-protocol-
spec"
3. Terminology
* Relay Function: Functionality of the QuicR architecture, that
implements store and forward behavior at the minimum. Such a
function typically receives subscriptions and publishes data to
the other endpoints that have subscribed to the named data. Such
functions may cache the data as well for optimizing the delivery
experience.
Jennings, et al. Expires 12 January 2023 [Page 3]
Internet-Draft QuicR Media July 2022
* Relay: Server component (physical/logical) in the cloud that
implements the Relay Function.
* Publisher: An endpoint that sends named objects to a Relay. [ also
referred to as producer of the named object]
* Subscriber: An endpoint that subscribes and receives the named
objects. Relays can act as subscribers to other relays.
Subscribers can also be referred to as consumers.
* Client/QuicR Client: An endpoint that acts as a Publisher,
Subscriber, or both. May also implement a Relay Function in
certain contexts.
* Named Object: Application level chunk of Data that has a unique
Name, a limited lifetime, priority and is transported via the
protocol defined in this specification.
* Origin server: Component managing/authoring the names scoped under
a domain for a specific application and is responsible for
establishing trust between clients and relays for delivering
media. Origin servers MAY implement other QuicR functions, such
as Relay function, as necessary.
4. Overview
At a high level, entities within QuicR architecture publish named
media objects that are end-to-end encrypted and consume media by
subscribing to the named objects. The published data carry metadata
identifying relative priority, time-to-live and other useful metadata
that's authenticated for components implementing Relay functions to
make drop/forwarding decisions. Entities that perform "Relay"
function provide the store and forward behavior to serve the
subscription requests, they optimize media delivery latencies through
local delivery and improved media quality via local repairs, wherever
applicable. The names (Section 5) used in the QuicR protocol are
scoped and authorized to a domain by the Origin serving that domain.
Jennings, et al. Expires 12 January 2023 [Page 4]
Internet-Draft QuicR Media July 2022
4.1. Typical Publish/Subscribe Message Exchange
A QuicR "Control Channel", based on QUIC streams, is used to setup
properties for media delivery over a "Media Channel" which in turn
can be over QUIC streams or QUIC datagrams. The Control channel is
typically used to setup QuicR names to be used, control media
properties during setup and mid-session, start/stop media delivery
and so on. The media data itself is sent over the "Media Channel"
and carry enough metadata to enable Relays and end-points to make a
forward/drop decisions under congestion, for example. Further
details on the messages can be found in Section 7.
Below is an high-level exchange capturing publish/subscribe flow
between Alice, the publisher and Bob, Carl, the subscribers and the
interactions that occur between Relays on-path and the origin server.
The details on how the trust setup happens between these entities are
skipped, however.
In the exchange depicted following sequence happen
* Alice sets up a control channel (QUIC Stream) to the relay
indicating its intent to publish media with name (video1/1) as the
representation id. It does so by sending "publish_intent".
video1/1 might represent video stream camera-1, quality-id 1 (HD),
for example. QuicR manifests (Section 6) are used to setup and
consume the names being published.
* On receiving the "publish_intent" from Alice, the Relay sets up
another control channel to the authorized Origin server and
forwards Alice's "publish_intent" message.
* Once "publish_intent_ok" is received from the Origin, Relay
forwards the same to Alice to enable publishing the media over the
media channel [QUIC Stream or QUIC Datagram]
* In the meanwhile, Bob and Carl subscribe to receiving media
corresponding to the wildcard'ed name (video1/*). They each send
"subscribe" messages to the Relay on the control channel and the
same is forwarded by the Relay to the Origin. Successful
subscribe responses are sent back to Bob and via the relay. Relay
makes note of Bob and Carl's interest in the name (video1/*). The
details of knowing the name via "manifest" is skipped in the
callflow.
* Eventually, Alice publishes media on the name (video1/1) towards
the relay on the media channel, which could be over QUIC Streams
or QUIC Datagram as chosen by Alice.
Jennings, et al. Expires 12 January 2023 [Page 5]
Internet-Draft QuicR Media July 2022
* Media from Alice gets cached at the relay and is forwarded to the
Origin server (optionally). On noting about interested
subscribers, the media received from Alice is forwarded to both
Bob and Carl from the local cache by the Relay.
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ Alice │ │ Bob │ │ Carl │ │ Relay │ │Origin │
└───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘
│ │ │ │
│ ctrl: pub_intent│ │ │
│ (video1/1) │ │ ctrl:pub_intent │
│ │ │ (video1/1) │
├─────────────┼────────────┼───────────────▶│ │
│ │ │ ├─────────────────▶
│ │ │ │
│ │ │ ctrl:pub_intent_ok
│ ctrl: pub_inten│_ok │
│ │ │◀────────────────┤
◀─────────────┼────────────┼────────────────┤ │
│ │ │ │
│ │ ctrl: subscribe (video1/*) │ │
│ │ │ │
│ ├────────────┼────────────────▶ ctrl: subscribe │
│ │ │ │ (video1/*) │
│ │ │ │─────────────────▶
│ │ │ │ │
│ │ │ │ ctrl: │
│ │ │ │ subscribe_ok │
│ │ │ │ (video1/*) │
│ │ │ │ │
│ │ │ ◀─────────────────┤
│ │ │ │ │
│ │ │─────┐ add bob: │
│ │ ctrl: subscribe_ok │ ◀───┘ video1/* │
│ │ │ │
│ │◀───────────┼────────────────┤ │
│ │ │ │ │
│ │ │ ctrl:sub: │ │
│ │ │ (video1/*) │ │
│ │ │ │ │
│ │ ├────────────────▶ ctrl: subscribe │
│ │ │ │ (video1/*) │
│ │ │ │─────────────────▶
│ │ │ │ ctrl: │
│ │ │ │ subscribe_ok │
│ │ │ │ (video1/*) │
│ │ │ │ │
│ │ │ ◀─────────────────┤
Jennings, et al. Expires 12 January 2023 [Page 6]
Internet-Draft QuicR Media July 2022
│ │ │ │ │
│ │ ├────┐ add carl: │
│ │ ctrl: subscribe_ok │◀───┘ video1/* │
│ │ │ │
│ │◀───────────┼────────────────┤ │
│ │ │ │
│ media:pub:video1/1 │ │ │
│ │ │ cache │
├─────────────┼────────────┼───────────────▶│ │
│ │ │ │─────┐ │
│ │ │ │ ◀───┘ [pub] │
│ │ │ │ │
│ │ media:pub: ├─────────────────▶
│ media:pub: │ (video1/1) │ │
│ (video1/1) │ │ │
│ │◀───────────────┤ │
│◀────────────┼────────────┼────────────────┤ │
│ │ │ │ │
│ │ │ │
{: title="Pub/Sub flow between Alice(publisher), Bob, Carl
(subscribers), Relay and Origin"}
4.2. Origin Server
The Origin serves as the authorization authority for the named
resources, in the manner similar to an HTTP origin. QuicR names to
be used under a given domain and the application are authorized by
the Origin server. It is also responsible for establishing necessary
trust relationship between the clients, the relay and itself.
4.3. Relays
The Relays play an important role within the QuicR architecture.
They receive subscriptions and intent to publish and forwards them
towards the origin. This may involve sending messages directly to
the Origin Relay or possibly traverse another Relay on the path.
Replies to theses message follow the reverse direction of the request
and when the Origin gives the OK to a subscription or intent to
publish, the Relay allows the subscription or future publishes to the
Names in the request. In this role, the Relays perform the role of
subscribers (consumers) as well as publishers (producers).
Jennings, et al. Expires 12 January 2023 [Page 7]
Internet-Draft QuicR Media July 2022
Subscriptions received are aggregated. When a relay receives a
publish request with data, it will forward it both towards the Origin
and to any clients or relays that have a matching subscriptions.
This "short circuit" of distribution by a relay before the data has
even reached the Origin servers provides significant latency
reduction for clients closer to the relay.
The Relay keeps an outgoing queue of objects to be sent to the each
subscriber and objects are sent in strict priority order. Relays MAY
cache some of the information for short period of time and the time
cached may depend on the origin and local cache policies.
Section 8 covers further details on the Relay functionality.
5. Names and Named Objects
Names are basic elements with in the QuicR architecture and they
uniquely identify objects. For publishers of the media, the names
identify application defined data objects being contributed and for
the subscribers/receivers, the names correspond to application data
objects to be consumed.
The scope and granularity of the names and the data objects they
represent are application defined and controlled.
However, a given QuicR name must maintain certain properties as given
below
* Each published name must be unique and is scoped to a given domain
and an application under that domain.
* Names should support a way for the subscribers to request for the
associated data either by specifying the full or partial names.
The latter is supported via wildcarding.
* Named objects should enable caching in relays in a way CDNs cache
resources and thus can obtain similar benefits such caching
mechanisms would offer.
5.1. Named Objects
The names of each object in QuicR is composed of the following
components:
1. Domain Identifier
2. Application Identifier
Jennings, et al. Expires 12 January 2023 [Page 8]
Internet-Draft QuicR Media July 2022
3. Data Identifier
Domain component uniquely identifies a given application domain.
This is like a HTTP Origin or an standardized identifier that
uniquely identifies the application and a root relay function.
Application component is scoped under a given Domain. This component
identifies aspects specific to a given application instance hosted
under a given domain (e.g. which movie or meeting identifier).
Data identifier identifies aspects of application, for example
representation_id in a CMAF segment or video stream from a conference
user. In cases where media being delivered is naturally grouped into
independently consumable groups (video group of picture or audio
synchronization points for example), this component is futher
composed into set of such groups, which are in turn made up of set of
objects (video frames idr, p-frame within a given gop). Each such
group is identified by a monotonically increasing integer and objects
within the group are also identified by another set of monotonically
increasing integers. The groupID and objectID start at 0.
Example: In the example below the domain component identifies
acme.meeting.com domain, the application component identifies an
instance of a meeting under this domain, say "meeting123", and the
data component captures high resolution camera stream from the user
"alice" being published as object 17 under group 15.
Example 1
quicr://acme.meeting.com/meeting123/alice/cam5/HiRes/15/17
Example 2
quicr://twitch.com/channel-fluffy/video-quality-id/group12/object0
Once a named object is created, the content inside the named object
can never be changed. Objects have an expiry time after which they
should be discarded by caches. Objects have an priority that the
relays and clients can use to make drop decisions or sequencing the
sending order. The data inside an object is end-to-end encrypted
whose keys are not available to Relay(s).
5.2. Wildcarding with Names
QuicR allows subscribers to request for media based on wildcard'ed
names. Wildcarding enables subscribes/requests for media to be made
as aggregates instead of at the object level granularity. Wildcard
names are formed by skipping the right most segments of the "Data
Identifier" component of the names.
Jennings, et al. Expires 12 January 2023 [Page 9]
Internet-Draft QuicR Media July 2022
For example, in an web conferencing use case, the client may
subscribe to just the origin, meeting_id and one of the publishers so
as to get all the media from that user in a particular. The example
matches all the named objects published by the user alice in the
meeting123.
"quicr://acme.meeting.com/meeting123/alice/*"
When subscribing, there is an option to tell the relay to one of:
A. Deliver any new objects it receives that match the name
B. Deliver any new objects it receives and in addition send any
previous objects it has received that are in the same group that
matches the name.
C. Wait until an object that has a objectId that matches the name is
received then start sending any objects that match the name.
6. QuicR Manifest
QuicR Manifests provides a light-weight declarative way for the
publishers to advertise their capabilities for publishing media.
Publisher manifest advertisement captures supported codecs, encoding
rates and also use case specific media properties such as languages
supported. Publisher advertisements are intend to declare
publisher's capabilities and a publisher is free to choose a subset
of those advertised in the manifest as part of the session and thus
does not require a manifest update. This could be, for example - to
change encoding bitrate or the codec used. However, in the case
where a new capability needs to be advertised, a manifest update MAY
be necessary.
Publishers advertise their capabilities via QuicR Control channel, as
and when its deemed necessary, under a well-known name. Manifest
objects are also scoped to a domain and the application under a given
Origin server.
Subscribers can retrieve the manifest for a given session by
subscribing to the well-known manifest QuicR name. On retrieving the
manifest, Subscribers/Receivers of the media can discover names being
published and proceed to request media for the corresponding names by
sending appropriate subscriptions (with wildcarding as necessary).
A representative well-known name for subscribing to manifest updates
for channel-2, twitch live session jon.doe.music.live.tv, can be
represented as
Jennings, et al. Expires 12 January 2023 [Page 10]
Internet-Draft QuicR Media July 2022
quicr://jon.doe.music.live.tv/channel-2/manifest/*
At any point in the session, updated manifest is pushed to the
subscribers like any media objects are delivered to the subscribers
of the manifest QuicR name.
6.1. Scope of the manifest
The role of the manifest is to identify the names as well as aspects
pertaining to the associated data in a given usage context of the
application.
* Typically a manifest identifies the domain and application aspects
for the set of names that can be published.
* The content of Manifest is application defined and end-to-end
encrypted.
* The manifest is owned by the application's origin server and are
accessed as a protected resources by the authorized QuicR clients.
* The QuicR protocol treats Manifests as a named object, thus
allowing for clients to subscribe for the purposes of
bootstrapping into the session as well as to follow manifest
changes during a session [ new members joining a conference for
example].
* The manifest has well known name on the Origin server.
Also to note, a given application might provide non QuicR mechanisms
to retrieve the manifest.
Below is a sample manifest for streaming application where a media
presentation server describes media streams available for
distribution. For downstream distribution of media data to clients
with varying requirements, the central server (along with the source)
generate different quality media representations. Each such quality
is represented with a unique name and subscribers are made know of
the same via the Manifest.
Note: Below json representation is provided as an example and need
not be the only way to encode the manifest.
Jennings, et al. Expires 12 January 2023 [Page 11]
Internet-Draft QuicR Media July 2022
{
"liveSessionID" : "jon.doe.music.live.tv",
"streams: [
{
"id": "1234",
"codec": "av1",
"quality": "1280x720_30fps",
"bitrate": "1200kbps",
"crypto": "aes128-gcm",
},
{
"id": "5678",
"codec": "av1",
"quality": "3840x2160_30fps",
"bitrate": "4000kbps",
"crypto": "aes256-gcm",
},
{
"id": "9999",
"codec": "av1",
"quality": "640x480_30fps",
"crypto": "aes128-gcm",
},
]
}
Given the above manifest, if a publisher wants to send a 4k stream,
it does so by publishing objects following the below pattern
//4K Stream
publish: quicr://jon.doe.music.live.tv/video/5678/[groupN/objectM ...]
If at any point, the producer intends to move to a lower quality
stream due to underlying network conditions, it can do so by
switching the published stream as below
//480p Stream
publish: quicr://jon.doe.music.live.tv/video/9999/[groupN/objectM ...]
and subscriber who is capable of receiving any of the qualities can
do so by
// Receiving any of the published streams and use its name
// to know more information about media properties via manifest and
// object data
subscribe: quicr://jon.doe.music.live.tv/video/*
Jennings, et al. Expires 12 January 2023 [Page 12]
Internet-Draft QuicR Media July 2022
7. QuicR Protocol Design
QuicR supports delivering media over QUIC Streams as well as over
QUIC Datagrams as chosen by the application.
Media delivery in QuicR is started by the publisher/subscriber
setting up a "Control Channel" for a given QuicR name. The control
channel, which is based on QUIC stream, is used to configure and
setup properties for the "Media Channel". Media data is delivered
over the Media Channel over QUIC streams or QUIC datagrams based on
the application settings. The Control Channel can also be used to
configure in-session parameters.
7.1. Control Channel
When a client or relay begins a transaction with the relay/origin,
the client starts by opening a new bilateral stream. This stream
will act as the "control channel" for the exchange of data, carrying
a series of control messages in both directions. The same channel
can be used for carrying media "fragment" messages if the media data
is sent in "stream" mode.
The control stream will remain open as long as the peers are still
sending or receiving the media. If either peer closes the control
stream, the other peer will close its end of the stream and discard
the state associated with the media transfer.
Streams are "one way". If a peer both sends and receive media, there
will be different control streams for sending and receiving.
7.2. QuicR Control Messages
The control channel carry series of messages, encoded as a length
followed by a message value:
quicr_message {
length(16),
value(...)
}
The length is encoded as a 16 bit number in big endian network order.
Jennings, et al. Expires 12 January 2023 [Page 13]
Internet-Draft QuicR Media July 2022
7.2.1. Subscribe Message
Entities that intend to receive named objects will do so via
subscriptions to the named objects. Subscriptions are sent from the
QuicR clients to the origin server(s) (via relays, if present) and
are typically processed by the relays. See {#relay_behavior} for
further details. All the subscriptions MUST be authorized at the
Origin server.
Subscriptions are typically long-lived transactions and they stay
active until one of the following happens
* a client local policy dictates expiration of a subscription.
* optionally, a server policy dictates subscription expiration.
* the underlying transport is disconnected.
When an explicit indication is preferred to indicate the expiry of
subscription, it is indicated via "SUBSCRIPTION_EXPIRY" message.
While the subscription is active for a given name, the Relay(s) must
send named objects it receives to all the matching subscribers. A
QuicR client can renew its subscriptions at any point by sending a
new "quicr_subscribe_message". Such subscriptions MUST refresh the
existing subscriptions for that name. A renewal period of 5 seconds
is RECOMMENDED.
enum subscribe_intent
{
immediate(0),
catch_up(1),
wait_up(2),
}
quicr_subscribe_message {
* message_type(i),
* name_length(i),
* name(...),
* mask(7)
* subscribe_intent intent,
* [datagram_stream_id(i)]
* }
Jennings, et al. Expires 12 January 2023 [Page 14]
Internet-Draft QuicR Media July 2022
The message type will be set to SUBSCRIBE_STREAM (1) if the client
wants to receive the media in stream mode (via QUIC streams), or
SUBSCRIBE_DATAGRAM (2) if receiving in datagram mode. If in datagram
mode, the client must select a datagram stream id that is not yet
used for any other media stream.
The origin field in the name identifies the Origin server for which
this subscription is targeted. "name" identified the fully formed
name or wildcard name along with the appropriate bitmask length.
The "intent" field specifies how the Relay Function should provided
the named objects to the client. Following options are defined for
the "intent"
* immediate: Deliver any new objects it receives that match the name
* catch_up: Deliver any new objects it receives and in addition send
any previous objects it has received that matches the name.
* wait_up: Wait until an object that has a objectId that matches the
name is received then start sending any objects that match the
name.
7.2.1.1. Aggregating Subscriptions
Subscriptions are aggregated at entities that perform Relay Function.
Aggregating subscriptions helps reduce the number of subscriptions
for a given named object in transit and also enables efficient
distribution of published media with minimal copies between the
client and the origin server/ or other relays, as well as reduce the
latencies when there are multiple subscribers for a given named
object behind a given cloud server.
7.2.1.2. Wildcard Names
The names used in "quicr_subscribe_message" can be truncated by
skipping the right most segments of the name that is application
specific, in which case it will act as a wildcard subscription to all
names that match the provided part of the name. The same is
indicated via bitmask associated with the name in
"quicr_subscribe_message". Wildcard search on Relay(s) thus turns
into a bitmask at the appropriate bit location of the hashed name.
7.2.2. SUBSCRIBE_REPLY Message
A "quicr_subscribe_reply" provides result of the subscription.
Jennings, et al. Expires 12 January 2023 [Page 15]
Internet-Draft QuicR Media July 2022
enum response
{
ok(0),
expired(1)
fail(2),
redirect(2)
}
quicr_subscribe_reply
{
Response response
[Reason Phrase Length (i),
[Reason Phrase (..)],
}
A response of "ok" indicates successful subscription, for "failed" or
"expired" responses, "Reason Phrase" shall be populated with
appropriate reason. An response of "redirect" informs the client
that relay is no longer serving the subscriptions and client should
retry to the alternate relay provided in the redirect message.
7.2.3. PUBLISH_INTENT Message.
The "quicr_publish_intent_message" indicates the names chosen by a
Publisher for transmitting named objects within a session. This
message is sent to the Origin Server whenever a given publisher
intends to publish on a new name (which can be at the beginning of
the session or during mid session). This message is authorized at
the Origin server and thus requires a mechanism to setup the initial
trust (via out of band) between the publisher and the origin server.
quicr_publish_intent_message {
* message_type(i),
* name_length(i),
* name(...)
* datagram_capable(i)
* }
The message type will be set to PUBLISH_INTENT (6). The
"datagram_capable" flag is set to 0 if the client can only publish/
post data in stream mode, to 1 if the client is also capable of
posting media fragments as datagrams.
Jennings, et al. Expires 12 January 2023 [Page 16]
Internet-Draft QuicR Media July 2022
On a successful validation at the Origin server, a
"publish_intent_ok" message is returned by the Origin server. The
"publish_intent_ok" message is sent in response to the
"quicr_publish_intent_message", on the server side of the QUIC
control stream. This message indicates the publisher is authorized
for using the intended name provided in
"quicr_publish_intent_message".
quicr_publish_intent_ok_message {
* message_type(i),
* use_datagram(i),
* [datagram_stream_id(i)]
}
The message id is set to PUBLISH_INTENT_OK (7). The "use_datagram"
flag is set to 0 if the server wants to receive data in stream mode,
and to 1 if the server selects to receive data fragments as
datagrams. In that case, the server must select a datagram stream id
that is not yet used to receive any other media stream.
This message enables cloud relays to know the authorized names from a
given Publisher. This helps to make caching decisions, deal with
collisions and so on.
"A>A cloud relay could start caching the data associated with the
names that has not been validated yet by the origin server and decide
to flush its cache if no PUBLISH\_INTENT\_OK is received within a
given implementation defined timeout. This is an optimization that
would allow publishers to start transmitting the data without needing
to wait a RTT."
7.2.4. Start Point Message
The Start Point message indicates the begin of message to be sent for
the media. They correspond to Group ID and Object ID of the first
object that will be sent for the media. It may be sent by the server
that received a "quicr_subscribe_message", or by the client that sent
a "quicr_publish_intent_message". This message is optional: by
default, media streams start with Group ID and Object ID set to 0.
* quicr_start_point_message {
* message_type(i),
* start_group_id(i),
* start_object_id(i),
* flags(i)
* }
The message id is set to START_POINT (8).
Jennings, et al. Expires 12 January 2023 [Page 17]
Internet-Draft QuicR Media July 2022
7.2.5. Fragment Message
The quicr_fragment_message message is used to convey the content of a
media stream as a series of fragments:
quicr_fragment_message {
* message_type(i),
* group_id(i),
* object_id(i),
* best_before(i),
* flags(i),
* offset_and_fin(i),
* length(i),
* data(...)
}
flags := Reserved (3) | IsDiscardable (1) | Priority (3)
The message type will be set to FRAGMENT (5). The "offset_and_fin"
field encodes two values, as in:
offset_and_fin = 2 * offset + is_last_fragment
The flag "is_last_fragment" is set to 1 if this fragment is the last
one of an object. The offset value indicates where the fragment data
starts in the object designated by "group_id" and "object_id".
Successive messages are sent in order, which means one of the
following three conditions must be verified:
* The group id and object id match the group id and object id of the
previous fragment, the previous fragment is not a "last fragment",
and the offset matches the previous offset plus the previous
length.
* The group id matches the group id of the previous message, the
object id is equal to the object id of the previous fragment plus
1, the offset is 0, and the previous message is a "last fragment".
* The group id matches the group id of the previous message plus 1,
the object id is 0, the offset is 0, and the previous message is a
"last fragment".
7.2.6. Fin Message
The Fin message indicates the final point of a media stream.
Jennings, et al. Expires 12 January 2023 [Page 18]
Internet-Draft QuicR Media July 2022
* quicr_fin_message {
* message_type(i),
* final_group_id(i),
* final_object_id(i)
* }
The message type will be set to FIN (3). The final "group_id" is set
to the "group_id" of the last fragment sent. The final "object_id"
is set to the object_id of the last fragment sent, plus 1. This
message is not sent when fragments are sent on stream.
7.2.7. SUBSCRIBE_CANCEL Message
A "quicr_subscribe_cancel_message" indicates a given subscription is
no longer valid. This message is an optional message and is sent to
indicate the peer about discontinued interest in a given named data.
* quicr_subscribe_cancel_message {
* message_type(i),
* name_length(i),
* name(...)
* Reason Phrase Length (i),
* Reason Phrase (..),
* }
7.2.8. RELAY_REDIRECT MESSAGE
"quicr_relay_redirect_message" enables relay failover scenarios that
is sent in response to PUBLISH, PUBLISH_INTENT and SUBSCRIBE messages
indicating the new relay to the clients.
quicr_relay_redirect_message
{
relay_address_length(i),
relay_address(...)
}
7.3. Sending Media as Datagrams
If transmission as datagram is negotiated, the media fragments are
sent as QUIC Datagram frames.
7.3.1. Datagram Header
The datagram frames are encoded as a datagram header, followed by the
bytes in the fragment:
Jennings, et al. Expires 12 January 2023 [Page 19]
Internet-Draft QuicR Media July 2022
datagram_frame_content {
datagram_header,
datagram_content
}
The datagram header is defined as:
* quicr_datagram_header {
* datagram_stream_id (i),
* group_id (i),
* object_id (i),
* offset_and_fin (i),
* best_before(i),
* flags (8),
* [nb_objects_previous_group (i)]
* }
flags := Reserved (3) | IsDiscardable (1) | Priority (3)
The datagram_stream_id identifies a specific media stream. The ID is
chosen by the receiver of the media stream, and conveyed by the
Request or Accept messages.
The "offset_and_fin" field encodes two values, as in:
offset_and_fin = 2*offset + is_last_fragment
The "flags" identifies the relative "priority" of this object and if
the object can be discarded. This can help Relay to make dropping/
caching decisions. "best_before" identifies the time upto when the
data for the given object valid. This aids in caches dropping the
data after "best_before" and also cease any error recovery mechanisms
that might be in progress for the corresponding data. "best_before"
can also be used by clients to make send/drop decisions.
The "nb_objects_previous_group" is present if and only if this is the
first fragment of the first object in a group, i.e., "object_id" and
"offset" are both zero. The number indicates how many objects were
sent in the previous groups. It enables receiver to check whether
all these objects have been received.
Jennings, et al. Expires 12 January 2023 [Page 20]
Internet-Draft QuicR Media July 2022
8. Relay Function and Relays
Clients may be configured to connect to a local relay which then does
a Publish/Subscribe for the appropriate named data towards the origin
or towards another Relay. These relays can aggregate the
subscriptions of multiple clients. This allows a relay in the LAN to
aggregate request from multiple clients in subscription to the same
data such that only one copy of the data flows across the WAN. In
the case where there is only one client, this may still provides
benefit in that a client that is experiencing loss on WIFI WAN has a
very short RTT to the local relay so can recover the lost data much
faster, and with less impact on end user QoE, than having to go
across the LAN to recover the data.
Relays can also be deployed in classic CDN cache style for large
scale streaming applications yet still provide much lower latency
than traditional CDNs using Dash or HLS. Moving these relays into
the 5G network close to clients may provide additional increase in
QoE.
At a high level, Relay Function within QuicR architecture support
store and forward behavior. Relay function can be realized in any
component of the QuicR architecture depending on the application.
Typical use-cases might require the intermediate servers (caches) and
the origin server to implement the relay function. However the
endpoint themselves can implement the Relay function in a Isomorphic
deployment, if needed.
The relays are capable of receiving data in stream mode or in
datagram mode. In both modes, relays will cache fragments as they
arrive.
In all modes, the relays maintain a list of connections that will
receive new fragments when they are ready: connections from clients
that have subscribed to the stream through this relay; and, if the
media was received from a client, a connection to the origin to pass
the content of the client-posted media to the origin. When new
fragments are received, they are posted on the relevant connections
as soon as the flow control and congestion control of the underlying
QUIC connections allow.
8.1. Cache and Relaying
The prototype relays maintain a separate cache of received fragments
for each media stream that it is processing. If fragments are
received in stream mode, they will arrive in order. If fragments are
received in datagram mode, fragments may arrive out of order.
Jennings, et al. Expires 12 January 2023 [Page 21]
Internet-Draft QuicR Media July 2022
The cache is created the first time a client connection refers to the
media URL. This might be:
* A client connection requesting the name, in which case the relay
will ask a copy of the media from the origin or the next hop relay
towards the origin.
* A client connection publishing named data, in which case the relay
will post a copy of the media towards the origin.
Once the media is available, the relay will learn the starting group
ID and object ID.
Fragments are received from the "incoming" connection. If fragments
are received in stream mode, they will arrive in order. If fragments
are received in datagram mode, fragments may arrive out of order.
When receiving in datagram mode, the media order is used to remove
incoming duplicate fragments. When a non duplicate fragment is
received, it is added to the cache and posted to corresponding
subscribers over streams or datagrams, when flow and congestion
control allow transmissions
In stream mode, the transmission may be delayed until fragments are
received in order. If the last fragment received "fills a hole",
that fragment and the next available fragments in media order will be
forwarded.
8.2. Out of order relaying
As noted in Section 8.1, fragments that arrive out of order are
relayed immediately.
This design has better properties compared to the following
alternatives:
* insisting on full order before relaying, as is done for stream
mode; OR
* insisting on full reception of all fragments making an object.
Jennings, et al. Expires 12 January 2023 [Page 22]
Internet-Draft QuicR Media July 2022
Full order would introduce the same head-of-line blocking also
visible in stream-based relays. In theory, relaying full objects
without requiring that objects be ordered would avoid some of the
head-of-line blocking, but in practice it is observed when some
streams contain large and small objects, and that losses affecting
fragments of large objects cause almost the same head of line
blocking delays as full ordering. Moreover, if losses happen at
several places in the relay graph, the delays will accumulate. Out
of order relaying avoids these delays.
8.3. Relay or Cache or Drop Decisions
Relays makes use of priority, time-to-live, is_discardable metadata
properties from the published data to make forward or drop decisions
when reacting to congestion as indicated by the underlying QUIC
stack. The same can be used to make caching decisions.
8.4. Cache cleanup
Relays store objects no more than "best_before" time associated with
the object. Congestion/Rate control feedback can further influence
what gets cached based on the relative priority and rate at which
data can be delivered. Local cache policies can also limit the
amount and duration of data that can be cached.
8.5. Relay fail over
A relay that wants to shutdown shall use the redirect message to move
traffic to a new relay. If a relay has failed and restarted or been
load balanced to a different relay, the client will need to
resubscribe to the new relay after setting up the connection.
TODO: Cluster so high reliable relays should share subscription info
and publication to minimize of loss of data during a full over.
8.6. Relay Discovery
Local relays can be discovered via MDNS query to TODO. Cloud relays
are discovered via application defined ways that is out of scope of
this document. A Relay can send a message to client with the address
of new relay. Client moves to the new relay with all of its
Subscriptions and then Client unsubscribes from old relay and closes
connection to it.
This allows for make before break transfer from one relay to another
so that no data is lost during transition. One of the uses of this
is upgrade of the Relay software during operation.
Jennings, et al. Expires 12 January 2023 [Page 23]
Internet-Draft QuicR Media July 2022
Appendix A. Acknowledgments
Thanks to TODO for contributions and suggestions to this
specification.
Appendix B. TODO Items
* Authorization and Authentication Considerations for control and
media messages
* End to End Security of named objects
* Manifest Encoding
Authors' Addresses
Cullen Jennings
cisco
Canada
Email: fluffy@iii.ca
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com
Christian Huitema
Private Octopus Inc.
Email: huitema@huitema.net
Jennings, et al. Expires 12 January 2023 [Page 24]
