You’re absolutely right. BitTorrent *IS* and *SHOULD* be lowest priority even if it’s used to supplement a CDN for on-demand streaming or even if it’s used for buffered video streaming. If the video stream is 1 Mbps and it’s pushing the file down the pipe at 4 Mbps (which is usually how web streaming works), there’s no reason to treat it as something other than file transfer.

The problem as you correctly point out is that some ISPs (mostly in Canada) are hard capping and hard throttling P2P. That is a heavy handed reaction that is the other extreme that claims that BitTorrent deserves just as much priority as everything else. Both the ISP and BitTorrent is wrong in demanding hard throttling or no deprioritization. The fair and efficient way to do this is to try to facilitate good performance for everyone. That means high priority for low bandwidth applications, low priority (but not hard capped) for file transfer applications.

The problem now is that we have special interests demanding that we can’t protect VoIP or online gaming. http://www.digitalsociety.org/2009/11/fcc-nprm-prohibits-good-network-management/

If they get their way, it won’t just harm VoIP and online gaming. That’s because a significant number of P2P users also play games and use VoIP. Those people will be forced to simply shut down P2P like they do today, and that harms P2P because it reduces the number of available seeds. So even if ISPs are prohibited from deprioritizing P2P file transfer, that won’t change the fact that P2P users will hard cap or shut down their own P2P applications because they or someone they live with will demand it.

But this is true – all BitTorrent traffic *IS* low priority. The problem is the actually implementation of that rule. ISPs are throttling BT traffic even when no other traffic is using that particular path. If they correctly throttled it only when the connection was nearly saturated, I doubt there would be a problem.

Having a low-priority queue or a “scavenger” class would be nice, but it is not mutually exclusive to an ISP implementing a default setting. We can still give user or application preference precedence, but that doesn’t mean having a default setting to catch every application and every user is a bad thing.

There are plenty of examples of “intelligent networks” that don’t require the ISP to interpret which application is the source of which packets. This is exactly what the TOS byte was designed for. I’m sure most P2P developers would be quite excited if some major ISPs would implement a low-prio queue for a certain value of the TOS. No violation of net neutrality and intelligent network at the same time.

I don’t believe this is a legitimate concern since the policy fairly prioritizes low bandwidth over high bandwidth applications. It doesn’t require the developer to do anything. So long as the network provider is transparent and they don’t abuse he network default priority (which I believe should take a backseat to application or user priority labels), I don’t see what your objection is especially when I’m suggesting that your preference is more important than the default ISP settings. Moreover, I would suggest that the FCC can oversee any potential anti-competitive abuse of the default settings e.g., ISP labels low bandwidth application as low priority.

Also, I never got an answer as to whether you believe BitTorrent (even in video streaming mode) should have equal priority to applications such as VoIP and online gaming which use less than 100 Kbps. Moreover, why would a round-robin queue that alternates between the VoIP/gaming packets and BitTorrent packets be unfair especially when it reduces jitter for the VoIP packets? As I explained here, http://www.digitalsociety.org/2009/09/the-need-for-a-smarter-prioritized-internet/, a First In First Out (FIFO) system is simply primitive and destructive for both VoIP which has negative repercussions for P2P (when the user shuts P2P down due to its bad behavior). Moreover, it would be fair if the queue forwarded 10 tiny VoIP or gaming packets (assuming 10 separate sessions) for every large BitTorrent packet because the router would spend equal time forwarding VoIP or gaming and BitTorrent.

Moreover, BitTorrent or any P2P application in its purist form is not appropriate for streaming video because of the fact that it is out-of-order. Hybrid CDN/P2P models work where the CDN supplies the necessary inline packets and the P2P network offloads random bits ahead of the playback. So in this video application, the P2P application is still a background application and it does not deserve to have 10x the bandwidth of the single CDN flow.

Lastly, you have not addressed the issue of BitTorrent taking 10 times more bandwidth than single-flow applications. This is a fundamental concern that has not been addressed by BitTorrent and it needs to be addressed at the network level.

So we’re certainly not against a philosophy where bandwidth for some apps should give way to bandwidth for other apps. But we believe that it makes good sense for application developers to implement this type of prioritization (like uTP) rather than a priori rules being established by ISPs which every application provider must conform to going forward. (Should I say that app providers must then conform to every different network providers different implementation of these policies – it becomes a real mess very quickly.)

I might point out an example. A number of developers (including us) are getting more and more advanced in implementing streaming on top of BitTorrent. At this point you have a protocol that is much higher priority in the mind of the user, but only the application knows that – the policy implemented by ISPs which blindly says “all BitTorrent is lowest priority” will simply squash it. This means that a natural development of download technology towards more of a progressive download (for content that makes sense) is somehow trumped by (perhaps well intentioned) a priori rules enforced in the “intelligent” network.

Thanks for your remarks.

It seems that your concerns are based on the accuracy of the intelligence in the network. My question to you is this. Asside from concerns about accuracy and possible misclassification (which I think can be addressed with intelligent classification mechanisms that look at traffic pattern and not just port numbers), do you have a philisophical opposition to always prioritizing low-bandwidth and low-duration applications over high-bandwidth and high-prioritization applications?

In simpler terms, do you believe that it is ever appropriate for an ISP to prioritize VoIP and online gaming traffic (sub 100 Kbps) over BitTorrent traffic?

Based on my tests from now and before, the amount of latency being induced in early 2008 is not much different from now with uTorrent 2.0. Those downstream spikes are horrendous, and I have suggested (http://www.formortals.com/?p=57) that BitTorrent should attempt to separate the individual upstream packets at equidistant intervals so that upstream jitter (and maybe to some extent downstream jitter) can be vastly reduced.

I will vehemently disagree with your resistance to “excessive intelligence” in the network because I feel this will not only result in better performance for other applications, but it will also improve BitTorrent (or any P2P) application. That’s the most direct way to manage per-user, per-subscriber, and per-application fairness and DiffServ on the broadband modem or cable/DSL head-end is the most direct way to eliminate upstream and downstream jitter respectively. By fighting these efforts and perhaps aligning yourselves with Net Neutrality advocates who hypocritically (http://blog.pff.org/archives/2009/06/free_press_hypocrisy_over_metering_internet_price.html) suggested that metered pricing was a better way to go than intelligent networks (http://blogs.zdnet.com/Ou/?p=914), you’re dooming your own application and protocol to poorer performance and more limited usage caps.

And as I have repeatedly said, bandwidth throttling is bad but deprioritization of P2P file transfer applications is good for both the applications that have to share a network with P2P and good for the P2P application as well.