Re: [hybi] SPDY protocol from google frame

[Mike Dierken <[e-mail]>]

Was the reduced page load time due to fewer TCP packets needing to be
exchanged (due to smaller HTTP request and response headers)?

Mike

On Thu, Nov 12, 2009 at 7:00 PM, Roberto Peon <[e-mail]> wrote:
> http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper
> Header compression resulted in an ~88% reduction in the size of request
> headers and an ~85% reduction in the size of response headers. On the
> lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request
> header compression in particular, led to significant page load time
> improvements for certain sites (i.e. those that issued large number of
> resource requests). We found a reduction of 45 - 1142 ms in page load time
> simply due to header compression.
> In other words, HTTP headers are so verbose that we get a large latency
> reduction simply by gzipping them. If we did a delimiter-based framing, we'd
> have to ensure that the compressed data was not including that delimiter, or
> we'd have to give up on header compression entirely. Neither of these
> options is particularly interesting.
> Hopefully, we can publish some more data about this later-- We've done a lot
> of experimentation with dummynet+chrome+SPDY server on a lot of sites. The
> server assumed that every resource came back in 30ms, which is on the fast
> side, but that should have biased in favor of HTTP... We're trying to be as
> data driven as possible about this.
> -=R
>
> On Thu, Nov 12, 2009 at 6:45 PM, Thomson, Martin <[e-mail]>
> wrote:
>>
>> It was interesting to hear the IAB opinions on this in relation to
>> internationalization.  The thesis was that the bulk of the web is video or
>> some other efficiently encoded binary data and that text makes up a very
>> small proportion of the data that is moved around.  The purported costs of
>> more verbose encodings (in this case of Unicode) were actually considered
>> negligible when compared to the other benefits.
>>
>>
>>
>> Thus, I’d question whether these speed benefits are of any tangible
>> benefit.  Sure, we minify javascript and there are still bandwidth-limited
>> devices that would benefit from some speed improvement, but I don’t see a
>> binary protocol improving this situation significantly.  And when I consider
>> that some folks are getting better bandwidth on their mobiles than I get
>> over my ADSL2+ connection at home, I wonder why we waste so much time on
>> saving bits.
>>
>>
>>
>> Can anyone point to the studies on impact of HTTP header sizes on
>> throughput, latency and overall bandwidth use?
>>
>>
>>
>> I’m also increasingly of the view that channels-based protocols aren’t
>> necessarily the right way to solve head-of-line blocking problems.  There
>> are other methods that do not demand the same overheads.  For instance, a
>> simple request identifier can be used for request-response correlation.
>>
>>
>>
>> I’m actually more excited about the prospect of getting HTTP over SCTP.
>>
>>
>>
>> --Martin
>>
>>
>>
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Ian Fette (????????)
>> Sent: Friday, 13 November 2009 11:00 AM
>> To: Infinity Linden (Meadhbh Hamrick)
>> Cc: [e-mail]
>>
>> Subject: Re: [hybi] SPDY protocol from google frame
>>
>>
>>
>> The point of SPDY was to make the web faster. Billions of users requesting
>> pages, want to speed it up. Of those billions of users, perhaps 100 care
>> whether it's binary or ASCII. Using ASCII just so that it's easier for 100
>> people to look at the traffic on the wire without any "specialized tools"
>> while slowing it down for billions of users seems like a strange tradeoff.
>>
>> 2009/11/12 Infinity Linden (Meadhbh Hamrick) <[e-mail]>
>>
>> +1 ted
>>
>>
>>
>> i have to admit i'm a fan of text based protocols that use ASCII for
>> headers, allow arbitrary length fields, and whose elements are delimited by
>> ASCII characters. in the early days of my career, i was a fan of fixed
>> length fields with binary elements. to be sure, there are definitely places
>> where they are useful. but in my experience, when you're building something
>> new, the benefits of extensibility and debuggability outweigh the drawbacks
>> of dealing with larger, variable length messages that may require a little
>> bit more coding to parse.
>>
>>
>>
>> <soapbox>
>>
>>
>>
>> but i am kind of curious.. if there are people on this list that prefer
>> binary formats, i wonder, what are the characteristics you're trying to
>> preserve?
>>
>>
>>
>> a. messages should be easy to parse?
>>
>> b. messages and message elements should be as small as possible?
>>
>> c. something else?
>>
>>
>>
>> the reason i ask it that i've had experience with building IIOP and SS7
>> implementations and debugging HTTP is waay more fun than IIOP. and by "fun"
>> i mean that i'm less likely to drink heavily after a 24 hour debugging
>> session.
>>
>>
>>
>> that being said... if i was building something for the telco ecosystem,
>> and i needed to respond to messages in a small, deterministic amount of
>> time, i would be interested in investigating where i would need to use fixed
>> length fields in a binary message. (but i wouldn't like it.)
>>
>>
>>
>> it just seems to me that we're talking about bidirectional HTTP here; not
>> BEEP or IIOP or SS7. HTTP is generally NOT a binary protocol. doesn't it
>> make sense that a bidirectional version of it should also be ASCII/text
>> based? you're going to have developers and tool chains that are probably
>> going to assume that headers flowing across port 80 will be human
>> comprehensible. and while i have no problem using binary encoding when it's
>> needed... but... is it really needed here?
>>
>>
>>
>> do we really have use cases where the < 1% savings you get on message size
>> by adding binary headers and protocol flow markers makes or breaks a
>> service?
>>
>>
>>
>> </soapbox>
>>
>>
>>
>> -cheers
>>
>> -meadhbh
>>
>>
>>
>> --
>>   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
>>         http://wiki.secondlife.com/wiki/User:Infinity_Linden
>>
>> On Thu, Nov 12, 2009 at 16:25, Ted Goddard <[e-mail]>
>> wrote:
>>
>> It appears to be a binary framing protocol carrying
>> an HTTP subset.  The goals of the protocol match the
>> BWTP "manifesto", so hopefully the SPDY authors will
>> join this BOF.
>>
>> I still like the idea of text-based framing and metadata
>> because it's easy to debug with telnet and tcpdump.
>> For instance, BWTP header persistence is still human
>> readable, would be very effective in terms of
>> compression, and could be retrofitted for httpbis;
>> whereas SPDY headers are compressed with gzip, resulting
>> in effective compression but no savings in header
>> encoding and decoding, and a random looking byte stream
>> unless you have a specialized debug tool.
>>
>> It would be interesting to take a poll to see if people
>> have a binary or a text-based protocol in mind.
>>
>> Ted.
>>
>>
>> On 2009-11-12, at 4:24 PM, Greg Wilkins wrote:
>>
>> Lloyd Wood wrote:
>>
>> How does this compare to BEEP?
>>
>> From my quick look:
>>
>> + It's simpler than beep in channel management
>> + It's addresses the header compactness issues
>> + It is definitely bound to uber-http semantics, while beep is more
>> general
>>  purpose (but could have a http binding defined).
>>
>> But in concept, it is not too far apart.  It's using the same grab
>> bag of techniques (multiplexed channels with fragmentation and orderly
>> channel management) that Beep uses (and BWTP is advocating).
>>
>> cheers
>>
>>
>> On 12 Nov 2009, at 22:05, Greg Wilkins wrote:
>>
>> FYI Google have announced some work they are doing on a HTTP improvement
>>
>> http://dev.chromium.org/spdy/spdy-whitepaper
>>
>>
>> It appears to capture many of the same ideas I was attempting to with BWTP
>> - but
>> they are binary encoded and have working code :)
>>
>> cheers
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>>
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>