Google To Propose QUIC As IETF Standard

As reported by TechCrunch, "Google says it plans to propose HTTP2-over-QUIC to the IETF as a new Internet standard in the future," having disclosed a few days ago that about half of the traffic from Chrome browsers is using QUIC already. From the article: The name "QUIC" stands for Quick UDP Internet Connection. UDP's (and QUIC's) counterpart in the protocol world is basically TCP (which in combination with the Internet Protocol (IP) makes up the core communication language of the Internet). UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP. ... That's why UDP is great for gaming services. For these services, you want low overhead to reduce latency and if the server didn't receive your latest mouse movement, there's no need to spend a second or two to fix that because the action has already moved on. You wouldn't want to use it to request a website, though, because you couldn't guarantee that all the data would make it. With QUIC, Google aims to combine some of the best features of UDP and TCP with modern security tools.

Comments

What is wrong with SCTP and DCCP?

[jd]

These are well-established, well-tested, well-designed protocols with no suspect commercial interests involved. QUIC solves nothing that hasn't already been solved.

If pseudo-open proprietary standards are de-rigour, then adopt the Scheduled Transfer Protocol and Delay Tolerant Protocol. Hell, bring back TUBA, SKIP and any other obscure protocol nobody is likely to use. It's not like anyone cares any more.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

you _do_ known that SCTP was by IBM, right?

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

But why should we pick something that Google has designed for their own ends over stuff others (including corporations, mind you) have proposed in the past, which Google has apparently not even considered properly before leaping in with their own new NIH technology? This is what they seem to always do, and it's getting tiresome. They shove their own version of the web into Chrome, and everyone claps like they're saving us, when in reality even their adopted tech is riddled with issues, and fast-tracking it has been problematic (like SPDY becoming HTTP/2).

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

quic has some nice things in it. some good design, some halfassery. fine results.

however there is no spec, just this giant sloppy implementation which is sitting like a tumor
on the side of chrome.

it violates the whole notion of layering.

spent two weeks trying to tease it out of chrome and failed

maybe it would be a good idea if it weren't so antithetical to the notion of a published standard.

Re:What is wrong with SCTP and DCCP?

[Lally Singh]

SCTP, for one, doesn't have any encryption. QUIC integrates a TLS layer into it, in a way that avoids a lot of connection setup time. The best you could do in SCTP is to put it under DTLS, which won't be as fast. Second, SCTP has horrible fragmentation behavior -- NDATA was supposed to help, but didn't make it in. It uses TCP's congestion window system over the entire association, while QUIC also has pacing. And looking at RFC2960, you'll see the names: Motorola, Cisco, Siemens, Nortel, Ericsson, and Telecordia. Generally someone has to pay engineers to make the standards.

As for the article, the UDP vs TCP discussion is a red herring. AFAICT, QUIC's use of UDP is for compatibility with existing IP infrastructure.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

How about discussing the technical differences and pros & cons instead of the source then? A post below does that and is way more informative than just listing off other protocols and saying nothing about them.

Re:What is wrong with SCTP and DCCP?

[WaffleMonster]

SCTP, for one, doesn't have any encryption.

Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack). A feature QUIC does not provide.

Managing transport and encryption in a single protocol makes the resulting system more brittle and complex. Improvements to TCP helps everything layered on top of it. Improvements to TLS helps everything layered on top of it.

Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.

QUIC integrates a TLS layer into it, in a way that avoids a lot of connection setup time.

TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.

I have yet to hear a coherent architectural justification for QUIC that makes sense... The reason Google pushes it is entirely *POLITICAL* this is the path of least resistance granting them full access to the TCP stack and congestion algorithms without having to work to build consensus with any other stakeholder.

Re:What is wrong with SCTP and DCCP?

[mveloso]

Did SCTP have horrible behavior, or the tested implementation? The QUIC doc says nothing about that. QUIC vs SCTP is on page 8.

https://docs.google.com/docume...

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

How about discussing the technical differences and pros & cons instead of the source then? A post below does that and is way more informative than just listing off other protocols and saying nothing about them.

What's the RFC for QUIC?

TCP and UDP were designed for different purposes. If you're going to defend using UDP for purposes that TCP is a better fit for, then it's up to you to present your arguments as to why.

Re:What is wrong with SCTP and DCCP?

[Jack9]

> QUIC solves nothing that hasn't already been solved.

Creating an IETF standard, based on a working implementation, isn't relevant to what problems it can service. While Google makes strategic and implementation mistakes, their technical research and solutions are usually quite good. The IETF is for this kind of documentation. ie Producing high quality, relevant technical documents that influence the way people design. The fact that someone might reject it as a "NotInventedHere", is not a compelling reason to avoid documenting a standard that may never be used by anyone else. More is better, in this context.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

