Shared publicly  - 
Google wants to make the web faster. We know it. 

For months now, Google Chrome Team is secretly working on creating a new web protocol named QUIC.
Full chromium-side code is available at

From what I understand, and I'm not a transport-security guy, it looks like a improved version of UDP with some extra features such as encryption.

You can already run chrome with --enable-quic switch to enable it and go to chrome://net-internals/#quic to see nothing. Yup. Since I don't know any QUIC server yet, it's kinda hard to test ;)
And if you try with another switch such as --origin-port-to-force-quic-on=80, you won't be able to browse at all.

On a side note, after SPDY, here's QUIC. What's next? RAPID, BRISK, FAST. 
Jennifer Bailey Bergen (tryjen)'s profile photoSirio Adler's profile photoRicardo Lavaggi's profile photoScott Mortimer's profile photo
Let's break standards with proprietary protocols. Yeah, that'll help. 
+François Beaufort even if the code is open, the protocol itself is not managed in the open. It's a vendor specific protocol. Where's the RFC? 
I see what you mean. I guess we'll have to wait to learn more about it.
We can only hope they use the "talk is cheap, show me the code" philosophy, and that they are just making a reference implementation for the protocol to see if it's feasible before they really talk about it in the open.
+Jan Wildeboer Yup, that's the current status. Innovations generally start out private. Standards bodies don't innovate. They only standardize the innovation. So I would reserve my judgement till this is ready for prime time.
+Jan Wildeboer : there isn't any protocol specification yet, it's just some code with some experimental protocol from a opensource project, why go to far and say it's proprietary protocol ?
+Jan Wildeboer or lets all just slumber whilst a standards committee has a meeting, to arrange a few more meetings, that arrange yet more meetings, that eventually decide that they should use the Oxford Comma in all future meeting minutes and agenda's when they arrange more meetings about the new protocol that they need to meet to discuss strategy with some blue sky out of the box thinking to cut the low hanging fruit from the design so we hit the ground running.  Breathe.  I may have over exaggerated my point there.
Any transport layer protocol will be simple enough to reverse engineer even if it were proprietary. It's better to have proprietary innovation than to have no innovation at all and be stuck with the same shitty protocols for 25 years.
I prefer google to focus on the code first, I don't want to see any failed tech showing up in specs. When it's done, push it as a standard.
+Joe Le Brech Is it code first already ? One cannot push one technology out there and set it as standard, it has to be accepted and used by many other big guys after being tested to be valuable compared to the current old technology :) 

Google focuses a lot of time on the internet structure, is it the good time to change the internet infrastructure :D 

If SPDY goes well, this one is gonna be a next step :)
Meh! I look forward to seeing it run in the wild. 
encryption + speed or GTFO 
if it takes even 2 secs more to pack and push its gonna face critique from the masses.
Alas, we await its implementation...and some proper documentation as well lol we all can't ride on the bus of just makes an ass of you and me.
+Quang Dũng of course, not only does the code have to 'work' it has to be fully tested, you don't want standards set in stone and big bugs being found later which means that nasty, competing hacks have to be used. all the release candidates have to be assessed first before any standards are set.
+Jan Wildeboer Actually, following a number of Google projects, it seems their usual method of operation is to get a working implementation and have it fairly stable (ABI/API kind of stable) before starting to work on standardization. As I understand it, it saves time during the actual standardization process.
I'm doing hard in finding any kind of protocol spec that I am really interested in. Anyone found this so far?
+Tais Plougmann Hansen that's fine for service/application level stuff. But when you go deep into the heart of TCP/IP it doesn't feel right. Such changes need broad support and agreement. That doesn't result from a code drop. See how SPDY is still struggling? It also didn't really work for WebM/VP8 AFAICS, BTW.
Jan, you should know that it's impossible to specify a low level protocol without testing at least one implementation. 

You also should know that there's lots of different buggy routers, proxies and firewalls in the real world and without testing, it's near impossible to know what works and what doesn't. There's tons of edge cases.

Jan, have you seen any official announcement? Why are you being so aggressive? Does people trying out new stuff bother you? Should the team announce vaporware first? IMHO, your initial comment was unwarranted.

Disclaimer: I'm not on the QUIC team.
+Marc-Antoine Ruel the code is in Chromium, right? So it has been pushed out to quite some users (unknowingly to most of them) I am not sure if it is also in Chrome right now.

The way it has been pushed into Chromium reminds me of vendor-specific browser features (remember the <blink> tag?) and thus of wars of the past that I hoped we have left behind.

Correct me if I am wrong, but there is no QUIC project page, no protocol description, no rationale, no manifesto, no design spec, only code. That's simply not the way i personally prefer such stuff to be done, If someone wants to extend UDP, that's totally fine with me. But please, please do it in the open. As an example of doing it better, you can check the history of the AMQP protocol. I sincerely hope that QUIC goes the same way. Right now I honestly do not know and that makes me wonder. And guess what - I share my worries on the net. Sorry for that.
+Jan Wildeboer the source code for chromium is out in the open, advanced features don't usually get ported to chrome til they are done. also if you can't read code, all code is "secret"
+Joe Le Brech I prefer a short rationale text that explains what QUIC does, how it does that and how we can find out more. Should be no problem to write that up in a short README. I am quite sure such a rationale document exists and was used to decide on GO/NO-GO for this project. I can read code, but this is quite some code and before I invest time in it I would prefer to know what it is about.

