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

Ian Swett <> Wed, 13 November 2019 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 232E712080A for <>; Wed, 13 Nov 2019 06:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 2LPUoNzrs6XJ for <>; Wed, 13 Nov 2019 06:39:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DBC9120808 for <>; Wed, 13 Nov 2019 06:39:40 -0800 (PST)
Received: by with SMTP id l38so720228uad.4 for <>; Wed, 13 Nov 2019 06:39:40 -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=6AQV+le2Sc6xFGowDoKA/P0kcc2xNSaUGj3Vs8i4l1A=; b=i8KXpP6TG70FZFuCtaG/+n6Gv4JqtQ4hqXFbh8lI0c8FF1oH+YStJWlZjfbYVMd5HW ecaSxkp/H+bXl1lRpJZ5pPHsz2agU2Vq2gnnnngLvKF0FuQ+Ys0Jp+rWmgbPGUl40nwL aID6uIWR7r+pOGr6f+O+5hjDL5wUXdVes7H8oUQjPpyCVbJNbPv3WOZzkpp4ANCpQHa/ WKWnTuxARvmc3gp/g/GnfskdqSoc/4tQfg+2vcwPfZ8rLrOB5a6UZj2flZ/P4P2n62Bw As81D3pmSqMb2nWC1frx8TzjLJTpIXdt2jfdNMUrAE+VbCfZtZmihJYhwd2wa0cCBzbl GA5w==
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=6AQV+le2Sc6xFGowDoKA/P0kcc2xNSaUGj3Vs8i4l1A=; b=U5/zNihRxOaGLjXTY+Fv2D+9qx5R6/4WQQS9EoJ30XszVuthiiudp6nar1wyTkud8j jm+k9R08W6dZQXpn9itKLRnWHIuc1GY1cvI9nUn1DNpZjBbxqWdU7+sewgpgUKo8PPgZ ISCv4QuoUW2beW4t6YO0c7skMIFH8e1okV3B0QUhKHWQ8sk8VFKe6Ox9FTqIWm6wLqwg IwzcGcdbymaBx/ypNrJtjAY66vIFJfiujbgp0ja6Ny0vmsXew7jTHM/RbJFn95Zp+Cv7 hq4HeqN5sJIEo93esJsCqZixRwtJH+4Yx9RasDTepWLFY5yaYHEamzZ+fK6ohETwt9xA 0WSg==
X-Gm-Message-State: APjAAAX/b6DNPaEzFV0XADxP8NsIhGX8Qb0Mc8dQq12FwVD9FLe4KrxK YDaPR67XjtgLxvFUXDDLz9irCKQkFo4ZltNs0eEUJQ==
X-Google-Smtp-Source: APXvYqykKZ6+A/FCeTg9G30/4A09ATXCS941MalZ1m/J7O0HbsG0BYpCy8WdFrMc4AeiIr7K9HulTP/hV3Q+FecYC/k=
X-Received: by 2002:ab0:5a8f:: with SMTP id w15mr2003731uae.91.1573655978729; Wed, 13 Nov 2019 06:39:38 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Wed, 13 Nov 2019 09:39:26 -0500
Message-ID: <>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
To: Martin Duke <>
Cc: Mike Bishop <>, Lars Eggert <>, Mark Nottingham <>, IETF QUIC WG <>, Roy Fielding <>
Content-Type: multipart/alternative; boundary="0000000000009cf09305973b5548"
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: Wed, 13 Nov 2019 14:39:43 -0000

I'm not aware of anything important in-flight( :) ) for recovery.  #3066
<> has been in the editor's
copy for over a week now, and did not quite make -24, so I would recommend
reading the editors copy.  There is one handshake optimization PR(#3080
<>) and an alternate
solution to the amplification deadlock(#3162
<>), but neither is critical
in my opinion.

There is a possibility of the discard keys conversation changing recovery,
though at least one solution(HANDSHAKE_DONE
<>) does not require any
changes.  If changes are required, I expect them to be ~2-3 sentences.

On Tue, Nov 12, 2019 at 7:43 PM Martin Duke <> wrote:

> Put another way, I think Gorry's planned review of draft-24 is probably
> premature.
> On Tue, Nov 12, 2019 at 4:42 PM Martin Duke <>
> wrote:
>> 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 <> 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 <> On Behalf Of Mark Nottingham
>>> Sent: Sunday, November 10, 2019 8:01 PM
>>> To: Roy Fielding <>
>>> Cc: Lars Eggert <>rg>; IETF QUIC WG <>
>>> 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 <> wrote:
>>> >
>>> >> On Nov 5, 2019, at 5:01 PM, Mark Nottingham <> 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