search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Client behavior when unicast connection is disrupted #12

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

How would a client behave if the unicast connection is interrupted but the Multicast channels still receive data? It wouldn’t be able to check the integrity of any packets, but it isn’t exactly idling either so the idle connection timeout would not trigger I guess? Should this be clarified so that all multicast session are left and the entire connection is shutdown if there is no message over the unicast connection for longer than the idle timeout?

GrumpyOldTroll commented 2 years ago

Yeah, good question. I guess maybe the client should actively ensure it still has unicast connectivity and leave sessions if it can't prove it does, on a timescale similar to max idle (or maybe another value?).

I guess if client gets no packets for some time on unicast, it should probably send a ping, and if it still has no ack after some time it should leave its sessions with a reason like "failed unicast". But yes, there should certainly be a section detailing the behavior, good point.