Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

Martin Duke <martin.h.duke@gmail.com> Wed, 13 November 2019 00:42 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922801200B5 for <quic@ietfa.amsl.com>; Tue, 12 Nov 2019 16:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnooTssaTMD4 for <quic@ietfa.amsl.com>; Tue, 12 Nov 2019 16:42:25 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63C3120091 for <quic@ietf.org>; Tue, 12 Nov 2019 16:42:24 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id b17so129658wmj.2 for <quic@ietf.org>; Tue, 12 Nov 2019 16:42:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t5bs9BOBb0qp3H07uPfggiidmhp7bS6Yf2BgVwGlfRk=; b=XuczZNc8kOzYq+5x9FtMhbvH+RwTAw0ZGpgLpE2CzJDJw/BBZ2VzJaoOU74IUoW5ff qx5/s0fzvJt7ozmQDW5mKVsmjr4iYmG7fWTQl8qxVGE9IUKY00gKzwrek0u8HKHmQSG5 69huCbiuHhZVjrH2VNLrVRxhGVQ+V+bM4bYKB2vXsQiH9ghf8iWo7c7mxF2ct0M4YiuK dt0tnUEZFa3aeGu3Hlvmm01CYf3cCjrnHn+wRyjn13NXiIBkcmVYPUEXgneMXrnTaawX jRvW6GhDZ5Wmz/6fQbJJa+A0uJReN343MecYn+kFszNBkLJd/c/vQrIURqXh8eNHNwkb 8K7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t5bs9BOBb0qp3H07uPfggiidmhp7bS6Yf2BgVwGlfRk=; b=UK19qYEbZbhcIFcndHTDPlZdjoQ5VoqInN9TKcupvZqsxXSVJ4VYud3VJhlDpXRGsK 1nBXJUeuOuBPWDI69oAAQSbh2T2p6p5EUEEAhi3Y7Qd5ixp0AsM+5HICn9d07Oc0HExQ 35g0dOoAZHxBIPGp/ieNr+wx53gSOPuk8qyIzKDqpkHlPMQaydF+5jA4YMOQLnv/0Fui TlYcdLjB+aPnUrJPO9wxxMvNZ8eG8+pXvtMDLmWf3JdbRl9nOIGARVKsTzsxHWqTxNi5 bjejIrO2ncXjzsfvmfL2bGPRUiQSSBRTJBiN25wLoewb/PCTEvy2V33i4VUllFRaAFmQ 0LOA==
X-Gm-Message-State: APjAAAUBcnbncVdkr1sKA7ZwNmDSMKhr1sMMyrX5UndWS5T/ve62HcBF xGDj7R20G+7FYUKml7w/y7iBMyEgyTewH1sI4IrZcw==
X-Google-Smtp-Source: APXvYqw9wei2FguG3zuFvEvSr13vMEyRDF3rAq9q6DUAaR6ljSkUSrzGjLQ9lIBt5HNwnWzdIKT6UXPZVD+3He/gpaI=
X-Received: by 2002:a05:600c:3cc:: with SMTP id z12mr217392wmd.151.1573605743127; Tue, 12 Nov 2019 16:42:23 -0800 (PST)
MIME-Version: 1.0
References: <6A43BEC7-F9DE-40C9-BF70-BF1618EAFE01@mnot.net> <88BCFF39-6F9D-4E03-8787-561EECBBACE4@gbiv.com> <FD5201A5-C179-4302-B437-57561FB8DB24@mnot.net> <DM6PR22MB20101F0D1CC9867D5F3EE865DA740@DM6PR22MB2010.namprd22.prod.outlook.com>
In-Reply-To: <DM6PR22MB20101F0D1CC9867D5F3EE865DA740@DM6PR22MB2010.namprd22.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 12 Nov 2019 16:42:12 -0800
Message-ID: <CAM4esxTYYJiPBgEdj278k2ZggZ_+D8CDd2rOjM14JRCLESowPg@mail.gmail.com>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
To: Mike Bishop <mbishop@evequefou.be>
Cc: Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000055f2ca05972fa35c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6qsEfXBdMeEUZN5TylaeFO4B7Hg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 00:42:29 -0000

IMO the recovery draft is in the midst of a major revision dealing with the
aftereffects of discarding the crypto timeout. Ian still has a bunch of
stuff in flight for this. When all of those PRs land I would like to have a
short period to review the working draft and see if it looks good.

On Mon, Nov 11, 2019 at 7:40 AM Mike Bishop <mbishop@evequefou.be>; wrote:

