Re: Knowledge transfer for extending QUIC (was Re: New Version Notification for draft-huitema-quic-ts-05.txt)

[Christian Huitema <[e-mail]>]

On 3/18/2021 10:42 AM, Lucas Pardue wrote:
> Hey Matt,
>
> On Thu, Mar 18, 2021 at 3:06 PM Matt Joras <[e-mail]> wrote:
>
>> 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.
>>
> You've done a much better job of articulating the idea that I had.
>
> My suggestion was motivated by an observation that people designing
> extensions might have to revisit the same questions over and over: "does
> this frame need to be ack-eliciting, can a packet of pure frames be sent,
> does the frame behave like that one or this one, or does it need to be a
> little special". This is all in the context of how the frame affects the
> transport, not the how the frame enables the extension. We're a young WG,
> and there are not many design patterns or cookie-cutter examples to help
> people focus on the problem they are solving rather than getting bogged
> down by problems they might cause. There is institutional knowledge in the
> WG and I'd love for us to find a way of capturing that so that others can
> benefit. The mvfst example sounds great, you optimized for implementers. A
> concrete frame type might be too far. But maybe we could start thinking
> about some format to build upon the advice already in the 19.21 of the
> transport doc. That might come with time as we learn but maybe some people
> already have some ideas...
>
> Cheers
> Lucas
>
> [1] https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-19.21

I suppose that you mean the part that says "Extension frames MUST be 
congestion controlled and MUST cause an ACK frame to be sent. The 
exception is extension frames that replace or supplement the ACK frame. 
Extension frames are not included in flow control unless specified in 
the extension." The TIMESTAMP frame falls in this "supplement the ACK 
frame" category.

What we have now is simple: just explain in the spec that the extension 
is treated as an extension of the ACK. I am not sure that we know enough 
to specify a container format or any such superstructure. Consider for 
example the ACK_MP proposals, in which a single packet could carry 
several ACK_MP. There are good reasons to add a TIMESTAMP to such 
packets, but you need only one of those for several ACK_MP. It would be 
very easy to define "container" formats that break in such unanticipated 
cases.

-- Christian Huitema