Re: Second Implementation Draft Guidelines

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

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