Subject: Design FAQs, Was: Our Schedule

From: Greg Wilkins <[email-masked]>
Date: Mon, 26 May 2014 21:29:45 +0200

Mark,

thanks for the recap of the argument for small request size.    I know that
the reasoning behind every design decision cannot be put into the draft,
but it would be really good if  some way could be found that didn't leave
such knowledge only in the email archives.    Perhaps a HTTP2 FAQ would
avoid re-runs of frequent discussions.

I certain accept the reasoning behind wanting to fit many requests into a
single CWIN to avoid round trips.   I also accept that gzip is not suitable
for security reasons.

But I think there are many more FAQs needed to explain HPACK and other
aspects of HTTP/2

 + why is hpack streaming?  Its design means that common fields like the
method are likely to be emitted at the end thus requiring the whole headers
to be buffered anyway and the server must apply a max header size anyway.
 + why a single reference table? Wont this be inefficient for connections
that aggregate unrelated streams?
 + why a dynamic reference table that can be mutated by any stream?
reference table(s) that can only be mutated by stream 0 would allow other
streams to progress in parallel without serialisation between streams.
 + Does HPACK really request contiguous header frames without flow
control?  It looks like a maximum size will be applied to the initial
headers anyway, so with that known head of line blocking can be avoided.
 + I know it has been explained to me before, the END_STREAM bit that
doesn't mean the end of the stream is another FAQ that really needs to be
explained.

If the WG wants to get more feedback from a wider audience, then they are
just going to get questions like these asked again and again unless some
effort is made to pro actively explain some of the more surprising aspects
of the design.

regards

On 26 May 2014 19:53, Mark Nottingham <[email-masked]> wrote:

> Michael,
>
> On 27 May 2014, at 2:35 am, Michael Sweet <[email-masked]> wrote:
>
> > Patrick,
> >
> > On May 26, 2014, at 10:45 AM, Patrick McManus <[email-masked]>
> 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/
>
>
>
>

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Roland Zink <[email-masked]>
Date: Tue, 27 May 2014 00:47:21 +0200

The design is more suited for a direct (secure) connection between 
client and servers. Intermediaries aren't really targeted. For example 
an intermediary can't stream a header frame until it knows about the 
complete header block as otherwise a client can block the whole 
connection between the intermediary and the server. I asked about the 
single reference set before and the answer was no because of the memory 
requirements, the reference set can be cleaned with a single op, the and 
a grouping / reference table selection would be necessary otherwise 
which was considered to complicated. On the other side in the HTTP/1.1 
world also usually the headers are processed as a unit, so there would 
be room for improvements.

Regards,
Roland

On 26.05.2014 21:29, Greg Wilkins wrote:
>
> Mark,
>
> thanks for the recap of the argument for small request size.    I know 
> that the reasoning behind every design decision cannot be put into the 
> draft, but it would be really good if  some way could be found that 
> didn't leave such knowledge only in the email archives.    Perhaps a 
> HTTP2 FAQ would avoid re-runs of frequent discussions.
>
> I certain accept the reasoning behind wanting to fit many requests 
> into a single CWIN to avoid round trips.   I also accept that gzip is 
> not suitable for security reasons.
>
>  + why is hpack streaming?  Its design means that common fields like 
> the method are likely to be emitted at the end thus requiring the 
> whole headers to be buffered anyway and the server must apply a max 
> header size anyway.
>  + why a single reference table? Wont this be inefficient for 
> connections that aggregate unrelated streams?
> reference table(s) that can only be mutated by stream 0 would allow 
> other streams to progress in parallel without serialisation between 
> streams.
> doesn't mean the end of the stream is another FAQ that really needs to 
> be explained.
>
>
> If the WG wants to get more feedback from a wider audience, then they 
> are just going to get questions like these asked again and again 
> unless some effort is made to pro actively explain some of the more 
> surprising aspects of the design.
>
> regards
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 26 May 2014 19:53, Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Michael,
>
>     On 27 May 2014, at 2:35 am, Michael Sweet <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     > Patrick,
>     >
>     > On May 26, 2014, at 10:45 AM, Patrick McManus
>     <[email-masked] <mailto:[email-masked]>> 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.
>     >
>     > 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.
>
>     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,
>
>     --
> Greg Wilkins <[email-masked] <mailto:[email-masked]>>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 May 2014 14:49:13 +1000

