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

[Martin Duke <[e-mail]>]

OK, I apparently missed taht a few of these pushed to master. Yes, let's
move for late-stage

On Wed, Nov 13, 2019 at 10:39 PM Ian Swett <[e-mail]> wrote:

> I'm not aware of anything important in-flight( :) ) for recovery.  #3066
> <https://github.com/quicwg/base-drafts/pull/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 <https://github.com/quicwg/base-drafts/pull/3080>) and an alternate
> solution to the amplification deadlock(#3162
> <https://github.com/quicwg/base-drafts/pull/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
> <https://github.com/quicwg/base-drafts/pull/3145>) 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 <[e-mail]>
> 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 <[e-mail]>
>> 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 <[e-mail]>
>>> 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 <[e-mail]> On Behalf Of Mark Nottingham
>>>> Sent: Sunday, November 10, 2019 8:01 PM
>>>> To: Roy Fielding <[e-mail]>
>>>> Cc: Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>
>>>> 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 <[e-mail]> wrote:
>>>> >
>>>> >> On Nov 5, 2019, at 5:01 PM, Mark Nottingham <[e-mail]> 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/
>>>>
>>>>