On 3/17/2021 10:11 PM, Lucas Pardue wrote:
Thanks for sharing the idea. I don't profess to be a CC guru but the I-D and the discussion made me wonder something. Now that you decoupled the timestamp from ACK, how coupled are the remaining elements? There's a frame with a field where the value is unilaterally set, some calculations based on the values, and some choices about how to pack. TIMESTAMP reminds me a little of DATAGRAM. So my curve ball thought is that one could define a container frame for the transport layer signalling that is unreliable and not flow or congestion controlled. We solve the problem once. Then different use cases, like 1WD, could just define a parameter in a container, along with some tips on how/when to packetize it.
I am not sure I follow the "container" idea. We could certainly have a property attached to a frame type -- we do that today. Or, we could have a special frame type reserved as a marker that "the next frame does not require an ACK".
As for CC effects, this is really all on the sender side, so there is little benefit in a fancy encoding that tells that to the peer. In fact, peers do not even negotiate which CC algorithm they use, and it is quite common for client and server to use different ones.
I can predict some downsides with that approach but curious if others think that make QUIC more pluggable.
You do need some additional code before sending or accepting a new frame type, so I am not too sure about the "pluggability" impact.
-- Christian Huitema
