Put SUBSCRIBE_NAMESPACE on a stream, make Namespaces and PUBLISH independent #1344

ianswett · 2025-10-31T00:15:26Z

I did not remove Request ID entirely in this PR, because it makes the most sense to do that all at once, but I did create new 'NAMESPACE' and 'NAMESPACE_DONE' messages that are separate from PUBLISH_NAMESPACE/PUBLISH_NAMESPACE_DONE and much simpler.

Saves bytes on the wire by not repeating the 'Track Namespace Prefix' for every Namespace.

Removes UNSUBSCRIBE_NAMESPACE because we can just close the stream.

Fixes #1348
Fixes #1310
Fixes #1305
Fixes part of #1168
Fixes #843

Further possible changes:

Don't send REQUEST_ERROR on errors, QUIC RESET_STREAM with the application error code. Loses Reason Phrase
Don't send REQUEST_OK on success. Loses response parameters.
Allow for subscribing to full Track names and not just Namespaces.
Prohibit sending NAMESPACE_DONE before a NAMESPACE is received for a SUBSCRIBE_NAMESPACE
Add a PUBLISH_BLOCKED sent on the response stream when a new PUBLISH couldn't be sent No way to indicate that PUBLISHes from SUBSCRIBE_NAMESPACE were blocked #1262
Drop the length from NAMESPACE and NAMESPACE_DONE

…ng to Namespaces or PUBLISH I did not remove Request ID entirely in this PR, because it makes the most sense to do that all at once, but I did create a new 'NAMESPACE' message that's separate from PUBLISH_NAMESPACE and much simpler. Fixes #1310 Fixes #1168 Fixes #843

afrind

What does the subscriber do with the write half of the bidi stream after the SUBSCRIBE_NAMESPACE? FIN, or leave open?

How does this impact UNSUBSCRIBE_NAMESPACE, if at all?

