Re: Second Implementation Draft Guidelines

[Ian Swett <[e-mail]>]

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