
Experimenting with QUIC - igrigorik
http://blog.chromium.org/2013/06/experimenting-with-quic.html
======
objectivefs
MinimaLT[1] is another interesting protocol with similar goals. From the
abstract:

"Minimal Latency Tunneling (MinimaLT) is a new network protocol that provides
ubiquitous encryption for maximal confidentiality, including protecting packet
headers. MinimaLT provides server and user authentication, extensive Denial-
of-Service protections, and IP mobility while approaching perfect forward
secrecy."

[1]: [http://cr.yp.to/tcpip.html](http://cr.yp.to/tcpip.html)

------
jeremyw
Wonderful. This reads like an evolution of CurveCP, with the goals of real
acceptance and downstream flexibility.

------
limsup
Wow - this is exciting. It sounds similar to the SSH protocol but with forward
error correction and fine-tuned for quick handshakes. Is the the beginning of
the end for TCP and SSL? I hope so!

~~~
igrigorik
TCP is not going away anytime soon... If anything, the hope is that QUIC can
help improve TCP in the long run -- but first, we need to validate a lot of
the design assumptions. :)

------
msirp
Awesome. Just awesome.

I've also been thinking about another possible optimization:

Two things have a big impact on connection start-up performance currently:
handshakes (3-way for TCP, 4-way for SCTP, any properly-designed UDP protocol
implements a similar one to prevent amplification attacks) and slow-start.
Currently both of those are on a per-connection (defined as an L4 connection)
basis.

What if there was a concept of "endpoint associations" in addition to
connections? An endpoint association would be a bundle of connections,
potentially from different applications, between the same endpoints. An active
endpoint association would include congestion control information (so new
connections within an established association could immediately start
communicating at full speed) and also means the endpoints are authenticated.
That makes the handshake only necessary for creation of associations, not
individual connections.

If that was done at the OS level, the process for opening a new connection
would be something like:

1\. User wants to open a connection to 1.2.3.4:80. (L4 protocol doesn't really
matter for the example.)

2\. OS checks if there is a currently active endpoint association with
1.2.3.4.

3\. If there is an endpoint association, create a connection within that
association and start sending data immediately, with no handshake, and using
the congestion control information (window size) from the association.

4\. If there isn't, open an endpoint association, complete the handshake for
that, and open the connection within the newly created association. (Future
connections would be able to go through the simplified and quicker process
above.)

I think the handshake isn't a big issue, but eliminating slow-start for
connections to an already-established association should be beneficial.
Thoughts?

~~~
igrigorik
Effectively, you're describing socket pooling and re-use.. across sessions /
tabs / windows. Most browsers already have this in place. :)

Some details on Chrome implementation here: [http://www.igvita.com/posa/high-
performance-networking-in-go...](http://www.igvita.com/posa/high-performance-
networking-in-google-chrome/#ipc)

~~~
msirp
Yep, that does look like the same concept, but only at the application level.

Do you think there could be any real-world advantages to doing this at the OS
level? On paper it would sound good to me, as it could do this optimization
across any application running on the machine.

------
oscargrouch
i´ve been waiting for the rationale from google for a long time. It was love
at first sight, when the QUIC source code arrived at my cloned chromium repo
for the first time :)

very promissing and sophisticate tech!

------
zrail
How much does this share with uTP[1], goal and/or design-wise? It seems like
they have related aims, at least (reduced latency, defeat TCP head-of-line
blocking).

[1]:
[http://en.wikipedia.org/wiki/Micro_Transport_Protocol](http://en.wikipedia.org/wiki/Micro_Transport_Protocol)

~~~
igrigorik
The goals section in the design doc provides a high-level comparison (and
motivation behind "why QUIC"):
[https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-
saqs...](https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-
ev2jRFUoVD34/preview?sle=true)

------
unwiredben
How does this deal with clients behind a NAT? Do modern NATs transparently
treat outgoing UDP the same way they do TCP, mapping the port numbers to allow
associating the return UDP packets with the right client?

~~~
msirp
Yes. UDP NAT is done using timeouts due to not having a standardized
connection setup/teardown sequence.

UDP is used by many consumer-level applications (online gaming including on
consoles, VoIP, video chat like Skype, etc.) so the lack of UDP NAT would
easily be noticed by many normal users.

------
RyJones
I guess there are only so many FLAs to go around.
[http://www.quicinc.com/](http://www.quicinc.com/)