WHY NOT USE SCTP over DTLS?
One recurring question is: Why not use SCTP (Stream Control Transmission Protocol) over DTLS (Datagram Transport Layer Security)? SCTP provides (among other things) stream multiplexing, and DTLS provides SSL quality encryption and authentication over a UDP stream. In addition to the fact that both of these protocols are in various levels of standardization, this combination is currently on a standard track, and described in this Network Working Group Internet Draft.

The largest visible issue with using these protocols relates to our goals in the area of connection latency, and is perhaps the most critical conflicting element. In addition, we can also anticipate issues in bandwidth efficiency that may reduce our ability to achieve the goals of QUIC.

CONNECTION ESTABLISHMENT LATENCY OF SCTP over DTLS
One of the major and believably achievable goals of QUIC, is to predominantly have zero RTT connection (re)establishment, as was mentioned in goal 3a above. It is highly doubtful that SCTP over DTLS can come close to achieving that goal.

The fact that SCTP and DTLS are currently implemented as layered protocols, one atop the other, already instigates an overall connection latency that is the sum of the two connection latencies. This is seen in section 5.1 of the Draft, where they note:

A DTLS connection MUST be established before an SCTP association can be set up.

SCTP (alone) appears to require 1 full round trip in connection establishment prior to any data transfer. See section 5 of the SCTP RFC 4960 for a discussion of this requirement.

DTLS appears to routinely require 3 round trips in its connection establishment. DTLS is modeled after TLS, which defaults to a 2 RTT HELLO exchange at connection establishment. As noted in section 8.1 of DTLS’s description: DTLS generally uses a full 3 round trips to negotiate a connection (including cookie exchange). That section notes that the 3 round trips are comparable to a TLS over TCP connection establishment, if the TCP’s connection RTT is accumulated with the 2 RTTs for the TLS HELLO.

As a result, with the above baseline connection round trips, we would anticipate a cost of roughly 4 round trips to establish an SCTP over DTLS connection. In contrast, we expect to be able to perform a QUIC connection establishment with zero RTT overhead. Worst case for QUIC should be one RTT overhead utilizing approaches kindred to SSL False Start. We anticipate being able to reduce the probability of that False Start case to very low levels.

It is plausible that some of the connection overhead in SCTP over DTLS could be reduced, but it is highly doubtful that without major changes and merging of the protocols, that a competitive startup latency could be achieved, and the goals of QUIC met.

EFFICIENT UTILIZATION OF BANDWIDTH FOR SCTP over DTLS
The layering of SCTP over DTLS tends to make it more difficult to most efficiently utilize bandwidth in UDP packets. As an example, the SCTP transport conveys data to order packets, and data ranges. At the same time, DTLS is required to separately transport distinctive packet information in the form of cryptographic initialization vectors, used for decryption of packets. Integrated protocols, such as QUIC, can utilize the sequencing information for the stream protocol, as the basis for the initialization vector in packet decryption. The result of this integration is reduced packet overhead. We anticipate that this integration will save data space in several additional places, notably increasing packing efficiency. [TBD: We should provide specific gains, and byte counts, per packet, to fully flesh out this argument.]

PACKET LOSS RETRANSMISSION LATENCY
Goal 3b suggests that we should attempt to reduce retransmission latency by utilizing FEC codes. Neither DTLS nor SCTP currently have provisions for using FEC, and it would appear to be a very significant modification to try to incorporate such. There are some efforts to add FEC b

Re:What is wrong with SCTP and DCCP?

[arglebargle_xiv]

These are well-established, well-tested, well-designed protocols with no suspect commercial interests involved. QUIC solves nothing that hasn't already been solved.

Yeah, but it's from Google, and whatever Google wants, Google gets. They've already done this with SPDY, rammed through the IETF with unseemly haste as "HTTP 2.0", with any objections either ignored or declared out of scope. I don't see how QUIC will be any different, the IETF will rename it to give the impression they had some input into the process, but that'll be all.

Re:What is wrong with SCTP and DCCP?

[Demonoid-Penguin]

How about discussing the technical differences and pros & cons instead of the source then? A post below does that and is way more informative than just listing off other protocols and saying nothing about them.

Nooooooo!! It should be decided by a house vote. Face-painters rule!

Re: What is wrong with SCTP and DCCP?

[Anonymous Coward]

If you actually read the article you linked you'd know that Poul was full of self-contradictory horseshit. He argues for no encryption and was one of the people in the IETF working group that made encryption not mandatory.

 

Re: What is wrong with SCTP and DCCP?