If we introduce REQUEST_UPDATE (#1332), where does that go?

draft-ietf-moq-transport.md

afrind · 2025-10-31T00:28:06Z

draft-ietf-moq-transport.md

+  Type (i) = 0x6,
+  Length (16),


Aren't these 3 bytes completely redundant?

Ah the response stream can have both NAMESPACE and PUBLISH_NAMESPACE_DONE so you need type (and also REQUEST_OK/ERROR, maybe?). Length feels useless here, but I can live with it.

Yes, I think I need a type. The Length is a bit more obviously redundant, but that goes back to the TLV vs TV conversation. I think there's a good argument that this isn't on the control stream and one could use TV even if we're using TLV elsewhere.

This stream is currently a mini control stream that supports:

REQUEST_OK
REQUEST_ERROR
NAMESPACE
PUBLISH_NAMESPACE_DONE

There's some nice code reusability there, enough that I can live with the length redundancy. The alternative is quite a bit more spec text, but I can live with that too if folks are concerned.

I think it's worth considering, but we can make it separable.

afrind · 2025-10-31T00:28:34Z

draft-ietf-moq-transport.md

-request the current set of matching published namespaces and `Established`
-subscriptions, as well as future updates to the set.
+The subscriber sends a SUBSCRIBE_NAMESPACE control message on a new
+bidirectional stream to a publisher to request the current set of matching


How do you distinguish the control stream from this stream?

It's a new bidi stream and it starts with the SUBSCRIBE_NAMESPACE message.

So if the first stream I receive starts with SUBSCRIBE_NAMESPACE, I hold it pending one that starts with CLIENT_SETUP?

Without 0RTT clearly described, which it isn't today, I'm unsure how that could happen?

Yeah @afrind if right.

It depends on if the QUIC library returns streams in stream_id order, but any bidirectional stream should be buffered until the CLIENT_SETUP is processed. In fact, the same is true for any unidirectional streams if pipelining a PUBLISH is valid (debatable with max_request_id), but that's a lot easier to implement.

Thanks, I understand the issue now. Yes, I can call out this potential issue.

PTAL at 2465b19

afrind · 2025-10-31T00:29:38Z

draft-ietf-moq-transport.md

-the Track Namespace Prefix that have not already been sent to this subscriber.
-If the set of matching PUBLISH_NAMESPACE messages changes, the publisher sends
-the corresponding PUBLISH_NAMESPACE or PUBLISH_NAMESPACE_DONE message.
+The publisher will respond with REQUEST_OK or REQUEST_ERROR.  If the


I think you mean to say these will come on the response half of the bidi stream.

True, I updated the text above. This text is fairly duplicative I think, but I guess we can move it in another PR?

afrind · 2025-10-31T00:30:18Z

draft-ietf-moq-transport.md

-the corresponding PUBLISH_NAMESPACE or PUBLISH_NAMESPACE_DONE message.
+The publisher will respond with REQUEST_OK or REQUEST_ERROR.  If the
+SUBSCRIBE_NAMESPACE is successful, the publisher will send matching
+NAMESPACE messages on the response stream if they are requested.


Do we need or want a mechanism to get only the track names in the same format as namespaces, or we think only PUBLISH is sufficient?

I think we do want that, but I was trying to keep this small. Happy to add it into this PR if we're all sure we want it.

draft-ietf-moq-transport.md

suhasHere · 2025-10-31T03:22:20Z

draft-ietf-moq-transport.md


 * Parameters: The parameters are defined in {{version-specific-params}}.

+## NAMESPACE {#message-pub-ns}


Suggested change

## NAMESPACE {#message-pub-ns}

## NAMESPACE_NOTIFY {#message-pub-ns}

I don't have a strong opinion, but NAMESPACE is shorter

draft-ietf-moq-transport.md

Save repeating the bytes in the namespace prefix

It doesn't do anything RESET_STREAM can't

ianswett · 2025-11-01T04:54:26Z

What does the subscriber do with the write half of the bidi stream after the SUBSCRIBE_NAMESPACE? FIN, or leave open?

I'm inclined to leave it open, at least until we decide if want to send REQUEST_UPDATE on it.

How does this impact UNSUBSCRIBE_NAMESPACE, if at all?

I removed it in the more recent update, because it wasn't needed.

If we introduce REQUEST_UPDATE (#1332), where does that go?

On the open bidi stream.

draft-ietf-moq-transport.md

afrind · 2025-11-01T13:11:25Z

draft-ietf-moq-transport.md

+  Type (i) = 0x6,
+  Length (16),


This stream is currently a mini control stream that supports:

REQUEST_OK
REQUEST_ERROR
NAMESPACE
PUBLISH_NAMESPACE_DONE

There's some nice code reusability there, enough that I can live with the length redundancy. The alternative is quite a bit more spec text, but I can live with that too if folks are concerned.

afrind · 2025-11-01T13:12:58Z

draft-ietf-moq-transport.md

-request the current set of matching published namespaces and `Established`
-subscriptions, as well as future updates to the set.
+The subscriber sends a SUBSCRIBE_NAMESPACE control message on a new
+bidirectional stream to a publisher to request the current set of matching


So if the first stream I receive starts with SUBSCRIBE_NAMESPACE, I hold it pending one that starts with CLIENT_SETUP?

draft-ietf-moq-transport.md

kixelated · 2025-11-03T04:17:42Z

draft-ietf-moq-transport.md

-request the current set of matching published namespaces and `Established`
-subscriptions, as well as future updates to the set.
+The subscriber sends a SUBSCRIBE_NAMESPACE control message on a new
+bidirectional stream to a publisher to request the current set of matching


Yeah @afrind if right.

It depends on if the QUIC library returns streams in stream_id order, but any bidirectional stream should be buffered until the CLIENT_SETUP is processed. In fact, the same is true for any unidirectional streams if pipelining a PUBLISH is valid (debatable with max_request_id), but that's a lot easier to implement.

draft-ietf-moq-transport.md

So it can use the Suffix approach and not specify the full Namespace

afrind · 2025-11-13T19:45:37Z

Discussed 11/13 with Authors/Editors -- plan to present to the wg at the interim

draft-ietf-moq-transport.md

afrind · 2025-11-18T03:46:35Z

Presented at 11/17 Interim:

Plan is to proceed with this design.

afrind

This looks close

draft-ietf-moq-transport.md

afrind · 2025-11-18T03:48:47Z

draft-ietf-moq-transport.md

 part of that namespace.  This includes echoing back PUBLISH or PUBLISH_NAMESPACE
 messages to the endpoint that sent them.  If an endpoint accepts its own


PUBLISH_NAMESPACE is not longer echoed?

I think it probably should be, to minimize any behavior change, but the PUBLISH_NAMESPACE would turn into a NAMESPACE message on the wire.

draft-ietf-moq-transport.md

afrind · 2025-11-18T03:51:15Z

draft-ietf-moq-transport.md

+
+The publisher sends the `NAMESPACE_DONE` control message to indicate its
+intent to stop serving new subscriptions for tracks within the provided Track
+Namespace. All NAMESPACE messages are in response to a SUBSCRIBE_NAMESPACE,


This bit about NAMESPACE messages applies to both NS and NS_DONE, and is in the NS_DONE section.

Fair point, any suggestions? Just remove it?

afrind · 2025-11-18T03:52:17Z

draft-ietf-moq-transport.md

+* Track Namespace Suffix: Specifies the final portion of a track's
+  namespace as defined in {{track-name}}. The namespace begins with the
+  'Track Namespace Prefix' specified in {message-subscribe-ns}.


"final portion" is a bit under defined. Maybe

Specifies the final portion of a track's namespace as defined in {{track-name}} after removing namespace tuples included in Track Namespace Prefix...

Co-authored-by: afrind <[email protected]>

draft-ietf-moq-transport.md

suhasHere · 2025-11-21T06:24:15Z

draft-ietf-moq-transport.md

  Length (16),
  Request ID (i),
  Track Namespace Prefix (..),
+  Subscribe Options (i),


Can one send 2 subscribe_namespace with 2 different options

No, this falls under duplicate prefix text elsewhere.

draft-ietf-moq-transport.md

vasilvv · 2025-11-26T01:09:07Z

draft-ietf-moq-transport.md

+could arrive prior to the control stream, in which case the data SHOULD be buffered
+until the control stream arrives and setup is complete.
+If an implementation does not want to buffer, it MAY reset other bidirectional
+streams before the session and control stream are established.


This PR does not really provide a good way for implementations to figure out what stream is the control stream.

There is a type identifier at the beginning of the control stream, which is the SETUP messages.

vasilvv · 2025-11-26T01:10:37Z

draft-ietf-moq-transport.md

 |-------|-----------------------------------------------------|
+| 0xE   | NAMESPACE_DONE  ({{message-namespace-done}})        |
+|-------|-----------------------------------------------------|
 | 0xC   | PUBLISH_NAMESPACE_CANCEL ({{message-pub-ns-cancel}})|


It looks like we're repeating the mistake we had in HTTP/3 where we are adding streams without type identifiers and then have some semantic rules about what messages can appear where. Can we have an explicit type for bidi streams instead?

@vasilvv the current PR is adequate, in that it either starts with CLIENT_SETUP or it starts with SUBSCRIBE_NAMESPACE. This is extensible since have varint frame type so have unlimited ways to start streams. It seems like it would be fairly redundant to have:

SETUP_STREAM
CLIENT_SETUP

and

SUB_NS_STREAM
SUB_NS

Right?

I guess the counter-argument is if in the future you want to start a stream with a non-message. This is what webtransport ran into and it got a little ugly, but ultimately resolved it by reserving a frame type and giving it new semantics.

I definitely don't want to repeat that mistake, but in this case we are adding type/message identifiers.

I can see that this works, but I don't see why we would want to do that. If there are two types of streams, and they have basically disjoint message type list, why do we want them to have the same format?

draft-ietf-moq-transport.md

suhasHere · 2025-12-01T01:58:33Z

draft-ietf-moq-transport.md

+A SUBSCRIBE_NAMESPACE can be cancelled by closing the stream with
+either a FIN or RESET_STREAM. Cancelling does not prohibit original publishers


Suggested change

A SUBSCRIBE_NAMESPACE can be cancelled by closing the stream with

either a FIN or RESET_STREAM. Cancelling does not prohibit original publishers

A SUBSCRIBE_NAMESPACE can be cancelled by the creator the stream, by closing the stream with

either a FIN or RESET_STREAM. Cancelling does not prohibit original publishers

It can be cancelled by either the creator or the peer.

draft-ietf-moq-transport.md

Co-authored-by: Suhas Nandakumar <[email protected]>

draft-ietf-moq-transport.md

Co-authored-by: Suhas Nandakumar <[email protected]>

ianswett requested a review from afrind October 31, 2025 00:15

ianswett requested review from suhasHere and vasilvv as code owners October 31, 2025 00:15

ianswett added Design Issues or PRs that change how MoQ works including the wire format. Publish Namespace (formerly Announce) Issues with PUBLISH_NAMESPACE (formerly Announce) labels Oct 31, 2025

afrind reviewed Oct 31, 2025

View reviewed changes

suhasHere reviewed Oct 31, 2025

View reviewed changes

ianswett commented Nov 1, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

89e380b

ianswett commented Nov 1, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett added 7 commits October 31, 2025 23:28

Update draft-ietf-moq-transport.md

abafb02

Change to Track Namespace Suffix

1a6fe39

Save repeating the bytes in the namespace prefix

Fix whitespace and a trailing sentence.

7e16420

Remove UNSUBSCRIBE_NAMESPACE

a30cd61

It doesn't do anything RESET_STREAM can't

Ref conflict

4b21ba2

Update draft-ietf-moq-transport.md

9c8cc68

Alan's suggestion

9ae1039

afrind reviewed Nov 1, 2025

View reviewed changes

ianswett commented Nov 3, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett added 4 commits November 2, 2025 22:44

Update draft-ietf-moq-transport.md

c71ae77

Update draft-ietf-moq-transport.md

a31e5b3

Change the codepoint of NAMESPACE to 0x8

b5e6711

Fix table formatting

0132f29

kixelated reviewed Nov 3, 2025

View reviewed changes

ianswett added 2 commits November 3, 2025 11:21

Describe the case when a SUBSCRIBE_NAMESPACE arrives first

2465b19

Add NAMESPACE_DONE

bd3ebc8

So it can use the Suffix approach and not specify the full Namespace

ianswett changed the title ~~Put PUBLISH_NAMESPACE on a stream and unlink Namespaces from PUBLISH~~ Put PUBLISH_NAMESPACE on a stream, make Namespaces and PUBLISH independent Nov 4, 2025

ianswett changed the title ~~Put PUBLISH_NAMESPACE on a stream, make Namespaces and PUBLISH independent~~ Put SUBSCRIBE_NAMESPACE on a stream, make Namespaces and PUBLISH independent Nov 4, 2025

ianswett added 2 commits November 13, 2025 14:07

Merge branch 'main' into ianswett-streamy-namespaces

13a3a6f

Fix subscribe-ns references

2e23347

ianswett commented Nov 18, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

c5e7fbf

afrind reviewed Nov 18, 2025

View reviewed changes

Update draft-ietf-moq-transport.md

49d3c32

Co-authored-by: afrind <[email protected]>

ianswett commented Nov 20, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

4a76892

suhasHere reviewed Nov 21, 2025

View reviewed changes

Update draft-ietf-moq-transport.md

9949625

afrind reviewed Nov 21, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

Update draft-ietf-moq-transport.md

b969d51

afrind approved these changes Nov 21, 2025

View reviewed changes

Merge branch 'main' into ianswett-streamy-namespaces

24b2efe

vasilvv requested changes Nov 26, 2025

View reviewed changes

Merge branch 'main' into ianswett-streamy-namespaces

6aba921

suhasHere reviewed Dec 1, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

suhasHere reviewed Dec 1, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

suhasHere reviewed Dec 1, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

suhasHere approved these changes Dec 1, 2025

View reviewed changes

ianswett and others added 3 commits December 1, 2025 10:56

Merge branch 'main' into ianswett-streamy-namespaces

e6a6368

Update draft-ietf-moq-transport.md

fe00420

Co-authored-by: Suhas Nandakumar <[email protected]>

Update draft-ietf-moq-transport.md

a0e6b3b

Co-authored-by: Suhas Nandakumar <[email protected]>

ianswett commented Dec 2, 2025

View reviewed changes

draft-ietf-moq-transport.md Outdated Show resolved Hide resolved

ianswett and others added 3 commits December 2, 2025 13:41

Reflow

8d39c86

Update draft-ietf-moq-transport.md

35695e0

Co-authored-by: Suhas Nandakumar <[email protected]>

Merge branch 'main' into ianswett-streamy-namespaces

17e0d0a


		* Parameters: The parameters are defined in {{version-specific-params}}.

		## NAMESPACE {#message-pub-ns}

	## NAMESPACE {#message-pub-ns}
	## NAMESPACE_NOTIFY {#message-pub-ns}

		part of that namespace. This includes echoing back PUBLISH or PUBLISH_NAMESPACE
		messages to the endpoint that sent them. If an endpoint accepts its own

		A SUBSCRIBE_NAMESPACE can be cancelled by closing the stream with
		either a FIN or RESET_STREAM. Cancelling does not prohibit original publishers

Put SUBSCRIBE_NAMESPACE on a stream, make Namespaces and PUBLISH independent #1344

Are you sure you want to change the base?

Put SUBSCRIBE_NAMESPACE on a stream, make Namespaces and PUBLISH independent #1344

Conversation

ianswett commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

afrind left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ianswett commented Nov 1, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

afrind commented Nov 13, 2025

Uh oh!

Uh oh!

afrind commented Nov 18, 2025

Uh oh!

afrind left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ianswett commented Oct 31, 2025 •

edited

Loading