GrumpyOldTroll
commented
2 years ago Yes, some kind of mechanism like this seems like a good idea. I was originally thinking bundling could cover it, but I think you're right that it shouldn't be so tightly coupled to max_ack_delay that you have to pick between impacting your unicast recovery and requiring too many acks for multicast data, and that as it stands there's not a way to treat them separately.
As a brainstorming proposal: what about maybe a "recommended ack bundle size" as another session property that advises a client on a bundle size specific to the session to use as a target for a bundled acknowledgement count, and maybe this would override max_ack_delay for sessions below the recommended bundle size unless there is a gap in the packet sequence numbers that lasted longer than max_ack_delay or max_idle_time was exceeded (or maybe also if a ping or path challenge was received). I think this would help with ack overhead (at least for the typical case?) without impacting unicast recovery.
To the other point you mentioned: I think there are already mechanisms that can avoid the need for retransmits, such as RESET_STREAM and DATAGRAM, and I don't think I know any use cases that need another way? (draft-lcurley-warp for instance will use a stream per object and a reset stream if there was loss that's late enough they'd rather abandon it, I think))
MaxF12
Following QUIC mechanics, every single STREAM frame has to be acknowledged. This is done so that missing frames can be retransmitted. However, in Multicast there are several use cases where a retransmission of missing frames might not be desired (such as live video streaming) and having to acknowledge every packet creates unnecessary overhead (which at Multicast scales could add up to be quite significant). I think it might be useful to have a mechanic that replaced the acknowledgement of every frame immediately with either a bundled acknowledgment of several frames that only occurs (relatively) rarely or even just an acknowledgment that (any) data is still being received over the Multicast Channel. I guess a high max_ack_delay could be used to bundle acknowledgments, but that is set by the client. There is also not (yet) the inclusion of a mechanic that would allow for different transport properties between the unicast connection and the Multicast channels, so you would be stuck with a high max_ack_delay for unicast frames as well.