[Bloat] Google's experiments with QUIC and SPDY

Dave Taht dave.taht at gmail.com
Fri Jun 28 12:57:29 EDT 2013


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


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



More information about the Bloat mailing list