Hi Greg,

I was thinking much the same thing last night, so I started scratching together a FAQ here:
  http://http2.github.io/faq/

Currently, it’s split into three parts; “general”, “implementer” and “deployment” FAQs, with no content in the latter two.

As always, feedback, suggestions welcome (especially in the form of pull requests). There’s a fair amount to cover, and I’ve only done the basics.

Note that one of the first TODOs I see is adding a ToC.

Cheers,

On 27 May 2014, at 5:29 am, Greg Wilkins <[email-masked]> wrote:

> 
> Mark,
> 
> thanks for the recap of the argument for small request size.    I know that the reasoning behind every design decision cannot be put into the draft, but it would be really good if  some way could be found that didn't leave such knowledge only in the email archives.    Perhaps a HTTP2 FAQ would avoid re-runs of frequent discussions.
> 
> I certain accept the reasoning behind wanting to fit many requests into a single CWIN to avoid round trips.   I also accept that gzip is not suitable for security reasons.
> 
> But I think there are many more FAQs needed to explain HPACK and other aspects of HTTP/2
> 
>  + why is hpack streaming?  Its design means that common fields like the method are likely to be emitted at the end thus requiring the whole headers to be buffered anyway and the server must apply a max header size anyway.
>  + why a single reference table? Wont this be inefficient for connections that aggregate unrelated streams? 
>  + why a dynamic reference table that can be mutated by any stream?   reference table(s) that can only be mutated by stream 0 would allow other streams to progress in parallel without serialisation between streams.
>  + Does HPACK really request contiguous header frames without flow control?  It looks like a maximum size will be applied to the initial headers anyway, so with that known head of line blocking can be avoided.
>  + I know it has been explained to me before, the END_STREAM bit that doesn't mean the end of the stream is another FAQ that really needs to be explained.
> 
> 
> If the WG wants to get more feedback from a wider audience, then they are just going to get questions like these asked again and again unless some effort is made to pro actively explain some of the more surprising aspects of the design.
> 
> regards
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> > On May 26, 2014, at 10:45 AM, Patrick McManus <[email-masked]> 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.
> >
> > 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,
> 
> --

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 27 May 2014 09:34:00 +0200

Roland,

I think that intermediaries cannot be avoided.  At the very least the
browser itself represents a virtual intermediary when it shares a
connection between tabs on the browser.

But many application servers are just not setup to terminate large numbers
of external connections, let alone TLS connections.    TLS will be
offloaded and load balancers will be used.  Aggregation is desirable in
those situations, so I can see h2c being using within server farms.

Also I'm dubious that many large corporations are going to see the
technical merit of http2 and thus allows all their staff to make un
interrupted connections through their corporate firewalls.  Aggregation is
less likely in such scenarios, but also not impossible, specially if a
caching proxy is used.

cheers

On 27 May 2014 00:47, Roland Zink <[email-masked]> wrote:

> client and servers. Intermediaries aren't really targeted. For example an
> intermediary can't stream a header frame until it knows about the complete
> header block as otherwise a client can block the whole connection between
> the intermediary and the server. I asked about the single reference set
> before and the answer was no because of the memory requirements, the
> reference set can be cleaned with a single op, the and a grouping /
> reference table selection would be necessary otherwise which was considered
> to complicated. On the other side in the HTTP/1.1 world also usually the
> headers are processed as a unit, so there would be room for improvements.
>
> Regards,
> Roland
>
>
>
> draft, but it would be really good if  some way could be found that didn't
> leave such knowledge only in the email archives.    Perhaps a HTTP2 FAQ
> would avoid re-runs of frequent discussions.
>
> are just going to get questions like these asked again and again unless
> some effort is made to pro actively explain some of the more surprising
> aspects of the design.
>
>  regards
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>