From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f66.google.com (mail-pb0-f66.google.com [209.85.160.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 200C921F18F for ; Fri, 28 Jun 2013 09:33:20 -0700 (PDT) Received: by mail-pb0-f66.google.com with SMTP id mc8so1508698pbc.9 for ; Fri, 28 Jun 2013 09:33:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=RG8F3KFC2DbHpxjvif2P2/KqrIn7udP7Tf+36QnkFdU=; b=COtoeeKF4jtuq1+DDkdKSQr8WSR7jKT8IuQJf6aZnDpT5JpyhE0kb3Hr8cQK2Pxawo ZecRdNp4cz4ENv/S8npzBQ0j5EQMnF2/yG2aLzc3PTnK6c8/ZRMF7hmt40IUAvzAnGQP 6RPCWhW7ou9ckkfxJ8F3nWCvg7bbp3/+T3Wr47MMBvGZ4NRLvEL6taJ+LH1+PmkH53tr phOOT2bDLTxbIs8UFU4RXxUvhH6vs82FttH1hX5ZfgSBqvtmWrlEYPVPBlhEDCnvYRqB 4GQxowXjWzyp+Mdy7hESsSjZmPO/Fq6tHSD/RQDaIP546yAEPm55BXG6q0bxwhufs6Uy /r5g== X-Received: by 10.68.203.103 with SMTP id kp7mr12151646pbc.165.1372437199271; Fri, 28 Jun 2013 09:33:19 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-71-109.bvtn.or.frontiernet.net. [50.53.71.109]) by mx.google.com with ESMTPSA id dc3sm8869261pbc.9.2013.06.28.09.33.18 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 28 Jun 2013 09:33:18 -0700 (PDT) Date: Fri, 28 Jun 2013 09:33:15 -0700 From: Stephen Hemminger To: Hal Murray Message-ID: <20130628093315.77e7dd0c@nehalam.linuxnetplumber.net> In-Reply-To: <20130628083322.D07BE406064@ip-64-139-1-69.sjc.megapath.net> References: <20130628083322.D07BE406064@ip-64-139-1-69.sjc.megapath.net> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQneB2PSAw9yO+IPQ4rdRZgljla5aCuqDv0x3tcoi/2i6a2lRsyRVOn6CFIwJrERfPRERMpD Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Google's experiments with QUIC and SPDY X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:33:20 -0000 On Fri, 28 Jun 2013 01:33:22 -0700 Hal Murray wrote: > Has anybody tried this stuff in a bloat sensitive environment? >=20 > Experimenting with QUIC > http://blog.chromium.org/2013/06/experimenting-with-quic.html >=20 > "QUIC (Quick UDP Internet Connections) is an early-stage network > protocol we are experimenting with that runs a stream multiplexing > protocol over a new flavor of Transport Layer Security (TLS) on top of > UDP instead of TCP. QUIC combines a carefully selected collection of > techniques to reduce the number of round trips we need as we surf the > Internet. You can learn more in the design document, but here are some > of the highlights: ..." >=20 >=20 > SPDY: An experimental protocol for a faster web=20 > http://www.chromium.org/spdy/spdy-whitepaper >=20 > As part of the "Let's make the web faster" initiative, we are experimenti= ng=20 > with alternative protocols to help reduce the latency of web pages. One o= f=20 > these experiments is SPDY (pronounced "SPeeDY"), an application-layer=20 > protocol for transporting content over the web, designed specifically for= =20 > minimal latency. In addition to a specification of the protocol, we have= =20 > developed a SPDY-enabled Google Chrome browser and open-source web server= . In=20 > lab tests, we have compared the performance of these applications over HT= TP=20 > and SPDY, and have observed up to 64% reductions in page load times in SP= DY.=20 > We hope to engage the open source community to contribute ideas, feedback= ,=20 > code, and test results, to make SPDY the next-generation application prot= ocol=20 > for a faster web. >=20 >=20 =46rom an application point of view TCP is just a latency inducer. Because end-to-end system engineering is hard, it natural to focus on the problem at hand. Is this a repeat of the story, "we don't like slow start and flow control s= o let's open lots of connections".