[Bloat] Google's experiments with QUIC and SPDY

[Bloat] Google's experiments with QUIC and SPDY

[Hal Murray]

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.


-- 
These are my opinions.  I hate spam.

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

[Stephen Hemminger]

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".

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

[Dave Taht]

On Fri, Jun 28, 2013 at 1:33 AM, 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: ..."

No. But I hadn't heard of this one... it sounds similar to how webrtc
works... I'd like to see udp more used... as there are plenty of
things that tcp does that aren't actually needed by a web interface
(in order packet delivery for example)

Ages ago I'd written a command line tool for searching google that
could do your basic search in a single packet in each direction. It is
very useful for doing research within emacs and org-mode in
particular.

http://gnugol.taht.net/

regrettably the API I used is deprecated by google, although it still
seems to work (as does the bing api and a few others), and I killed
the single udp packet version of the protocol in an orgy of code
cleanup one misguided day thinking I'd add crypto (DTLS or pgp) to
it...


>
>
> 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.

There has been also been work on sctp and multipath tcp. It's good to
keep banging the rocks together until something, anything, makes a
spark.

> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

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

[Dave Taht]

On Fri, Jun 28, 2013 at 9:57 AM, Dave Taht <dave.taht@gmail.com> wrote:
> On Fri, Jun 28, 2013 at 1:33 AM, 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: ..."
>
> No. But I hadn't heard of this one... it sounds similar to how webrtc
> works... I'd like to see udp more used... as there are plenty of
> things that tcp does that aren't actually needed by a web interface
> (in order packet delivery for example)
>
> Ages ago I'd written a command line tool for searching google that
> could do your basic search in a single packet in each direction. It is
> very useful for doing research within emacs and org-mode in
> particular.
>
> http://gnugol.taht.net/
>
> regrettably the API I used is deprecated by google, although it still
> seems to work (as does the bing api and a few others), and I killed
> the single udp packet version of the protocol in an orgy of code
> cleanup one misguided day thinking I'd add crypto (DTLS or pgp) to
> it...

A very good analysis of the RTTs induced by introducing crypto to
various protocols is within the QUIC design document:

https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true

Hmm. one of the things the never finished gnugol code did was out of
band public key lookup (and caching) for a given destination utilizing
the mit keyserver architecture. So an individual connection had a high
likelyhood of being a single packet along the path..

secondly connects were signed with a key that could also be looked up
out of band and cached so as to be used for the return path...

shades of ccn..

>
>>
>>
>> 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.
>
> There has been also been work on sctp and multipath tcp. It's good to
> keep banging the rocks together until something, anything, makes a
> spark.
>
>> --
>> These are my opinions.  I hate spam.
>>
>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html