Re: Second Implementation Draft Guidelines

[Ian Swett <[e-mail]>]

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