Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is working on creating a new protocol named QUIC to replace UDP

plus.google.com

Post reply on HN
Print view View original

61–70 of 118 posts

Re: Google is working on creating a new protocol named QUIC to replace UDP

#61

Post by corresation »

ZeroGravitas wrote: post #16
santaragolabs wrote: post #11

Earlier quoted context omitted.

Care to point me to some sources on these limitations? I'm just curious.

I think they're talking about this: Not as SPDY as you thought : http://www.guypo.com/technical/not-as-spdy-as-you-thought/ The guy seems to know what he's talking about, and has actually run some tests but the test setup seems kind of weird. Effectively he's saying "if you only change HTTP to SPDY and make no other changes, then it's 3% slower (though more secure)" or "if you only change HTTPS to SPDY and make no ot…

I really, really wish this particular link would disappear from the net. It is a TERRIBLE test. It has been soundly refuted over, and over, and over again. Yet it recurs.

He used a non-caching proxy with SPDY, against distributed non-SPDY back-end resources. This is not how anyone in the world will actually use it, and his test is effectively akin to testing the speed of a sports car by having it drive behind a transport truck: The whole foundation of the test is nonsense to begin with.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#62

Post by xyzzy123 »

18pfsmt wrote: post #56
xyzzy123 wrote: post #50

Earlier quoted context omitted.

Write failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!

Sorry for the beginner questions, but how did the remote port change from 80 to 4007? Are you NATed on both ends? And, how did you go about getting the IP:port of your local router? Are you using some tool, or do you have root on your office router?

Nah not silly questions at all.

I changed the remote port from 80 to 4007 because I figured my web server might get DoS'd :)

I have a crappy cable modem which is kind of a "research problem" to root, so I did the netstat on the web server end to get the local port.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#63

Post by gritzko »

latitude wrote: post #20

I'll tell you a dirty little secret of the protocol design. Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will. So - surprise! - you have no choice but to des…

Actually, there are also "scavenger" congestion control algorithms that use leftover bandwidth. The most high-profile example is LEDBAT used by BitTorrent's uTP. uTP is indeed a TCP clone, but I had my chance to develop a protocol which was using LEDBAT and it was NOT a TCP clone at all (it later became IETF PPSP). So, TCP eating all the bandwidth is not an issue sometimes.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#64

Post by ay »

xyzzy123 wrote: post #50
xyzzy123 wrote: post #49

Earlier quoted context omitted.

Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing... Also, crap, I'm an idiot. Let me do that non-natted ;) tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc

Write failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!

Could it have been your NAT which terminated the connection due to inactivity ?

Quite a few stacks have implemented RFC5961, which should make this attack rather challenging.

(Though, I totally agree with the fundamental problem).

Re: Google is working on creating a new protocol named QUIC to replace UDP

#65

Post by jbooth »

walls wrote: post #58
jbooth wrote: post #41

Earlier quoted context omitted.

Yeah, but 90% of those standards were TERRIBLE. Like, GOD AWFUL. EJB? SOAP? It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java. Eventually the JCP turned into "take popular open source ideas like hibernate and spring, and bless them with a JCP number". Which worked a lot better, and each of those individual projects was usually launched by an individual or…

> It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java. I would really love to hear how you could possibly believe otherwise.

The language Java is simpler than the language Python or Ruby. Fewer keywords, those keywords do fewer things.

Ruby and Python seem simpler for most web work due to better frameworks and dynamic typing, which is less simple than static typing, but is easier to work with in most web situations.

I guess I'm drawing a distinction between 'simple' and 'convenient'. Monkey patching in Ruby is not simple, but can be convenient and make rails possible.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#66

Post by jbooth »

taligent wrote: post #45
taligent wrote: post #34

Earlier quoted context omitted.

The Java Community Process back in the day was a good example of how lots of large companies working together could define a standard and yet still leave room for innovation. H.264 and WiFi standards are recent examples of a lot of companies working together.

jbooth: Hindsight is a wonderful thing. The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most people thought XML was the future of the world and component architectures would be how all business software would be written. Little did we know. But I still use SOAP everyday with Java, .Net, iOS and JS clients. So the benefits of companies working on commons st…