[Anonymous Coward]

Do you think that there should be an RFC before the protocol is fully baked?

Do you believe in design by committee?

Re: What is wrong with SCTP and DCCP?

[Anonymous Coward]

No they don't.
IG TLS frames are unalgned with the transport framing, then a packet loss causes a delay in the interpretation of any data of that TLS frame until the packet is recovered. The means, practically, that TLS on TCP is lots slower when there is any packet loss. .. And packet loss is fairly common, at between 1.5 and 3% on "good" networks,and far worse in placed like India.

Re:What is wrong with SCTP and DCCP?

[swillden]

SCTP, for one, doesn't have any encryption.

Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack).

I disagree. To me there's at least one really compelling reason: To push universal encryption. One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.

But there are other reasons as well, quite well-described in the documentation. The most significant one is performance. QUIC achieves new connection setup with less than one round trip on average, and restart with none... just send data.

Improvements to TCP helps everything layered on top of it.

True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least. That would not only slow adoption, it would also mean a whole lot of additional design complexity forced by backward compatibility requirements. QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself. It will make its way into the OS stacks, but systems that don't have it built in will continue using it as an app library.

Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.

So improve and use those protocols. You may even want to look to QUIC's design for inspiration. Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.

In the meantime, QUIC will be widely deployed, making your work irrelevant.

