Re: Second Implementation Draft Guidelines

[Kazuho Oku <[e-mail]>]

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



-- 
Kazuho Oku