suhasHere
commented
2 years ago yes subscribes does need some state to be maintained on the serves/relays and it needs to eb refreshed to be kept alive. Timer based clean up of state/cache is very typical of CDN implementations and I am not sure why this would be different
On moving between the relays, the spec does define redirect option for the client to move to a new relay and client can itself choose to do so based on application triggers. Either will involve cleaning up existing state on the old relay ( implicit in former and an explicit unsubscribe from the client in the latter)
I don't think pinning relay is needed and the spec should except clients to work with the way today CDN interactions work. Today get for a segment mp4 file typically go one to rack of servers in a region , all of which have the file stored ( either by CDN internally cross copying or client requests filling in the caches on each of those servers due to the reason of it being landed on diff server each time the same file is being asked for) .. The same holds true with subscriptions as well.
I am afraid the ask for each segment when they become available adds latency and want to really understand why existing subscriptions doesn't work. OTOH, even with subscriptions client is still in control of its subscriptions.
May be we are mixing 2 different levels of abstractions and should chat live ?
TimEvens
In classic publish/subscribe architecture, the client subscribes to some event, and when the even occurs the servers sends the client a notification. There are multiple ways to map this to QUIC. The simplest way is to use client's transaction to place subscription state on the server, and then have the server send events as "server initiated streams", similar to the "push" method defined in HTTP 3. When looking at a network of content distribution servers or relays, there are two potential downsides in this simple method: it requires creating and maintaining subscription state in the relays; and, it assumes that the server handing the subscription is the same that handles the transmission of events.
Issues occur if a transaction sets subscription state in the relays. The state will have to be dropped when the client is not interested any more, which requires a timer. The client needs to keep the subscription alive by issuing series of transactions to refresh it. In a classic CDN architecture, there is no guarantee that the "refresh" subscription will arrive at the same relay as the original request, which could create some confusion, such as duplicate subscriptions for short period. Even if the client does not change location, relays may well be composed of a rack of servers behind a load balancer. The refresh may end up processed by a different server in the rack.
One possible solution is to "pin" the relay, so the client always uses the same one, but this is a trade-off. The client may well move during a long session. The relay picked at the beginning of the session may become inadequate. Ideally, the media should always come from the "best" relay, not from the relay pinned an hour ago. This is achieved if the client "pulls" media segments independently, as they become available, and if the "pull" transaction is naturally routed to the nearest gateway.
Suppose that instead of describing the subscription as installing state on the server we model the subscription as a long duration QUIC connection and QUIC stream, over which the client is notified of the availability of media segments. This moves the burden of "keeping the subscription state" from the relay to the client. The relay receives a request to "get the subscription object", and treats that as any other media acquisition. The client receives a stream of messages, such as "segment-x is available". The client can then request the segments separately, as a pull command directed to the nearest relay.
If the "subscription state" is modeled as a long duration stream, the client becomes in charge of maintaining the connection, or resetting it to the nearest relay if it breaks. The relay state is limited to passing data, the relay does not need to parse the subscription data and act on it based on available media. If the client does not need the subscription anymore, it will just close the connection.