search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Replace Max Idle Time with Max Ack Delay #63

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

I think we talked about this but forgot the issue I think:

Since the server knows if/ when reception of multicast is interrupted (by no longer getting ACKs) there is no need for clients to leave channels unilaterally if they think the channel timed out.

GrumpyOldTroll commented 2 years ago

Yeah, and ideally they should not do so, to allow popularity analysis to work correctly inside the ISP. I think this point probably deserves a mention in the operational considerations section (#61) (Clients can still leave for other reasons as desired but should not leave due to non-receiving.)

GrumpyOldTroll commented 2 years ago

There's already a max_ack_delay transport parameter in base quic (https://www.rfc-editor.org/rfc/rfc9000#section-18.2), is there any reason we can't just use that and leave this out?

GrumpyOldTroll commented 2 years ago

I remember now--I think we said there should be a different value that was per-channel, basically to allow for more aggregation especially on slower channels (and especially considering the linear ack scaling problems).

But I think we probably don't need the Bundle Size anymore if we take out the idle time, it can just fit in the per-channel max_ack_delay, right?