Re: [hybi] SPDY protocol from google frame

[Mike Dierken <[e-mail]>]

Sounds great. I really like this pragmatic approach of doing things to
improve user's experience that have a good chance of wide deployment.
I'm also very interested in the goal to allow the server to initiate
communication with the client. Would this be accomplished via
bi-directional streams within the TCP connection - but  the connection
itself would still need to be initiated by the client? Meaning you
haven't figured out a magical way to put an httpd on the client?

Mike

On Mon, Nov 16, 2009 at 7:54 PM, Roberto Peon <[e-mail]> wrote:
> That was only part of the savings, though it was certainly the most
> significant savings for users with thin pipes.
> Much of the improvement comes from the multiplexing+prioritization-- since
> the browser can trust the server to fill the pipe with the things the
> browser wants the most, it is free to issue requests as soon as it knows
> that it needs them. Today, browsers will artificially induce a delay in
> requests because it is vastly important that the HTML and CSS arrive
> unimpeded.
> Also a factor is how quickly we open up the cwnd. Since the protocol is
> multiplexing, it has more bytes to stuff down the pipe (and sooner that it
> would with HTTP thanks to prioritization+multiplexing), and so it opens cwnd
> more quickly. This is simplifying a bit.. but you get the picture :)
> -=R
>
> On Mon, Nov 16, 2009 at 7:40 PM, Mike Dierken <[e-mail]> wrote:
>>
>> 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
>> >
>> >
>
>