Proposal: clarifying the semantics of the track names

[vasilvv]

(background: #70, probably more)

At the end of the last meeting, I've volunteered to write up a proposal that would let us make progress on the track name semantics. I propose the following (in the form of individual numbered points, so that they are easier to comment on):

1. (Observation) In order to subscribe to a track, the client in the current design needs at least three distinct pieces of information: a connect URL, a track namespace and a track name.
2. (Should be in the spec) The connect URL tells the client how to establish a network connection.
3. (Already in the spec) The track name and the track namespace are the two strings sent in the SUBSCRIBE request; together they are referred to as the full track name.
4. (New definition) A single MoQ server is an entity that is uniquely identified by a connect URL (that is to say, if two entities have different URLs, we consider them different servers).
5. (New definition) Let us introduce a new term, MoQ scope. A MoQ scope is defined to be a set of servers for which requesting the same full track name will result in the client subscribing to the same track with the same data on it.
6. (Already in the spec, but clarified) It is up to the application building on top of MoQ to define how large the scope has to be. An application that deals with connections between devices on a local network may limit the scope to a single connection. An application that uses multiple CDNs to serve media may require the scope to be all of those CDNs.
7. (New rule) The full track name is the only piece of information that a specific MoQ server uses to identify the track. It does not use any sort of header-based negotiation like HTTP provides with Vary/Accept/etc. The connect URL is not used directly, but it does imply the scope for the name.
8. (Corollary) A full track name can be used as a complete cache key (for a given scope).

(Open problem: while a full track name might identify the track at a specific instance of time, at a later point in time that name could refer to a completely different track. We should decide how we want to deal with that, but probably in a different issue)

@fluffy @suhasHere @kixelated What do you think about this proposal? Does it address your concerns?

[fluffy]

This proposal works for me. ( I could also live with even weaker versions). I have some nit picking on the way scope is defined but I agree with the idea of scope you are trying to get to here and the implications that the track name.

[suhasHere]

Thanks Victor for writing this up. I also agree with the general direction here. One thing we can add in the PR text based on the above is identifying the purpose of full track namespace on its own , which you already have above.

Look forward to review the PR text

[fluffy]

Nit picking on scope: I am not trying to change what is in scope, just how it is defined. I agree with the proposal.

I don't like using the term MoQ server for the way it used here. A connect URL look like moq.akamai.com and use geo DNS and / or anycast to refer to a crap load of servers, or a connect URL might refer to a specific set of edge load balancers in a specific cluster in an specific availability zone in a given region (stealing AWS terminology) and could be moq-cluser-f.us-east1-1b.webex.com and even then that might be more than one server or it might look like TV-3889.moq-cast._udp.local. It just seems it will get very confused with the term "Server" we already have in the draft which is more a specific instance that terminated a TLS connection.

Perhaps we could remove MoQ Sever as term and just talk about the "scope" of a namespace and define that as all the servers ( including relays ) where this will be published or subscribed too.

[afrind]

Individual comment:

In general, this proposal matches my thinking.

I do think there's power in being able to hand out the same "virtual" full track name to many clients and have the logic to resolve that to a real full track name on the server. As I read this proposal, it would be explicitly disallowed by 7 and 8. Perhaps it can still be supported by adding a SUBSCRIBE REDIRECT reply to a SUBSCRIBE message, though it costs 1 RTT to start the correct subscription.

We are also experimenting with server-side ABR in HTTP video delivery, where the client simply asks for the video and the server is dynamically switching between renditions based on available bandwidth measured at the transport. I'm not sure how that can be done with moq following the rules laid out here? Since every user may see a different sequence of bits, do they all need to subscribe to (or be redirected to) unique track names? That would add complexity to our design and doesn't seem strictly necessary.

I'd expect the full working group to have opinions on this topic regardless of what the authors choose, so I don't know that we need to completely resolve the issue this week. If there isn't immediate consensus, I'd be ok if draft-05 had Victor's proposal and continuing to discuss the above issues in the working group.

[kixelated]

This works for me since the connect url MAY be used to determine the MoQ scope. +1 with Cullen to remove the "MoQ Server" definition.

[fluffy]

Somewhere back Luke had asked me if I was OK with a connect URL of webex.akamai.com and namespace of just meeting1234 and I had said I did no see how that would work. I think with this scope framing, I now understand how that would work. So if akamai is bringing up a set of virtual relays that are only used by webex and these relays have there own connected UR, and inside of that scope, then the namespace meeting1234 can provide enough information for the relays to work.

So having the "connect URL MAY determine the MoQ scope" does work for me.

[suhasHere]

Looks like we have authors agreement on the general direction. Adding connect url MAY define scope is certain conditions is good to support use case that Luke has brought to considerations.

Agree with Alan that we should get a Pr to clarify things listed in the discussions above.

[vasilvv]

Wrote #162, mostly based on the text above. Please comment on specifics wording.

A few comments on some points Alan has brought up:

Perhaps it can still be supported by adding a SUBSCRIBE REDIRECT reply to a SUBSCRIBE message, though it costs 1 RTT to start the correct subscription.

It doesn't necessarily have to be that way if you allow a reply to be "name A got redirected to the name B, and you're now subscribed to the name B".

We are also experimenting with server-side ABR in HTTP video delivery, where the client simply asks for the video and the server is dynamically switching between renditions based on available bandwidth measured at the transport. I'm not sure how that can be done with moq following the rules laid out here? Since every user may see a different sequence of bits, do they all need to subscribe to (or be redirected to) unique track names? That would add complexity to our design and doesn't seem strictly necessary.

I believe Luke had a proposal where you could subscribe to multiple tracks that are interchangeable, and the server would perform ABR. Regardless, there has to be some complexity here, since the CDN does not necessarily know which sets of tracks can be ABR switch between (since the catalog and the media bitstream are opaque), and, while on client<->CDN hop you would want a single version of the same media, on the CDN<->backend hop, you'd want to fetch many of those at once.

[afrind]

It doesn't necessarily have to be that way if you allow a reply to be "name A got redirected to the name B, and you're now subscribed to the name B".

Yes, I thought of that too. Maybe we'll end up proposing something along these lines down the road.

Regardless, there has to be some complexity here

Fair enough. To make it work the groups need to be synchronized between the tracks as well or it gets even more complicated. This may be the kind of thing we build an extension for and bring it back to the WG after we figure it out.

Assuming we had "subscribed-you-to-this-redirected-stream" feature, that would solve the naming problem (eg: you subscribe to foo.com/video and we redirect+subscribe you to foo.com//video).