As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value. A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful. Stuff always gets repurposed and sufficient re-evaluation of security requirements is rare (even assuming the initial evaluation wasn't just wrong).

TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.

Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.

There was much valid (IMO) criticism of SPDY, that it really only helped really well-optimized sites -- like Google's -- to perform significantly better. Typical sites aren't any slower with SPDY, but aren't much faster, either, because they are so inefficient in other areas that request bottlenecks aren't their problem, so fixing those bottlenecks doesn't help. But QUIC will generally cut between two and four RTTs out of every web browser connection. And, of course, it also includes all of the improvements SPDY brought, plus new congestion management mechanisms which are significantly bette

Re:What is wrong with SCTP and DCCP?

[epiphani]

I have yet to hear a coherent architectural justification for QUIC that makes sense... The reason Google pushes it is entirely *POLITICAL* this is the path of least resistance granting them full access to the TCP stack and congestion algorithms without having to work to build consensus with any other stakeholder.

Many years ago, in an earlier life, I tried to make changes through the IETF to an existing protocol. I was responsible for one of the major IRC servers, and still am though IRC is effectively in maintenance only. IRC is a shit protocol - really, embarrassingly bad. So I set up a conversation - grabbed the developers of all of the major clients and servers, and got us all on a mailing list to try to do something about it. We ALL knew it was bad, and we all knew it needed serious overhaul - if not a complete scrapping. We'd even fantasized about a non-tcp multipathing protocol that would be more appropriate for IRC. But like hell that was gonna happen.

This was a group of people that, for the most part, didn't make money from IRC. It was a hobby. We had no corporate agendas, no major impacts to our livelihoods, and the only constraint to implementation was our own time. In the six months we spent, we managed to publish one draft to the IETF. It expired and we effectively gave up. Building consensus is hard, time consuming, and quite honestly not worth the effort when you're talking about this kind of thing.

Google is in a position to just do it, and honestly, I'm fine with that. Otherwise everyone would pop up with an opinion, and nobody would get anywhere. That's why we haven't seen anything come up to rival TCP, even though TCP is pretty bad for a lot of applications.

The only point at which I'd have a problem is if their QUIC protocol isn't completely open and free, and totally unencumbered by intellectual property constraints (patents, etc). Otherwise, go for it - and give me a protocol api/sdk in C so I can give it a shot.

Re:What is wrong with SCTP and DCCP?

[loufoque]

NIH syndrome, a Google specialty.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself.

Ah, so there's the rub. It means google can roll out new versions of Google QUIC[tm] with every new Google Chrome[tm], and leave any and all competitors in the dust. In fact, it'll happen fully automatically with automatic updates whenever Google (not evil) wills it so.

But QUIC will generally cut between two and four RTTs out of every web browser connection.

Not having looked at the specs I'll take this at face value at least for the sake of argument. Taking it that way this is pretty good in the sense that it better matches the model http started out with, and then took to eleven, and way, way beyond.

But that doesn't mean that http is on the right track here. And if it isn't, changing its underpinnings, however helpful, amounts to polishing turds. Sure it'll be a really shiny turnd Real Soon Now, but it'll also still be a turd. Nor that the biggest drain is even in the connection set-up these days. There is a lot going on with ever heavier javascript eating more of my cycles and needing ever more acceleration because even the fastest CPUs would have trouble keeping up otherwise. Something Google (not evil) was and is a big driver of, qv. AJAX. Also note how they're deliberately breaking functionality that previously worked Just Fine if they arbitrarily decide you, silly user, must now upgrade your browser to a new version.

I think the naysayers here have forgotten the ethos that made the Internet what it is: Rough consensus and running code first, standardization after. In my admittedly biased opinion (some of my friends work on SPDY and QUIC), Google's actions with SPDY and QUIC aren't a violation of the norms of Internet protocol development, they're a return to those norms.

That worked rather better when redmond hadn't yet heard of the internet. (The ooxml "standardisation" process, anyone? poster child large company abusing power while seeming to play by the book, if you squint hard enough.) The point here isn't even so much the technical merits of the thing, but the political agendas (multiple) being pushed. Yes, Google (not evil) is quite a lot less blatant about it, and the technology isn't half as shoddy. But that doesn't mean that they're not pushing agendas. They are, very much their own. And that is quite far from the spirit of the thing, in fact it's another nail in its coffin.

Re:What is wrong with SCTP and DCCP?

[haibijon]

It looks like you can already start playing in C/C++ if you want, you just need Go to build the libquic BoringSSL dependency (and there's already a discussion around trying removing Go from the build process in Issues).

libquic: "sources and dependencies extracted from Chromium's QUIC Implementation with a few modifications and patches to minimize dependencies needed to build QUIC library."

Re:What is wrong with SCTP and DCCP?

[DarkOx]

Working code speak volumes in the standards process and that is okay. You take on the risk that nobody will be interested in what you have built or you may discover political opposition that you never counted on; if the resistance is strong enough you get left holding the bag having spent time and treasure on something that will never see wide use.

On the other hand if you start out with a large open consensus building process as you say its very likely you don't get anywhere, or end up with a bastardized design by committee mess, and we spend the next two decades reading on slashdot about how if only people had listened to Person about X during the design process the world would be better.

Short answer is there are problems with both approaches and neither is right or wrong, you just have to go with what makes the most sense in terms of resources and time scale for you.

Re:What is wrong with SCTP and DCCP?

[rossdee]

"NIH syndrome, a Google specialty."

What has the National Institute of Health have to do with it.

(Although I'm guessing Rick Perry will abolish it if he becomes President)

Re:What is wrong with SCTP and DCCP?

[loufoque]

http://lmgtfy.com/?q=nih+syndr...

Re: What is wrong with SCTP and DCCP?

[Anonymous Coward]

"Do you think that there should be an RFC before the protocol is fully baked?" Yes. Definitely.

"Do you believe in design by committee?" Yes. the alternative only has the view and needs of the one or the few to derive the result. When you want only those few to use it, then you are fine. If you want everyone else to be using it, damn straight you need a committee.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

Factless FUD.

It means google can roll out new versions of Google QUIC[tm] with every new Google Chrome[tm]

No, that's what they're doing now. That's not why they're going through a standardization committee.

But that doesn't mean that http is on the right track here. And if it isn't, changing its underpinnings, however helpful, amounts to polishing turds. Sure it'll be a really shiny turnd Real Soon Now, but it'll also still be a turd.

Opinion. Heavily undermined by HTTP's success in the real world. Maybe you meant HTTP2, but more than likely you're just being stupid about this. It takes some level of intelligence to have an opinion about HTTP, but this is a stupid opinion. HTTP is a ludicrously successful protocol.

Nor that the biggest drain is even in the connection set-up these days. There is a lot going on with ever heavier javascript eating more of my cycles and needing ever more acceleration because even the fastest CPUs would have trouble keeping up otherwise.

Now you're just bitching about random crap. Also, I can tell you're not a web developer, because if you were, you'd know that [a] non-AJAX websites did not work "just fine", and [b] it's the users who are demanding AJAX interfaces, not Google. Honestly, I don't know what you were expecting. You include a scripting language with your document browser, and you're surprised that people use and abuse it? Honestly, the only marvel is that it's remotely secure: having people write entire apps with this scripting language was inevitable. And again, none of this is actually relevant to the topic, which is not the application layer. People are going to abuse that no matter what.

Also note how they're deliberately breaking functionality that previously worked Just Fine if they arbitrarily decide you, silly user, must now upgrade your browser to a new version.

I would ask for a citation but I'm pretty sure that you're full of crap and also that it's irrelevant.

That worked rather better when redmond hadn't yet heard of the internet. (The ooxml "standardisation" process, anyone? poster child large company abusing power while seeming to play by the book, if you squint hard enough.) The point here isn't even so much the technical merits of the thing, but the political agendas (multiple) being pushed. Yes, Google (not evil) is quite a lot less blatant about it, and the technology isn't half as shoddy. But that doesn't mean that they're not pushing agendas. They are, very much their own. And that is quite far from the spirit of the thing, in fact it's another nail in its coffin.

FUD. Argument by analogy, and you can't identify the "political" agenda. Because Google is not the Web and there is no governance to be had, at least not more than they already have. If they were operating as you say, they would not have submitted this as a standard.

Re:What is wrong with SCTP and DCCP?

[osu-neko]

...and good for that. Bad standards arise from committees sitting around spit-balling ideas. Good standards come from committees blessing existing practices already proven in the field. Maybe you smooth out a rough spot or two, but ultimately it ought to look for the most part like what's already out there working well. "Not in scope" was precisely the right response for most of the junk people wanted to throw into HTTP/2.0. Alas, it does give people who didn't their favorite feature thrown in ample opportunity to whine. Kamp's whining has the wonderful virtue of being amusingly self-contradictory. "History has shown overwhelmingly that if you want to change the world for the better, you should deliver good tools for making it better, not policies for making it better." Exactly. Trying to improve the world by setting policy via IETF standards, though, is exactly what the IETF did not do in this case, by not adding those things he thinks should be used as a matter of course, and that's what's making Kamp so mad.

Re:What is wrong with SCTP and DCCP?

[recharged95]

Hence, whatever happened to RUDP?

Everyone keeps turning UDP into some pseudo TCP w/o all the extras....that's what RUDP was built for.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

Factless FUD.

Right, and your opinion so obviously isn't. Thanks for saving me the time reading your VALUABLE OPINION.

Re: What is wrong with SCTP and DCCP?

[grmoc]

Having seen the result of design-by-committee (i.e. design by politics instead of designing to fit a functional need), I can say that it doesn't work.

The outcome is almost always better when the protocol has actually been implemented, the kinks worked out, and then you ask others to use it. ...You know, useful is a necessary component of reusable...
But, if you're interested in FUD and a lack of progress instead of something which actually works, by all means do design-by-committee and get nearly useless protocols that implementers ignore.

Re:What is wrong with SCTP and DCCP?

[WaffleMonster]

I disagree. To me there's at least one really compelling reason: To push universal encryption.

Too bad the goal was not pushing universal security instead.

One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.

What we need are systems that are actually secure not ones that pretend to be. Hard to get excited about a "feature" that is worthless against most threats.

True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least.

Is there a technical barrier with respect to TCP and or TLS that makes addressing issues unrealistic? Linux kernel has had TFO support for years and it didn't take decades for SYN cookies or SACKs to hit all but the long tail. There must be at least a dozen or two TLS extensions by now. How hard can it be from a technical perspective to tweak session tickets or whatever vs throwing everything out and reinventing wheels?

QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself.

Not sure retrofitting IP stacks into applications qualifies as a feature. More of the same thing duplicated everywhere usually means a bigger headache for all.

Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.

These are political not technical arguments. Heads of state routinely whine about not being "king" yet there are advantages to not so easily having your way.

I totally understand why Google is doing what their doing. If you own the net stack and the browser and the servers and are a big enough player this is a completely understandable and logical approach to accomplish your goal.

As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value.

I'll assume it can cost nothing in terms of CPU, I/O or Time.

A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful.

Not everyone has the same problems or constraints. Caution against mapping your experiences onto the rest of the world and drawing conclusions from it.

I may need to use a specialized security layer.

I may care about the ability for agents to passively monitor a telemetry stream.

I may care only about integrity of a message.

I may be prohibited by law or corporate rules from encrypting data.

I may have a mission critical system where any use of encryption is an unnecessary potential for failure.

Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.

Yes at a minimum any TCP + TLS solution would require minimum 2 separate unavoidable round trips - one for TCP and a second for TLS regardless of construction if state / cookies / tickets / whatever were not available for TCP and or TLS. So what?

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

Nice selection bias there. All the things Google deemed insufficient, they'll come up with something (what you call NIH). And what Google deems sufficient, they'll just use and you won't hear a blip about it (I'm sure there are thousands of open source technology Google is using that they didn't design/write). Or should I take it you're complaining about BigTable, Google's own hardware designs, self driving cars, etc... being NIH as well?

Look, just because you don't butt up against Google-scale problems doesn't mean those problems don't exist.

Re: What is wrong with SCTP and DCCP?

[mrchaotica]

Do you think that there should be an RFC before the protocol is fully baked?

Do you know what the acronym "RFC" fucking means?!

If you have no intention of accepting "Comments" suggesting changes to your protocol, then WTF is the point of submitting a "Request For" them?

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

hey. we reject kings, etc etc etc

write a spec, get three interoperable implementations developed independently, then
lets go to town

100,000 of undigestable c++ doesn't quite look the same

Re: What is wrong with SCTP and DCCP?

[Anonymous Coward]

> Having seen the result of design-by-committee (i.e. design by politics instead of designing to fit a functional need), I can say that it doesn't work.

You could say exactly the same of design by corporations.

The outcome is almost always pseudo hack that cannot be named "standard" that match the requirement of the company and shit on everything else.

OOXML is a perfect example of this.

Re:What is wrong with SCTP and DCCP?

[Anonymous Coward]

as a cache user, I WANT stuff that doesn't need encryption to be unencrypted. why? because then I don't have to MITM the encryption to be able to cache things. not everyone has multi-gigabit internet, and likely never will.

Re: What is wrong with SCTP and DCCP?

[ThePhilips]

[...] TLS on TCP is lots slower when there is any packet loss.

And how a (almost) stateless protocol like QUIC supposed to handle the packet loss any better?

The previous write-ups about the Google protocols were all like one based on the premise that packet loss is a very very rare occurrence. That's why they use effectively a stateless transport: because they assume that errors are rare. In other words, they are too very bad at handling it.

Coming from the old days of IPX vs TCP debates, I remember how the IPX proponents were going abruptly silent in the face of a bad network connection: IPX wasn't able to transfer literally anything, while TCP slowly was churning data, allowing to download OS update and fix the issue. It would be hilarious (and not unexpected) if (or rather when) Google would step into the same cowpie.

Re: What is wrong with SCTP and DCCP?

[Anonymous Coward]

QUIC isn't stateless (it has HTTP/2's state plus TLS's state and TCP's state... How is that stateless?), and it is being developed precisely because the folks who did SPDY knew that the transport needed fixing as well as the application layer.

Hard numbers: SPDY does better or the same when packet loss is below between 1.5 to 3%. Packet loss like this is basically average-- you see this level of packet loss on uncongested links with no SNR issues...

If an average web page is around 1000 packets (basically understating then average today) you'd expect 15 to 30 lost packets and, for TCP+TLS on a standard stack where you cannot align frames, significant latency increase.

Re: What is wrong with SCTP and DCCP?

[grmoc]

RFCs no longer mean request-for-comments, at least in the IETF context.

Re: What is wrong with SCTP and DCCP?

[grmoc]

Dude, the code is open. Then a spec is written, potentially with modifications, if it proves useful.
You *don't* have to use it.

Summary in error

[Anonymous Coward]

It should be "half the traffic from Chrome _to Google servers_", not half the traffic from Chrome period.

Link not linking anywhere

[Anonymous Coward]

"half of the traffic from Chrome browsers is using QUIC already" is an A element without a HREF.

Re:Link not linking anywhere

[zenbi]

Should link here.

Well...

[koan]

It sounds a bit like a coding cluster fuck.

Side note: Anyone using Comcast? I notice that all my Google services are extremely slow at least some of the day, everyday.
When I turn on VPN there is no issue, I'd to say it's routing... but at this point don't we all know better?

Re:Well...

[drinkypoo]

The official explanation is that there is insufficient peering 'twixt Comcast (or $OTHER_ISP) and Google, and that's the congested link.

Of course, other Google services have no such problems at such times, which makes me suspect it's bullshit. But that's still the story.

Re:Well...

[koan]

Ahhh haven't heard that one....

Encryption?

[koan]

How about UDP and encryption... or lack of it.

So encrypted request and data sent with no encryption...

Someone tell me my thinking is wrong here.

Re:Encryption?

[Anonymous Coward]

TCP also lacks encryption and you do SSL over that. How would UDP be different?

Re:Encryption?

[Opportunist]

The main difference I'd see is that it's much harder if not impossible to spoof an IP address in a TCP connection, considering that it takes a completed handshake before any meaningful traffic (read: lots of bits) can take place. I could for example see this making upstream filtering of DDoS attacks more difficult.

Just say no

[WaffleMonster]

Google just wants dominion over congestion algorithms for their own benefit.

Re:Just say no

[Anonymous Coward]

And WaffleMonster just wants to bash Google for his/her own benefit (i.e. paid by MS).

Re:Just say no

[WaffleMonster]

And WaffleMonster just wants to bash Google for his/her own benefit (i.e. paid by MS).

Was in the room for delivery of one-sided Google presentations touting benefits of aggressive congestion schemes and ICW settings during TCPM meetings. I honestly fear ease at which clients and servers can cheat and tinker for competitive advantage with completely user land stacks embedded in applications.

Wording was probably a little unfair and oversimplified yet I believe in the general theme. I don't work for a large corporation and have little interest in this space other than promotion of an open decentralized Internet.

Oh good!

[93 Escort Wagon]

I bet QUIC will make those DART-driven VP9 video services really SPDY.

Second link is empty A tag

[GrayNimic]

The second link in the story ("half of the traffic from Chrome browsers is using QUIC already") is broken - it's an empty <a> tag, with no href. Also means we can't workaround it, since we don't have any hints about the destination.

Re:Second link is empty A tag

[GrayNimic]

Though the first link's article does mention the destination, https://blog.chromium.org/2015...

Proxies share key?

[CaptQuark]

QUIC is designed so that if a client has talked to a given server before, it can can start sending data without any round trips, which makes web pages load faster.

So, if I have three clients behind a NAT or proxy, do they all share the same TLS key? Does that mean my encryption is compromised in a WiFi environment?

~~

Re:Proxies share key?

[SuricouRaven]

No, and no more than usual.

Stupid NAT.

[SuricouRaven]

It's impossible to introduce any new transport-layer protocols now, because the vast majority of connected devices are behind at least one layer of NAT, and that means transport protocols can only work if the router support them. We're stuck with TCP and UDP, and no chance of deploying any potentially better alternatives.

Bring on IPv6! Coming soon since 1998.

Re:Stupid NAT.

[ledow]

So when everyone goes IPv6, when ISP's literally say "That single IPv4 address you used to have? This is the replacement IPv6 starting with XXXX:XXXX:XXXX:0001?

Do you think they are going to pull up all their existing systems renumber every internal machine, make them all publicly accessible, give each a unique IP from the range allocated, etc.

Or do you think they'll buy an IPv6 compatible router, slap it into the network as the same gateway on IPv4, and have it pick up the first IPv6 address offered from the ISP?

If anything, all you will see is more NAT - ISP's will NAT your connection for you in the interim rather than IPv6 all their systems (I can name precisely one ISP in the UK that I know offers IPv6 connectivity).

Sorry, mate, NAT is not "solved" by IPv6. It's here to stay for way more than the foreseeable future. And your problem is not necessarily even NAT. It's stateful firewalls. And guess what anyone with half a brain will put in front of their hundreds of clients that you want to individually route to the Internet? A stateful firewall.

UDP works JUST FINE with NAT, if you haven't noticed. Has done for decades. Anything initiated inside the local network will go out just fine, and Internet servers have to have open-ports anyway in order to work. As soon as you send a reply, the stateful part of the firewall knows that it can bypass NAT, NAT itself does little in this regard. And, as the summary says, Google Chrome works JUST FINE with UDP at the moment..

People have this thing about NAT being evil but it's not. And it's not "fixed" by the existence of IPv6 (or we'd all jump ship just to avoid NAT, if the problem was that bad). And it's not even going to go away on IPv6.

Not sure what you're hoping for but I'll worry about my ISP providing me any kind of IPv6 functionality before I even think of removing NAT from my local networks and - chances are - I won't for years until EVERYTHING, every server, every website, every service, is IPv6 anyway. And I'll still have a stateful firewall so your unsolicited packets to my network still won't succeed anyway (unless port-forwarded or open-port) and still all the servers on the planet will need to have open ports.

Re:Stupid NAT.

[amaurea]

It is coming, finally. In 2010 0.1% of the connections to Google's services were native ipv6, and about the same used 6to4. Now, about 6% of the connections are native ipv6, while 6to4 is almost completely gone. 6% is enough that it's actually starting to matter. The fraction currently seems to be growing by 2.5 percentage points per year, though it might still be accelerating. So perhaps we will finally be free from the curse of NAT in a few more decades.

Re:Stupid NAT.

[drinkypoo]

Do you think they are going to pull up all their existing systems renumber every internal machine, make them all publicly accessible, give each a unique IP from the range allocated, etc.

Wow, it's almost like you're completely ignorant of how networking actually works, and yet still posted on slashdot anyway!

UDP works JUST FINE with NAT, if you haven't noticed.

Yes, as long as the firewall is stateful. Otherwise you need protocol support to receive responses.

People have this thing about NAT being evil but it's not.

No, certain protocols are evil, like SIP, and NAT exacerbates that evil. As such, it's not evil, just a massive PITA.

Re:Stupid NAT.

[Anonymous Coward]

Actually, the thing most likely to happen with routers is they will have a "pseudo" NAT that will literally just emulate some features of NAT, a load of private addresses, and one public.

This will be incredibly more flexible, however, due to the larger number of addresses. And there won't be weird port forwarding issues and other nonsense, slightly decreasing overhead. (only noticeable in high bandwidth admittedly, maybe shave a couple ms off your ping)

Of course, I don't think you will reliably be able to emulate some of NAT, such as only giving a person one IP to connect to the many services behind your router.
Could be done, but it would be weird and confusing, and basically just NAT again.

Re:Stupid NAT.

[Anonymous Coward]

Stop whining and start using IPv6 then. It's there already. There isn't going to be a magical date when everybody has it. In 30 years there will STILL be users and places that only use IPv4.

Re:Stupid NAT.

[andrewbaldwin]

"I can name precisely one ISP in the UK that I know offers IPv6 connectivity"

Would you mind letting us know who that might be?

I'm considering moving ISP and want one where I can have a static IP address; looking to the future it seems to me that it's worth having IPv6 support now rather than a second upheaval in a few years time

Re:Stupid NAT.

[Lumpy]

I send custom Transport protocols as well as the "wrong" protocols over port 80 that traverse NAT just fine.

Routers dont care about the content just the port, the firewall may freak out, but that has nothing to do with routing.

Re:Stupid NAT.

[ledow]

Andrews & Arnold.

Re:Stupid NAT.

[tgetzoya]

https://en.wikipedia.org/wiki/... The U stands for UDP.

Re:Stupid NAT.

[andrewbaldwin]

Thanks

I've heard good things about A & A and they're high on my list of potential new suppliers

Re:Stupid NAT.

[Anonymous Coward]

Eh. If Comcast is your ISP, you *already* have an IPv6 connection. All you have to do is ask your router to talk DHCPv6-PD to Comcast's DHCP servers. Many routers (including Apple's) do this automatically. Somewhat recent versions (Easy since Barrier Breaker, harder in the previous version) of OpenWRT can be trivially configured to do so, as well as vaguely recent versions of Tomato.

Re:Stupid NAT.

[Anonymous Coward]

I...

Read about DHCPv6-PD. Also read about dual-stack IP systems. IPv6 isn't an all-or-nothing affair, as a given network interface can easily have multiple IPv4 or IPv6 addresses.

Re:Stupid NAT.

[Anonymous Coward]

You should look into IPv6 ULA addresses, and the ability for the IPv6 next hop to be a Link Local address.

You should also look into what the IETF says about IPv6 NAT, and DNATting in general.

Routers and stateful firewalls are *substantially* more powerful (and a fair bit less complicated) than people expect. Additionally, IPv6 got a lot more tiny things right than people expect. (There's very fair criticism of many parts of the IPv6 protocol, but for day-to-day operation on small-to-medium-sized networks, it's quite nice.)

Re:Stupid NAT.

[Anonymous Coward]

lol. it seems your definition of "works fine" = horribly insecure and relying on cookies and state guesswork in your router.

I've been IPv6 dual stack for years. Stateful firewalls are a kludge at best when attempting to use them with stateless protocols such as UDP.

Re:Stupid NAT.

[Anonymous Coward]

The best part is that your router can figure out where in the packet the port number is for each custom transport you use, even when there isn't even a port number system for that custom transport.

Unfortunately the routers most of use are not that advanced, and can only figure out what port a packet is addressed to if it's UDP or TCP.

OMG they have discovered UDP

[Anonymous Coward]

... what? it was always there?

Re:

[Anonymous Coward]

Why are you surprised that Google claimed to create something that already existed? Have you been asleep for the last decade?

Trust google for setting standards....

[Anonymous Coward]

... Trust them like politicians, they are there too look out for you, not to get rich at the cost of you. Let google drive change and soon enough you will have to explain to the children how you could be so fucking stupid.... and you can say that you did not know any better cause you are too busy with your own stupidity!

Re:Trust google for setting standards....

[Anonymous Coward]

Fuck you, idiot.

NAT is ok for asymetric usage...

[Anonymous Coward]

i.e service consumption (think DNS). For peer to peer it doesn't work without godawful things like hacking up SIP SDP payloads. Hmm.. I wonder if that's on purpose.

shit is it that bad already?

[Virtucon]

From the summary:

UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP. ... That's why UDP is great for gaming services.

Stateful vs. Stateless, Connection Oriented vs Connectionless. These are all at the core of TCP/IP and specifically TCP vs. UDP and the reliability contract that each protocol provides. It's not that "one's better than the other at error correction."

Re:shit is it that bad already?

[Anonymous Coward]

One actually does error detection and re-transmits.

Given Google's past protocols

[heroine]

Does this mean all web pages are going to partially reload for 5 minutes, toggling between 2 resolutions, then give up with a static filled error message?