Google's QUIC

Mailman List Mirror (Read Only)
1

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

2

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

3

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

The FAQ claims they're paying attention to that, but I haven't read the
details. I sure hope they grok that not understanding Van Jacobson dooms
you to repeat it.

Mike

4

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.

5

I'm no genius, but doesn't the article say it's UDP? (in the name of
the protocol even)

-chris

6

I was trying to emphasize "replacement", not UDP. This is, that works on
the same layer, that requires OS-level modifications, as opposed to a
protocol that could be similar to UDP but work on the application layer.

My point was that all that work could be focused on a *really* good
transport (even with end-user multihoming without bloating the routing
table), and have streamlined TCP and UDP that takes advantage of the new
protocol.

Everyone's calling upon SCTP. Implementing similar techniques on multiple
transport protocols calls for a transport-session separation.

7

"In the presence of layer-3 load-balancers, a multiplexed transport has the
potential to allow the different data flows, coming and going to a client,
to be served on a single server." - Google

I'll drink the juice

8

The idea reminds me of uTP in terms of congestion handling.

9

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.

I'm no genius, but doesn't the article say it's UDP? (in the name of
the protocol even)

I was trying to emphasize "replacement", not UDP. This is, that works on
the same layer, that requires OS-level modifications, as opposed to a

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?

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.

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?

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

sure, ilnp?

Everyone's calling upon SCTP. Implementing similar techniques on multiple
transport protocols calls for a transport-session separation.

right, and the 1 application using sctp is so wide spread we've all
heard of it even.
possibly this will be a similar diversion into protocol/application
testing even.

-chris

10

i don't think much juice is required... doesn't that just say that the
same 'flow' will follow the same path through the network? and that
most/all (save a10/yahoo!) loadbalancers just LB based on 5-tuple (at
best)? so keeping things in a single flow/stream/5-tuple will drop
packets from one host deterministicaly on a single other host at the
far side?

11

I took that as path agnostic.

12

Simple Computer Telephony Protocol? Did anyone ever actually implement that?

Cheers,
-- jra

13

No:

      http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

*Mike*

14

From: "Michael Thomas" <mike@mtcc.com>
My first reaction to this was why not SCTP, but apparently they think

Simple Computer Telephony Protocol? Did anyone ever actually implement that?

No:

Stream Control Transmission Protocol - Wikipedia

SCTP is used successfully for the purpose for which it was intended, which is connecting SS7 switches over IP. It's not as much a posterchild for an application agnostic transport as some people would like to think.

15

OK, I'll bite... does anything else notable actually use it?

16

Well, I'm pretty sure that Randy Stewart has a more expansive take on SCTP
than SS7oIP, but I get the impression that there just weren't enough other things
that cared about head of line blocking. But now, 15 years later, it seems like maybe
there is.

In any case, if what you're worried about is head of line blocking, SCTP definitely
does that, and there are kernel implementations so for an *experiment* it seems
like you could get a long way by ignoring its warts.

But I think the most provocative thing is the idea of sending data payloads prior
to handshake. That sort of scares me because of the potential for an amplification
attack. But I haven't actually read the protocol paper itself.

Mike

17

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

The FAQ claims they're paying attention to that, but I haven't read the
details. I sure hope they grok that not understanding Van Jacobson dooms
you to repeat it.

Van is at Google. Much grokking is going on.

-Scott

18

Well it mostly non-user stuff, Netflow exporting, diameter, sip. Wait webrtc using it, firefox and chrome have sctp code, last time a checked

19

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

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

sure, ilnp?

ILNP is new for me. Looks interesting, thanks.

20

again... not a super smart on this stuff, but..

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.

"Runs in top of UDP"... "Is not UDP"...

If it has protocol set to 17 it is UDP.

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

Lisp is actually very much about multihoming... In fact that was one of the
key reasons it got started. It actually could make multihoming and mobility
very much simpler at the applications if it were used.

It is a bit complex though... At least for normal ivp4/6 routing minded
folk.

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

sure, ilnp?

ILNP is new for me. Looks interesting, thanks.

Mind that ilnp is v6only also requires stack changes...