Re: Rechartering QUIC for Post Version 1 Work

Spencer Dawkins at IETF <> Fri, 29 January 2021 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C24A63A017E for <>; Thu, 28 Jan 2021 16:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] 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 Pe5W5xvXR7Vz for <>; Thu, 28 Jan 2021 16:22:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EECDE3A0100 for <>; Thu, 28 Jan 2021 16:22:36 -0800 (PST)
Received: by with SMTP id k4so7267907ybp.6 for <>; Thu, 28 Jan 2021 16:22:36 -0800 (PST)
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=uy8VIUR9oHCnebBDR7HkwzQ1cEcNDHGSshO8+GgMRtA=; b=siG9t3nNlcIWctVDXzMCHbkpsHsabpb+DQE7bq7iJIPXvlag6ethqqmq25wxkstiuy I1sVeQvUfyTxQ0GTnaIyYuMFuAUL7v+vl5B9oe5G7xYxlM0OcPg6uGg2871b20ZorQ/C e2QybU/Vuhqw35yQ/jiTOhwRZx7dqukHplrqn/6uHqNWu8iAEpzITn9hqvMiUzQDnUPR qophgoZtKPMNy7SVB6KFuiPk0nbN1mMaklpKcs4W1jn0NBRYEQXHXe8f0y8eQiXyEOw8 cQuSZZIdXqdGeobsr4wadPjD4xlGQxIVPsy9EyLIupeSdoh2EaA4Y1GkBssDfnUoMUWH suCg==
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=uy8VIUR9oHCnebBDR7HkwzQ1cEcNDHGSshO8+GgMRtA=; b=lOqn4eiyYQT4GJjySptoAbj5ulymt6I6AY1aB0DunefpkG9oEOUTge0FgsbC+BBW52 weWAGM0qi5mYjn3U94OXkcU796ag3YTcPGELoBqiQzW6WxQ+AYwpdOT3S6LDJpvXzXrk AViuowbrYaYbYiTF6DdBtPepnmGoVAyGosa8v4dvSyJsOlXthtRXwjX7cXvW6agqzseA N5Zu2V4eXMniV//ovFYm83R0PZg/jtsXuct1wb8l39Iobby3YERkklT26XAa0ur0S6iW JvETa1sFMXBxLldDpDNF9dADEneoW744Ad4SdwMARccfKr/wfa/0WhDGCpUW5fM/ZEhM b1ag==
X-Gm-Message-State: AOAM53231KhqGM5r9SH4rUy1Yy32ozW1XBp29KBuZB0EdHeU6zDVdrJ6 FKYrCuYpyythUMeTSv3PMtqIpCiAJN1Fo0Goo7Dg+GgM
X-Google-Smtp-Source: ABdhPJyHdtUlkPfEBuRhoGbb1d6OweGPEkxTwceXsXR57yd7AFFervGXsJ3cFf1m6ghjOqUn4lGZI9grXPOPzyiKaQU=
X-Received: by 2002:a25:1fc5:: with SMTP id f188mr2489359ybf.389.1611879756127; Thu, 28 Jan 2021 16:22:36 -0800 (PST)
MIME-Version: 1.0
References: <> <20210126170048.GB364092@okhta> <> <20210126170932.GC364092@okhta> <> <20210126184815.GD364092@okhta> <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 28 Jan 2021 18:22:10 -0600
Message-ID: <>
Subject: Re: Rechartering QUIC for Post Version 1 Work
To: Matt Joras <>
Cc: David Schinazi <>, IETF QUIC WG <>, Lucas Pardue <>
Content-Type: multipart/alternative; boundary="00000000000048e9b105b9ff00a2"
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: Fri, 29 Jan 2021 00:22:39 -0000

Hi, Matt,

On Tue, Jan 26, 2021 at 8:08 PM Matt Joras <> wrote:

> Hi all,
> Some responses inline about the example listing, extension tracks,
> multipath, and qlog.
> On Tue, Jan 26, 2021 at 5:21 PM David Schinazi <>
> wrote:
>> Thanks for your reply, Lucas. Responses inline.
>> On Tue, Jan 26, 2021 at 4:56 PM Lucas Pardue <>
>> wrote:
>>> Hi David,
>>> Thanks for the feedback. I've responded in-line, and some of that text
>>> responds to points Ian raised too.
>>> On Tue, Jan 26, 2021 at 9:54 PM David Schinazi <>
>>> wrote:
>>>> I'm supportive of the overall direction of this rechartering, with some
>>>> concerns though:
>>>> 1) multipath is not mentioned in this charter - based on the
>>>> conversations we've had over the past months, I think we should be explicit
>>>> about whether multipath is in or out of scope
>>> The intention was that the new charter would allow the group, as the
>>> focal point for QUIC-related things, to consider work such as multipath
>>> QUIC. The guidance for discussion of multipath is still the same as Lars'
>>> sent to the WG in November [1]. To borrow a bit of that, we still feel it
>>> premature to adopt an proposal as a work item.
>> I see your point, I'm OK with not precluding multipath as long as the
>> guidance from November still holds. But then again, a recharter could be
>> seen as invalidating prior charter-related decisions so being explicit
>> could be useful here.
>> There's an interesting contrast between this point and your second point.
>>> It seems there's a balance between being specific and appearing not open to
>>> new ideas.
>> From my perspective, multipath was important enough of a topic to warrant
>> its own interim a few months back which isn't true of any of our extensions
>> - so I guess that's where I'd draw the line in terms of mentioning
>> something or not?
> In my view codifying any particular position on multipath in the charter
> is problematic (as we've experienced with the existing charter) and could
> be seen as a firm commitment to adopting those work items immediately along
> with the rechartering. The proposed text gives us the flexibility to adopt
> and prioritize multipath work as we see fit without implying that it is
> immediately necessary.

That's probably true, but it's worth pointing out that removing any mention
of multipath from the charter also sends a message (it's not just what the
charter says now, but what the deltas are). But, moving on ...

Please allow me to up-level a bit (and this may also be relevant for my
comment a few minutes ago, about other groups specifying QUIC usages that
at some point start to require QUIC extensions).

Where I thought we were after November on multipath, was that the chairs
(and the working group) wanted to have conversations about proposed
multipath work in the QUIC working group, but didn't want to have anything
that looked like a commitment to adopt a proposal before people presented
their implementation and deployment experiences.

(Any of the chairs can correct me on that, of course, including you)

Would saying something like that help with multipath, or partially reliable
HTTP (as Roberto asked about), or <insert random proposed extension here>?