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

Thanks, Poul-Henning.

I'm a bit confused by your proposed tweak:

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

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:phk@phk.freebsd.dk]
> Sent: Friday, June 22, 2012 08:02
> To: Rob Trace
> Cc: ietf-http-wg@w3.org
> Subject: Re: New Version Notification for draft-montenegro-httpbis-speed-
> mobility-02.txt
> 
> In message
> <FF649A28BA27384396FD4F7BADF45DDF382957D8@TK5EX14MBXW602.w
> ingroup.wi
> ndeploy.ntdev.microsoft.com>, Rob Trace writes:
> 
> >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
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by
> incompetence.
>

Received on Saturday, 23 June 2012 00:11:05 UTC