From cbce8aabfbd833d1ed29e8e847d7e5c4ae509715 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 14 Aug 2024 11:22:41 -0700 Subject: [PATCH 01/23] Rebase --- draft-ietf-moq-transport.md | 152 +++++++++++++++++------------------- 1 file changed, 71 insertions(+), 81 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 6bb6cfd0..cfe4011e 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -310,9 +310,39 @@ payload. This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads. +## Peeps {#model-peeps} + +A peep is a collection of one or more objects and is a sub-unit of a group +({{model-group}}). A peep consists of a set of objects within a group that +have a dependency and priority relationship consistent with sharing a QUIC +stream. + +When a Track's forwarding preference (see {{object-fields}}) is "Track" or +"Datagram", Groups do not contain Peeps, no Peep IDs are assigned, and the +description in the remainder of this section does not apply. + +QUIC streams offer in-order reliable delivery, differentiation of priority in +delivery, and the ability to cancel sending and retransmission of data. + +In general, higher object IDs in a peep are dependent on lower object IDs +in that peep. If an object is dependent on a lower object ID in a peep but +higher object IDs in the same peep are not dependent on it, it should +generally be in a separate peep. + +For example, imagine that Object 3 and Object 2 are both dependent on Object +1, but are have no depedency relationship with each other. It would +therefore be appropriate for Objects 1 and 3 to be in one peep and Object 2 +in another, with lower priority. The separate stream prevents delivery of +Object 3 from being blocked by the loss of Object 2. + +Original publishers assign each Peep a Peep ID. + +Every object belongs to exactly one Peep. Applications define this mapping, +but SHOULD follow the guidelines above when mapping objects to peeps. + ## Groups {#model-group} -A group is a collection of objects and is a sub-unit of a track +A group is a collection of one or more peeps and is a sub-unit of a track ({{model-track}}). Objects within a group SHOULD NOT depend on objects in other groups. A group behaves as a join point for subscriptions. A new subscriber might not want to receive the entire track, and may @@ -555,7 +585,7 @@ The subscriber indicates the priority of a subscription via the Subscriber Priority field and the original publisher indicates priority in every stream or datagram header. As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a -property of the Track and the Objects it contains. In both cases, a lower +property of the Track and the Peeps it contains. In both cases, a lower value indicates a higher priority, with 0 being the highest priority. The Subscriber Priority is considered first when selecting a subscription @@ -582,9 +612,10 @@ the corresponding SUBSCRIBE_OK. Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a -higher Object Id, regardless of the specified Group Order. If the priority -varies within a Group, higher priority Objects are sent before lower -priority Objects. +higher Object Id, regardless of the specified Group Order. If the group +contains more than one Peep and the priority varies between these Peeps, +higher priority Peeps are sent before lower priority Peeps, and Objects +in peeps are sent in increasing Object Id order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used. @@ -1256,7 +1287,6 @@ TRACK_STATUS_REQUEST Message { {: #moq-track-status-request-format title="MOQT TRACK_STATUS_REQUEST Message"} - ## SUBSCRIBE_OK {#message-subscribe-ok} A publisher sends a SUBSCRIBE_OK control message for successful @@ -1488,7 +1518,7 @@ An OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, cache, and forward it. Objects are sent by publishers. -### Canonical Object Fields +### Canonical Object Fields {#object-fields} A canonical MoQ Object has the following information: @@ -1505,9 +1535,13 @@ group. the Object {{priorities}}. * Object Forwarding Preference: An enumeration indicating how a publisher sends -an object. The preferences are Track, Group, Object and Datagram. An Object +an object. The preferences are Track, Peep, and Datagram. An Object MUST be sent according to its `Object Forwarding Preference`, described below. +* Peep ID: The object is a member of the indicated peep ID ({{model-peep}}) +within the group. This field is omitted if the Object Forwarding Preference is +Track or Datagram. + * Object Status: As enumeration used to indicate missing objects or mark the end of a group or track. See {{object-status}} below. @@ -1557,45 +1591,14 @@ are sent on a new stream. This is to avoid the status message being lost in cases such as a relay dropping a group and reseting the stream the group is being sent on. +### Object Message Formats -## Object Stream - -An `OBJECT_STREAM` message carries a single object on a stream. An -`OBJECT_STREAM` message MUST be the first and only message on a unidirectional -stream. - -An Object received in an `OBJECT_STREAM` message has an `Object Forwarding -Preference` = `Object`. - -To send an Object with `Object Forwarding Preference` = `Object`, open a stream, -serialize object fields below, and terminate the stream. - -~~~ -OBJECT_STREAM Message { - Subscribe ID (i), - Track Alias (i), - Group ID (i), - Object ID (i), - Publisher Priority (8), - Object Payload Length (i), - [Object Status (i)], - Object Payload (..), -} -~~~ -{: #moq-transport-object-stream-format title="MOQT OBJECT_STREAM Message"} - -* Subscribe ID: Subscription Identifier as defined in {{message-subscribe-req}}. - -* Track Alias: Identifies the Track Namespace and Track Name as defined in -{{message-subscribe-req}}. - -If the Track Namespace and Track Name identified by the Track Alias are -different from those specified in the subscription identified by Subscribe ID, -the subscriber MUST close the session with a Protocol Violation. - -* Other fields: As described in {{canonical-object-fields}}. +Every Track has a single 'Object Forwarding Preference' and the Original +Publisher MUST NOT mix different forwarding preferences within a single track. +If a subscriber receives different forwarding preferences for a track, it +SHOULD close the session with an error of 'Protocol Violation'. -## Object Datagram +**Object Datagram Message** An `OBJECT_DATAGRAM` message carries a single object in a datagram. @@ -1620,24 +1623,24 @@ OBJECT_DATAGRAM Message { ~~~ {: #object-datagram-format title="MOQT OBJECT_DATAGRAM Message"} -## Multi-Object Streams +### Streams -When multiple objects are sent on a stream, the stream begins with a stream +When objects are sent on streams, the stream begins with a stream header message and is followed by one or more sets of serialized object fields. If a stream ends gracefully in the middle of a serialized Object, terminate the session with a Protocol Violation. -A publisher SHOULD NOT open more than one multi-object stream at a time with the -same stream header message type and fields. +A publisher SHOULD NOT open more than one stream at a time with the same stream +header message type and fields. TODO: figure out how a relay closes these streams -### Stream Header Track +**Stream Header Track** When a stream begins with `STREAM_HEADER_TRACK`, all objects on the stream belong to the track requested in the Subscribe message identified by `Subscribe -ID`. All objects on the stream have the `Publisher Priority` specified in the +ID`. All objects on the stream have the `Object Send Order` specified in the stream header. ~~~ @@ -1670,32 +1673,32 @@ The Object Status field is only sent if the Object Payload Length is zero. A publisher MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or -equal to a previously sent Object ID within a given group on that stream. +equal to a previously sent Object ID with the same Group ID. -### Stream Header Group +**Stream Header Peep** -When a stream begins with `STREAM_HEADER_GROUP`, all objects on the stream +When a stream begins with `STREAM_HEADER_PEEP`, all objects on the stream belong to the track requested in the Subscribe message identified by `Subscribe -ID` and the group indicated by `Group ID`. All objects on the stream -have the `Publisher Priority` specified in the stream header. +ID` and the peep indicated by 'Group ID' and `Peep ID`. ~~~ -STREAM_HEADER_GROUP Message { +STREAM_HEADER_PEEP Message { Subscribe ID (i), Track Alias (i), Group ID (i), + Peep ID (i), Publisher Priority (8), } ~~~ -{: #stream-header-group-format title="MOQT STREAM_HEADER_GROUP Message"} +{: #stream-header-peep-format title="MOQT STREAM_HEADER_PEEP Message"} -All Objects received on a stream opened with `STREAM_HEADER_GROUP` have an -`Object Forwarding Preference` = `Group`. +All Objects received on a stream opened with `STREAM_HEADER_PEEP` have an +`Object Forwarding Preference` = `Peep`. -To send an Object with `Object Forwarding Preference` = `Group`, find the open -stream that is associated with the subscription and `Group ID`, or open a new -one and send the `STREAM_HEADER_GROUP` if needed, then serialize the following -fields. +To send an Object with `Object Forwarding Preference` = `Peep`, find the open +stream that is associated with the subscription, `Group ID` and `Peep ID`, +or open a new one and send the `STREAM_HEADER_PEEP`. Then serialize the +ollowing fields. The Object Status field is only sent if the Object Payload Length is zero. @@ -1712,7 +1715,7 @@ The Object Status field is only sent if the Object Payload Length is zero. A publisher MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. -## Examples +### Examples: Sending a track on one stream: @@ -1736,16 +1739,16 @@ STREAM_HEADER_TRACK { } ~~~ -Sending a group on one stream, with a unordered object in the group appearing -on its own stream. +Sending a peep on one stream: ~~~ Stream = 2 -STREAM_HEADER_GROUP { +STREAM_HEADER_PEEP { Subscribe ID = 2 Track Alias = 2 Group ID = 0 + Peep ID = 0 Publisher Priority = 0 } { @@ -1758,21 +1761,8 @@ STREAM_HEADER_GROUP { Object Payload Length = 4 Payload = "efgh" } - -Stream = 6 - -OBJECT_STREAM { - Subscribe ID = 3 - Track Alias = 3 - Group ID = 0 - Object ID = 1 - Publisher Priority = 0 - Payload = "moqrocks" -} ~~~ - - # Security Considerations {#security} TODO: Expand this section, including subscriptions. From bbaa1ebd4a0049f8c6977b80c7b655f0d127f4c4 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Mon, 29 Jul 2024 15:18:34 -0700 Subject: [PATCH 02/23] Rebase --- draft-ietf-moq-transport.md | 38 ++++++++++++++++++++++++++++--------- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index cfe4011e..f8bd6221 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -324,10 +324,21 @@ description in the remainder of this section does not apply. QUIC streams offer in-order reliable delivery, differentiation of priority in delivery, and the ability to cancel sending and retransmission of data. -In general, higher object IDs in a peep are dependent on lower object IDs -in that peep. If an object is dependent on a lower object ID in a peep but -higher object IDs in the same peep are not dependent on it, it should -generally be in a separate peep. +Every object belongs to exactly one Peep. + +Original publishers assign each Peep a Peep ID, and do so as they see fit. +However, the following strategy is RECOMMENDED: + +- Higher object IDs are dependent on lower object IDs in the same peep. + +- If two objects are dependent on the same lower object ID, but are not +dependent on each other, one ought to assigned the same peep as the lower +ID, but the other ought to be in a different peep. The second peep would +ideally have a lower priority than the one with two objects. + +- There often multiple assignment schemes that meet these conditions. +Original publishers ought to choose an assignment that minimizes the number +of peeps (and therefore QUIC streams) in the group. For example, imagine that Object 3 and Object 2 are both dependent on Object 1, but are have no depedency relationship with each other. It would @@ -335,10 +346,18 @@ therefore be appropriate for Objects 1 and 3 to be in one peep and Object 2 in another, with lower priority. The separate stream prevents delivery of Object 3 from being blocked by the loss of Object 2. -Original publishers assign each Peep a Peep ID. +Alternatively, objects 1 and 2 could be in one peep and 3 in another. The +optimal choice would depend on the dependencies of later objects. -Every object belongs to exactly one Peep. Applications define this mapping, -but SHOULD follow the guidelines above when mapping objects to peeps. +An original publisher might not follow these guidelines. Reasons would +include implementation complexity, lack of foreknowledge of the dependencies +of further objects, the knowledge that the transport is WebTransport over +HTTP/2 (thus introducing head-of-line blocking across streams), or knowledge +of low session stream limits that require aggregation of independent objects +into the same stream. + +For the purposes of peep assignment, the dependencies of objects with non- +normal status are described in {{object-status}}. ## Groups {#model-group} @@ -1286,7 +1305,6 @@ TRACK_STATUS_REQUEST Message { ~~~ {: #moq-track-status-request-format title="MOQT TRACK_STATUS_REQUEST Message"} - ## SUBSCRIBE_OK {#message-subscribe-ok} A publisher sends a SUBSCRIBE_OK control message for successful @@ -1512,7 +1530,7 @@ Publisher MUST NOT mix different forwarding preferences within a single track. If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. -## Object Headers {#message-object} +## OBJECT {#message-object} An OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, @@ -1763,6 +1781,8 @@ STREAM_HEADER_PEEP { } ~~~ + + # Security Considerations {#security} TODO: Expand this section, including subscriptions. From 2b71bd7b0749192dbe65c8663d0100b4dcb4638b Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Mon, 29 Jul 2024 15:50:56 -0700 Subject: [PATCH 03/23] typos --- draft-ietf-moq-transport.md | 262 ++++++++++++++++++++++++++++++++++++ 1 file changed, 262 insertions(+) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index f8bd6221..fccd0c1d 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1305,6 +1305,268 @@ TRACK_STATUS_REQUEST Message { ~~~ {: #moq-track-status-request-format title="MOQT TRACK_STATUS_REQUEST Message"} +<<<<<<< HEAD +======= + + +## OBJECT {#message-object} + +An OBJECT message contains a range of contiguous bytes from from the +specified track, as well as associated metadata required to deliver, +cache, and forward it. Objects are sent by publishers. + +### Canonical Object Fields {#object-fields} + +A canonical MoQ Object has the following information: + +* Track Namespace and Track Name: The track this object belongs to. + +* Group ID: The object is a member of the indicated group ID +{{model-group}} within the track. + +* Object ID: The order of the object within the group. The +IDs starts at 0, increasing sequentially for each object within the +group. + +* Publisher Priority: An 8 bit integer indicating the publisher's priority for +the Object {{priorities}}. + +* Object Forwarding Preference: An enumeration indicating how a publisher sends +an object. The preferences are Track, Peep, and Datagram. An Object +MUST be sent according to its `Object Forwarding Preference`, described below. + +* Peep ID: The object is a member of the indicated peep ID ({{model-peep}}) +within the group. This field is omitted if the Object Forwarding Preference is +Track or Datagram. + +* Object Status: As enumeration used to indicate missing +objects or mark the end of a group or track. See {{object-status}} below. + +* Object Payload: An opaque payload intended for an End Subscriber and SHOULD +NOT be processed by a relay. Only present when 'Object Status' is Normal (0x0). + +#### Object Status {#object-status} + +The Object Status informs subscribers what objects will not be received +because they were never produced, are no longer available, or because they +are beyond the end of a group or track. + +`Status` can have following values: + +* 0x0 := Normal object. The payload is array of bytes and can be empty. + +* 0x1 := Indicates Object does not exist. Indicates that this object + does not exist at any publisher and it will not be published in + the future. This SHOULD be cached. + +* 0x2 := Indicates Group does not exist. Indicates that objects with + this GroupID do not exist at any publisher and they will not be + published in the future. This SHOULD be cached. + +* 0x3 := Indicates end of Group. ObjectId is one greater that the + largest object produced in the group identified by the + GroupID. This is sent right after the last object in the + group. This SHOULD be cached. + +* 0x4 := Indicates end of Track and Group. GroupID is one greater than + the largest group produced in this track and the ObjectId is + one greater than the largest object produced in that + group. This is sent right after the last object in the + track. This SHOULD be cached. + +Any other value SHOULD be treated as a protocol error and terminate the +session with a Protocol Violation ({{session-termination}}). +Any object with a status code other than zero MUST have an empty payload. + +Though some status information could be inferred from QUIC stream state, +that information is not reliable and cacheable. + +For the purposes of Peep assignment, original publishers SHOULD treat +"Object does not exist: and "end of Group" messages as dependent on the previous +object ID and highest Normal object ID in the group, respectively. This +reduces the number of streams required to transmit a group. + +"Group does not exist" and "end of Track and Group" messages have unique Group +IDs and therefore are always constitute a single-object Peep. + +If a stream is reset before the "end of Group" message present in a peep is +fully acknowledged, that message is instead sent on a separate stream with the +same peep ID. + +### Object Message Formats + +Every Track has a single 'Object Forwarding Preference' and the Original +Publisher MUST NOT mix different forwarding preferences within a single track. +If a subscriber receives different forwarding preferences for a track, it +SHOULD close the session with an error of 'Protocol Violation'. + +**Object Datagram Message** + +An `OBJECT_DATAGRAM` message carries a single object in a datagram. + +An Object received in an `OBJECT_DATAGRAM` message has an `Object +Forwarding Preference` = `Datagram`. To send an Object with `Object +Forwarding Preference` = `Datagram`, determine the length of the fields and +payload and send the Object as datagram. In certain scenarios where the object +size can be larger than maximum datagram size for the session, the Object +will be dropped. + +~~~ +OBJECT_DATAGRAM Message { + Subscribe ID (i), + Track Alias (i), + Group ID (i), + Object ID (i), + Publisher Priority (8), + Object Payload Length (i), + [Object Status (i)], + Object Payload (..), +} +~~~ +{: #object-datagram-format title="MOQT OBJECT_DATAGRAM Message"} + +### Streams + +When objects are sent on streams, the stream begins with a stream +header message and is followed by one or more sets of serialized object fields. +If a stream ends gracefully in the middle of a serialized Object, terminate the +session with a Protocol Violation. + +A publisher SHOULD NOT open more than one stream at a time with the same stream +header message type and fields. + + +TODO: figure out how a relay closes these streams + +**Stream Header Track** + +When a stream begins with `STREAM_HEADER_TRACK`, all objects on the stream +belong to the track requested in the Subscribe message identified by `Subscribe +ID`. All objects on the stream have the `Publisher Priority` specified in the +stream header. + +~~~ +STREAM_HEADER_TRACK Message { + Subscribe ID (i) + Track Alias (i), + Publisher Priority (8), +} +~~~ +{: #stream-header-track-format title="MOQT STREAM_HEADER_TRACK Message"} + +All Objects received on a stream opened with STREAM_HEADER_TRACK have an `Object +Forwarding Preference` = `Track`. + +To send an Object with `Object Forwarding Preference` = `Track`, find the open +stream that is associated with the subscription, or open a new one and send the +`STREAM_HEADER_TRACK` if needed, then serialize the following object fields. +The Object Status field is only sent if the Object Payload Length is zero. + +~~~ +{ + Group ID (i), + Object ID (i), + Object Payload Length (i), + [Object Status (i)], + Object Payload (..), +} +~~~ +{: #object-track-format title="MOQT Track Stream Object Fields"} + +A publisher MUST NOT send an Object on a stream if its Group ID is less than a +previously sent Group ID on that stream, or if its Object ID is less than or +equal to a previously sent Object ID with the same Group ID. + +**Stream Header Peep** + +When a stream begins with `STREAM_HEADER_PEEP`, all objects on the stream +belong to the track requested in the Subscribe message identified by `Subscribe +ID` and the peep indicated by 'Group ID' and `Peep ID`. + +~~~ +STREAM_HEADER_PEEP Message { + Subscribe ID (i), + Track Alias (i), + Group ID (i), + Peep ID (i), + Publisher Priority (8), +} +~~~ +{: #stream-header-peep-format title="MOQT STREAM_HEADER_PEEP Message"} + +All Objects received on a stream opened with `STREAM_HEADER_PEEP` have an +`Object Forwarding Preference` = `Peep`. + +To send an Object with `Object Forwarding Preference` = `Peep`, find the open +stream that is associated with the subscription, `Group ID` and `Peep ID`, +or open a new one and send the `STREAM_HEADER_PEEP`. Then serialize the +ollowing fields. + +The Object Status field is only sent if the Object Payload Length is zero. + +~~~ +{ + Object ID (i), + Object Payload Length (i), + [Object Status (i)], + Object Payload (..), +} +~~~ +{: #object-group-format title="MOQT Group Stream Object Fields"} + +A publisher MUST NOT send an Object on a stream if its Object ID is less than a +previously sent Object ID within a given group in that stream. + +### Examples: + +Sending a track on one stream: + +~~~ +STREAM_HEADER_TRACK { + Subscribe ID = 1 + Track Alias = 1 + Publisher Priority = 0 +} +{ + Group ID = 0 + Object ID = 0 + Object Payload Length = 4 + Payload = "abcd" +} +{ + Group ID = 1 + Object ID = 0 + Object Payload Length = 4 + Payload = "efgh" +} +~~~ + +Sending a peep on one stream: + +~~~ +Stream = 2 + +STREAM_HEADER_PEEP { + Subscribe ID = 2 + Track Alias = 2 + Group ID = 0 + Peep ID = 0 + Publisher Priority = 0 +} +{ + Object ID = 0 + Object Payload Length = 4 + Payload = "abcd" +} +{ + Object ID = 1 + Object Payload Length = 4 + Payload = "efgh" +} +~~~ + + +>>>>>>> bb27020 (typos) ## SUBSCRIBE_OK {#message-subscribe-ok} A publisher sends a SUBSCRIBE_OK control message for successful From 4f341eeb6a5f4acab45ac805a3a89c6d55e7d166 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Mon, 29 Jul 2024 15:53:40 -0700 Subject: [PATCH 04/23] typo --- draft-ietf-moq-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index fccd0c1d..03e99ed8 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1382,7 +1382,7 @@ Though some status information could be inferred from QUIC stream state, that information is not reliable and cacheable. For the purposes of Peep assignment, original publishers SHOULD treat -"Object does not exist: and "end of Group" messages as dependent on the previous +"Object does not exist" and "end of Group" messages as dependent on the previous object ID and highest Normal object ID in the group, respectively. This reduces the number of streams required to transmit a group. From 82c85d5d0937f66b16f770fedf287d9d3618ce77 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 14 Aug 2024 11:12:14 -0700 Subject: [PATCH 05/23] Response to reviews --- draft-ietf-moq-transport.md | 34 +++++++++++++++++++++++----------- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 03e99ed8..c262dbf4 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -313,20 +313,26 @@ modify object payloads. ## Peeps {#model-peeps} A peep is a collection of one or more objects and is a sub-unit of a group -({{model-group}}). A peep consists of a set of objects within a group that +({{model-group}}). A peep consists of a set of objects within a Group that have a dependency and priority relationship consistent with sharing a QUIC -stream. +stream. In some cases, a Group will be most effectively delivered using more +than one stream.. When a Track's forwarding preference (see {{object-fields}}) is "Track" or "Datagram", Groups do not contain Peeps, no Peep IDs are assigned, and the description in the remainder of this section does not apply. -QUIC streams offer in-order reliable delivery, differentiation of priority in -delivery, and the ability to cancel sending and retransmission of data. +QUIC streams offer in-order reliable delivery and the ability to cancel sending +and retransmission of data. Furthermore, many implementations offer the ability +to control the relative priority of streams, which allows control over the +scheduling of sending data on active streams. + +Every object within a Group belongs to exactly one Peep. -Every object belongs to exactly one Peep. +Original publishers assign each Peep a Peep ID, and do so as they see fit. The +scope of a Peep ID is a Group, so Peeps from different Groups MAY share a Peep +ID without implying any relationship between them. -Original publishers assign each Peep a Peep ID, and do so as they see fit. However, the following strategy is RECOMMENDED: - Higher object IDs are dependent on lower object IDs in the same peep. @@ -1365,8 +1371,8 @@ are beyond the end of a group or track. * 0x3 := Indicates end of Group. ObjectId is one greater that the largest object produced in the group identified by the - GroupID. This is sent right after the last object in the - group. This SHOULD be cached. + GroupID, including any end of Peep objects. This is sent right after + the last object, of any Status, in the group. This SHOULD be cached. * 0x4 := Indicates end of Track and Group. GroupID is one greater than the largest group produced in this track and the ObjectId is @@ -1374,6 +1380,10 @@ are beyond the end of a group or track. group. This is sent right after the last object in the track. This SHOULD be cached. +* 0x5 := Indicates end of Peep. ObjectIds increment by one, beginning after the + last normal Object in the Group. These objects MUST NOT appear if + normal Objects in the group are not assigned Peep IDs. + Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation ({{session-termination}}). Any object with a status code other than zero MUST have an empty payload. @@ -1382,9 +1392,11 @@ Though some status information could be inferred from QUIC stream state, that information is not reliable and cacheable. For the purposes of Peep assignment, original publishers SHOULD treat -"Object does not exist" and "end of Group" messages as dependent on the previous -object ID and highest Normal object ID in the group, respectively. This -reduces the number of streams required to transmit a group. +"Object does not exist" and "end of Peep" objects as dependent on the previous +object ID in the Group and highest Normal object ID in the peep, respectively. +End of Group objects SHOULD be treated as dependent on the Object with the +highest ID in the group. This reduces the number of streams required to transmit +a group. "Group does not exist" and "end of Track and Group" messages have unique Group IDs and therefore are always constitute a single-object Peep. From d2ac8bcb6771f5e430fb034f532a60dcec17e8b7 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 14 Aug 2024 11:27:18 -0700 Subject: [PATCH 06/23] Fix botched rebase --- draft-ietf-moq-transport.md | 270 +----------------------------------- 1 file changed, 2 insertions(+), 268 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index c262dbf4..bbcf4fa7 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1311,274 +1311,6 @@ TRACK_STATUS_REQUEST Message { ~~~ {: #moq-track-status-request-format title="MOQT TRACK_STATUS_REQUEST Message"} -<<<<<<< HEAD -======= - - -## OBJECT {#message-object} - -An OBJECT message contains a range of contiguous bytes from from the -specified track, as well as associated metadata required to deliver, -cache, and forward it. Objects are sent by publishers. - -### Canonical Object Fields {#object-fields} - -A canonical MoQ Object has the following information: - -* Track Namespace and Track Name: The track this object belongs to. - -* Group ID: The object is a member of the indicated group ID -{{model-group}} within the track. - -* Object ID: The order of the object within the group. The -IDs starts at 0, increasing sequentially for each object within the -group. - -* Publisher Priority: An 8 bit integer indicating the publisher's priority for -the Object {{priorities}}. - -* Object Forwarding Preference: An enumeration indicating how a publisher sends -an object. The preferences are Track, Peep, and Datagram. An Object -MUST be sent according to its `Object Forwarding Preference`, described below. - -* Peep ID: The object is a member of the indicated peep ID ({{model-peep}}) -within the group. This field is omitted if the Object Forwarding Preference is -Track or Datagram. - -* Object Status: As enumeration used to indicate missing -objects or mark the end of a group or track. See {{object-status}} below. - -* Object Payload: An opaque payload intended for an End Subscriber and SHOULD -NOT be processed by a relay. Only present when 'Object Status' is Normal (0x0). - -#### Object Status {#object-status} - -The Object Status informs subscribers what objects will not be received -because they were never produced, are no longer available, or because they -are beyond the end of a group or track. - -`Status` can have following values: - -* 0x0 := Normal object. The payload is array of bytes and can be empty. - -* 0x1 := Indicates Object does not exist. Indicates that this object - does not exist at any publisher and it will not be published in - the future. This SHOULD be cached. - -* 0x2 := Indicates Group does not exist. Indicates that objects with - this GroupID do not exist at any publisher and they will not be - published in the future. This SHOULD be cached. - -* 0x3 := Indicates end of Group. ObjectId is one greater that the - largest object produced in the group identified by the - GroupID, including any end of Peep objects. This is sent right after - the last object, of any Status, in the group. This SHOULD be cached. - -* 0x4 := Indicates end of Track and Group. GroupID is one greater than - the largest group produced in this track and the ObjectId is - one greater than the largest object produced in that - group. This is sent right after the last object in the - track. This SHOULD be cached. - -* 0x5 := Indicates end of Peep. ObjectIds increment by one, beginning after the - last normal Object in the Group. These objects MUST NOT appear if - normal Objects in the group are not assigned Peep IDs. - -Any other value SHOULD be treated as a protocol error and terminate the -session with a Protocol Violation ({{session-termination}}). -Any object with a status code other than zero MUST have an empty payload. - -Though some status information could be inferred from QUIC stream state, -that information is not reliable and cacheable. - -For the purposes of Peep assignment, original publishers SHOULD treat -"Object does not exist" and "end of Peep" objects as dependent on the previous -object ID in the Group and highest Normal object ID in the peep, respectively. -End of Group objects SHOULD be treated as dependent on the Object with the -highest ID in the group. This reduces the number of streams required to transmit -a group. - -"Group does not exist" and "end of Track and Group" messages have unique Group -IDs and therefore are always constitute a single-object Peep. - -If a stream is reset before the "end of Group" message present in a peep is -fully acknowledged, that message is instead sent on a separate stream with the -same peep ID. - -### Object Message Formats - -Every Track has a single 'Object Forwarding Preference' and the Original -Publisher MUST NOT mix different forwarding preferences within a single track. -If a subscriber receives different forwarding preferences for a track, it -SHOULD close the session with an error of 'Protocol Violation'. - -**Object Datagram Message** - -An `OBJECT_DATAGRAM` message carries a single object in a datagram. - -An Object received in an `OBJECT_DATAGRAM` message has an `Object -Forwarding Preference` = `Datagram`. To send an Object with `Object -Forwarding Preference` = `Datagram`, determine the length of the fields and -payload and send the Object as datagram. In certain scenarios where the object -size can be larger than maximum datagram size for the session, the Object -will be dropped. - -~~~ -OBJECT_DATAGRAM Message { - Subscribe ID (i), - Track Alias (i), - Group ID (i), - Object ID (i), - Publisher Priority (8), - Object Payload Length (i), - [Object Status (i)], - Object Payload (..), -} -~~~ -{: #object-datagram-format title="MOQT OBJECT_DATAGRAM Message"} - -### Streams - -When objects are sent on streams, the stream begins with a stream -header message and is followed by one or more sets of serialized object fields. -If a stream ends gracefully in the middle of a serialized Object, terminate the -session with a Protocol Violation. - -A publisher SHOULD NOT open more than one stream at a time with the same stream -header message type and fields. - - -TODO: figure out how a relay closes these streams - -**Stream Header Track** - -When a stream begins with `STREAM_HEADER_TRACK`, all objects on the stream -belong to the track requested in the Subscribe message identified by `Subscribe -ID`. All objects on the stream have the `Publisher Priority` specified in the -stream header. - -~~~ -STREAM_HEADER_TRACK Message { - Subscribe ID (i) - Track Alias (i), - Publisher Priority (8), -} -~~~ -{: #stream-header-track-format title="MOQT STREAM_HEADER_TRACK Message"} - -All Objects received on a stream opened with STREAM_HEADER_TRACK have an `Object -Forwarding Preference` = `Track`. - -To send an Object with `Object Forwarding Preference` = `Track`, find the open -stream that is associated with the subscription, or open a new one and send the -`STREAM_HEADER_TRACK` if needed, then serialize the following object fields. -The Object Status field is only sent if the Object Payload Length is zero. - -~~~ -{ - Group ID (i), - Object ID (i), - Object Payload Length (i), - [Object Status (i)], - Object Payload (..), -} -~~~ -{: #object-track-format title="MOQT Track Stream Object Fields"} - -A publisher MUST NOT send an Object on a stream if its Group ID is less than a -previously sent Group ID on that stream, or if its Object ID is less than or -equal to a previously sent Object ID with the same Group ID. - -**Stream Header Peep** - -When a stream begins with `STREAM_HEADER_PEEP`, all objects on the stream -belong to the track requested in the Subscribe message identified by `Subscribe -ID` and the peep indicated by 'Group ID' and `Peep ID`. - -~~~ -STREAM_HEADER_PEEP Message { - Subscribe ID (i), - Track Alias (i), - Group ID (i), - Peep ID (i), - Publisher Priority (8), -} -~~~ -{: #stream-header-peep-format title="MOQT STREAM_HEADER_PEEP Message"} - -All Objects received on a stream opened with `STREAM_HEADER_PEEP` have an -`Object Forwarding Preference` = `Peep`. - -To send an Object with `Object Forwarding Preference` = `Peep`, find the open -stream that is associated with the subscription, `Group ID` and `Peep ID`, -or open a new one and send the `STREAM_HEADER_PEEP`. Then serialize the -ollowing fields. - -The Object Status field is only sent if the Object Payload Length is zero. - -~~~ -{ - Object ID (i), - Object Payload Length (i), - [Object Status (i)], - Object Payload (..), -} -~~~ -{: #object-group-format title="MOQT Group Stream Object Fields"} - -A publisher MUST NOT send an Object on a stream if its Object ID is less than a -previously sent Object ID within a given group in that stream. - -### Examples: - -Sending a track on one stream: - -~~~ -STREAM_HEADER_TRACK { - Subscribe ID = 1 - Track Alias = 1 - Publisher Priority = 0 -} -{ - Group ID = 0 - Object ID = 0 - Object Payload Length = 4 - Payload = "abcd" -} -{ - Group ID = 1 - Object ID = 0 - Object Payload Length = 4 - Payload = "efgh" -} -~~~ - -Sending a peep on one stream: - -~~~ -Stream = 2 - -STREAM_HEADER_PEEP { - Subscribe ID = 2 - Track Alias = 2 - Group ID = 0 - Peep ID = 0 - Publisher Priority = 0 -} -{ - Object ID = 0 - Object Payload Length = 4 - Payload = "abcd" -} -{ - Object ID = 1 - Object Payload Length = 4 - Payload = "efgh" -} -~~~ - - ->>>>>>> bb27020 (typos) ## SUBSCRIBE_OK {#message-subscribe-ok} A publisher sends a SUBSCRIBE_OK control message for successful @@ -1804,6 +1536,7 @@ Publisher MUST NOT mix different forwarding preferences within a single track. If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. + ## OBJECT {#message-object} An OBJECT message contains a range of contiguous bytes from from the @@ -2057,6 +1790,7 @@ STREAM_HEADER_PEEP { + # Security Considerations {#security} TODO: Expand this section, including subscriptions. From 412b2e43cb110e658886e87a5350c359474441e2 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 14 Aug 2024 11:35:20 -0700 Subject: [PATCH 07/23] More rebase repair --- draft-ietf-moq-transport.md | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index bbcf4fa7..fc734f7a 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1311,6 +1311,8 @@ TRACK_STATUS_REQUEST Message { ~~~ {: #moq-track-status-request-format title="MOQT TRACK_STATUS_REQUEST Message"} + + ## SUBSCRIBE_OK {#message-subscribe-ok} A publisher sends a SUBSCRIBE_OK control message for successful @@ -1536,8 +1538,7 @@ Publisher MUST NOT mix different forwarding preferences within a single track. If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. - -## OBJECT {#message-object} +## Object Headers {#message-object} An OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, @@ -1616,14 +1617,8 @@ are sent on a new stream. This is to avoid the status message being lost in cases such as a relay dropping a group and reseting the stream the group is being sent on. -### Object Message Formats -Every Track has a single 'Object Forwarding Preference' and the Original -Publisher MUST NOT mix different forwarding preferences within a single track. -If a subscriber receives different forwarding preferences for a track, it -SHOULD close the session with an error of 'Protocol Violation'. - -**Object Datagram Message** +## Object Datagram Message An `OBJECT_DATAGRAM` message carries a single object in a datagram. @@ -1648,7 +1643,7 @@ OBJECT_DATAGRAM Message { ~~~ {: #object-datagram-format title="MOQT OBJECT_DATAGRAM Message"} -### Streams +## Streams When objects are sent on streams, the stream begins with a stream header message and is followed by one or more sets of serialized object fields. @@ -1661,11 +1656,11 @@ header message type and fields. TODO: figure out how a relay closes these streams -**Stream Header Track** +### Stream Header Track When a stream begins with `STREAM_HEADER_TRACK`, all objects on the stream belong to the track requested in the Subscribe message identified by `Subscribe -ID`. All objects on the stream have the `Object Send Order` specified in the +ID`. All objects on the stream have the `Publisher Priority' specified in the stream header. ~~~ @@ -1700,7 +1695,7 @@ A publisher MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID with the same Group ID. -**Stream Header Peep** +### Stream Header Peep When a stream begins with `STREAM_HEADER_PEEP`, all objects on the stream belong to the track requested in the Subscribe message identified by `Subscribe @@ -1740,7 +1735,7 @@ The Object Status field is only sent if the Object Payload Length is zero. A publisher MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. -### Examples: +## Examples Sending a track on one stream: @@ -1790,7 +1785,6 @@ STREAM_HEADER_PEEP { - # Security Considerations {#security} TODO: Expand this section, including subscriptions. From 7b43994618c5da3d17ab4d9dde5489f77c9cd9fa Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 14 Aug 2024 11:38:13 -0700 Subject: [PATCH 08/23] typo --- draft-ietf-moq-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index fc734f7a..56e70e05 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -316,7 +316,7 @@ A peep is a collection of one or more objects and is a sub-unit of a group ({{model-group}}). A peep consists of a set of objects within a Group that have a dependency and priority relationship consistent with sharing a QUIC stream. In some cases, a Group will be most effectively delivered using more -than one stream.. +than one stream. When a Track's forwarding preference (see {{object-fields}}) is "Track" or "Datagram", Groups do not contain Peeps, no Peep IDs are assigned, and the From 88d079c9e2d5de7b7789a169f335bd06acaf7968 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 14 Aug 2024 12:57:46 -0700 Subject: [PATCH 09/23] update references --- draft-ietf-moq-transport.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 56e70e05..c97a457a 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -310,7 +310,7 @@ payload. This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads. -## Peeps {#model-peeps} +## Peeps {#model-peep} A peep is a collection of one or more objects and is a sub-unit of a group ({{model-group}}). A peep consists of a set of objects within a Group that @@ -1522,13 +1522,11 @@ variable-length integer indicating the type of the stream in question. |-------|-----------------------------------------------------| | ID | Stream Type | |------:|:----------------------------------------------------| -| 0x0 | OBJECT_STREAM ({{object-stream}}) | -|-------|-----------------------------------------------------| | 0x1 | OBJECT_DATAGRAM ({{object-datagram}}) | |-------|-----------------------------------------------------| | 0x50 | STREAM_HEADER_TRACK ({{stream-header-track}}) | |-------|-----------------------------------------------------| -| 0x51 | STREAM_HEADER_GROUP ({{stream-header-group}}) | +| 0x52 | STREAM_HEADER_PEEP ({{stream-header-peep}}) | |-------|-----------------------------------------------------| An endpoint that receives an unknown stream type MUST close the session. @@ -1618,7 +1616,7 @@ in cases such as a relay dropping a group and reseting the stream the group is being sent on. -## Object Datagram Message +## Object Datagram Message {#object-datagram} An `OBJECT_DATAGRAM` message carries a single object in a datagram. From 06471d752b1a8c9e7a57195fe051775ebc205561 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Thu, 15 Aug 2024 08:55:44 -0700 Subject: [PATCH 10/23] Some Suhas comments --- draft-ietf-moq-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index c97a457a..10639b08 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1658,7 +1658,7 @@ TODO: figure out how a relay closes these streams When a stream begins with `STREAM_HEADER_TRACK`, all objects on the stream belong to the track requested in the Subscribe message identified by `Subscribe -ID`. All objects on the stream have the `Publisher Priority' specified in the +ID`. All objects on the stream have the `Publisher Priority` specified in the stream header. ~~~ @@ -1716,7 +1716,7 @@ All Objects received on a stream opened with `STREAM_HEADER_PEEP` have an To send an Object with `Object Forwarding Preference` = `Peep`, find the open stream that is associated with the subscription, `Group ID` and `Peep ID`, or open a new one and send the `STREAM_HEADER_PEEP`. Then serialize the -ollowing fields. +following fields. The Object Status field is only sent if the Object Payload Length is zero. From d3552d86412f3126e7fe4f6d300f3ea668024982 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Thu, 22 Aug 2024 14:53:28 -0700 Subject: [PATCH 11/23] Remove normative peep assignment rules --- draft-ietf-moq-transport.md | 42 ++++++++++++------------------------- 1 file changed, 13 insertions(+), 29 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 10639b08..e19cf7df 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -329,22 +329,24 @@ scheduling of sending data on active streams. Every object within a Group belongs to exactly one Peep. -Original publishers assign each Peep a Peep ID, and do so as they see fit. The +Original publishers assign each Peep a Peep ID, and do so as they see fit. The scope of a Peep ID is a Group, so Peeps from different Groups MAY share a Peep -ID without implying any relationship between them. +ID without implying any relationship between them. In general, publishers assign +objects to peeps in order to leverage the features of QUIC streams as described +above. -However, the following strategy is RECOMMENDED: +An example strategy for using QUIC stream properties follows. If object A is +dependent on object B, then delivery of A can follow B, i.e. B and A can be +usefully delivered over a single QUIC stream. Furthermore, in this example: -- Higher object IDs are dependent on lower object IDs in the same peep. +- If an object is dependent on all previous objects in a Peep, it is added to +that Peep. -- If two objects are dependent on the same lower object ID, but are not -dependent on each other, one ought to assigned the same peep as the lower -ID, but the other ought to be in a different peep. The second peep would -ideally have a lower priority than the one with two objects. +- If an object is not dependent on some of the objects in a Peep, it goes in +a different Peep. -- There often multiple assignment schemes that meet these conditions. -Original publishers ought to choose an assignment that minimizes the number -of peeps (and therefore QUIC streams) in the group. +- There are often many ways to compose Peeps that meet these criteria. Where +possible, choose the composition that results in the fewest Peeps in a group. For example, imagine that Object 3 and Object 2 are both dependent on Object 1, but are have no depedency relationship with each other. It would @@ -355,16 +357,6 @@ Object 3 from being blocked by the loss of Object 2. Alternatively, objects 1 and 2 could be in one peep and 3 in another. The optimal choice would depend on the dependencies of later objects. -An original publisher might not follow these guidelines. Reasons would -include implementation complexity, lack of foreknowledge of the dependencies -of further objects, the knowledge that the transport is WebTransport over -HTTP/2 (thus introducing head-of-line blocking across streams), or knowledge -of low session stream limits that require aggregation of independent objects -into the same stream. - -For the purposes of peep assignment, the dependencies of objects with non- -normal status are described in {{object-status}}. - ## Groups {#model-group} A group is a collection of one or more peeps and is a sub-unit of a track @@ -1608,14 +1600,6 @@ Any object with a status code other than zero MUST have an empty payload. Though some status information could be inferred from QUIC stream state, that information is not reliable and cacheable. -In most cases, messages with a non zero status code are sent on the same -stream that an object with that GroupID would have been sent on. The -exception to this is when that stream has been reset; in that case they -are sent on a new stream. This is to avoid the status message being lost -in cases such as a relay dropping a group and reseting the stream the -group is being sent on. - - ## Object Datagram Message {#object-datagram} An `OBJECT_DATAGRAM` message carries a single object in a datagram. From 43653fd5fce6ec35fbc34c214e6720fa5a42e494 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Thu, 22 Aug 2024 14:57:04 -0700 Subject: [PATCH 12/23] Restore end of Peep object, which disappeared --- draft-ietf-moq-transport.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index e19cf7df..349dea27 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1593,6 +1593,9 @@ are beyond the end of a group or track. group. This is sent right after the last object in the track. This SHOULD be cached. +* 0x5 := Indicates end of Peep. Object ID is one greater than the largest + normal object ID in the Peep. + Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation ({{session-termination}}). Any object with a status code other than zero MUST have an empty payload. From 7f2355db9fa4e4cc99cee3daebb92b42b597eec0 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 09:02:23 -0700 Subject: [PATCH 13/23] Update draft-ietf-moq-transport.md Co-authored-by: ianswett --- draft-ietf-moq-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 349dea27..e05f182f 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -312,8 +312,8 @@ modify object payloads. ## Peeps {#model-peep} -A peep is a collection of one or more objects and is a sub-unit of a group -({{model-group}}). A peep consists of a set of objects within a Group that +A peep is a sequence of one or more objects from the same group +({{model-group}}) in ascending order by Object ID. Objects in a peep have a dependency and priority relationship consistent with sharing a QUIC stream. In some cases, a Group will be most effectively delivered using more than one stream. From a027ce381c5bbd72fb86a8c00298cefbaac2c714 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 09:02:31 -0700 Subject: [PATCH 14/23] Update draft-ietf-moq-transport.md Co-authored-by: ianswett --- draft-ietf-moq-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index e05f182f..68b16f10 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -316,7 +316,7 @@ A peep is a sequence of one or more objects from the same group ({{model-group}}) in ascending order by Object ID. Objects in a peep have a dependency and priority relationship consistent with sharing a QUIC stream. In some cases, a Group will be most effectively delivered using more -than one stream. +than one QUIC stream. When a Track's forwarding preference (see {{object-fields}}) is "Track" or "Datagram", Groups do not contain Peeps, no Peep IDs are assigned, and the From 6e070cb39ed385f35b4dd53f9df994df3b952044 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 09:03:01 -0700 Subject: [PATCH 15/23] Update draft-ietf-moq-transport.md Co-authored-by: ianswett --- draft-ietf-moq-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 68b16f10..657976ab 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -319,7 +319,7 @@ stream. In some cases, a Group will be most effectively delivered using more than one QUIC stream. When a Track's forwarding preference (see {{object-fields}}) is "Track" or -"Datagram", Groups do not contain Peeps, no Peep IDs are assigned, and the +"Datagram", Objects are not sent in Peeps, no Peep IDs are assigned, and the description in the remainder of this section does not apply. QUIC streams offer in-order reliable delivery and the ability to cancel sending From d706b8a3bb17fbcad8044b9fae72ddbc67e31d10 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 09:04:55 -0700 Subject: [PATCH 16/23] Update draft-ietf-moq-transport.md Co-authored-by: ianswett --- draft-ietf-moq-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 657976ab..9c71232a 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -359,7 +359,7 @@ optimal choice would depend on the dependencies of later objects. ## Groups {#model-group} -A group is a collection of one or more peeps and is a sub-unit of a track +A group is a collection of objects and is a sub-unit of a track ({{model-track}}). Objects within a group SHOULD NOT depend on objects in other groups. A group behaves as a join point for subscriptions. A new subscriber might not want to receive the entire track, and may From 11fd0f75ab84bb24afb4db2689324dc59e550b9f Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 09:05:07 -0700 Subject: [PATCH 17/23] Update draft-ietf-moq-transport.md Co-authored-by: ianswett --- draft-ietf-moq-transport.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 9c71232a..0dc84849 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -348,14 +348,6 @@ a different Peep. - There are often many ways to compose Peeps that meet these criteria. Where possible, choose the composition that results in the fewest Peeps in a group. -For example, imagine that Object 3 and Object 2 are both dependent on Object -1, but are have no depedency relationship with each other. It would -therefore be appropriate for Objects 1 and 3 to be in one peep and Object 2 -in another, with lower priority. The separate stream prevents delivery of -Object 3 from being blocked by the loss of Object 2. - -Alternatively, objects 1 and 2 could be in one peep and 3 in another. The -optimal choice would depend on the dependencies of later objects. ## Groups {#model-group} From 729fac947020ae244b350fa58eae6bacf0c43fb5 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 09:22:05 -0700 Subject: [PATCH 18/23] Some Ian comments --- draft-ietf-moq-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index 0dc84849..e93907d7 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -335,14 +335,14 @@ ID without implying any relationship between them. In general, publishers assign objects to peeps in order to leverage the features of QUIC streams as described above. -An example strategy for using QUIC stream properties follows. If object A is -dependent on object B, then delivery of A can follow B, i.e. B and A can be +An example strategy for using QUIC stream properties follows. If object B is +dependent on object A, then delivery of B can follow A, i.e. A and B can be usefully delivered over a single QUIC stream. Furthermore, in this example: - If an object is dependent on all previous objects in a Peep, it is added to that Peep. -- If an object is not dependent on some of the objects in a Peep, it goes in +- If an object is not dependent on all of the objects in a Peep, it goes in a different Peep. - There are often many ways to compose Peeps that meet these criteria. Where From 8680442d7270f70f42964344ea940d736c1b8105 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 10:04:53 -0700 Subject: [PATCH 19/23] Clarified behavior of peeps with equal priority --- draft-ietf-moq-transport.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index e93907d7..d2e4103c 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -623,8 +623,10 @@ Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a higher Object Id, regardless of the specified Group Order. If the group contains more than one Peep and the priority varies between these Peeps, -higher priority Peeps are sent before lower priority Peeps, and Objects -in peeps are sent in increasing Object Id order. +higher priority Peeps are sent before lower priority Peeps. If the priority of +two Peeps in a Group are equal, there is no normative requirement for which of +those Peeps is sent next. Within a Peep, Objects MUST bs sent in increasing +Object ID order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used. From 363410f796914af288f85331c0696f82795a7176 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 11:15:45 -0700 Subject: [PATCH 20/23] Update draft-ietf-moq-transport.md Co-authored-by: ianswett --- draft-ietf-moq-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index d2e4103c..d33b69c7 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -346,7 +346,8 @@ that Peep. a different Peep. - There are often many ways to compose Peeps that meet these criteria. Where -possible, choose the composition that results in the fewest Peeps in a group. +possible, choose the composition that results in the fewest Peeps in a group +to minimize the number of QUIC streams used. ## Groups {#model-group} From 1352ddb87d4827aef80d48e379e74933fee6f677 Mon Sep 17 00:00:00 2001 From: Will Law Date: Mon, 19 Aug 2024 16:55:59 +0200 Subject: [PATCH 21/23] Update draft-ietf-moq-transport.md Removing TODO around MOQ Streaming Format registration --- draft-ietf-moq-transport.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index d33b69c7..b0ec1559 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -1801,12 +1801,6 @@ TODO: fill out currently missing registries: TODO: register the URI scheme and the ALPN -TODO: the MOQT spec should establish the IANA registration table for MoQ -Streaming Formats. Each MoQ streaming format can then register its type -in that table. The MoQ Streaming Format type MUST be carried as the -leading varint in catalog track objects. - - # Contributors {:numbered="false"} From 338941500bee6f543eeaf97194557a815b9f2382 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Fri, 23 Aug 2024 13:59:42 -0700 Subject: [PATCH 22/23] Lower peep ID has priority --- draft-ietf-moq-transport.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index b0ec1559..bf203fe6 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -624,10 +624,9 @@ Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a higher Object Id, regardless of the specified Group Order. If the group contains more than one Peep and the priority varies between these Peeps, -higher priority Peeps are sent before lower priority Peeps. If the priority of -two Peeps in a Group are equal, there is no normative requirement for which of -those Peeps is sent next. Within a Peep, Objects MUST bs sent in increasing -Object ID order. +higher priority Peeps are sent before lower priority Peeps. If the specified +priority of two Peeps in a Group are equal, the lower Peep ID has priority. +Within a Peep, Objects MUST bs sent in increasing Object ID order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used. From 4c13bd1e00469a037d1fca6d2387fb235947bf74 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 28 Aug 2024 10:26:40 -0700 Subject: [PATCH 23/23] Cullen comments --- draft-ietf-moq-transport.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/draft-ietf-moq-transport.md b/draft-ietf-moq-transport.md index fcf0a0a3..09c07123 100644 --- a/draft-ietf-moq-transport.md +++ b/draft-ietf-moq-transport.md @@ -329,6 +329,11 @@ scheduling of sending data on active streams. Every object within a Group belongs to exactly one Peep. +Objects from two peeps cannot be sent on the same QUIC stream. Objects from the +same Peep MUST NOT be sent on different QUIC streams, unless one of the streams +was reset prematurely, or upstream conditions have forced objects from a Peep +to be sent out of Object ID order. + Original publishers assign each Peep a Peep ID, and do so as they see fit. The scope of a Peep ID is a Group, so Peeps from different Groups MAY share a Peep ID without implying any relationship between them. In general, publishers assign @@ -600,9 +605,12 @@ The subscriber indicates the priority of a subscription via the Subscriber Priority field and the original publisher indicates priority in every stream or datagram header. As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a -property of the Track and the Peeps it contains. In both cases, a lower +property of the Track and the Objects it contains. In both cases, a lower value indicates a higher priority, with 0 being the highest priority. +When Objects are contained in Peeps, all Objects in the Peep have the same +priority. + The Subscriber Priority is considered first when selecting a subscription to send data on within a given session. When two or more subscriptions have equal subscriber priority, the original publisher priority is considered @@ -1611,7 +1619,8 @@ are beyond the end of a group or track. largest object produced in the group identified by the GroupID. This is sent right after the last object in the group. If the ObjectID is 0, it indicates there are no Objects - in this Group. This SHOULD be cached. + in this Group. This SHOULD be cached. A publisher MAY use an end of + Group object to signal the end of all open Peeps in a Group. * 0x4 := Indicates end of Track and Group. GroupID is one greater than the largest group produced in this track and the ObjectId is