I am not telling Google what to do though. Don't get me wring. If they think a code drop is the best way - so be it. I know from my experience that it is better to use the classical toolkit (mailing list, design rationale etc) if you want to get a working community around a new protocol. That's what happened over at AMQP. And quite some more projects. Naked code simply looks like dumping a pile of waste with a big fat "deal with it" attitude. I don't like that. But that is just my personal opinion.
+Jan Wildeboer : you won't have, because it's a exprimental, you have to involve into the project to know what it is.
It's like you walk across the stress, see someone are watching TV in their house, and you come and demand the person tells you what they watch.
+Công Nguyễn as the code is in Chromium and can be activated it is more like someone knocking on my door talking in an unknown language he invented himself and I really don't know how to talk to him ;-)
GRDY a faster and ultra secure protocol targeted for money transactions is next. And NGINX will be the first big product to implement it.
Just snooping through, I'm not a part of Chromium/Google

It looks like SPDY for UDP.

Some background for others on this thread. SPDY is essentially an improved HTTP, the main feature is a faster HTTPS start-up (fist-bump vs formal handshake and hug). However, both HTTP and SPDY need to do a TCP which is whole song and dance. If you want to make communication really fast, clear, and you're willing to lose some information- like say streaming video/ WebRTC / Web Socket. Then you want to do the UDP song (no dance required), but UDP is just a transport - no application / security baked in. I believe QUIC is a way of doing the SPDY fist-bump for a UDP connection.

+Jan Wildeboer : it's an open sourced project, no once forced you to use it (it doesn't even in beta version), you choose to use the commit, you compile it, you enable the trigger, you run it, now you tell me it is some stranger knocking on your door ?
+Jan Wildeboer I don't ever recall anyone saying this is an official announcement of a protocol. I just see a post on Google+ and a repo in chromium google source for something called quic, that +François Beaufort was interested in. I don't understand why you say it "breaks standards" when we know very little about the intent of what they want to do with this. Maybe you know more about their intent than we do. What standard is it breaking or will break? Also, I don't understand why you said it's "proprietary", when all we see is BSD code in a repo. Please, let me know if you know any patents or licenses wrapped around this that they own. You can call me old fashioned, but I complain when a formal announcement is made for a finished/unfinished product before I pass judgement on it's intent.
+Brian Woods There is a protocol that uses UDP AFAICS. It is called QUIC. There is no design document, no rationale, yet the code is added to Chromium. Exactly as you say with no announcement, no explanation. I would like to see the rationale and some explan ation before I compile that code. As it stands it could be a possible risk. I don't like this approach. I prefer when features are added in an open and transparent way. Thus I raise my objections and ask for at least a little bit of explanation. That's all.
Looks like some way to get tcp-fast open and other nice features into OS and devices out there which otherwise have to wait years to get such cool features.
And yes this even includes red-hat as it will take a considerable amount of time till we have e.g tcp-fast open in red-hat or any linux distribution out there...

All this is quite understandable because tcp clearly starts to show it's age and a faster turnaround between protocol design and deployment in production is needed. Something which is currently impossible with tcp because it's part of the OS which usually takes years to get something new to an appropriate number of users.
I really don't see a problem drafting new protocols on top of UDP to shorten the turn around time to a mere weeks than years (all standards started this way, and those who did not are basically crap, also called "designed by commitee").

Though some rational or design things would be nice +François Beaufort (some further documentations is still google internal with
+Jan Wildeboer Why so quick to judge?  No one said it was "proprietary".  The fact that there is source code is committed to an open-source project would suggest otherwise.
I think this is an attempt to push the boundaries. Transport layer protocols have not really seen any improvement in a long time, and as with SPDY now being the basis for HTTP 2.0, I think QUIC could push folks to update UDP. 
Every standard is "vendor-specific" while the original engineer(s) are building it.  Nothing is being created that requires support for the protocol, locking out clients that don't support it.  Why is Google not allowed to create new (possibly better) alternatives to existing technologies, provided services are able to fall back on established protocols?
What +Stephen Eisenhauer said. Standards based on something that is useful and significantly adopted in the real world are better than fairy tales pulled out of the asses of some random standards committee.  Let Google do whatever they want, if it's good it will succeed, if not, then nobody need be bothered.
+Stephen Eisenhauer They are allowed to. You're exactly right. +Jan Wildeboer was being an unconstructive troll, who believes that anyone who writes code must meet his expectations first and foremost. Especially if it is clever and innovative. It's like my mother always told me, "Never believe anything that comes from a male named Jan."... or maybe it was 'Fran'... I can't remember, but you get my point.
+Matt Bolt ad hominem helps I guess. I still prefer a README with the rationale over a codedrop in Chromium. Insulting me helps exactly how?
+Stephen Eisenhauer Google is free to do whatever it wants. I am free to ask for an explanation and some description instead of a codedrop. That's all.
Is it an attempt to fix the issues with the current protocol to be used now in the existing internet speeds or is it an attempt to have a better protocol to be used in the mid/long term, when internet speed will be in the gigabits per sec?
Just food for thought.
Looks it's more like adding security over udp. Saw comment in quic_framer.h
  // Pass a UDP packet into the framer for parsing.
  // Return true if the packet was processed succesfully. |packet| must be a
  // single, complete UDP packet (not a frame of a packet).  This packet
  // might be null padded past the end of the payload, which will be correctly
  // ignored.
  bool ProcessPacket(const QuicEncryptedPacket& packet);
So is it better for Google to be writing all of this code in secret and just code dump it and expect the world to live with the consequences, or actually develop it out in the open, where people can critize it, file bugs against it, etc?

Really, I don't exactly see why people are complaining. They're not trying to hide it. As far as we know, it's one guy in the Chrome camp who's using his 20% time to see what SPDY over UDP would look like.
Why complain about secrecy? Initial secrecy can be a good thing. It can allow them to experiment and test and fail faster and privately. They can open source or give access to things once they are ready to share a good idea, but I don't mind them having this or any other project in double-secret skunkworks. I'm just glad to know they are working on things like this. 
Add a comment...