Re: New Version Notification for draft-huitema-quic-ts-05.txt

[Christian Huitema <[e-mail]>]

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