DISQUS

The quoted section of your article doesn't support your thesis. The article implies that they are cutting access to P2P in order to thwart piracy while you draw the conclusion that it is to reduce network usage.

Red herring but I'll bite: Off the top of my head Vuze and Bittorrent Inc (the company) sell Hollywood-authorized content and World-of-Warcraft distributes its patches via Bittorrent. Of course you will decree that these don't meet whatever standards you have.

But again, it's irrelevant: A protocol doesn't need be used by major industries to be justified.

But I would suspect that users who run BitTorrent seeders and VPNs at the same time will have all their traffic demoted.

There is still the issue of whether P2P traffic will be is demoted as much as it would have been otherwise. But I think the issue is less cut and dried for the ISPs than you make it out to be. First, it becomes very complicated to try to explain to the layman why their VPN traffic is being demoted by the ISP. Trying to explain the relationship between the apparently unrelated VPN and Bittorrent protocols is going to be futile. Worse still will be trying to convince a customer that their VPN is slow because of something that their kid is doing or because some new service they are using happens to use Bittorrent to distribute files (Online video purchases, online gaming patch distribution): "No it was working fine for the past 3 years, what did you (ISP) do?", "No, my router tells me I have plenty of bandwidth. I read in the newspaper that you are screwing up my VPN", "I don't have Bittorrent", etc.

Second, if Comcast's RSTs to Bittorrent -- a protocol relatively few people even know about -- raised the ire of the FCC what do the ISPs think will happen for a work-related protocol like VPN?

I guess we will see how this plays out.

...it will become necessary for ISPs to demote all encrypted traffic on high traffic user accounts to lowest priority.

Yes, this is exactly the point I was driving at. The question for ISPs changes from "Can we throttle Bittorrent without too much consumer backlash?" to "Can we throttle VPN (or SSL email, etc.) on high-volume connections without too much consumer backlash?". ISPs will have a much harder time justifying the latter than they have the former even in the case where they can correctly identify a P2P user but not the connections in particular. And, for the same reason, if they do decide to decrease QOS for encrypted streams it will be more likely they will do it to a far lesser extent than they have traditionally for P2P. This is the way obfuscation and encryption are forcing the hand of ISPs whether they know it or not.

I wasn't arguing that this would be an effective countermeasure to all forms of traffic analysis and neither do the designers of the proposal: they are very explicit that this only addresses one particular vulnerability that is trivially exploitable by an eavesdropper. I was merely pointing out that Bram's argument of the relative effectiveness of obfuscation does not apply in this case: it is clear that it is far easier to identify Bittorrent connections using this vulnerability than without it.

Whether obfuscation 'works' depends on you measure success. As you point out it is trivial to identify high bandwidth usage. It is not as trivial to identify a particular obfuscated protocol in operation and even less trivial to identify whether a particular TCP session is part of that protocol. So, at best, what can be achieved by obfuscation/encryption is forcing protocol-agnostic traffic management. If an ISP wants to throttle a particular user's P2P app they will also have to throttle their VPN connection and other unidentifiable connections. So the obfuscated P2P protocol will be treated as well as unidentifiable protocols that received preferential treatment from the ISP.

ISPs have generally shied away from protocol-uniform (per user) traffic management for whatever reason. If this remains the case then obfuscating the protocol has arguably achieved its goal.

Bram's 2006 post addressed peer-to-peer obfuscation, not tracker-peer as in the current proposal. Even when applied to tracker-peer communication none of the Bram's criticism in that 2006 post apply to the new proposal. For example, there is no Diffie-Hellman (or other) key exchange, it is *not* harmful (to the protocol due to backwards compatibility), etc. In fact, the only potentially valid criticisms that could even remotely apply to the current proposal is that 1. obfuscation is marginally effective 2. it is hostile to the ISP and unprofessional.

(1) does not apply in this case as Bram was talking about the difference in difficulty in identifying obfuscated and non-obfuscated peer-peer communication. The new proposal addresses a RST denial-of-service attack that is made trivial by observing the peer list a client receives from the tracker.

Bram does not elaborate on his reasoning for (2) but it is a value judgment that, needless to say, many people disagree with and would argue that sending resets is the hostile act.

Finally, I would hesitate to point to Bram as a current day opponent to the obfuscation protocol: His company did propose it after all.

Thanks for the response.

Just to clarify: A single bandwidth request can only serve a single TCP packet? That is, the modem cannot make a request for slots for multiple packets simultaneously during the use of a single contention slot?

Can you elaborate on this point:

"The bottleneck on the
upstream side isn't bandwidth per se, it's the packet rate. So a
number of connection requests use up the cable modem's contention
slots before raw bandwidth is maxed out. It's not about bandwidth,
it's about duty cycle."

Is your argument, in sum, the following?

In contrast to
other forms of traffic, Bittorrent produces a large number of small
synchronization (SYN/ACK) packets which substantially increases
contention at the DOCSIS MAC level (through collisions on the
"contention slot"? Or contention for mini-slots?). Packet drop has no
appreciable effect on the number of these packets and so such
"throttling" is ineffective.

I would expect the rate of contention to be a function of the amount
of data to be transmitted and not the number of packets: if you are
constantly sending data you need to vie for the same transmit slots
regardless of the size or type of the individual packets. That is, the
same data rate HTTP transfer should create the same degree of
contention as a Bittorrent transfer.

Second, the amount of contention is limited in some way (it is not
unbounded). How?

Finally, in the paper you cited, "Assessing the Impact of
BitTorrent on DOCSIS Networks" I see no comparison to performance
degradation caused by other forms of traffic (e.g. HTTP). That there
is contention when links are highly utilized is not under
question. There is no evidence in that paper that Bittorrent, as a
protocol, causes more contention that other forms of traffic.

Please do not shy away from precise, technical explanations.

The implication that customers would save money with a pay-for-usage model is misguided. Telecos are not merely covering their costs but maximizing profits. They will charge as high a rate as possible to achieve this. Without any meaningful competition and given that customers are willing to pay current rates, why would they reduce their prices? Out of the goodness of their hearts?

One could argue that such a model would bring on new customers who were hitherto without broadband because of the cost, but the proposition that the end result would result in higher profits for the teleco would need to be supported. Moreover it is not a given that a signifcant proportion of existing customers would see any price decrease for their usage levels.