Re: Second Implementation Draft Guidelines

[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).