Subject: New Version Notification for draft-montenegro-httpbis-speed-mobility-02.txt

From: Rob Trace <[email-masked]>
Date: Tue, 19 Jun 2012 20:28:22 +0000

I should have sent this earlier...

A new version of I-D, draft-montenegro-httpbis-speed-mobility-02.txt

has been successfully submitted by Henrik Frystyk Nielsen and posted to the IETF repository.

Filename:            draft-montenegro-httpbis-speed-mobility

Revision:              02

Title:                      HTTP Speed+Mobility

Creation date:   2012-06-15

WG ID:                  Individual Submission

Number of pages: 36

URL:             http://www.ietf.org/internet-drafts/draft-montenegro-httpbis-speed-mobility-02.txt

Status:          http://datatracker.ietf.org/doc/draft-montenegro-httpbis-speed-mobility

Htmlized:        http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02

Diff:            http://tools.ietf.org/rfcdiff?url2=draft-montenegro-httpbis-speed-mobility-02

Abstract:

   This document describes "HTTP Speed+Mobility," a proposal for HTTP

   2.0 that emphasizes performance improvements and security while at

   the same time accounting for the important needs of mobile devices

   and applications.  The proposal starts from both the Google SPDY

   protocol and the work the IETF has done around WebSockets.  The

   proposal is not a final product but rather is intended to form a

   baseline for working group discussion.

The IETF Secretariat

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 22 Jun 2012 15:02:10 +0000

In message <[email-masked]

>A new version of I-D, draft-montenegro-httpbis-speed-mobility-02.txt

I have read this draft, and I do like the thinking, even if not all
the details.

With one small tweak, this prosal has the potential to solve what
I see as one of the really big high-performance issues: load-balancing
at Tbit/s rates.

The tweak I seek is:

	Once created, all requests on a given stream MUST have the
	same "Host:" header.

This does not prevent a client (or proxy) from using multiple streams
with same "Host:" header to get parallelism, but it means that
load-balancers in front of hosting farms only need to examine the
first request on any stream to find the "Host:" header, after that,
it can just shift the stream through.

Another way to think of this, is to make the stream-ID also
work as a hop-to-hop flow-label.

With that said...

A lot of the benefit thus gained will be eaten up because taking a
SPDY stream apart is a performance nightmare, particularly at Tbit/s
rates, but at least the load-balancers will only need to take the
first part of the SPDY streams apart.

I seem to recall Willy and Adrien working on using serialization/encoding
to save header transmission cost, instead of just blindly throwing
things at gzip.

Put something like that on top of Bobs draft instead of SPDY, and
Tbit/sec starts to look realistic.

Poul-Henning

PS: I was happy to see that Guy didn't find any significant improvement
from the gzip static dictionary, I thought I had done something wrong
when I got that result.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Gabriel Montenegro <[email-masked]>
Date: Sat, 23 Jun 2012 00:10:27 +0000

Thanks, Poul-Henning.

> 	Once created, all requests on a given stream MUST have the

Currently, we don't reuse streams, so the assumption is that a request creates one and a reply tears it down. Something good about that is that the lifecycle of a stream is well defined and the intermediaries or servers don't have to deal with  a constantly growing collection of stream ids (and associated data) with all the complexities of figuring out when to reclaim those resources. 

But for now, a new request/response uses a new stream ID, so your reuse of the stream is as a flow identifier would not be supported. It would be interesting to think about possibilities here. For example, one could make the lifecycle very clear so that reuse of stream IDs would be doable. Your draft with Willy on network friendly HTTP 2.0 also has some ideas that could be useful here.

> -----Original Message-----
> From: Poul-Henning Kamp [mailto:[email-masked]]
> Sent: Friday, June 22, 2012 08:02
> To: Rob Trace
> Cc: [email-masked]
> Subject: Re: New Version Notification for draft-montenegro-httpbis-speed-
> mobility-02.txt
> 
> In message
> <[email-masked]
> ingroup.wi
> I have read this draft, and I do like the thinking, even if not all the details.
> 
> With one small tweak, this prosal has the potential to solve what I see as one
> of the really big high-performance issues: load-balancing at Tbit/s rates.
> 
> The tweak I seek is:
> 
> This does not prevent a client (or proxy) from using multiple streams with
> same "Host:" header to get parallelism, but it means that load-balancers in
> front of hosting farms only need to examine the first request on any stream
> to find the "Host:" header, after that, it can just shift the stream through.
> 
> Another way to think of this, is to make the stream-ID also work as a hop-to-
> hop flow-label.
> 
> With that said...
> 
> A lot of the benefit thus gained will be eaten up because taking a SPDY
> stream apart is a performance nightmare, particularly at Tbit/s rates, but at
> least the load-balancers will only need to take the first part of the SPDY
> streams apart.
> 
> I seem to recall Willy and Adrien working on using serialization/encoding to
> save header transmission cost, instead of just blindly throwing things at gzip.
> 
> Put something like that on top of Bobs draft instead of SPDY, and Tbit/sec
> starts to look realistic.
> 
> Poul-Henning
> 
> PS: I was happy to see that Guy didn't find any significant improvement from
> the gzip static dictionary, I thought I had done something wrong when I got
> that result.
> 
> --

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 23 Jun 2012 08:08:01 +0000

In message <[email-masked]
ndeploy.ntdev.microsoft.com>, Gabriel Montenegro writes:

>Currently, we don't reuse streams, so the assumption is that a request creates
>one and a reply tears it down.

OK, I don't know how I could have missed that bit.

I think that is a bad idea, it adds a lot of overhead-processing that
can be trivially be avoided by reusing the stream in the restricted way
I propose.

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 25 Jun 2012 20:02:13 +0000

I can see why you'd want this field in the clear. But perhaps you expressed the real goal better in the minification thread:

"HTTP/2.0 should serialize (at least) these crucial fields without
gzip and preferably in a way that makes it very easy and cheap to
find them."

One way is to make the crucial fields for routing the request available in the clear. Header compression could be defined to allow leaving such fields in the clear. We'd lose the benefit of compression, though. One could replace with some hash or handle, but then we are facing the question of lifecycle for those handles as well.

Another way is what you suggest here, to reuse the stream ID and use that as a handle with the constraint you suggest. The stream lifecycle would have to be spec-ed carefully as otherwise opening up Stream IDs without clear indication as to when to reclaim them and delete the resources could be used as a DoS. HTTP's request/response pattern is an easy way to solve this. But in websockets multiplexing there is no such pattern, so perhaps we need to solve this anyways (I think ideally we should have a common or at least an aligned solution between HTTP 2.0 mux and websockets mux). There's always explicit stream (or "channel", in websockets mux) teardown. Beyond that, I guess any system can impose any limits it wants on numbers of outstanding streams open.

So yes, there are several ways to make requests easily routable in HTTP 2.0, not sure which is the best.

Gabriel

> Sent: Saturday, June 23, 2012 01:08
> To: Gabriel Montenegro
> Cc: Rob Trace; [email-masked]
> <[email-masked]
> ingroup.wi