Google's QUIC

Octavio Alvarez alvarezp at alvarezp.ods.org
Fri Jun 28 22:24:44 UTC 2013


On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow
<morrowc.lists at gmail.com> wrote:

> again... not a super smart on this stuff, but..
> why does it require OS modifications? isn't this just going be
> 'chrome' (or 'other application') asking for a udp socket and spewing
> line-rate-foo out of that? isn't the application going to be doing all
> of the multiplexing and jankiness?

I hope not. What would be the point of only letting one application take
the benefit of all those improvements?

"If we're able to identify clear performance wins, our hope is to
collaborate with the rest of the community to develop the features and
techniques of QUIC into network standards."

So yes, QUIC itself doesn't require OS-level modifications, but letting
stay there is pointless.

>> protocol that could be similar to UDP but work on the application layer.
>
> it's not 'similar to UDP', it is in fact UDP, from what I read in the  
> article.

Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is
needed just to work through NAT.

>> My point was that all that work could be focused on a *really* good
>> transport (even with end-user multihoming without bloating the routing
>
> how's that sctp going for you?
> lisp?
> sham6?

That's the point exactly. Google has more power and popularity to
influence adoption of a protocol, just like with SPDY and QUIC.

Neither of the three are widely implemented. That said, neither of those
enable full path resiliency. Path resiliency requires the end-point to be
available through different paths and being able to detect those paths
*before* the first connection is established.

SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is
IPv6-specific and can help you "recover" an already successful connection.
LISP... I can't still grasp LISP, although it doesn't have anything to do
with multihoming. :-)

>> table), and have streamlined TCP and UDP that takes advantage of the new
>> protocol.
>
> sure, ilnp?

ILNP is new for me. Looks interesting, thanks.


-- 
Octavio.




More information about the NANOG mailing list