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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Lucas,

On Thu, Mar 18, 2021 at 12:43 PM Lucas Pardue <[e-mail]>
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...
>

I was just talking about work like this in the Cellar working group
yesterday.

In the Days before CoViD-19 (IETF 106), we talked in TSVAREA (
https://datatracker.ietf.org/doc/minutes-106-tsvarea/) about two ideas that
seemed to have traction:

   - running a couple of QUIC Dispatch sessions for all the extensions that
   were stacked up behind the core QUIC documents (
   https://datatracker.ietf.org/wg/quic/documents/ shows 11 docs adopted,
   28 not yet adopted), so that proposals could get the benefit of guidance
   from the QUIC community without using QUIC working group time, and
   - doing something to give guidance to implementers, before QUIC is like
   SIP or TCP with dozens of documents for people to read and grok (see
   https://tools.ietf.org/html/rfc7414 for TCP,
   https://tools.ietf.org/html/rfc5411 for SIP, but those aren't perfect
   models, because the number of specifications was so large before anyone
   tried to organize guidance).

The first suggestion is up to you and Matt, of course, but the second
section seems like something we could start on now.

Best,

Spencer