Subscriber has to look up subscriptions by both track alias and subscribe ID

[martinduke]

The subscriber needs to index all of its subscriptions by track_alias, because this is how objects will arrive. After the brief period waiting for SUBSCRIBE_OK/ERROR, the only time it needs to lookup a subscription by subscribe_id is when SUBSCRIBE_DONE arrives.

There is no reason this couldn't be the track_alias instead.

An implementer could just iterate through all its subscriptions to find the matching ID, or set up a separate map of subscribe_id to subscription. But that's pointless.

[ianswett]

SUBSCRIBE_UPDATE also uses Subscribe ID, so I'd prefer using the ID for any state changes to SUBSCRIBE, and track alias is only for object delivery.

[martinduke]

This is an issue for messages that arrive at the Subscriber. The subscriber has no choice but to set up a map of track alias to subscription to manage incoming messages.

It has to keep a much smaller map of subscribe ID to subscription for subscriptions still waiting for SUBSCRIBE_OK and SUBSCRIBE_ERROR.

Having SUBSCRIBE_DONE use Subscribe ID means that all subscriptions need to be in two maps: one by track alias, one by subscribe ID.

Personally, I'd prefer we just get rid of track alias and use subscribe ID, since the latter has flow control implications. The next easiest thing to implement would be to always use track alias after the initial SUBSCRIBE.

[afrind]

SUBSCRIBE_UPDATE also uses Subscribe ID

As a data point, moxygen also requires a publisher side map based on subscribe ID to retain the subscription priority only so it can handle SUBSCRIBE_UPDATE, though with some planned major API redesign it might not be necessary.

[fluffy]

Yes and I don't see this as a problem.

You may have more than one subscribe delivering data for the same track. (particularly if we start doing filtering and other things).

So a track may have no subscriptions, one subscription, or more than one subscription. A subscription will have exactly one track but the switch proposal allows that track to change.

I have always favoured a very strong separation of data plane and control pane. Subscribe ID is only on control plane and identifies a subscribe transaction and changes to subscribe. Track ID is is a short alias for the track and is only on the data plane.

[vasilvv]

You may have more than one subscribe delivering data for the same track. (particularly if we start doing filtering and other things).

This is currently explicitly disallowed by the spec, and before that, we had text that required each individual object to be delivered for every subscription on the connection.

I have always favoured a very strong separation of data plane and control pane. Subscribe ID is only on control plane and identifies a subscribe transaction and changes to subscribe. Track ID is is a short alias for the track and is only on the data plane.

MoQT does not really have control and data planes; both control and data streams go on the same connection, and you can't really decouple the state due to how QUIC works.

For what its worth, after implementing MoQT, I think that track alias is not useful (it adds a layer of indirection for zero upside), and subscribe ID should be used consistently throughout.

[martinduke]

Yes and I don't see this as a problem.

You may have more than one subscribe delivering data for the same track. (particularly if we start doing filtering and other things).

So a track may have no subscriptions, one subscription, or more than one subscription. A subscription will have exactly one track but the switch proposal allows that track to change.

This is an inaccurate statement of the current spec. Section 6.4 specifically prohibits a session having two active subscriptions to the same track. Unless you're referring to multiple sessions?

[afrind]

Individual Comment:

(particularly if we start doing filtering and other things).

I agree the current spec disallows. If I squint I can see filtering breaking this property, but let's wait until we're looking at a PR for that before discussing extensively here.

subscription will have exactly one track but the switch proposal allows that track to change.

I think this is a good point to consider - if SWITCH is adopted, it may create a dependency on Track Alias. Today Track Alias only provides an optimization for fan-out relays.

Subscribe ID is only on control plane

Subscribe ID is now included in FETCH streams which are in the data plane.

Chair Comment:

@martinduke are you looking just to change SUBSCRIBE_DONE to contain a Track Alias instead of a Subscribe ID to prevent the subscriber needing a long term map from Subscribe ID to Track Alias, as described in the original issue? The discussion is veering into "Let's remove Track Alias", which is not a necessary discussion if that's the desired outcome.

[TimEvens]

FWIW,

I'm in favor of keeping track alias over subscribe ID. Either way, both are not needed.

tl;dr

The original use-case, as I understand it, was that subscribe ID was to support multiple tracks (e.g., full track namespace and name = track alias) at the same time.... but that was when Fetch didn't exist and subscribe was used. The use-case was that you could have multiple fetches taking place at the same time for the same track, hence the need for subscribe id.

Considering that fetch exists and that section 6.4 as @martinduke states that one subscription for a given track namespace/name (e.g, track alias) can only exist, the use-case for subscribe ID as a distinguisher is no longer needed.

I'm in favor of track alias because we can reject a track alias and request the client to use one that we provide (we being relay). This allows the relay to use the track alias in a larger scope that may span peering and other clients for the same track. Subscribe Id wouldn't make sense to do that.