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…
Google is working on creating a new protocol named QUIC to replace UDP
81–90 of 118 posts
Re: Google is working on creating a new protocol named QUIC to replace UDP
#82Earlier quoted context omitted.
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…
> fake ipsec traffic ..., most of it, is filtered out by the replay protection at virtually no processing cost. The HMAC verification is not exactly a CPU killer either, even less so if there's some sort ASIC/accelerator involved, which won't be that unusual if there is an IPsec involved. To not multiple the comments - what I said above about a single TCP packet obviously implies being on the route between the partie…
Really? Think about that and reply, given the ability of your adversary to send arbitrary traffic.
> To not multiple the comments - what I said above about a single TCP packet obviously implies being on the route between the parties.
How is this seriously distinguishable from MITM? I mean what the hell. Come on you're stretching definitions here.
Uhhh anyway, I think in about 5 years you might be right. Practically speaking no consumer hardware has ipsec embedded but hopefully everyone will in the next few years.
The last time I was in Taiwan working on ASIC hardware none of the white brands did (and most of the big brands are just buying that crap and re-labelling it). Yeah designed in $country? Nah. Taiwan is super good at design, they just need the vendor and the label on the box. Anwyay, that was 2 years ago though, and I was just doing consumer bullshit.
In case you're interested (and you're probably not) the ASIC NAT hardware was the only there coz it enabled the anemic CPU to NAT at the box rated speed. Unfortunately it also turns out, that's why most home users can't seriously torrent or do nice things :( Damn ASICs.
People wonder sometimes why "open source" version is more expensive, and in terms of consumer routers, it's because the pure linux versions don't have the secret sauce. You gotta use more CPU and memory. It's a worthwhile trade-off for not putting up with a real RTOS. But also, good luck MIMO 450 Mbps wireless N using just the broadcom CPU at the rated Mhz :) I'm not even sure if they license the drivers for open source now, I know they definitely didn't before.
There are some really hilarious things which happen where like $marketing from $vendor decide that not only they need a custom enclosure (everyone needs that), but that the box would look way better if the antennas were arranged in certain way. This triggers multiple all-nighters from the engineers who have to relayout the boards and redo the EMC tests.
Wait, I'm way off topic. I think my original point is that you probably don't have ipsec in hardware at home. I await brutal smackdown, coz the community is knowledgable.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#83Earlier quoted context omitted.
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…
What did Microsoft do to WebGL? I thought they simply liked to pretend it doesn't exist.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#84Earlier quoted context omitted.
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…
What did Microsoft do to WebGL? I thought they simply liked to pretend it doesn't exist.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#85Note how SPDY has proven to have limited benefits in the realworld vs a lab. Not that I want to stop their brilliant minds from looking at these problems and trying to solve them, especially on their dime.
If SPDY has limited benefits in the real-world why have both Facebook and Twitter deployed it?
Re: Google is working on creating a new protocol named QUIC to replace UDP
#86Earlier quoted context omitted.
How do you think things get proposed to organizations like the IETF? Someone comes up with a working implementation, proves it to work & to be better than the existing stuff, and then they propose it for inclusion. That's what Google is doing, and they're using Google Chrome as their test bed (along presumably, with a bunch of non-Chrome stuff internally). This is the same thing they did with SPDY. See http://en.wiki…
I appreciate their initiative and their wealth of engineering talent. I completely get what you're saying -- someone has to propose it; and a usable reference implementation is all the better. Unfortunately it seems, given Googles mammoth size, that many folks who might otherwise chime in simply shrug and go "oh, Google has already solved/implemented/popularized a solution" and move on.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#87Transport security, endpoint multiplexing and endpoint mobility done right.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#88Re: Google is working on creating a new protocol named QUIC to replace UDP
#89Hey, what happened to SCTP?
Re: Google is working on creating a new protocol named QUIC to replace UDP
#90These use cases spring to my mind: real-time data and multi-player action games, perhaps even streaming media. TCP and HTTP are less than ideal transports when it comes to real time data. In case of a network error, TCP retransmits the lost data but in a real-time environment, the data is already old and therefore next to useless. Real time action games (like quake) favor udp over tcp. Some questions: Why replace UDP…