search

GrumpyOldTroll / draft-jholland-quic-multicast

Work in progress to propose a multicast extension to quic.
Other
6 stars 6 forks source link

AMT #34

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

This might be too much for the initial document and could be an expansion, but it might be useful to add a frame that contains information about available AMT relays for the channel in question. That way you could still distribute load better in cases where e2e native multicast isn't supported by utilizing as much multicast as possible (up until the relays) and reduce the load on the server by having many unicast connections.

I guess this idea similar to having a fan out, but it might be an interesting alternative. You might even be able to do something clever by determining which relay is best suited by the clients IP or something along those lines and then just including that.

I guess in theory this could be done by simply adding an AMT relay field to the MC_CHANNEL_PROPERTIES.

GrumpyOldTroll commented 2 years ago

I think this is just worse for network offload than sending the data on the unicast channel?

(It adds a bit of AMT overhead, but since the gateway is embedded in the client and talking to a server-chosen relay it definitely didn't use any network replication except in the server-controlled part of the network.)

MaxF12 commented 2 years ago

Right, I was thinking that you might at some point get ISP/ operator provided relays close to the edge like Lenny (I think?) suggests. I guess there is a bit missing that would allow these relays to announce themselves to the server. In either case, it should not be part of the base spec so I am gonna move this issue to my fork just so its written down somewhere.

GrumpyOldTroll commented 2 years ago

ISP/operator-run relays wouldn't be something the server could transmit in its channel properties. That could happen, yes, and it could usefully be integrated with receive libraries, but it would be an integration with how to do local discovery of relays, not a server advertisement feature.

I think this is plausible for instance with DNS-SD using a local search domain, which is why I put that discovery path in RFC 8777 at higher priority than the actual driad extension, but for the same reason it's not under the source ip's reverse ip dns space, it also can't be in the server-sent channel properties. It would have to be a separate thing in the browser that's about local service discovery, so I think it's a separate thing from this spec.