search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Remove MC_STATE JOINED? #126

Open MaxF12 opened 2 years ago

MaxF12 commented 2 years ago

Is it enough to have it be implicit by sending ACKs for packets received on a channel?

GrumpyOldTroll commented 2 years ago

Maybe. I'm a little worried about the corner cases and state ambiguity here.

I made an updated server state diagram if we do that, and sure, it's simpler: https://docs.google.com/presentation/d/1J1ISZFYUT-9nxX7vq17oNKAtDXZYv6KrXH4Y6AtiLSM/edit#slide=id.g14992269579_0_0

I'm a little worried whether there's any issues if MC_ACKs arrive late and falsely indicate that we're in Join Confirmed from an older join, after we leave and rejoin a channel.

Also, packets containing only ACKs (and probably MC_ACKs, though I don't think we wrote it down yet) don't themselves get acked, so if early acks got dropped or if there's a pause in the data transfer such that you don't see any MC_ACKs, the server won't know if the client attempted to join and saw nothing yet or whether it's waiting before joining for some reason.

Maybe it doesn't matter, but I'm not quite sure, and it seems to me harder to reason about, so harder to figure out if there's a problem, whereas the MC_STATE(Joined) provides a gate to verify that the state transition happened regardless of timing. Maybe before we pin this down we should figure out how to do a formal analysis or something...