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

[Lucas Pardue <[e-mail]>]

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