Re: Second Implementation Draft Guidelines

[Ian Swett <[e-mail]>]

There are two practical options to mitigate performance issues on opposite
ends of the spectrum, and both of which I expect to perform at least
slightly better than H2 over TCP for most applications.

1) Run HTTP/2 over a single QUIC stream.  This should be easy for most
implementers, but incurs maximum HOL blocking.
2) Use the HPACK static dictionary to get some of the header compression
benefits.  I think this provides a better baseline to evaluate QPACK/QCRAM
from.

On a high level, I support adding some sort of HTTP application mapping to
the second draft, with the knowledge it is likely to change a large
amount.  GQUIC has already changed it's HTTP mapping at least twice that
I'm aware of, and it has some challenges, but it's fairly doable, even when
supporting both for long periods of time.

On Mon, Jul 10, 2017 at 3: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
>
>