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

[Matt Joras <[e-mail]>]

On Wed, Mar 17, 2021 at 11:23 PM Christian Huitema <[e-mail]> wrote:
>
>
> 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".

I think what Lucas is suggesting, and has been suggested before, is
that we are likely to have many frames which have similar
transmission/loss/transport handling properties, so why not have a
generic frame we build atop for some extensions?

I would hope we don't take this direction, as we did not take this
direction in the "core" frames in the specification, many of which
have identical transport handling. The design of QUIC v1, IMO,
encourages more frames rather than fewer. It is very easy for us to
add new frames. Putting "similar" frames all on a generic frame's
framework doesn't really save us time in specifying the semantics of
that frame. At best it might save some implementation complexity, but
I would argue that such concerns can be addressed by the
implementations. For example, mvfst has the notion of a generic
"simple frame" which is one which is not retransmitted and there are
not expected to be a great many of them. Many extension frames will
likely be implemented using this implementation-specific framework,
and I would expect other implementations to have their own techniques
for optimizing the implementation of new frames. And as Christian
notes an implementation will always have to implement the semantics of
what the frame actually does anyway.

>
> 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
>