Taking Google's QUIC For a Test Drive 141
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."
Re:It's not broken... (Score:1, Interesting)
TCP is far from not broken. TCP for modern uses is hacks upon hacks at best. Everyone knows this.
The problem is coming to an agreement as to what is the best way to get away from this to optimize things best.
SPDY worked fairly well, god knows what is happening there. It helped fix a lot of lag and could cut down some requests by more than half with very little effort on part of the developers or delivery mechanisms.
This... yeah not sure what is happening there either.
TCP is far from useful. It is terrible for most things in fact. It is sadly all we have because we got used to it. Just like we got used to using paper instead of computers. So much for the future.
TCPs abuse is on levels worse than the web being used to deliver the internet through it instead of the web being another service on top of the internet like it originally was.
Both are huge problems that won't be fixed overnight. And both are problems that do need serious fixing as bloat is constantly increasing every 2years in service deployment. It is a headache for us developers and a headache for the network guys even more so. My poor friend, I feel bad for the things I do to him.
Re:Fuck you, site. (Score:5, Interesting)
Fun trick: Copy the address into your URL bar, hit enter and then very quickly hit Escape.
Javascript isn't technically required to view the page (as shitty as that would be). They're just being dicks.
Pacing, Bufferbloat (Score:5, Interesting)
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
Re:Pacing, Bufferbloat (Score:4, Interesting)
What seems likely is that when you generate a large burst of back-to-back packets, you are much more likely to overflow a buffer, causing packet loss.
Pacing makes it less likely that you overflow the router buffers, and so reduces the chance of packet loss.
TCP does actually do pacing, though it is what is called "ack-clocked". For every ACK one receives, one can send more packets out. Since the ACKs traverse the network and get spread out in time as they go through bottlenecks, you end up with pacing.... but ONLY when bytes are continually flowing. TCP doesn't end up doing well in terms of pacing out packets when the bytes start flowing and stop and restart, as often happens with web browsing.