From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (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 7C44521F1A5 for ; Fri, 28 Jun 2013 10:48:02 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so4724517iec.36 for ; Fri, 28 Jun 2013 10:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gRG85vIPjMd6EeTIL4GE0GMrGwbRzUhXDXfI8nRZI0Y=; b=gEQ+WQ+DotxrgSpeNw1RJc1d5E4pKSoLiicebV5GWfwHRhS0foUEZRKv912TuUbvI5 5UM5QzmCfF2wSxBkGx8GsmY1YJ7swiGLl5mcxyi7Hqi+cWJOErwNazgGUV6CkAoseqij ufGm1uNkyqicXPExdxeQfJC/aZVmhXyK2Xui869ifahk6kgaC3/gOgFolHztiN7s/TrA /tJma6HjYoRHIR/xJ1wwFedk46eHEfmeSKxaxE6qj/ElK1Ig5omUMys1DiqcTS7h4igo Q8/K+XI89I6IVi1L6X63tOY7Ncf/yol4+yle/R+QLM597BH+V3ERRDgSzIURnY5jnqBz I6pA== MIME-Version: 1.0 X-Received: by 10.50.67.111 with SMTP id m15mr537291igt.54.1372441681727; Fri, 28 Jun 2013 10:48:01 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Fri, 28 Jun 2013 10:48:01 -0700 (PDT) In-Reply-To: References: <20130628083322.D07BE406064@ip-64-139-1-69.sjc.megapath.net> Date: Fri, 28 Jun 2013 10:48:01 -0700 Message-ID: From: Dave Taht To: Hal Murray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 17:48:02 -0000 On Fri, Jun 28, 2013 at 9:57 AM, Dave Taht wrote: > On Fri, Jun 28, 2013 at 1:33 AM, Hal Murray wro= te: >> 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 th= e >> Internet. You can learn more in the design document, but here are so= me >> 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-ev2jRFUo= VD34/preview?sle=3Dtrue 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 experiment= ing >> 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 fo= r >> minimal latency. In addition to a specification of the protocol, we hav= e >> developed a SPDY-enabled Google Chrome browser and open-source web serve= r. In >> lab tests, we have compared the performance of these applications over H= TTP >> and SPDY, and have observed up to 64% reductions in page load times in S= PDY. >> We hope to engage the open source community to contribute ideas, feedbac= k, >> code, and test results, to make SPDY the next-generation application pro= tocol >> 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=E4ht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html