Re: Second Implementation Draft Guidelines

["Brian Trammell (IETF)" <[e-mail]>]

> On 10 Jul 2017, at 12:33, Ian Swett <[e-mail]> wrote:
> 
> 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.

This seems like a good target, as long as it's possible to ensure it's blindingly obvious to everyone that it is likely to change a large amount.

We have a bit of a paradox here. In order to keep people from shipping 2nd impl it needs to be functionally limited to the point that it's obviously silly to ship. But it can only be useful as a test of the features in the spec that it implements, which argues against an obviously silly profile.

A useful question to ask at this point: how many separate implementation drafts do we target before WGLC?

Cheers,

Brian

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