W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: Our Schedule

From: James M Snell <jasnell@gmail.com>
Date: Wed, 28 May 2014 08:59:06 -0700
Message-ID: <CABP7RbcwxxdaDmKNhBXwdE-vmgvMUXDzKWy3gq8-7WzFOAcQ9w@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mark Nottingham <mnot@mnot.net>, Patrick McManus <pmcmanus@mozilla.com>, Cory Benfield <cory@lukasa.co.uk>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>
This thread is becoming increasingly impossible to follow. As per the
original point regarding the schedule: my preference would be to not rush
or fast track a WGLC but rather let the spec sit and simmer for a bit while
more implementors catch up and become able to provide  evidence that http/2
as it is currently defined is satisfactory.
On May 27, 2014 7:17 AM, "Mike Bishop" <Michael.Bishop@microsoft.com> wrote:

>  The obvious issue is that you actually need the most aggressive
> compression on the first packet, while the CWND is small.  With
> negotiation, you wouldn’t get to move to the better compression until at
> least an RTT later, when you have more window to send
> less-efficiently-compressed requests.
> Not that you can’t do *something* here, but I think that’s the hurdle to
> overcome.
> *From:* James M Snell [mailto:jasnell@gmail.com]
> *Sent:* Monday, May 26, 2014 11:18 AM
> *To:* Mark Nottingham
> *Cc:* Patrick McManus; Cory Benfield; Greg Wilkins; HTTP Working Group;
> Michael Sweet
> *Subject:* Re: Our Schedule
> What would be wrong with:
> 1. Opting for a significantly less complicated, less aggressive
> compression strategy by default; and
> 2. Leveraging extensibility and negotiation in the framing layer so that
> HPACK can be developed and experimented with independently.
> There's nothing I've seen so far that convinces me that HPACK ought to be
> a normative requirement in http/2.
> On May 26, 2014 10:53 AM, "Mark Nottingham" <mnot@mnot.net> wrote:
> Michael,
> On 27 May 2014, at 2:35 am, Michael Sweet <msweet@apple.com> wrote:
> > Patrick,
> >
> > On May 26, 2014, at 10:45 AM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
> >> ...
> >> I disagree. the fundamental value of http/2 lies in mux and priority,
> and to enable both of those you need to be able to achieve a high level of
> parallelism. Due to CWND complications the only way to do that on the
> request path has been shown to be with a compression scheme. gzip
> accomplished that but had a security problem - thus hpack. Other schemes
> are plausible, and ones such as james's were considered, but some mechanism
> is required.
> >
> > I see several key problems with the current HPACK:
> >
> > 1. The compression state is hard to manage, particularly for proxies.
> > 2. HEADER frames hold up the show (issue #481)
> > 3. There is no way to negotiate a connection without Huffman compression
> of headers (issue #485).
> >
> > *If* we can come up with a header compression scheme that does not
> suffer from these problems, it might be worth the added complexity in order
> to avoid TCP congestion window issues.  But given that we are already
> facing 3.5 RTTs worth of latency just to negotiate a TLS connection I'm not
> convinced that compressing the request headers will yield a user-visible
> improvement in the speed of their web browsing experience.
> The previous discussion that Patrick was referring to has a lot of
> background.
> In a nutshell, he made an argument for header compression a while back (I
> can dig up the references if you like), where he basically showed that for
> a very vanilla page load, merely getting the requests out onto the wire
> (NOT getting any responses) would take something like 8-11 RTs, just
> because of the interaction between request header sizes and congestion
> windows. This assumes that the page has 80 assets (the average is not over
> 100, according to the Web archive), and request headers are around 1400
> bytes (again, not uncommon).
> In contrast, with compressed headers (his experiment was with gzip), you
> can serialise all of those requests into one RTT, perhaps even a single
> packet.
> This is a very persuasive argument when our focus is on reducing end-user
> perceived latency. It’s especially persuasive when you think of the
> characteristics of an average mobile connection.
> HPACK is not as efficient as gzip, and as we’ve said many times, our goal
> is NOT extremely high compression; rather, it’s safety. If we could ignore
> the CRIME attack, we would use gzip instead, and I don’t think we’d be
> having this discussion.
> Hope this helps,
> --
> Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 28 May 2014 15:59:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC