4 ms·

Experimenting with QUIC

102 points by igrigorik 13y ago

deleted 13y ago
[deleted]
oscargrouch 13y ago
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!
limsup 13y ago
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 13y ago
  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. :)
TempleOS 13y ago
I thought of that 2 centuries ago, smart ass and put it into yer head. God seys... C:\TAD\Text\WALDEN.TXT precisely these objects which we behold make a world? Why has man just these species of animals for his neighbors; as if nothing but a mouse could have filled this crevice? I suspect that Pilpay & Co. have put animals to their best use, for they are all beasts of burden, in a sense, made to carry some portion of our thoughts. The mice which haunted my house were not the common ones, which are said to have been introduced into the country, but a wild native kind not found in the village. I sen
zrail 13y ago
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 13y ago
  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-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...
jeremyw 13y ago
Wonderful. This reads like an evolution of CurveCP, with the goals of real acceptance and downstream flexibility.
objectivefs 13y ago
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
RyJones 13y ago
I guess there are only so many FLAs to go around. http://www.quicinc.com/ http://www.quicinc.com/
msirp 13y ago
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 13y ago
  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-google-chrome/#ipc http://www.igvita.com/posa/high-performance-networking-in-go...
  - msirp 13y ago
    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.
unwiredben 13y ago
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 13y ago
  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.

102 points by igrigorik 13y ago

deleted 13y ago

[deleted]

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!

limsup 13y ago

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 13y ago
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. :)

TempleOS 13y ago

I thought of that 2 centuries ago, smart ass and put it into yer head. God seys... C:\TAD\Text\WALDEN.TXT precisely these objects which we behold make a world? Why has man just these species of animals for his neighbors; as if nothing but a mouse could have filled this crevice? I suspect that Pilpay & Co. have put animals to their best use, for they are all beasts of burden, in a sense, made to carry some portion of our thoughts. The mice which haunted my house were not the common ones, which are said to have been introduced into the country, but a wild native kind not found in the village. I sen

zrail 13y ago

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 13y ago
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-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...

jeremyw 13y ago

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

objectivefs 13y ago

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

RyJones 13y ago

I guess there are only so many FLAs to go around. http://www.quicinc.com/ http://www.quicinc.com/

msirp 13y ago

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 13y ago
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-google-chrome/#ipc http://www.igvita.com/posa/high-performance-networking-in-go...
- msirp 13y ago
  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.

unwiredben 13y ago

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 13y ago
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.