It's not just XML. Why would you ever choose SOAP over a simple REST endpoint? If you use SOAP frequently, have you used jaxb or jaxrpc? Those things were awful.

The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to say that, that arrangement could turn all kinds of great ideas into disasters.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#67

Post by ori_b »

DanWaterworth wrote: post #48
EwanToo wrote: post #32

Earlier quoted context omitted.

I think it's entirely sensible to think about the influence that companies like Google are gaining. Each individual component is a sensible step forwards, but there's no doubt that Google could choose to do some pretty anti-competitive things if they wanted, and in the future there will always be different, more short-term, management in charge

This. The point is not what they are doing, it's what they could do.

A big company will always have the potential to do harm. If it's not about what they're doing, but what they could do, then any company that has influence in a market needs to be taken down.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#68

Post by Flenser »

Flenser wrote: post #51
taligent wrote: post #27

Earlier quoted context omitted.

>I'd go so far as to say that in these areas Google is serving as a model corporate citizen. Well that is a curious way to look at it. Instead of working with other companies to define a common standard they force it through attrition. That's the exact opposite of how this sort of thing should work. And given Google's disgraceful behaviour in abusing the FRAND process they are hardly a model citizen by any measure.

If they'd announced this before they had a working implementation then Microsoft would have either created their own competing standard or wanted changes that only benefit themselves and slowed down development. AFTER EDIT: Why the downvote? Ok, maybe I shouldn't have singled out Microsoft, but I think their past behaviour explains a lot the way Google are behaving now. I'm thinking in particular of what happened wit…

Seriously, why the downvotes? I don't think developing in secret is how things should be done (in a perfect world). I'm just theorising why Google might have chosen to work that way. Is this not a reasonable motive, or is there a better explanation for their behaviour?

Re: Google is working on creating a new protocol named QUIC to replace UDP

#69

Post by DannyBee »

taligent wrote: post #27
InclinedPlane wrote: post #21

Earlier quoted context omitted.

Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome. I'd go so far as to say that in these areas Google is serving as a model…

>I'd go so far as to say that in these areas Google is serving as a model corporate citizen. Well that is a curious way to look at it. Instead of working with other companies to define a common standard they force it through attrition. That's the exact opposite of how this sort of thing should work. And given Google's disgraceful behaviour in abusing the FRAND process they are hardly a model citizen by any measure.

Sorry, but standards aren't formed in committees, they are standardized there. The right way to do this is: Put out your stuff, get others to implement it, everyone has experiences, get together and standardize based on those experiences.

This is why folks like IETF rely on "rough consensus and running code" when standardizing.

I always see this idea that companies should get together in a room and define protocols, and having seen standards orgs that do this, it scares the hell out of me.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#70

Post by xyzzy123 »

ay wrote: post #64
xyzzy123 wrote: post #50

Earlier quoted context omitted.

Write failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!

Could it have been your NAT which terminated the connection due to inactivity ? Quite a few stacks have implemented RFC5961, which should make this attack rather challenging. (Though, I totally agree with the fundamental problem).

PREFIX: this is going to sound really cynical. Also, I haven't read RFC5961, so thanks :)

Yeah, actually it might have been. But I prefer to give HN the benefit of the doubt.

Umm I try and be gentle. But let's talk about the fundamental problem, since you appear to understand it.

TCP-RST DoS is like the worst denial of service ever, since it has such massive negative amplification. You're spending like something like 30k * (required window guess packets) to interrupt one connection, which requires like say less than 10 packets to re-establish. Unless you're talking about BGP, which shit, we normally use TCP-MD5 for anyway. Even commodity home bullshit throws most of your packets away for free.

I take things quite slowly. The normal HN methodology is to go "Incorrect. blah blah blah.". Reality is nuanced and complicated. I try and avoid doing that, because honestly most statements are actually right when you squint at them the right way. Unfortunately, I get the most fake internet points when I say stupid and ultimately unsupportable bullshit while drunk. I still try to avoid doing that :/ But ahhhh here I go anyway.

The nuanced version of this is that most people's devices are going to get DoS'd way harder by fake ipsec traffic which forces checksums in CPU than it is by out of sequence packets which get handled in hardware.

But why don't we live in this fantasy world where we can all terminate TCP connections with imaginary sniper packets and ipsec solves everything.

Post reply on HN