Re: Second Implementation Draft Guidelines

[Martin Duke <[e-mail]>]

If there are some improvements in -05, that's fine with me, but that's a
bit orthogonal to the purpose of this document. The first interop is
attached to a specific set of features, which might involve more than one
draft.

This document is trying to figure out what the next set of features should
be. It should also drive which open issues we should prioritize.

On Fri, Jul 14, 2017 at 10:45 AM, Eric Rescorla <[e-mail]> wrote:

> 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
>>>
>>
>>
>