Comments on: Nuts & Bolts: A User’s Guide to ISP Network Management

By: laptop battery

laptop battery — Thu, 05 Nov 2009 12:36:21 +0000

This is great news. Best of luck for the future and keep up the good work.

By: laptop battery

laptop battery — Thu, 05 Nov 2009 08:36:21 +0000

This is great news. Best of luck for the future and keep up the good work.

By: Tim Lee

Tim Lee — Wed, 25 Feb 2009 22:00:31 +0000

But if everyone (or, more accurately, every application) demanded prioritization, then prioritization is meaningless.

Exactly. Which is why prioritization based on application isn't going to be a viable long-term strategy. No application developer is going to voluntarily downgrade the performance of his own software. Nor is a user going to meekly accept slower performance merely because an ISP has decreed that he's running a "low-priority" application. This is why any viable network management strategy needs to let end users, rather than network owners, decide which packets are high-priority, and to do so in a way that gives them an incentive to be sparing with the "high priority" flag. In other words, any practical prioritization scheme is likely to be consistent with the end-to-end principle.

Personally, I have my doubts about whether prioritization is useful at all, but if it is made to work, it will be an end-to-end-friendly protocol like DiffServ, not a clumsy hack like Sandvine.

By: Adam Marcus

Adam Marcus — Wed, 25 Feb 2009 21:16:11 +0000

I think DiffServ is a great idea, but wasn't really designed to be used by end-users. And my understanding is that there really aren't any mechanisms in place to deal with packet prioritization across networks owned by different companies. But Bandwidth Brokers (http://en.wikipedia.org/wiki/Bandwidth_Broker) may provide a solution for both end-users and inter-ISP networks.

By: Ryan Radia

Ryan Radia — Wed, 25 Feb 2009 21:00:36 +0000

What are your thoughts on DiffServ (http://en.wikipedia.org/wiki/Differentiated_ser... I think the idea would be that ISPs maintain not just bandwidth tiers but also priority tiers, such that pricing would differ depending on the priority level of a packet.

By: Tim Lee

Tim Lee — Wed, 25 Feb 2009 21:00:31 +0000

By: Adam Marcus

Adam Marcus — Wed, 25 Feb 2009 20:16:11 +0000

By: Ryan Radia

Ryan Radia — Wed, 25 Feb 2009 20:00:36 +0000

By: Adam Marcus

Adam Marcus — Wed, 25 Feb 2009 18:26:20 +0000

Tim: You may not want Cox deciding which of your packets are high priority, but you may very well want Cox deciding that your VoIP packets (which are time-sensitive) should be prioritized over your neighbor's BitTorrent packets (which aren't as time-sensitive). There's nothing to stop BitTorrent users from encrypting their headers to evade detection (which would result in BitTorrent being prioritized). But if everyone (or, more accurately, every application) demanded prioritization, then prioritization is meaningless. Similarly, if every vehicles on the roads had sirens and flashing lights, then police, fire, and EMS vehicles would have slower response times. But that kind of prioritization is something that most everyone agrees is a good thing.

A better solution to the network management issue may be for application developers themselves to decide whether their application needs to be prioritized and indicate such in the packet headers, but to my knowledge there isn't a network management system in use that would allow for that. There is also the concern that if application developers could do this with no consequences, then every application developer would do so and we'd be no better than if we didn't have network management.

By: Tim Lee

Tim Lee — Wed, 25 Feb 2009 00:53:17 +0000

Adam,

If I'm a Cox customer, why would I want Cox deciding which of my packets are "high priority" and which are "low priority?" If I want my BitTorrent packets to be high-priority, is there a way to request that, or are BitTorrent users forever second-class citizens? Also, what's to stop BitTorrent users from encrypting their headers to evade detection?

By: Steve R.

Steve R. — Tue, 24 Feb 2009 16:40:45 +0000

Regretfully, I find many of the Network Neutrality posts to be carefully constructed to only present half the truth while purposely ignoring the deeper implications of what an unregulated packet flow could potentially mean. The simplistic focus is that managing a network is an engineering issue to the exclusion the concept of what a company may actually do to actively "manage" the flow of data.

I do not have a problem with companies implementing "pure" engineering solutions to manage the flow of data. The issue (which is conveniently not disclosed) is that companies can manage traffic for undisclosed opaque "business purposes" that have nothing to do with engineering. There have been cases were telephone companies have blocked access to certain websites as an anti-competitive action or have degraded internet service as a means of "encouraging" customers to move to more profitable alternative services. Then we have the likes of the RIAA and the MPPA demanding that ISPs filter the data flow. The issue of net neutrality is not just limited to simple engineering, it must also consider how data flows can be manipulated to actively interfere with the free flow of data.