Original text:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del>  Track Namespace: Identifies the namespace of the track as defined in (track-name).

Reviewer comments:
Small editorial clarification on duplicate track alias for subscriptions that addresses aspects of
As I read the draft, is the distinguisher of a given subscription. is made unique for a subscription state by indicating "If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error." The is mentioned as "A session specific identifier for the track.". It is initially set by the subscriber, where the publisher MAY reject... likely not if it wants to avoid long subscribe times. The draft does not indicate that the track alias is a hash of track or not. If the client implementation uses a sequence ID for both subscribe ID and track alias, then it could result in duplicate subscribes that would result in the relay building state, propagating the subscribe toward the publisher to solicit a response of OK/ERROR. In some implementations that support headless publishers, the relay would send a subscribe OK immediately. The edge relay that has the connection to the publisher performs state compression of subscribes, but that's only at the level per the draft. In this case, the track alias is different, resulting in a new subscribe (duplicate when looking at the ) being created to the publisher. The publisher receives the subscribe with a new and and starts to publish data objects using the and that match internally the track . If one or more clients do this repeatedly, it would result in all relays and the actual publisher itself sending duplicate data that matches . Below diagram illustrates the above. I'm sure there are many reasonable fixes for this... below are a few. This would change the verbiage of duplicate track detection to perform duplication check on and instead of only on track alias. The state machine for subscribe SHOULD change to move from TO . This simplifies the state machine by reducing the complexity in: detection and elimination of duplicate subscribes eliminating the challenges with having to deal with trial and error responses A hash of namespace and name would allow for the duplicate track detection to work per draft, but... Track alias has a max value of 62 bits. Collisions are the largest pitfall for using a hash of two values. Registry/directory service could act as gatekeeper of track aliases. While this would work, it introduces another micro service for a simple pub/sub, which isn't great. It will also slow the subscribe process down. Many other issues will likely arise with this approach.
I don't understand duplicate subscribes issue here ? can you please elaborate .
If a subscriber sends 2 subscriptions for the same track to a publisher ( ignoring relays for a bit here and also ignoring any form if Ids ), what should be the expected behavior of the publisher ? There are few options Publisher sends 2 copies of the objects (wherever they overlap) Publisher rejects the second subscribe since it is in the same connection Publisher sends only 1 copy of the overlapping objects What is in draft today allows for 1.
Clarification on relay vs publisher needs to be distinct here. When discussing this topic, we need to be distinct on is the request for a range of objects (aka fetch operation where there is a start and finish?) or subscribe to live stream where there is no known end? Some of the challenges here are introduced with the MOQT decision to overload to support both fetch operation and subscribe to live stream, possibility starting at X. In the case of fetch operation, subscribes do not get forwarded to original publisher or to other relays, they are instead immediately fulfilled by the first hop relay, which may pull the data from some distributed/localized cache. It is totally acceptable that fetch based subscribes (aka filter type 0x4), can be in duplicate... although I suspect that is a mistake/error on the client side to request at the same time overlapping/exact same data. Regardless, it's not a big deal for the relay to satisfy this repeated request over the same data at the exact same time, but there needs to be some level of rate limits established to mitigate DoS. While MOQT doesn't need to define the limits, it does need to support error responses that the limit has exceeded. In the case of live stream, IMO it's 100% mistake for any client to ask for the same live stream twice via the same QUIC connection. While talking with NAME , he mentioned a possible use-case where there are two or more displays that you want to display the same content to. If the display has IP connectivity, it should be reasonable that the display would have connected and subscribed to the content, hence moot. In the case where the display does not have IP connectivity, a HUB device could be used that does have IP to act as the MOQT client to receive the data content. IMO, it does not make sense that anyone would want duplicate live feeds of the same data via the same QUIC connection. Instead, if the HUB device has multiple displays that are not IP connected and cannot make MOQT connections themselves, they likely have some other method to mirror content, such as an HDMI splitter. I'm interest in hearing the use-cases that require MOQT to directly support and require relays to support duplication of live streams to the same QUIC connection. Per discussion with NAME , the relay peering would never duplicate the live feeds. It would de-dup all these requests using the track , regardless of how many track aliases were used by a client subscribe. The original publisher would realize this aggregation/de-duplication. In other words, each subscribe from the same QUIC connection or from multiple QUIC connections (in theory different clients) would be grouped together by the relay using the . Each of the and values together represent a feed. In this sense, only or is needed for this process, not both when considering live feeds. Again, fetch is different and is distinguished not only by , , but also by start and end ranges. I'm interesting in hearing the use-cases of why MOQT requires of the relay to support duplicate fetch requests for the exact same ranges at the same time when the other hasn't finished yet. Seems like it would make sense that if the same QUIC connection (aka client endpoint) request range X - Y and while still sending X - Y, it requests it again, that it would cancel the previous and start over. Add some text around that endpoint to relay can establish duplicate live streams by using different track aliases for the same namespace/name. The relay or original publisher MAY implement rate limits on the number of active subscribes for the same namespace+name. The relay and/or original publisher may implement different rate limits based on FITLER TYPE. For example, filter type 04 may allow a maximum of 10 active subscribes for the same namespace+name, while filter types less than 4 that involve live stream feeds is restricted to 1.
The status quo of having both needs to be fixed at some point, see
Does this mean we close the complete quic session? Can we just reject the subscribe?

Revised text:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track  <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).