> I'll also note that it's relatively easy from a spec perspective to allow
> trailers to arrive before the end of the body, or to allow multiple sets of
> trailers to arrive.  I suspect most clients won't process trailers until
> they have the body anyway, but the real question is what clients do with
> multiple trailer sets.  I'm not certain whether that's in our scope or not,
> but that's a separate conversation.  Feel free to open an issue for that
> specific discussion.
>
> -----Original Message-----
> From: QUIC <quic-bounces@ietf.org>; On Behalf Of Mark Nottingham
> Sent: Sunday, November 10, 2019 8:01 PM
> To: Roy Fielding <fielding@gbiv.com>;
> Cc: Lars Eggert <lars@eggert.org>;; IETF QUIC WG <quic@ietf.org>;
> Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the
> Late-Stage Process
>
> Hi Roy,
>
> Responding to the parts relevant to this CfC.
>
> > On 7 Nov 2019, at 5:39 am, Roy T. Fielding <fielding@gbiv.com>; wrote:
> >
> >> On Nov 5, 2019, at 5:01 PM, Mark Nottingham <mnot@mnot.net>; wrote:
> >>
> >> Previously, we've moved to the 'late-stage process' documented at [1]
> for the Transport and TLS drafts. The chairs and editors now feel that it's
> time to move the Recovery, HTTP/3, and QPACK drafts to that process as well.
> >>
> >> As before, this is because we're getting to a stage we feel the
> documents would benefit from slower and slightly more formal process, so
> that the rate of change is not so high, changes that do occur are
> well-vetted, and the documents get closer to reflecting consensus in the
> working group.
> >
> > I don't think that process has worked well for QUIC.
>
> Noted.
>
> > There are specific issues that are contentious enough to timebox and
> > conclude, in a formal (and faster) fashion than was done before.
> > That makes sense when needed for a specific issue. I don't know of any
> > such issues for those three drafts. IOW, I don't know of any issues
> > for which it makes sense for the Chairs to pre-empt the specification
> > authors in deciding what can or cannot result in changes to the drafts
> > just because of the timing of when the issue was raised.
>
> You misunderstand the process; the Chairs aren't pre-empting anything, the
> group is attempting to agree to a path to completing this work.
>
> > The late-stage process seems to focus all of our energy into
> > in/out-of-scope arguments rather than actual text in the specifications.
>
> I don't see any evidence for that claim; what makes you believe that?
>
> > The last interim spent easily twice as much time discussing process
> > and process planning than it did HTTP/3. Prior interims were worse.
>
> We spent a day talking about transport and TLS, part of a morning talking
> about planning the future of our work (if you want to call that "process
> and process planning") and the bulk of the (longer) afternoon session
> talking about H3. This isn't surprising, since our goal for the meeting was
> to get the Transport and TLS documents close to finished.
>
> > I don't even recall the last time contents of the HTTP/3 spec being
> > discussed on list, outside of very specific issues related to transport.
> > I would like to see HTTP/3 written with HTTP in mind, not as a set of
> > diffs against h2.
>
> That is by charter; we're largely limited to mapping H2 onto QUIC.
>
> > This is not a small undertaking, but it isn't a massive one either.
> > Basically, import the bits of h2 that are necessary to explain
> > HTTP/3's operation and intent, and then start referencing the
> > http-core drafts instead of 723x. Yes, I know that is risky, but it is
> the right thing to do.
> > And it needs to be done before http-core is finished, since that
> > effort exists largely to place the right content (in the right places)
> > for
> > HTTP/3 to reference.
>
> AIUI that is still our intent, and shouldn't be impeded by the late-stage
> process, since that work should be editorial.
>
> > I have no idea what the status is with QPACK, but we should learn a
> > lesson from the last time and make sure the fixed compression
> > dictionary (if any) is based on traffic at more than one proxy or
> > origin server. Or at least have each of the major deployments generate
> > their local "best" encoding and do some cross-testing of the N choices
> > (plus one or two based on a hand-crafted expert merge).
> >
> > I would like for HTTP/3 to have a mechanism for communicating metadata
> > (like trailers) in mid-stream, both for requests (e.g., priority) and
> > responses (e.g., chained sigs). That has been a design goal for HTTP
> > since 1995 or so. HTTP/1.1 had it, albeit limited to chunked extensions.
> > It has been proposed multiple times and keeps getting postponed
> > because of "concern about scope". This is not a semantics issue (they
> > are just optional trailers that arrive early) -- it is a multiplex
> > framing issue (a new frame type and expectation to process).
>
> Where are the multiple proposals you refer to? We've been working on h3
> now for more than three years. If you submit them now, they'll be design
> issues.
>
> I'd say that the Late-Stage process (or at least the proposal of adopting
> it) is working exactly as intended here -- making people realise that if
> they still have issues / changes that they want discussed, they need to
> bring them to our attention now, not as we go to WGLC.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>