Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:What is wrong with SCTP and DCCP? (Score 1) 32

by swillden (#49503565) Attached to: Google To Propose QUIC As IETF Standard

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 better than what's in TCP (so I'm told, anyway; I haven't actually looked into that part).

I'm not saying the approach you prefer couldn't work. It probably could. In ten to twenty years. Meanwhile, a non-trivial percentage of all Internet traffic today is already using QUIC, and usage is likely to grow rapidly as other browsers and web servers incorporate it.

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.

Comment: Re: And GOD said (Score 1) 113

by penguinoid (#49502755) Attached to: The Origin of the First Light In the Universe

If God were to stop it, and supposedly he could, it would mean that he would have to override the consequences of what are supposedly freely willed human decisions, making the very point of giving us free will in the first place moot.

OK then, quick free will/morality test:
1) You see a criminal beating an innocent child to death. You have with you a cell phone, a tazer, and a handgun. Do you intervene? Does your intervention mean the criminal doesn't have free will?

2) You see a criminal beating an innocent child to death. You're omniscient and omnipotent. In particular, you have the ability to teleport to a nearby location in the form of a human owning a cell phone, a tazer, and a handgun. Do you intervene? Does your intervention mean the criminal doesn't have free will?

Bonus question: If someone tries to flap their arms and fly, does their inability to do so impinge on their free will? Conversely, if there were a law of physics that prevented murder, would such a law of physics impinge on a person's free will? If your answers don't match, how do you tell the difference between a law of physics that impinges on free will and a law of physics that doesn't?

Comment: Re:Simple (Score 2) 188

