Re: [hybi] SPDY protocol from google frame
Roberto Peon <fenix@google.com> Fri, 13 November 2009 03:01 UTC
Return-Path: <fenix@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA493A6A06 for <hybi@core3.amsl.com>; Thu, 12 Nov 2009 19:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.882
X-Spam-Level:
X-Spam-Status: No, score=-105.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GMnR7dEsg1d for <hybi@core3.amsl.com>; Thu, 12 Nov 2009 19:01:27 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id EEEC83A6991 for <hybi@ietf.org>; Thu, 12 Nov 2009 19:01:26 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nAD31sj2016436 for <hybi@ietf.org>; Fri, 13 Nov 2009 03:01:54 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258081315; bh=uAov8voX5hhaITiYhhKL53yKf0g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=i/uFIO8+miSY3iZatbzcP769X8ni2eyRKCtCrIHBluKKuFgc8AjTedBm+YNpA/Mp0 I69uHEBQcoYFtw7fu6qXw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=KEWK4dDnLS4C3inXCRSp/I7DyEvpWfISHfyEZyj2QAtQpeKWBZ6GG6SAP84nxDvhj Cx5Dwisk/wjWLHDJyDolQ==
Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by wpaz13.hot.corp.google.com with ESMTP id nAD31pAp015946 for <hybi@ietf.org>; Thu, 12 Nov 2009 19:01:51 -0800
Received: by qw-out-2122.google.com with SMTP id 9so520156qwb.17 for <hybi@ietf.org>; Thu, 12 Nov 2009 19:01:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.100.13 with SMTP id w13mr2216166qan.292.1258081311005; Thu, 12 Nov 2009 19:01:51 -0800 (PST)
In-Reply-To: <ad99d8ce0911121900p18554bf8u27e604cbfa5a414c@mail.gmail.com>
References: <4AFC869C.9090403@webtide.com> <F4C6CDAD-1ABE-4A2A-A65B-0C8EEA95D90B@surrey.ac.uk> <4AFC9936.8090007@webtide.com> <803EA6E6-F94E-4F8D-9026-86C6EB33422A@icesoft.com> <3a880e2c0911121751q22b3929bwc5d7dbcaa0731226@mail.gmail.com> <bbeaa26f0911121800m6ee5e014n327b1dee77dafd54@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F0F35CBBC@SISPE7MB1.commscope.com> <ad99d8ce0911121900p18554bf8u27e604cbfa5a414c@mail.gmail.com>
Date: Thu, 12 Nov 2009 19:01:50 -0800
Message-ID: <ad99d8ce0911121901pd40c160ja462384a6d97da28@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
Content-Type: multipart/alternative; boundary="00c09fa217a7a41fe7047837e16f"
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] SPDY protocol from google frame
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 03:01:29 -0000
Oh, and I'm excited about SCTP too.. I just don't think that it solves all of the problems that the browsers have (you need browser-indicated priority, flow control, etc. SCTP isn't a silver bullet). -=R On Thu, Nov 12, 2009 at 7:00 PM, Roberto Peon <fenix@google.com> wrote: > http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper > <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. > > <http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper>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 < > Martin.Thomson@andrew.com> 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:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf >> Of *Ian Fette (????????) >> *Sent:* Friday, 13 November 2009 11:00 AM >> *To:* Infinity Linden (Meadhbh Hamrick) >> *Cc:* hybi@ietf.org >> >> *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) <infinity@lindenlab.com> >> >> +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 <ted.goddard@icesoft.com> >> 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 >> hybi@ietf.org >> 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/><L.Wood@surrey.ac.uk> >> >> >> >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> >
- Re: [hybi] SPDY protocol from google frame Lloyd Wood
- Re: [hybi] SPDY protocol from google frame Greg Wilkins
- [hybi] SPDY protocol from google frame Greg Wilkins
- Re: [hybi] SPDY protocol from google frame Ted Goddard
- Re: [hybi] SPDY protocol from google frame Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] SPDY protocol from google frame Ian Fette (イアンフェッティ)
- Re: [hybi] SPDY protocol from google frame Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] SPDY protocol from google frame Jamie Lokier
- Re: [hybi] SPDY protocol from google frame Infinity Linden (Meadhbh Hamrick)
- Re: [hybi] SPDY protocol from google frame Thomson, Martin
- Re: [hybi] SPDY protocol from google frame Thomson, Martin
- Re: [hybi] SPDY protocol from google frame Greg Wilkins
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] SPDY protocol from google frame Jamie Lokier
- Re: [hybi] SPDY protocol from google frame Martin J. Dürst
- Re: [hybi] SPDY protocol from google frame Julian Reschke
- Re: [hybi] SPDY protocol from google frame Ian Fette (イアンフェッティ)
- Re: [hybi] SPDY protocol from google frame Thomson, Martin
- Re: [hybi] SPDY protocol from google frame Martin J. Dürst
- Re: [hybi] SPDY protocol from google frame Martin J. Dürst
- Re: [hybi] SPDY protocol from google frame Ted Goddard
- [hybi] channel alternatives Ted Goddard
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] channel alternatives Roberto Peon
- Re: [hybi] SPDY protocol from google frame Ted Goddard
- Re: [hybi] channel alternatives Ted Goddard
- Re: [hybi] channel alternatives Roberto Peon
- Re: [hybi] SPDY protocol from google frame Greg Wilkins
- Re: [hybi] SPDY protocol from google frame Mike Dierken
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] SPDY protocol from google frame Mike Dierken
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] SPDY protocol from google frame Jamie Lokier
- Re: [hybi] SPDY protocol from google frame Larry Masinter
- Re: [hybi] SPDY protocol from google frame Thomson, Martin
- Re: [hybi] SPDY protocol from google frame Roberto Peon
- Re: [hybi] SPDY protocol from google frame Jamie Lokier
- Re: [hybi] SPDY protocol from google frame Kensaku KOMATSU