Slashdot Mirror
QUIC: Google's New Secure UDP-Based Protocol
New submitter jshurst1 writes "Google has announced QUIC, a stream multiplexing protocol running over a new variation of TLS, as well as UDP. The new protocol offers connectivity with a reduced number of round trips, strong security, and pluggable congestion control. QUIC is in experiment now for Chrome dev and canary users connecting to Google websites."
Frankly after all the NSA spying and how quick these companies were willing to jump on board? I have serious doubts in ANY new network tech not having backdoors of some sort. Maybe after some independent devs have taken the code apart and checked it with a fine tooth comb I'll trust it but as of this moment I honestly don't trust ANY of the major players to have our interests at heart.
As the old saying goes treat everything as suspect, then if it turns out its not you are pleasantly surprised and if it turns out you are right you aren't blindsided. Kinda sad that we all have to be this cynical but that is one of the nice things about the net, they can't hide their bullshit as easily as they could in the past.
ACs don't waste your time replying, your posts are never seen by me.
Why is it that when the NSA goes in Google's Backdoor everyone else gets F'ed?
Is QUIC simply faster? Should I buy options on Vaseline? ... or Ben-Gay?
I am soooo confused.
Big Brother, the NSA and Google thank you for your compliance.
Dump all things Google.
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection? TCP uses the overhead caused by ACK packets as a rate limiter on clients.
There are obviously high-bandwidth frameworks where you're already putting a strain on systems just by using them, where low-latency is also critical, and UDP is appropriate; video chat comes to mind, but outside of that very limited purview, what use could encrypting UDP actually do?
I see no indication of a security audit. Given that SPDY initially had a major security hole (chosen plain text attack based on the compression+encryption combination), I will wait for some expert review of this.
That said, this sounds like a great idea, and I'm looking forward to see how this develops. It appears to be a lower latency faster to connect encrypted network protocol. I'd love to see all network traffic encrypted, and I suspect this would have a disproportionately large improvement for multi-hop encrypted streams, like TOR. If this works out, it will be great for privacy and security.
On the other hand, it might have horrible security holes all over. We need to be careful, but this does look promising. I'll give it a good read through, but I don't consider myself qualified to say much about its security.
I have no objection to protocol experiments that are 100% Open Source implementations. I wouldn't trust one that was not, and an Open Standard is just instructions for people who make implementations.
But it seems that a lot of this might belong in a system facility rather than the browser and server. I don't know if it makes sense to put all of TLS in the kernel, but at least it could go in its own process. Using UDP is fine for an experiment, but having 200 different ad-hoc network stacks each tied into their own application and all of them using UDP is not.
Bruce Perens.
"The chinaman [protocol] is not the issue here, Dude." If google gives up data to the NSA who gives a shit about the encryption involved in transporting that data to a google server? That's like saying "I'm using bittorrent to seed copyrighted info to a MPAA spy but I'm using full stream encryption, they'll never catch me TROLOLOLOLOL"
The point of this is to improve performance for tiny HTTP transactions. The need for all those tiny transactions comes from ads and tracking data and their associated tiny bits of Javascript and CSS. The useful content is usually one big TCP send.
Blocking of all known tracking systems is a simpler solution.
It is bad enough that they rush the TCP start with no regard for the effects of the initial packet flood. If they are going to give up throughput control altogether, network operators will justifiably throttle flows to prevent unfair monopolization of the bandwidth through flooding. Web traffic is not real-time traffic. UDP creates an impression of urgency that isn't true. That kind of traffic will be a bad neighbor on your network.
What do we get from this that we don't already get from TCP? Not to be as conspiratorial as some other posters here; but remember the good ol' days when Microsoft angered you by playing around with HTTP? Now Google wants to muck around at a much lower layer. Whatever.
So... we're probably going to see new connection flood DOS attacks like the ones that prompted SYN cookies a couple of decades ago. Application stacks will need to handle their own congestion control, and applications that do so poorly will negatively impact carrier networks. And, yay, a new variant of TLS when there are already several versions that aren't widely implemented, let alone deployed.
Oh, and in the application so that each of those problems can be addressed over and over. Yay!
Everyone has seen this work before, nothing new here except the who, and the why. Without protocols like this, VDI is next to impossible to give anything like a normal experience over the web. If Google rolls out cloud desktops to go with their apps, I think certain people may take notice. Vmware recently added HTML5 access into the mix, though its still kind of spartan in the current version, its hopefully going to mature in the next. I don't really pay attention to citrix that much, so I don't know where the state of HDX is right now.
Here we are again.
After VP8, protocol buffer, Google is a it again providing some free replacement of some existing standard (DTLS here http://www.rfc-editor.org/rfc/rfc4347.txt)
But of course, Google's people know better and have more money. And the list can go on. Dart as a replacement of javascript. Protocol buffer as replacement of ASN.1, SPDY to replace HTTP. With Jingle google tried to replace SIP protocol as well but at least the extended an existing standard but they dropped the support when stopping Google talk. For couse everyting is free, open source and Not Evil. So why bother?
Well as an aging network engineer, I am starting to be fed up with such "innovations". More consensus building would be refreshing.
I don't know how you expect to keep things in sequence and accommodate dropped packets without implementing a sequencing and transmission protocol. With that in mind, you've just recreated TCP.
What's more likely is Google will create a TCP protocol (you must accept the EULA) which forwards a copy of everyone's session to Google. When you make a request to, say weather.com, Google will then serve you cached results from previous cached sessions to make things faster by eliminating network hops to weather.com. Muhahahahaha...
Join the Slashcott! Feb 10 thru Feb 17!
BE ON A WRONG Users. BSD/OS And exciti>ng; some of you have
Wow, we hit another low point for /. A 2 line 'article' gets to front page because it contains a bunch of TLA's and a FLA (Three-Letter-Abbreviation and Four-Letter-Abbreviation).
It would be really nice if someone would actually explain in any 'article' what the f*ck they are talking about to all the people reading it who don't know what a TLS is. Or even an UDP for that matter.
Is it that difficult to simple put some brackets and the full name after the TLA?
Sorry all, but I can't figure out why this is even 'news' !!!
> Please, if you can't use SSL+TCP for text chat and keep it real time
They could have, but QUIC is "better" for their use cases. In many ways, it's like an improved version of TCP. It runs on top of UDP simply
because routers, firewalls, etc. often only speak TCP and UDP. From the FAQ:
> it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas,
> and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.
> You can outright lose data. Your packets can arrive out of order. It's okay with video data where a hiccup only makes a few missing pixels,
> but with text, that's a terrible idea.
Unless of course the protocol you're running over UDP handles that stuff, just like TCP handles that stuff.
Normally, it's a bad idea to use UDP to run a protocol that has in-order packets, guaranteed delivery, etc. because TCP already gives you that.
Why re-invent TCP? Unless you're going to spend a few million dollars on R&D to make your UDP-based protocol actually be better than TCP,
you should just use TCP.
That "unless you're going to spend a few million dollars on R&D" is the key here. Google DID make the investment, so the protocol actually does
work better for the particular use than TCP does.
Reducing RTT for connection setup and encryption is a nobel goal yet I'm not clear on why technically this can't be solved without the reinvention of TCP over UDP.
TCP fast open coupled with TLS session tickets/snap start offers essentially the same possibility for actual transmission of an encrypted request before completion of first round trip.
Multiple concurrent TCP streams normally end up having much the same properties as multiplexed UDP in the aggregate so I don't buy head of line koolaid either.
What I think is really going on here they want an excuse to bring congestion control algorithms into user space where they can program whatever congestion algorithms they want into their browser and bypass having to deal with the OS vendors.
The design of congestion algorithms is a black art... I worry about algorithms designed using data from google networks not generally applicable to the Internet or otherwise too aggressive which could ultimatly give browser vendors and sites an unfair advantage or prove to be detremental to the larger Internet.
Even in their text they talk about "speculative" double posting of packets just to mitigate against the *possibility* of incurring delays due to dropped packets. There must some kind of real pain felt when packet loss occurs otherwise things turn to shit. Google is always blabing away about "tail loss" and avoiding the dreaded RTO but they never seem to care about the repercussions.
http://www.cs.utexas.edu/users/sustik/QUIC
What I don't understand is why over UDP? They are building a transport protocol, which logically should be another alternative to TCP, UDP, SCTP, etc. Wouldn't this be both more efficient and architecturally cleaner?
What's with the naming convention? With Google releasing SPDY, Snappy and QUIC, I'm guessing they will run out of synonyms for 'fast' sooner than Apple will run out of cats...