Slashdot Mirror
Stanford Engineers Propose A Technology To Break The Net Neutrality Deadlock (phys.org)
An anonymous reader quotes a report from Phys.Org: Stanford engineers have invented a technology that would allow an internet user to tell network providers and online publishers when and if they want content or services to be given preferential delivery, an advance that could transform the network neutrality debate. Net neutrality, as it's often called, is the proposition that internet providers should allow equal access to all content rather than give certain applications favored status or block others. But the Stanford engineers -- Professor Nick McKeown, Associate Professor Sachin Katti and electrical engineering PhD Yiannis Yiakoumis -- say their new technology, called Network Cookies, makes it possible to have preferential delivery and an open internet. Network Cookies allow users to choose which home or mobile traffic should get favored delivery, while putting network operators and content providers on a level playing field in catering to such user-signaled preferences. "So far, net neutrality has been promoted as the best possible defense for users," Katti said. "But treating all traffic the same isn't necessarily the best way to protect users. It often restricts their options and this is why so-called exceptions from neutrality often come up. We think the best way to ensure that ISPs and content providers don't make decisions that conflict with the interests of users is to let users decide how to configure their own traffic." McKeown said Network Cookies implement user-directed preferences in ways that are consistent with the principles of net neutrality. "First, they're simple to use and powerful," McKeown said. "They enable you to fast-lane or zero-rate traffic from any application or website you want, not just the few, very popular applications. This is particularly important for smaller content providers -- and their users -- who can't afford to establish relationships with ISPs. Second, they're practical to deploy. They don't overwhelm the user or bog down user devices and network operators and they function with a variety of protocols. Finally, they can be a very practical tool for regulators, as they can help them design simple and clear policies and then audit how well different parties adhere to them." The researchers presented a technical paper on their approach at a conference in Brazil.
This is like the "do not track" button.
Only worse.
Every advertiser in the universe will want to programmatically toggle this option "for the convenience of the user."
No. Treat all traffic identically. Bits from CNN are more more important than bits from lemonparty.com
Nobody gets special treatment, that's what net neutrality IS.
Idiots.
It's not about the users. The whole reason ISP's want to give preferential treatment to traffic is specifically so that they can force content providers to pay them for access to their customers. They want to pick the winners, punish competitors, and make money doing it. Anyone that thinks this is about improving the end user experience isn't paying attention.
Which will obviously give me an advantage over everyone else because they sure won't do so.
http://lkml.org/lkml/2005/8/20/95
Why is individual A's desire to see CNN load .5 ms faster more important than individual B's desire to see their friend pranked into being sent to lemonparty asap, given priority?
No. Traffic. Is. Traffic.
The person requesting the traffic wants it asap all the time. Now, an option to DELAY delivery, that may be useful. I am less interested in some kinds of data hurled at me than others. Especially data I don't particularly want, like flash ad streams.
No. Traffic. Is. Traffic. The person requesting the traffic wants it asap all the time.
Not true. If I am audio chatting with a friend, I want packets delivered in milliseconds. But if I am running a torrent in the background, anytime in the next hour or so is good enough. It would be nice to be able to set my own preferences.
If the line is not over subscribed, or bufferbloated, your traffic will not be impeded by that other traffic.
You can already set your torrent client to self throttle. The ISP does not need to do it for you, and should not be in the position or business of doing it for you.
Better solution: forbid the same company to be a connectivity provider and a content seller.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Yes, and because people are people and people are assholes, everyone will set their own traffic to "maximum speed, all the time", essentially resulting in what we already have.
Prisoner's dilemma at its finest.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
and what, exactly, do you suppose CAUSES jitter issues, eh?
When a packet has to wait to enter or leave an interface (gets buffered), the packet is not dropped unless the TTL expires. Instead, its latency just goes up.
Packets wait to enter or leave an interface when:
1) There is congestion (like from oversubscription)
2) Other packets are prioritized
Most torrent clients try to run balls to the walls on bandwidth. This is NOT ideal, because then the medium is saturated, and traffic can neither enter nor leave the pipe efficiently.
Instead, you at most want to let it have 90% of the pipe. That leaves room for some overhead (TCP messages, ARP packets, et al), and ensures that packets are not sitting and rotting inside a buffer, as their TTLs expire.
Your VoIP stream needs to be able to enter and leave the pipe at an unimpeded rate. It wont wait if the pipe is not saturated, and other traffic is not being prioritized. By throttling the torrent stream, you ensure there is sufficient resources for this stream to have good response time. While there might be some jitter associated with irregularities in the number of torrent packets entering/leaving between VoIP packets do, causing jitter, this can be controlled with effective TCP congestion algorithms.
The better routers for home use DO IN FACT allow you to set this. OpenWRT and DDWRT BOTH allow you to define this.
If the ISP is ALSO 1) NOT saturating the pipe (through oversubscription and refusal to build out additional capacity), 2) Not using bloated buffers to make certain traffic types wait around, and 3) ALSO using good Tcp congestion controls, then you will not experience much issue with jitter, even when other kinds of traffic are present.
In the physical world this is done by giving visitors the possibility to pay to jump queues.
It is nothing more than an attempt to monetize congestion, therefore removing any incentive to eliminate the congestion.
The dark fiber will stay dark.
Whats is wrong with "A" technology? It is a technology if it solves a problem.
This appears to be a technological solution to a social problem and those rarely work well. Net neutrality is only a problem because certain companies feel their economic self interest should be more important than the good of the overall system or the needs/wants of the end user.
I actually agree with what this solution does. No one will care that their netflix packets are prioritized lower than their voice packets, since netflix streams and voice needs to be near real-time. Same thing for SSH sessions, page loads, or IM applications. They need faster response times than your Carbonite subscription or drop-box sync.
They will care when AT&T or Comcast starts a massive campaign to convince people to prioritize the services they favor over the ones that the user might otherwise choose. What, you think they'll sit idly on the sidelines over something that could make them huge amounts of money?
Doing it this way (but making it adjustable to the home user by doing something like... right-click on the application and set its "priority" on a scale or something) could be really useful, especially in bandwidth-limited deployments when your backup starts and kills your phone conversation.
This will fail the "mom test" horribly. I can see the family tech support calls coming in now. Shudder...
The path from a neutral Internet to the one Comcast execs dream of at night is a slippery slope. Even embracing partial steps towards that end will lead to yet more, as the specific cases are generalized down to something so vague and weak that any ISP can use it to assign whatever priorities they want to whatever traffic. It will go from "user controlled fast lanes" to "dynamic fast lanes" to "ISP curated fast lanes" to "ISP controlled fast lanes for the sake of general network health".
No one will care that their netflix packets are prioritized lower than their voice packets, since netflix streams and voice needs to be near real-time.
Latency and throughput are very different things. NetFlix does not need to be "real-time" -- it only requires enough throughput to build up a buffer big enough to smoothly play content and handle network variations. Voice calls are very different. They require very low latency and cannot be buffered.
No application bandwidth limiting, just prioritization.
I agree, but we already have that and you even named it. Quality of Service and Class of Service have already largely solved this problem. The only people saying that this kind of prioritization is the same thing as provider or application level throttling (fast and slow lanes), or that QoS will be illegal under Net Neutrality laws are the big telecos and their paid shills.
Once you open the door to "fast lanes" even a little bit, that's it. The level of neutrality will fall over time until it's another fondly distant Internet memory -- kind of like anonymity and the Fourth Amendment.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)