Re: Second Implementation Draft Guidelines

[Martin Duke <[e-mail]>]

OK, I understand now. I've added a third option as you described. But I
omitted

Further revisions to mechanisms in the First Implementation Draft (e.g.
changes to the public header format, connection close).

as something that might not be entirely relevant to getting something
deployed, in the interests of reducing scope. If that's a big mistake, let
me know.

On Thu, Jul 13, 2017 at 6:33 PM, Kazuho Oku <[e-mail]> wrote:

> 2017-07-14 9:57 GMT+09:00 Ian Swett <[e-mail]>:
> > I think it is an MVP of HTTP over QUIC, and one I believe Google would be
> > willing to deploy at some scale.
> >
> > That's not to say I'm opposed to the other two options, but I have a
> > preference for something I believe can run real applications with
> reasonable
> > performance, even if it's not ideal.
>
> +1.
>
> I agree that think that sending multiple HTTP requests / responses
> over QUIC, with stateless HPACK would be a nicely balanced approach
> that can be used deployed at some scale as well as one that can be
> used for preliminary performance measurements.
>
> > On Thu, Jul 13, 2017 at 8:47 PM, Martin Duke <[e-mail]>
> > wrote:
> >>
> >> I'm a little concerned that a blend of the strategies leaves us with
> >> something that still allows ossification and isn't quite enough for
> decent
> >> performance testing. But I did add your further clarifications about
> HTTP/2,
> >> and the "at scale" provision.
> >>
> >> Is your option 3 the MVP for something you'd like to do with this
> >> iteration?
> >>
> >> On Thu, Jul 13, 2017 at 5:28 PM, Ian Swett <[e-mail]> wrote:
> >>>
> >>> Thanks for the update.  I would suggest a third potential option, which
> >>> is a mix of what you have with a small clarification(in bold):
> >>>
> >>> Further revisions to mechanisms in the First Implementation Draft (e.g.
> >>> changes to the public header format, connection close).
> >>>
> >>> Transport Parameter Exchange. At the very least, the four parameters
> >>> specified as MUST in the draft.
> >>>
> >>> Address validation and HelloRetryRequest
> >>>
> >>> An HTTP/2 application to require multiple streams (with stateless HPACK
> >>> compression, no QPACK, QCRAM, etc) and no server push.
> >>>
> >>>
> >>> Any implementations that deploy at any scale must also do:
> >>>
> >>> Loss Recovery beyond the exising 1-RTO retransmissions. (I believe this
> >>> includes a number of concepts that are extensively tested in TCP and
> has low
> >>> interoperability concerns).
> >>>
> >>> Congestion Control
> >>>
> >>>
> >>> The reasoning being that both stateless reset and 0RTT are a fair bit
> of
> >>> work to get right based on my experience, and are not critical to
> having a
> >>> useful QUIC application.
> >>>
> >>> On Thu, Jul 13, 2017 at 7:46 PM, Martin Duke <[e-mail]>
> >>> wrote:
> >>>>
> >>>> Alright, I updated the second implementation draft significantly.
> >>>>
> >>>> https://github.com/quicwg/base-drafts/wiki/Second-
> Implementation-Draft
> >>>>
> >>>> There are now two strategies: "Lock down the wire image" and "do what
> we
> >>>> need to allow useful performance testing". I much prefer the former
> but it
> >>>> is worth discussing, since people appear to be interested in both.
> >>>>
> >>>> It's also clear (at least to me) that we need to do basic stream
> >>>> life-cycle stuff in either case, so that has moved into the "must
> include"
> >>>> category.
> >>>>
> >>>> Martin
> >>>>
> >>>> On Mon, Jul 10, 2017 at 5:06 PM, Ian Swett <[e-mail]>
> wrote:
> >>>>>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
>
> --
> Kazuho Oku
>