When to use Track Alias or Subscribe ID?

[martinduke]

Sec 6.4.2: "If the Track Alias is already in
use, the publisher MUST close the session with a Duplicate Track
Alias error (Section 3.5)."

This makes sense if it's a different track name. But if it's the same track for two subscriptions, they should have the same track_alias, right? What's the purpose of track alias and subscribe ID always going together in objects, anyway?

[martinduke]

Having read through this now, I think we should just eliminate Subscribe_id from the Object message types.

If there are overlapping subscriptions, senders should only send it once, and it's ambiguous what subscribe ID to use.

[afrind]

Individual Comment:

If there are overlapping subscriptions, senders should only send it once, and it's ambiguous what subscribe ID to use.

I think the idea is that you have to send the object multiple times if it matches more than one subscription. Without subscription ID, there's no way for a receiver to know if a received object matches the relative subscribe locations it sent. That said, we could come up with a format that allows for more than one subscription ID, which is almost certainly more compact.

There was also concern about mixing objects from different subscriptions in the same multi-object stream.

[martinduke]

I confess to not having thought about relays as much as most, but I'm not sure how this model works for relays.

1. Clearly, the relay cannot just forward each subscription, as that totally negate the scalability benefit.

2. If the relay is aggrating subscriptions which come in over time, that is going to result in duplicate objects en masse? Or are we planning to have relays routinely SUBSCRIBE_FIN when a new subscription comes in, so it can send a new consolidated SUBSCRIBE?

3. Or are we counting on the vast majority of client subscriptions being "give me the next one", so as not to require a new relay subscription to produce?

[martinduke]

This is entangled with a bunch of other issues, but I don't see the point of specifying a track ID at all -- the subscriber proposes one, the publisher can refuse it, but this number is never used again except as a (redundant) identifier in the OBJECT message.

So what's the purpose of this message?

[martinduke]

also: how does sending multiple copies relate to forwarding preference? i.e. if I send the same object twice, is it on the same stream or on different streams?

[hardie]

On Mon, Jan 29, 2024 at 5:47 PM Martin Duke ***@***.***> wrote: also: how does sending multiple copies relate to forwarding preference? i.e. if I send the same object twice, is it on the same stream or on different streams?

The current theory, at least as I understand it, is that it depends on how many subscriptions there are. If the two objects are being sent because there are two active subscriptions, they would be on different streams even in the one-stream-per-track theory. The larger context for this is that we expect the client to be the one to manage the use cases where it both wants a subscription from the live edge and to gather data from before the live edge for playback. It sends two distinct subscriptions,one per desired result, and when it starts seeing duplicate objects it can then unsubscribe from one of the two (it may not, if they are going to different devices, so this is not required, but up to the UE). —

…

Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKVXZE32NKA3UDNBVYB3SLYQ7OE3AVCNFSM6AAAAABCM2QLDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVGI2TOMJQG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[martinduke]

OK, after some clarification on the list, I think this is the state:

• the draft currently requires sending one copy per subscribe, though this is by no means settled. (See Multiple subscriptions and updating a subscription #269)
• if we end up sticking with that, then track_alias is entirely pointless and should be removed
• if we go to one-time transmission, then subscribe_id should be removed from Object messages.

[fluffy]

Definitely need some discussion time on this.

The subscribes should be used to for the client to say what it wants but because the data is not delivered in order with the control steam, there are all kinds of race conditions particularly with clients reconnecting, multiple layers of relays, things failing and HA, etc. That makes me think the data plane / objects should not have the subscription ID.

[vasilvv]

I think deduplicating objects in MoQT is not a good idea for a lot of reasons, for instance:

1. Subscriptions have different priorities.
2. In stream-per-group, all streams have to start with object 0, except for the very first group of the subscription. Reconciling this across multiple subscriptions is tricky.
3. It allows one subscription affect another in weird, counterintuitive ways, and if that happens on relays, it can be observed by unrelated clients.
4. Deduplication creates additional logic not only on the sender side, but on the receiver side too.

If we do not deduplicate, every object sent on the connection has to be associated with some subscription ID, so putting that ID in makes sense. With that, I agree with Martin that track alias is redundant, since subscription ID implies it.

The subscribes should be used to for the client to say what it wants but because the data is not delivered in order with the control steam, there are all kinds of race conditions particularly with clients reconnecting, multiple layers of relays, things failing and HA, etc. That makes me think the data plane / objects should not have the subscription ID.

I'm not sure I understand the logic here. In order to send the client anything, you need to have the QUIC state for that connection, so requiring the subscription table right next to that state should not change that much. Client reconnecting means the connection is gone, so you have to resubscribe anyways.

[ianswett]

Removing the Track Alias from the protocol entirely leaves it equally functional and simpler. However, we had people who claimed they needed Track Alias so the Subscribe ID would be identical across subscriptions to a single relay.

As an individual, given different subscriptions are going to have different Stream IDs, encryption keys, etc, having one more ID that's different doesn't seem onerous to me. If an application really needed strict rules to achieve full performance, one could inform the client to do something custom that made the Stream ID, Subscribe ID, etc all conform to that specific scheme. The most extreme case of this I can imagine is multicast, but that requires quite a few other changes to QUIC.

[kixelated]

As an individual, given different subscriptions are going to have different Stream IDs, encryption keys, etc, having one more ID that's different doesn't seem onerous to me. If an application really needed strict rules to achieve full performance, one could inform the client to do something custom that made the Stream ID, Subscribe ID, etc all conform to that specific scheme. The most extreme case of this I can imagine is multicast, but that requires quite a few other changes to QUIC.

+1 QUIC is not a multicast protocol. Each QUIC session will have a different connection ID, packet number, encryption key, stream ID, webtransport session ID, and potentially MTU. Adding a subscribe ID does not change the equation, nor does track alias unlock an optimization.

And I'll add that only the stream header will have the different subscribe ID. The stream body will be identical for all subscribers and a relay can proxy QUIC STREAM an offset (the stream header size) if there's no start/end object ID. Note that you can never proxy STREAM frames without first receiving the header, as you don't know where to forward the stream otherwise.

[martinduke]

Parking this until FETCH is decided (#368)