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.
Could we please get everyone to implement RFC3514?
https://www.ietf.org/rfc/rfc3514.txt
Please? It would make network security a lot easier to deal with.
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.
Way back when, the definition of net neutrality was not "the proposition that internet providers should allow equal access to all content rather than give certain applications favored status or block others."
When I first heard the term in the 1990s, net neutrality meant that the main trunks all processed data the same for every provider and end user. They could certainly make the decision to route some data packets before others, such as video before text. The problem is that the ISPs are now also providers, and have decided that their video is more important than another provider's video. So Comcast is fucking with Netflix, claiming Netflix pushes out too much data. But if I am Comcast's customer, I don't want them disrupting my video feed just because they want more money than they already gouge from their customers.
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
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.
We have this already. It is called QoS, and it is basically ignored on public networks, because it is easily abused by users (malicious or naive) setting everything to top priority. I don't see how this proposal avoids this problem.
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.
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.
I do network engineering at an ISP. We are small, though I have discussed these things with my peers at larger networks.
Once you scale above a very small network (like your home connection), allowing congestion isn't really okay in practice, even with QoS. When I say it's not "okay" here, I'm speaking purely technically.
It might be possible to let networks congest somewhat if you had a large amount of elastic traffic that you could reliably identify. Netflix, for example, could meet these criteria. But that's not okay politically; that's an example of why net neutrality is good!
QoS in carrier networks is only useful for priority (de-)queuing of traffic to reduce latency and jitter. For example, real-time voice or video traffic could benefit. This is where it'd be nice to actually be able to honor user traffic markings.
It's not (currently at least) practical to make the decisions on a flow-by-flow basis in the core of the network (which is what your proposal would require). This is a hardware scaling issue. To be clear, tracking flows statistically is okay at scale. ISPs do plenty with NetFlow/sFlow. But taking an incoming packet, assigning it to a flow, and marking it appropriately, for every packet, in real time is the scaling challenge.
The following approach would scale perfectly in trusted CPE (ONT/cable modem) or reasonably well in a DSLAM (for DSL). Give each user (for example) two queues. Honor the incoming DSCP markings. Put a small, but reasonable, limit on the size of the priority queue; overflowing traffic gets remarked and placed into the non-priority queue. Then, honor markings through the rest of the network.
There are a few problems with even this approach. First off, there are going to be users who legitimately create more high priority traffic than any limit that's acceptable across the board. Is it okay to charge them for a higher limit? If not, how do you avoid gaming the system? If yes, won't that incentivize ISPs to set the limit to zero and charging for all priority? Is that okay? If so, what fraction of people will request and pay for priority in that world? Will that be enough to encourage application developers to mark traffic appropriately? Or does this just degrade into our current zero-priority Internet?
Second, this only gets you one direction (upload). To handle the download direction, you'd need to honor priority bits on your upstream and peering links. But there, you can't trust the markings (unless it's a 1:1 peering link and you are guaranteed your peer implements a compatible policy at their incoming edge), at least without policing. Policing the queues there is easy, but gives you terrible results in real life. If the limit is exceeded with traffic that "should not have been" marked priority, it will destroy the prioritization of "legitimate" priority flows by forcing some fraction of their packets into the non-priority queue. If you accept all (or just a high enough fraction of) incoming traffic as priority traffic, then you have destroyed the prioritization yourself. If you try to mark flows per IP/customer, we're back to that scaling problem.
It might be possible to do something that involves tracking flows at the customer edge and using the incoming markings for the downstream direction. But this is only prioritizing in the last mile. At best, this is a lot of work for very little benefit.