Closed GrumpyOldTroll closed 2 years ago
Capturing the other notes from the thread: I guess session properties should implicitly reserve the session id, but also a MC_RESERVE_SESSIONIDS frame to reserve a list of IDs without sending their properties.
I think if there is a collision it doesn't matter until the server issues a JOIN, but if the client has not yet migrated connection ID it can refuse the join with an "ID Collision" reason and we don't really need other signaling about it I think? Actually it occurs to me the server should already know if the connection ID is in use, and can determine when it has closed to retry the join?
Another option here is just an empty MC_CHANNEL_PROPERTIES, if there's space constraints and to NOT add this frame. I think if you use a 0 content field and a 0 from packet number it's only 2 bytes of overhead. We can make a note that server can do this to reserve channel id space even before a channel is active, and that clients SHOULD migrate away from colliding connection IDs and avoid creating colliding connection ids whenever they see a MC_CHANNEL_PROPERTIES, and then we don't need a new frame.
From Max in issue #4 comment: https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/pull/8#discussion_r854656985
There should probably be a mechanic to force clients to not use some connection IDs for unicast connections. I think only doing it in the MC_SESSION_PROPERTIES frame is too late, it should probably be done immediately after the handshake of the unicast connection. Its basically a frame telling the client "Do not use any of these connection IDs for your unicast streams as we might have a multicast session that uses this ID. If you (by sheer bad luck) already use one of them for a unicast connection (i.e. the initially created one), issue a new connection ID and retire the old one immediately."