Slashdot Mirror

← Back to Stories (view on slashdot.org)

Taking Google's QUIC For a Test Drive

Posted by Soulskill on from the hopefully-in-one-of-google's-automated-cars dept.

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."

3 of 141 comments (clear)

  1. Re:Fuck you, site. by GameboyRMH · · Score: 4, 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.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  2. Pacing, Bufferbloat by MobyDisk · · Score: 4, 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

    1. Re:Pacing, Bufferbloat by grmoc · · Score: 3, 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.