Re: Second Implementation Draft Guidelines

[Kazuho Oku <[e-mail]>]

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