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.
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.
Please mod this up. TFS repeats the intentional incorrect framing of the network neutrality debate that its opponents like to promulgate. Network neutrality is about a level playing field, not about making QoS illegal. It's completely fine for an ISP to prioritise HTTP over BitTorrent, for example, as long as HTTP is the same priority whether it's coming from some no-name blog or from Facebook.
More importantly, most useful traffic shaping is not so much about relative priorities, it's about identifying whether the traffic is latency, jitter, or bandwidth sensitive. If I'm doing VoIP, the bandwidth is tiny in comparison to pretty much anything a typical user does, but I'll notice jitter a lot and I'll notice latency. I want my ISP to treat the optimisation goals of this stream as jitter then latency then bandwidth. For normal web browsing, the priority should be latency, bandwidth, jitter (I want the page to start loading quickly, ideally I also want it to finish loading quickly, and I really don't care how bursty the packets are). For BitTorrent or big downloads (including video streams, where you can assume that it's buffered a bit on the client), you want bandwidth, latency, then jitter.
All that's really needed is a mechanism for identifying which of these three characteristics is most important for your packets. Three bits per packet would be enough to identify all of the possible priority orderings, have a 'don't care' mode and leave one value for future use. I think that there are even enough available values in the DSCP field to express all of these, and DSCP also expresses more (for example, it's better to drop this packet than delay it), though it falls into the trap of trusting the sender and providing things that say 'I am important, give me all the things' rather than 'given the choice between these things, I prefer this one'.
I am TheRaven on Soylent News