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

Spencer Dawkins at IETF <> Tue, 23 March 2021 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF4EB3A097B for <>; Tue, 23 Mar 2021 05:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZ9qmxLC5szM for <>; Tue, 23 Mar 2021 05:47:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21E593A0976 for <>; Tue, 23 Mar 2021 05:47:59 -0700 (PDT)
Received: by with SMTP id w8so10186737ybt.3 for <>; Tue, 23 Mar 2021 05:47:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b6RkVYHuvlgKqgtKvNsdj9EgRGD4nfUaU6skTqnPego=; b=shZG7B89wIBOK4tzsAEvxS/4WrvmNT8zUY0MHt6Hgc95lJhV26LoMaxvSKYRJBZkKv D3XcdPqCG1jGXlOxrsKp+VI6t7Sx2jgCEznTQTN/VI4yghS/3CeenpO6GVz2FKskYqNe 8vdHfQLPlx77n/4B6UJZGWj47x0pn7cTi0+RsNJ4eB93cqujBgqVIkvoUKbz0EWzInDi l00WORE5RrBHiyYOBXm1oR/uphLit7QmEmVt36A/NmQ9QiWm4bN1xHy3yzBNMLPJ91zM T6XpVP0CUHczxSEcuogzT7ETba04gGHMiIH6y4IUr60VP573IcNbm/kSQBgN1FbZqhmO WJyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b6RkVYHuvlgKqgtKvNsdj9EgRGD4nfUaU6skTqnPego=; b=WnaUkbOQ1X2vBMB0AE0AoAZBAYdlE2oJrXjgc+0PK5qm7ZyhKXueN5wjGNruuO3FVt DcZOA8fAbxzYgA+3t0wK/FxX+33F341RCHGhgY41XuT3MSpM6JgQXYOFpHIa44nZmO3H QgBL45Ywytiz9i/erewkY4qT81irAUHqP4zT9zP9X6uxl/1mPMkOm4dDFDITXGTUuCsX 9Ucz7akIAIx/qBdxw86RYgoTzk09cszycwceTIWbX9dH1sb5AV/uwUzD7b3nDIjnyoOj zDnFO2CdLOL4A+F1Mw9/agIrkpCd8HC3VTZYwXI2T4SmCQaLNgpiYFsX3wxWmluxAk6q Z85A==
X-Gm-Message-State: AOAM532aZTDMYDzN7rq/1ZVrNUZWc5vBE/UjhcNTwpJQb+nhODezIvsG RDuF2jqc6+aI7IqCRahh2iVH3OAmOu5FltNBuLw=
X-Google-Smtp-Source: ABdhPJy7Px4q2ovYD2c2qhgCzW7/UYKxB2qsDBEl1u2GixOID3MudMepLOvpLZi9EAP3DyGBCc7xLKdwGnhF0cr10PY=
X-Received: by 2002:a25:868c:: with SMTP id z12mr4839258ybk.389.1616503677758; Tue, 23 Mar 2021 05:47:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Tue, 23 Mar 2021 07:47:31 -0500
Message-ID: <>
Subject: Re: Knowledge transfer for extending QUIC (was Re: New Version Notification for draft-huitema-quic-ts-05.txt)
To: Lucas Pardue <>
Cc: IETF QUIC WG <>, Matt Joras <>
Content-Type: multipart/alternative; boundary="0000000000007db06a05be33972a"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Mar 2021 12:48:03 -0000

Hi, Lucas,

On Thu, Mar 18, 2021 at 12:43 PM Lucas Pardue <>

> Hey Matt,
> On Thu, Mar 18, 2021 at 3:06 PM Matt Joras <> 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

In the Days before CoViD-19 (IETF 106), we talked in 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 ( 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 for TCP, 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.