by swillden (#49502187) Attached to: Ask Slashdot: What Features Would You Like In a Search Engine?

False analogy. There's a huge difference between a personal assistant, who by definition *I* know personally, and a faceless business entity who I know not at all (read adversarial entity) scraping 'enough' information about me to presume it knows me sufficiently to second guess what I want and give me that instead of what I requested.

Not really.

I'd say there's a good argument that all of the information I give Google actually exceeds what a personal assistant would know about me. The real difference (thus far) lies in the assistant's ability to understand human context which Google's systems lack. But that's merely a problem to be solved.

Note, BTW, that I'm not saying everyone should want what I want, or be comfortable giving any search engine enough information to be such an ideal assistant. That's a personal decision. I'm comfortable with it... but I'm not yet getting the search results I want.

Comment: Re:Simple (Score 1) 188

by swillden (#49502045) Attached to: Ask Slashdot: What Features Would You Like In a Search Engine?

Why would I want crappy results? I want it to give me what I want, which by definition isn't "crappy".

And you think a system built by man can divine what you and everyone else wants at the moment you type it in? That'll be the day. Until then, assume I know what I want and not your system.

I think systems built by man that knows a sufficient amount about me, my interests and my needs can. We're not there yet, certainly, but the question was what I want... and that's it.

Put it this way: Suppose you had a really bright personal assistant who knew pretty much everything about you and could see what you are doing at any given time, and suppose this assistant also had the ability to instantly find any data on the web. I want a search engine that can give me the answers that assistant could.

Comment: Re:Technically, probably not a good move to dodge (Score 1) 119

by penguinoid (#49501805) Attached to: Twitter Moves Non-US Accounts To Ireland, and Away From the NSA

then they would be *safer* here in the USA where the NSA is not allowed to spy on them,

Trouble is, the US Constitution is more like a guideline than a law, since there is no punishment for violating it. On the other hand, in non-US countries it would be possible to arrest the NSA agents for espionage, at least in theory, or at least publicly humiliate their agency by holding their agent until they say "pretty please".

Comment: Re:privacy? (Score 4, Insightful) 188

by Rei (#49501647) Attached to: Ask Slashdot: What Features Would You Like In a Search Engine?

I just want the search engine to stop changing what I'm searching for. I don't want to have to quote every word like I have to do with Google to make sure that the word is actually in the page, and by "the word", I mean "the word I type, not a word that Google things may be similar to the one I typed". It's worst when you're searching for foreign words, product names, acronyms, or whatnot and Google tries to treat them as if they're English words and declines them or chooses synonyms.

"Did you mean X?" is fine. Even "Searching for X (see original results here)", if you're very confident that the person made a common spelling error or whatnot. But just going in and swapping out words as if this is expected behavior? Terrible. At least let me disable it if you want to do that...

Beyond all this: I do like how one can do simple commonn operations on Google - math, conversions, etc. The more of these the better IMHO, so long as they have a standardized format - be they tracking numbers, flight lookups, whatever. It's okay in my book to be a bit Wolfram-y.

Keep the interface plain, simple, the sort of thing that'll work on any browser, from a modern Chrome to a simple text-only browser. Only use javascript where it's not essential for the site to work. Here's an example of something that would be a good use of javascript: if you need to track clicks, like Google does, do it through javascript rather than by having a link redirect like Google does. I hate how I can't just right click and copy link on Google without getting some massive Google redirect link.

Just my thoughts. :)

Comment: Re:Define intelligence (Score 2) 271

by penguinoid (#49501571) Attached to: Can High Intelligence Be a Burden Rather Than a Boon?

No, because there is all kinds of intelligence that is not measurable by IQ tests. For example, a huge chunk of our brains is the visual cortex, but for some reason people don't consider it a sign of intelligence to be able to be able to distinguish basic objects like apples or elephants, or to recognize spoken words (especially with background chatter), or to hold a meaningful conversation. Yet anyone who's tried to have a computer do it knows what a PITA it is. Speaking of computers, just about every math skill is done better by computers, but almost no one considers a computer intelligent.

So at the very least you have 1) raw brain/computing power 2) specialized skills 3) knowledge/data/programming which is rather like precalculated solutions.

Comment: Re:Does it report seller's location and ID? (Score 1) 140

by swillden (#49501287) Attached to: Google Helps Homeless Street Vendors Get Paid By Cashless Consumers
Sure, but that requires only very coarse -- city-level, at most -- geolocation. If I were reviewing this product for launch, I'd tell them that they can use location as a risk signal, but must coarsen it to avoid making it possible to use it for people-tracking.

Comment: Re:What the fuck is the point of the ISP middleman (Score 1) 41

by swillden (#49501277) Attached to: Google Ready To Unleash Thousands of Balloons In Project Loon

If local ISPs are involved, then what the fuck is the point of this?

Not really ISPs, at least as we traditionally think of them. Mobile network operators.

Why the fuck is there still this useless ISP middleman?

The MNO in question isn't the middleman, it's the service provider. It provides service to the balloons, which relay it to regions that are too remote to service now.

For crying out loud, this whole problem exists in the first place because the local ISPs weren't able or willing to invest in the infrastructure needed to provide Internet access to these regions.

No, most of these regions aren't served because it's uneconomical. It's not that no one is willing to invest, it's that it's not an "investment" if you know up front that the ROI will be negative. Putting up a bunch of cell towers to serve remote African farmers, for example, doesn't pan out economically because there's no way the farmers can afford to pay high enough fees to cover the costs of all the infrastructure. Project Loon aims to fix this by radically lowering the cost of serving those regions, to a point where it is economical, so the fees the people in the region can afford to pay are sufficient to make serving them profitable.

As for why Google is partnering with MNOs rather than deploying their own connectivity? I don't know but I'd guess a couple of reasons. First, I expect it will be feasible to scale faster by partnering with entities who already have a lot of the infrastructure in place, particularly when you consider all of the legal and regulatory hurdles (which in many areas means knowing who to bribe, and how -- Google, like most American companies, would not be very good at that). Second, by working through local companies Google will avoid getting into power struggles with the local governments. Google is helping their local businesses to grow, not replacing them.

(Disclaimer: I work for Google, but I don't know anything more about this than what I see/read in the public press.)

Whoever dies with the most toys wins.

Working...