[Bloat] Google's experiments with QUIC and SPDY

[Dave Taht]

On Fri, Jun 28, 2013 at 9:57 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Fri, Jun 28, 2013 at 1:33 AM, Hal Murray <hmurray at 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 at 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