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

2 of 141 comments (clear)

  1. Morons by Anonymous Coward · · Score: 2, Insightful

    UDP is for messages (eg. DNS) and real time data. TCP is far superior for bulk data because of the backoff mechanism, something they want to work around with that UDP crap.

    QoS works perfectly with TCP because of TCP backoff.

    So much wrong with this idea it makes my head hurt. It is OK to run game servers with UDP. It is OK for RT voice or even video to use UDP. It is not OK to abuse the network to run bulk, time insensitive transfers over UDP, competing with RT traffic.

    What is the problem? Too many connections for 1 resource each? Too many TCP handshakes? You know, there was this idea about PIPELINING. Perhaps improve that a little to reduce 200 tcp connections to maybe 3 or 5, instead of piping data over UDP. But that would be too easy - why not invent your own network stack instead :S

    What are people at Google smoking?

  2. Re:Thank you by fatphil · · Score: 5, Insightful

    > 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