Re: [Bloat] Google's experiments with QUIC and SPDY

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 28 Jun 2013 01:33:22 -0700
Hal Murray <hmurray@megapathdsl.net> wrote:

> Has anybody tried this stuff in a bloat sensitive environment?
> 
> Experimenting with QUIC
> http://blog.chromium.org/2013/06/experimenting-with-quic.html
> 
>    "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: ..."
> 
> 
> SPDY: An experimental protocol for a faster web 
>   http://www.chromium.org/spdy/spdy-whitepaper
> 
> As part of the "Let's make the web faster" initiative, we are experimenting 
> with alternative protocols to help reduce the latency of web pages. One of 
> these experiments is SPDY (pronounced "SPeeDY"), an application-layer 
> protocol for transporting content over the web, designed specifically for 
> minimal latency.  In addition to a specification of the protocol, we have 
> developed a SPDY-enabled Google Chrome browser and open-source web server. In 
> lab tests, we have compared the performance of these applications over HTTP 
> and SPDY, and have observed up to 64% reductions in page load times in SPDY. 
> We hope to engage the open source community to contribute ideas, feedback, 
> code, and test results, to make SPDY the next-generation application protocol 
> for a faster web.
> 
> 
From 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 so let's
open lots of connections".