search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Loss of a MC_CHANNEL_PROPERTIES frame (and potentially MC_CHANNEL_LEAVE) #35

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

If sent over multicast, a MC_CHANNEL_PROPERTIES frame might get lost. Add text that states that servers MUST retransmit frames lost this way over unicast.

If the split into multiple frames happens, this would probably be only a MUST for the key update frames.

GrumpyOldTroll commented 2 years ago

Why? I think it's just up the server like anything else it wants to send on how's the best way?

Both unicast and multicast have cases where the client doesn't get the update before the Until Packet Number runs out, but then the client just leaves until further notice from the server, I think. Is there some reason that's not a good enough fallback for this case?

MaxF12 commented 2 years ago

Well I was thinking more along the lines that the client misses a key change (that may or may not occur before the previously stated until_packet) and then suddenly can no longer verify the integrity of the multicasted frames.

But you’re right, MUST is too strong here. I just thought it would be good to make it clear that this is something that might happen and will in most cases probably not be what the server intents. So maybe a SHOULD?

GrumpyOldTroll commented 2 years ago

Key change means they can no longer decrypt, but yes, same if they miss a hash algorithm change.

I agree server has to cause a retransmit that client can receive and interpret in a reasonable amount of time, but I think it could for instance be sent on a different multicast channel rather than the unicast channel (and any channel that's broken or left by a client won't work, including the channel that just got updated and client missed it) but I'm not seeing how there's inherently a unicast-specific requirement as opposed to any path that's still working even if the frame in question got lost.

Maybe it could be right to have a paragraph pointing out that when some updates are missed it makes the channel broken, so server shouldn't use it for retransmitting.

GrumpyOldTroll commented 2 years ago

I'm not actually sure we need any text for this specifically, as opposed to just actually writing the recovery section (#26), so maybe we should close this one as a dup?

MaxF12 commented 2 years ago

Sure, makes sense I guess