[164172] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Google's QUIC

daemon@ATHENA.MIT.EDU (Josh Hoppes)
Fri Jun 28 16:16:51 2013

In-Reply-To: <51CDED87.6050503@mtcc.com>
Date: Fri, 28 Jun 2013 15:16:16 -0500
From: Josh Hoppes <josh.hoppes@gmail.com>
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

My first question is, how are they going to keep themselves from
congesting links?

On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas <mike@mtcc.com> wrote:
> http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1
>
> Sorry if this is a little more on the dev side, and less on the ops side but
> since
> it's Google, it will almost certainly affect the ops side eventually.
>
> My first reaction to this was why not SCTP, but apparently they think that
> middle
> boxen/firewalls make it problematic. That may be, but UDP based port
> filtering is
> probably not far behind on the flaky front.
>
> The second justification was TLS layering inefficiencies. That definitely
> has my
> sympathies as TLS (especially cert exchange) is bloated and the way that it
> was
> grafted onto TCP wasn't exactly the most elegant. Interestingly enough,
> their
> main justification wasn't a security concern so much as "helpful" middle
> boxen
> getting their filthy mitts on the traffic and screwing it up.
>
> The last thing that occurs to me reading their FAQ is that they are
> seemingly trying
> to send data with 0 round trips. That is, SYN, data, data, data... That
> really makes me
> wonder about security/dos considerations. As in, it sounds too good to be
> true. But
> maybe that's just the security cruft? But what about SYN cookies/dos? Hmmm.
>
> Other comments or clue?
>
> Mike
>


home help back first fref pref prev next nref lref last post