back to article Google's 'QUIC' TCP alternative slow to excite anyone outside Google

Google's contribution to Internet standards, the fast-than-TCP thanks to multiplexing QUIC protocol, has yet to extend much beyond the Chocolate Factory, according to a German report into its adoption. An experiment from 2012, Google's Quick UDP Internet Connections hit the internet standards track with this draft, and an IETF …

  1. Voland's right hand Silver badge

    fast-than-TCP thanks to multiplexing QUIC

    Least interesting property for most people fighting with it.

    TCP has the "advantage" of wide-spread support. Everyone recognizes it and wants to put a foot in - Apps, OS, network adapters, network gear, etc.

    If you want your data unmolested or if OS/Hardware TCP offloads are giving you trouble, QUICK is your first port of call.

    1. Christian Berger

      Yes, and on the disadvantage side

      You have lots more complexity for virtually no advantage. The current implementations probably still have lots of unfound bugs of which many likely are security critical.

      1. Warm Braw

        Re: Yes, and on the disadvantage side

        I suppose if you compare QUIC with (TLS + TCP) you're looking at a similar level of complexity overall.

        Setting aside the cryptographic stuff, QUIC does fix a number of inherent security problems with TCP and finally deals with its window size limitations, though it curiously does not incorporate any message boundary delineation. I have a suspicion that the complexity of the stream multiplexing and the individual acknowledgment of small chunks of data in each stream is a bear trap - that in practice a lost packet will stall more streams and result in more data being held pending retransmission than if the streams were sent individually.

        That might not matter if the main application is retrieving web pages - the improvement in connection overhead is likely to be more than adequate compensation, but it would be interesting to see data from other types of application.

        The only performance figures I've seen compare QUIC and HTTP (which I presume means they're not using the cryptographic features) and in those circumstances QUIC doesn't seem to be a clear winner and no more robust in the face of packet loss than HTTP over TCP.

        1. Anonymous Coward
          Anonymous Coward

          Re: Yes, and on the disadvantage side

          We run it on many servers for customers, the difference in load times vs. websites over https (even with http2) is noticeable when browsing, especially given the number of elements a modern unoptimised site tends to load.

    2. Justthefacts Silver badge

      Re: fast-than-TCP thanks to multiplexing QUIC

      That was my first thought, except the other way round: what about all those hundreds of use cases where TCP doesn’t operate well in practice, and needs a bit of custom help. i.e. the accumulated network wisdom of fifty years.

      Here’s one: TCP PEPs , over a satellite link with 750ms round trip latency.

  2. sabroni Silver badge

    some versions introduce radical protocol changes without backward compatibility

    And you say adoption is slow? No shit!

  3. rjed

    Quite an achievement, given that QUIC is still not a RFC/standard

    QUIC is not been deployed yet because it is still not a standard !! IETF is working on it and has recently pushed back the dates (to end of 2018) and streamlined what could possibly be achieved in the first version to make most of em/us happy.

    Because it is still not a standard, open source implementations haven't sprung up and thus the adoption is limited.

    Currently only google has deployed "its own version of QUIC" in their own clients and servers. It has seen the prospects and want others to adopt (and eventually/naturally google will also benefit along with others).

    Amongst others, 3GPP has already realized the potential and proposed it for 5G core control plane (https://www.ietf.org/mail-archive/web/quic/current/msg01878.html).

    Point is, the adoption is slow for a reason. The reason is, it is still not a standard and hence not many stable open sources.

    1. diodesign (Written by Reg staff) Silver badge

      Re: rjed

      "QUIC is not been deployed yet because it is still not a standard !! IETF is working on it and has recently pushed back the dates (to end of 2018)"

      Yeah, so as we said, only Google seems excited by it. Everyone else seems to be taking their sweet time - of course, they're allowed to do whatever they want. But the point is, only Google seems excited by it, mostly.

      C.

      1. Lysenko

        Re: rjed

        Given that IPv6 has only got to 11.6% (source: https://w3techs.com/technologies/details/ce-ipv6/all/all) after a couple of decades as an IETF standard, Google may well regard QUIC progress as quite satisfactory given that it's only been with IETF for three years.

        1. Crypto Monad Silver badge

          Re: rjed

          The difference is that QUIC is properly backwards-compatible.

          QUIC runs over UDP, so it can be deployed one device at a time, without changes in your own network or your upstream Internet service, and works through existing NAT devices and firewalls.

          Perhaps most importantly: it gives a visible benefit to the end user who deploys it (in the form of faster page loads).

          SCTP is a standardised protocol whose scope is similar to QUIC. However since it requires OS stack support *and* support from any intervening NAT boxes, firewalls and load-balancers, it has seen limited adoption.

          1. Anonymous Coward
            Anonymous Coward

            Re: rjed

            Re: Crypto Monad

            Ehm, RFC 6951 says otherwise.

        2. Yes Me Silver badge

          Re: rjed

          Actually IPv6 is up to about 20% (https://www.google.com/intl/en/ipv6/statistics.html) but you're right, deployment of new stuff as basic as a transport protocol takes many years. As with the French Revolution, it's too soon to tell.

  4. RyokuMas
    Stop

    Guess it's not so easy to push a proprietary protocol as it is proprietary markup...

  5. Anonymous Coward
    Anonymous Coward

    Hidden QUIC

    Would be interesting to see intra-data-center measurements. it may be that QUIC sees more use for "east-west" traffic inside the DC than it does over the WAN...

  6. MarkelHill

    Second system syndrome?

    tl;dr I see no fundamental advantage to QUIC that can't be achieved with existing protocols (possibly with some comparatively minor optimisations in the kernel or API layers).

    QUIC is a hugely complicated protocol. The amount of code needed to implement it is enormous (look at the Chrome open source repo for an idea of the client-side cost). That suggests the benefits should be very apparent and significant to justify the cost and risk. However..

    1. The multiplexing benefit mostly replaces multiple sockets implemented in the kernel with multiple "streams" implemented in user-space.

    But there is no fundamental reason why the cost/state of a TCP socket is higher than the cost/state of QUIC stream - after all, they more or less do the same thing. In the old days sockets were expensive but that is no longer true as kernels improve and memory becomes cheap.

    2. There are very few if any high-performance friendly APIs for QUIC such as select(), epoll(), kqueue() or libev/libevent at a higher layer. This significantly hinders adoption in existing applications.

    3. In some ways QUIC is anti-thetical to high-performance programming and multi-core CPUs.

    You essentially need to funnel all of a QUIC connection's traffic thru a dispatching thread to farm out stream traffic. This implies user-space driven context-switching costs. No such implementation model is forced on you when using separate sockets.

    As a simple example, adapting Apache's httpd server to QUIC would incur significant performance costs and application complexity.

    5. In many regards QUIC is no different from SCTP (RFC4960), so why not use or incrementally improve SCTP? Google have invested enormously in QUIC. If that effort had been directed at an SCTP++ we would have seen a fantastic improvement by now that would be readily available to a much larger development community.

    Admittedly a number of these criticisms could be addressed by moving QUIC into the kernel, but that seems to go against the philosophy of the QUIC proponents. But even then are you merely re-implementing a variant of SCTP?

    For my money, enhance SCTP and present SCTP streams as sockets to applications and you have a ready-to-go QUIC alternative at about 1/100th the cost.

  7. Anonymous Coward
    Anonymous Coward

    The paper is wrong. QUIC is going like a ROcket and Mobile operators are shitting themselves.

    This paper is full of holes because they dont have access to real data.

    This does and shows QUIC is taking off like a rocket

    https://owmobility.com/blog/meteoric-rise-google-quic-worrying-mobile-operators/

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like