Slashdot Mirror
Taking Google's QUIC For a Test Drive
agizis writes "Google presented their new QUIC (Quick UDP Internet Connections) protocol to the IETF yesterday as a future replacement for TCP. It was discussed here when it was originally announced, but now there's real working code. How fast is it really? We wanted to know, so we dug in and benchmarked QUIC at different bandwidths, latencies and reliability levels (test code included, of course), and ran our results by the QUIC team."
Javascript required to view *static* content?
No.
Learn how to write a webpage properly.
Yeah, with the current state of the code, and for the scenarios we tested, that's about right. Google's big focus is on doing a better job of multiplexing streams and reducing the amount of round-trips required to establish the connection and stuff. So our test scenario, of pulling down a 10MB psuedorandom file, is a scenario that's near and dear to our hearts, but isn't at the top of Google's TODO. I suspect that flipping on forward error correction is a simple thing, and changing the maximum congestion window size to better overcome the Long Fat Network problem shouldn't be too bad, either.
Paragraph 1 of RFC:
User SHALL register for Google Plus
The current problem with UDP is that many border routers do not check whether outgoing udp packages are from within their network. This is the base for DNS based ddos attacks. They are very difficult to mitigate on server level without creating openings for Joe job attacks instead... Standardizing on udp for other protocols will emphasize this problem
If an experiment works, something has gone wrong.
As someone working with the project.
The benchmarking here is premature.
The code is not yet implementing the design, it is just barely working at all.
Again, they're not (yet) testing QUIC-- they're testing the very first partial implementation of QUIC!
That being said, it is great to see that others are interested and playing with it.
As I understand it, QUIC is largely about multiplexing - downloading all 35 files needed for a page concurrently. The test was the opposite of what QUIC is designed for
TCP handles one file at at a time* - first download the html, then the logo, then the background, then the first navigation button ....
QUIC gets all of those page elements at the same time, over a single connection. The problem with TCP and the strength of QUIC is exactly what TFA chose NOT to test. By using a single 10 MB file, their test is the opposite of web browsing and doesn't test the innovations in QUIC.
* browsers can negotiate multiple TCP connections, which is a slow way to retrieve many small files.
> reliable UDP protocol
You want a reliable *unreliable* datagram protocol protocol?
Sounds like something guaranteed to fail.
Everyone tries to reinvent TCP. Almost always they make something significantly worse. This is no exception.
Also FatPhil on SoylentNews, id 863
Those fuckers at www.connectify.me redirected my connection attempt to
http://www.connectify.me/no-javascript/ so that even after I authorized Javascript for their site I was unable to navigate to my intended destination (whatever shit they pulled did not even leave a history item for the originally requested URL).
This sucks because I middle-click many URLs into tabs I might not visit until ten minutes later. It I had a bunch of these tabs open I wouldn't even have been able to recollect where I had originally been. In this case, I knew to come back here.
Those fuckers at www.connectify.me need to procure themselves an Internet clue stick PDQ.
In some of the web page scenario tests, HTTP over QUIC was about 4x faster than HTTP over TCP, and in others, QUIC was about 3x worse. I'll probably look into that next. The QUIC demo client appears to take about 200ms to get warmed up for a transfer, so testing with small files over fast connections isn't fair. After that 200ms, it seemed to perform as one would expect, so tests that take longer than a couple seconds are a pretty fair judge of current performance.
The slides refer to a feature called "pacing" where it doesn't send packets as fast as it can, but spaces them out. Can someone explain why this would help? If the sliding window is full, and an acknowledgement for N packets comes in, why would it help to send the next N packets with a delay, rather than send them as fast as possible?
I wonder if this is really "buffer bloat compensation" where some router along the line is accepting packets even though it will never send them. By spacing the packets out, you avoid getting into that router's bloated buffer.
From the linked slides:
Does Packet Pacing really reduce Packet Loss?
* Yes!!! Pacing seems to help a lot
* Experiments show notable loss when rapidly sending (unpaced) packets
* Example: Look at 21st rapidly sent packet
- 8-13% lost when unpaced
- 1% lost with pacing
UDP and TCP have different uses; one isn't better than the other, they just do different things.
UDP is message-based. When I send a UDP message the remote end either gets the whole message or none of it. This can make parsing in applications a lot easier; rather than putting delimiters into a stream and trying to pick apart the data as it comes in in chunks I can be sure that I'm always working with a complete message, and the messages can by of different types/sizes/etc. as dictated by my application-layer needs. But there's a maximum size for messages, and if I need to send more data than fits in a single message it's up to my application to ensure they get put into the right order when they are received.
UDP is unreliable, in that if a UDP packet gets drop the message is lost and no notification is made to the sender. Often this is bad, but in certain instances it is valuable. One such instance is data with a short lifetime, such as games or streaming media. If I'm in the middle of a game and a packet gets dropped it doesn't do me any good to get that packet 2 seconds later -- the game has moved on. This unreliable nature also makes UDP simpler; there's no need to setup a "connection" to send UDP data -- you just slap an IP address on the packet and send it along, and the other end will get it or not and use it or not and you don't have to care. So if you're writing a server that will handle billions of clients UDP has a lot less overhead as it doesn't have to keep track of billions of "connections" (or have billions ports available).
TCP is a streaming protocol. You put data in on one end and it pops out in the same order on the other. This is great if you're sending a single file -- you can be sure the other end will get all the bits in the right order. But it also means if you have something important to say you have to wait in line until all of the preceding data has been transmitted, possibly including things that will be expired by the time they are received. It also means your application-layer protocol has to have some method to separate messages if you send more than one thing over a single connection.
TCP has reliable delivery. Often this is a good thing, as the sender can be sure the receiver got all the data (and got it in the right order). But in order to make the protocol reliable the receiver must acknowledge each and every packet from the sender, and the sender and receiver must store information about each other so they can keep track of this ongoing bi-directional connection. So there's at least a couple of round-trip exchanges necessary to setup a TCP connection, and when you connect to a server it must have a free TCP port number for each and every client it's connected to, and enough memory to keep track of all of the connections.
QUIC (and several other new-ish protocols) are proposing a sort of compromise protocol -- a protocol that's both message-based and reliable, and frequently that allows messages of any size. Such protocols provide the delivery assurances of TCP without the waiting-in-line issues the streaming model can produce, and they reduce the amount of setup overhead by allowing clients to open a single connection to the server and fetch many different things.