[164174] in North American Network Operators' Group
Re: Google's QUIC
daemon@ATHENA.MIT.EDU (Octavio Alvarez)
Fri Jun 28 16:27:21 2013
To: "NANOG list" <nanog@nanog.org>, "Michael Thomas" <mike@mtcc.com>
Date: Fri, 28 Jun 2013 13:26:10 -0700
From: "Octavio Alvarez" <alvarezp@alvarezp.ods.org>
In-Reply-To: <51CDED87.6050503@mtcc.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Fri, 28 Jun 2013 13:09:43 -0700, 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.
Sounds like a UDP replacement. If this is true, then OS-level support will
be needed. If they are on this, then it's the perfect opportunity to fix
some other problems with the Internet in general.
My reaction is: why, oh why, repeat the same mistake of merging everything
on the transport layer and let the benefits be protocol-specific instead
of separating the "transport" from "session".
I mean, why not let redundancy and multipath stay on the transport layer
through some kind of end-user transport (like the Host Identification
Protocol, RFC 5201) and let a simpler TCP and UDP live on top of that, on
the session layer.
Streamline the protocols and separate their functionality.
It's easier than it sounds.
--
Octavio.
