Re: Second Implementation Draft Guidelines

[Martin Duke <[e-mail]>]

Stateless reset (NOT stateless Reject)  is in option 1 because it is a wire
image issue. 0-RTT is in option 2 because I think it's an important to
performance.

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