search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Initial timeout #33

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

The initial time to join a channel can be significantly longer than the value in max idle time (as that is intended as the time to detect a disruption of an already established channel) as the join has to be propagated and the multicast tree constructed.

There could probably be an additional field in MC_CHANNEL_PROPERTIES (something like max establishment time) or just general guidance and a recommendation on the time it might take.

GrumpyOldTroll commented 2 years ago

Yes, I wasn't sure whether this belongs in MC_CHANNEL_PROPERTIES or whether it should just be documented as a client-side configuration parameter that doesn't appear on the wire. We certainly need to say something about it, but I'm not sure server-driven properties is the right place to put it because it's more dependent on what typically works for the receive network than on a common characteristic of the server. The way I think of it, there's some kind of "expected join time" in the client network (which might be unknown and needs a reasonable default), and this should be added to the max_idle_time before sending a leave due to lack of traffic.

Maybe another reason for the leave would be good to add as well to indicate "never got any data" that's different from "Max Idle Time Exceeded".