Closed MaxF12 closed 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))
Sorry, should have phrased it better, let me retry: I think the server does not always even need to know which specific packets are getting acknowledged (in cases when there is no intention to retransmit missing packets), so it might be sufficient to just send a frame saying "Out of the last x packets I received y" so the server can still know if/ how many dropped packets there are. I wonder if the handshake should also somehow negotiate if the server and client want reliable transmission or not.
I like the idea about having a bundle size, maybe it would also be sufficient to say clients SHOULD try to fill the PMTU as good as possible?
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.