Re: Second Implementation Draft Guidelines

[Eric Rescorla <[e-mail]>]

I think it would be good to declare another "implementation draft" very
soon, with roughly the contents of -05. What I see people doing now is some
mix of -04 and -05(pre), and informally coordinating. It would probably be
easier if we just published -05 and said "do -05". I totally don't care if
we call it the second implementation draft or the first implementation
draft bis or anything else.

-Ekr


On Fri, Jul 14, 2017 at 9:50 AM, Martin Duke <[e-mail]>
wrote:

> OK, I understand now. I've added a third option as you described. But I
> omitted
>
> Further revisions to mechanisms in the First Implementation Draft (e.g.
> changes to the public header format, connection close).
>
> as something that might not be entirely relevant to getting something
> deployed, in the interests of reducing scope. If that's a big mistake, let
> me know.
>
> On Thu, Jul 13, 2017 at 6:33 PM, Kazuho Oku <[e-mail]> wrote:
>
>> 2017-07-14 9:57 GMT+09:00 Ian Swett <[e-mail]>:
>> > I think it is an MVP of HTTP over QUIC, and one I believe Google would
>> be
>> > willing to deploy at some scale.
>> >
>> > That's not to say I'm opposed to the other two options, but I have a
>> > preference for something I believe can run real applications with
>> reasonable
>> > performance, even if it's not ideal.
>>
>> +1.
>>
>> I agree that think that sending multiple HTTP requests / responses
>> over QUIC, with stateless HPACK would be a nicely balanced approach
>> that can be used deployed at some scale as well as one that can be
>> used for preliminary performance measurements.
>>
>> > On Thu, Jul 13, 2017 at 8:47 PM, Martin Duke <[e-mail]>
>> > wrote:
>> >>
>> >> I'm a little concerned that a blend of the strategies leaves us with
>> >> something that still allows ossification and isn't quite enough for
>> decent
>> >> performance testing. But I did add your further clarifications about
>> HTTP/2,
>> >> and the "at scale" provision.
>> >>
>> >> Is your option 3 the MVP for something you'd like to do with this
>> >> iteration?
>> >>
>> >> On Thu, Jul 13, 2017 at 5:28 PM, Ian Swett <[e-mail]>
>> wrote:
>> >>>
>> >>> Thanks for the update.  I would suggest a third potential option,
>> which
>> >>> is a mix of what you have with a small clarification(in bold):
>> >>>
>> >>> Further revisions to mechanisms in the First Implementation Draft
>> (e.g.
>> >>> changes to the public header format, connection close).
>> >>>
>> >>> Transport Parameter Exchange. At the very least, the four parameters
>> >>> specified as MUST in the draft.
>> >>>
>> >>> Address validation and HelloRetryRequest
>> >>>
>> >>> An HTTP/2 application to require multiple streams (with stateless
>> HPACK
>> >>> compression, no QPACK, QCRAM, etc) and no server push.
>> >>>
>> >>>
>> >>> Any implementations that deploy at any scale must also do:
>> >>>
>> >>> Loss Recovery beyond the exising 1-RTO retransmissions. (I believe
>> this
>> >>> includes a number of concepts that are extensively tested in TCP and
>> has low
>> >>> interoperability concerns).
>> >>>
>> >>> Congestion Control
>> >>>
>> >>>
>> >>> The reasoning being that both stateless reset and 0RTT are a fair bit
>> of
>> >>> work to get right based on my experience, and are not critical to
>> having a
>> >>> useful QUIC application.
>> >>>
>> >>> On Thu, Jul 13, 2017 at 7:46 PM, Martin Duke <[e-mail]
>> >
>> >>> wrote:
>> >>>>
>> >>>> Alright, I updated the second implementation draft significantly.
>> >>>>
>> >>>> https://github.com/quicwg/base-drafts/wiki/Second-Implementa
>> tion-Draft
>> >>>>
>> >>>> There are now two strategies: "Lock down the wire image" and "do
>> what we
>> >>>> need to allow useful performance testing". I much prefer the former
>> but it
>> >>>> is worth discussing, since people appear to be interested in both.
>> >>>>
>> >>>> It's also clear (at least to me) that we need to do basic stream
>> >>>> life-cycle stuff in either case, so that has moved into the "must
>> include"
>> >>>> category.
>> >>>>
>> >>>> Martin
>> >>>>
>> >>>> On Mon, Jul 10, 2017 at 5:06 PM, Ian Swett <[e-mail]>
>> wrote:
>> >>>>>
>> >>>>> Agreed, performance analysis is going to be useless in the absence
>> of
>> >>>>> loss recovery and congestion control.  Presumably anyone deploying
>> this at
>> >>>>> scale would implement the recovery draft in a relatively complete
>> manner,
>> >>>>> but that doesn't mean everyone has to do it.
>> >>>>>
>> >>>>> But there's nothing interesting to measure with no application.
>> >>>>>
>> >>>>> On Mon, Jul 10, 2017 at 12:55 PM, Martin Duke <
>> [e-mail]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm not sure how "performance analysis" is going to function in the
>> >>>>>> absence of loss recovery or congestion control. An alternate
>> approach to
>> >>>>>> implementations is to tackle the big performance drivers first,
>> presumably
>> >>>>>> loss recovery, congestion control, and streaming to prevent HOL
>> blocking.
>> >>>>>> However, this would run directly opposite to Jana's suggestion to
>> lock down
>> >>>>>> the wire image to prevent ossification.
>> >>>>>>
>> >>>>>> On Mon, Jul 10, 2017 at 12:32 AM, Kazuho Oku <[e-mail]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> 2017-07-10 12:28 GMT+09:00 Ryan Hamilton <[e-mail]>:
>> >>>>>>> >
>> >>>>>>> >
>> >>>>>>> > On Sun, Jul 9, 2017 at 5:39 PM, Kazuho Oku <[e-mail]
>> >
>> >>>>>>> > wrote:
>> >>>>>>> >>
>> >>>>>>> >> 2017-07-09 1:45 GMT+09:00 Jana Iyengar <[e-mail]>:
>> >>>>>>> >> > I've been thinking about this, and I'm starting to think
>> that we
>> >>>>>>> >> > should
>> >>>>>>> >> > cover more ground in the second implementation draft.
>> >>>>>>> >> >
>> >>>>>>> >> > I'm hearing about increasing deployments of gQUIC, largely
>> due
>> >>>>>>> >> > to market
>> >>>>>>> >> > pressures. The availability of the Chromium implementation
>> makes
>> >>>>>>> >> > it
>> >>>>>>> >> > particularly easy for folks to deploy QUIC with that code. I
>> >>>>>>> >> > think we
>> >>>>>>> >> > need
>> >>>>>>> >> > to move with some urgency, even if we don't change everything
>> >>>>>>> >> > about QUIC
>> >>>>>>> >> > to
>> >>>>>>> >> > make it perfect, so that we can start getting IETF QUIC
>> >>>>>>> >> > deployments out
>> >>>>>>> >> > there. Specifically, I think we should:
>> >>>>>>> >> > 1. work out the wire-visible invariants and finalize all of
>> >>>>>>> >> > those for
>> >>>>>>> >> > the
>> >>>>>>> >> > second impl draft. We know that there are some middleboxes
>> that
>> >>>>>>> >> > already
>> >>>>>>> >> > have
>> >>>>>>> >> > classifiers for gQUIC, and we need to move quickly and push
>> >>>>>>> >> > IETF-QUIC so
>> >>>>>>> >> > we
>> >>>>>>> >> > can test that IETF-QUIC is deployable. I fear that the
>> longer we
>> >>>>>>> >> > take,
>> >>>>>>> >> > the
>> >>>>>>> >> > more widespread gQUIC ossification will be.
>> >>>>>>> >> > 2. allow impls to make serious progress towards a basic HTTP
>> >>>>>>> >> > mapping
>> >>>>>>> >> > over
>> >>>>>>> >> > QUIC. We can punt on header compression (QPACK/QCRAM), but
>> >>>>>>> >> > perhaps test
>> >>>>>>> >> > a
>> >>>>>>> >> > basic HTTP request-response over QUIC. We can still punt
>> >>>>>>> >> > performance-oriented things such as full loss recovery and
>> >>>>>>> >> > congestion
>> >>>>>>> >> > control to later. This forces us to try and finalize the HTTP
>> >>>>>>> >> > mapping
>> >>>>>>> >> > details, which is a good thing, IMO.
>> >>>>>>> >>
>> >>>>>>> >> I agree with Jana.
>> >>>>>>> >>
>> >>>>>>> >> If we can have some basic HTTP mapping (it can be as basic as
>> >>>>>>> >> using
>> >>>>>>> >> HTTP/1.0 over each stream), we can use that to test how the
>> IETF
>> >>>>>>> >> version of QUIC performs well in the field, by comparing its
>> >>>>>>> >> performance to HTTP over TCP.
>> >>>>>>> >
>> >>>>>>> >
>> >>>>>>> > Interesting idea. One challenge with performance analysis is
>> that
>> >>>>>>> > it'll be a
>> >>>>>>> > bit of an apples to oranges comparison. QUIC will be doing
>> HTTP/1
>> >>>>>>> > (without
>> >>>>>>> > header compression) against HTTP/2 (with header compression) or
>> >>>>>>> > HTTP/1.1
>> >>>>>>> > (over multiple connections).
>> >>>>>>>
>> >>>>>>> Agreed.
>> >>>>>>>
>> >>>>>>> Though I might argue that collecting metrics of a QUIC
>> implementation
>> >>>>>>> without header compression could be useful. We can use that as a
>> >>>>>>> baseline when we formalize QPACK / QCRAM.
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Kazuho Oku
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Kazuho Oku
>>
>
>