GrumpyOldTroll
commented
2 years ago From discussion on 5/25:
- probably we remove idle timeout and leave it to the server on when to leave
- however, we still probably need a max ack delay
- and we probably should specify that the first ack of data after joining a channel should be immediate, without any bundling or delay, to ensure server knows data is arriving for the channel
In general, retransmits for the frames with reliability in dropped packets on the multicast channels can happen on any channel that reaches the client, either over the unicast connection or the same or a different multicast channel. Server has responsibility to give the client all the frames with reliability (any of the control frames, as well as STREAM frames).
Also possible to do a STREAM_RESET if a server gives up on some block of data. When this happens, it's possible for the client to pick the stream up again later after a STREAM_BOUNDARY.
A section covering this will probably also need to cover https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/issues/16 (about how to handle limits on how much data server will buffer before abandoning a client that's not keeping up), so maybe these issues should be merged, or have different subsections. But something reasonably complete is going to be needed on this topic.