You are not logged in.
Pages: 1
The Sandvine attack, outlined in another thread, is one of the first "hacking" type attacks implemented by ISPs. What Sandvine does is something one would expect from a malicious attack performed by an intruder who has tapped into your network, not the traditional (and effective) throttling which your ISP would normally use. Comcast, the largest ISP first observed using the Sandvine appliance, had denied using Sandvine, but has recently defended its use of Sandvine to the FCC.
http://arstechnica.com/news.ars/post/20 … tices.html
http://blogs.zdnet.com/Ou/?p=1001
The Why
The primary reason that Comcast claims it needs to "throttle" BT traffic (and only BT traffic) is that BT users tend to leave BT running at their full upstream rate. Cable modem networks only have about 10 mbps of upstream rate divided amongst (up-to) 450 customers. When people run their torrents at the maximum upload rate of 345 kbps (384*0.9 for overhead -> 42 KBps), the local node will be swamped with only 25 peers (6 %) uploading. Of course, other people are using upstream bandwidth too. George Ou estimates the breakdown of Comcast's network traffic.
http://blogs.zdnet.com/Ou/?p=1031
The Law
The law in the United States does not allow anyone to eavesdrop on private communications (18 U.S.C. § 2511), whether they are voice or data. Communications companies are allowed to "intercept" only what they need in order to properly route and bill the call or data communication, and nothing more. Obviously, the Sandvine box is "listening" in on a private communication in an attempt to determine who is communicating, and to determine if it will interfere in that communication. Even under a loose interpretation of the law, the manufacture and use of a Sandvine box violates Title 18. The law makes no exclusions for "traffic shaping".
The Analogy
To use an analogy where Comcast's network is a toll road and the data traffic is the vehicular traffic:
Comcast advertises the use of its road by showing a nearly empty highway with the occasional race car zipping by. Comcast says that it will let anyone use its ultra-fast tollway. Trucking companies start making heavy use of the tollway, and send lots of "wide loads" down it. This slows the tollway down, so Comcast places a 40 ton limit on the road. Traffic improves and is no longer congested, but Comcast estimates that its road will need repairs sooner than expected (due to the heavy traffic), which will reduce its profits. Comcast identifies the major users of its tollway, and singles-out trucks carrying iron bars. Comcast still claims to allow anyone (under 40 tons) to use its tollway, but whenever a truck gets on it, Comcast secretly X-rays the inside of the vehicle, and then sends out a special crew to hijack the trucks carrying iron bars and make them disappear. Comcast claims that it's not hijacking trucks, but that it's OK to hijack trucks because it needs to keep the traffic flowing, and it's Comcast's tollway anyway. But hijacking is still hijacking.
The Alternative
What makes Comcast's use of the Sandvine appliance even worse, is that there are readily available, non-eavesdropping means to invisibly shape network traffic. I particularly refer to bit bucket based queuing. A TCP stream will only run at the rate of its slowest point. Comcast and some of it supporters have claimed that these solutions aren't available, but more-than-likely, Comcast's routers already have highly configurable, bit bucket based queues inside them. For over 7 years it has been possible to configure a Linux PC to act as a "fair queuing" router, and routing appliances haven't been far behind. Comcast has also claimed that these queues won't help traffic on the node-side of the cable loop (where it matters), but "a TCP stream will only run at the rate of its slowest point", and BT is TCP based.
Other systems also exist, but bit buckets are by far the most adaptable and fastest reacting of any of them, including Sandvine boxes. A more slowly reacting system would be to decrease the throttles of heavy users at the cable modem, and increase it as their usage calms down. When their Vonage doesn't work because they've been throttled to 96 kbps and their BT is taking it all, they might figure it out.
The Terms of Service
Comcast's Terms of Service (ToS) stipulate that people are not allowed to run servers. So far, Comcast has only targeted BT seeds (unidirectional uploaders), not peers. This is because Comcast has determined that a seeder constitutes a "server". Of course, this is a rather valid view. So Comcast has also argued that two wrongs make a right. The proper action against someone who is serving in violation of the ToS would be to cut them off, or severely throttle their connection. Servers can be readily identified by observing for listening ports on extreme uploaders. No need to eavesdrop here either.
The Point is Moot
Well, mostly moot. If BEP 0008,
http://www.bittorrent.org/beps/bep_0008.html
is adopted, the Sandvine boxes will stop working, and Comcast will need to do much deeper packet inspection to target BT. The result is that they will probably turn to "fair queuing", which is what they should have been doing all along. Of course, if Comcast still insists on trying to target BT, I suspect that SSL will be used for all BT peer communications, and some type of SSL-light will be used for tracker communications.
But We Can All Get Along
As I stated earlier, the real problem is people using up all of their upstream bandwidth on BT. Yes, BT is designed to take advantage of unused bandwidth, but not ALL of it! If Comcast wanted to be "ultra fair", to the point of being ludicrous, they would throttle every user at 96 kbps down, and 24 kbps up (that's 12 KBps down, 3 KBps up). Of course, BT would still work fine at those speeds, but Comcast doesn't do this because:
1) People are not using the network all-at-once.
2) When someone occasionally wants to upload something large, they can do it fast.
The basic lesson is: Don't be a bandwidth hog!
And developers, most of the people using BT won't understand a lick of this. You might want to hard code a "Cable Modem" rate of 30 KBps down: 5 KBps up. Or even include an "Even Share" rate of 8:8, or a "Re-seed" rate of 5:10. You might also want to check how many other clients are running, and what their rates are, and then pop-up a warning if it's too many.
Offline
Well, mostly moot. If BEP 0008, http://www.bittorrent.org/beps/bep_0008.html is adopted, the Sandvine boxes will stop working
This hasn't be proven. And anecdotal evidence using https trackers or DHT-only suggests otherwise.
The basic lesson is: Don't be a bandwidth hog!
Far from it. Look at sweden, bittorrent is highly popular, 10M/10M internet is commonly available at low prices (40€ or so) and no significant traffic shaping is applied. This alone proves that infrastructure capable of dealing with bittorrent is feasible and economical. Users shouldn't be forced to not use certain applications because their ISP was to lazy or greedy to expand their infrastructure like others have.
Another thing is that bittorrent is a zero-sum game. If someone uploads less then someone else has to upload more to sustain the same overall throughput, so you're merely shiftingt the problem to other ISPs, which is hardly a fair solution and would fail if everyone does it.
What makes Comcast's use of the Sandvine appliance even worse, is that there are readily available, non-eavesdropping means to invisibly shape network traffic.
which are already in use by several ISPs to various degrees, some british ISPs throttle(!) bittorrent traffic during peak hours, several canadian ISPs throttle it 24/7, some of them also to an unreasonable degree (down to 10KB/s).
Az dev
Offline
If anyone has more intimate knowledge of how Sandvine detects BitTorrent connections, it would be highly useful to the discussion.
Offline
The basic lesson is: Don't be a bandwidth hog!
Far from it. Look at sweden, bittorrent is highly popular, 10M/10M internet is commonly available at low prices (40€ or so) and no significant traffic shaping is applied. This alone proves that infrastructure capable of dealing with bittorrent is feasible and economical. Users shouldn't be forced to not use certain applications because their ISP was to lazy or greedy to expand their infrastructure like others have.
I would have to totally disagree here. If we're going to talk about apples, we shouldn't bring up oranges. The Comcast service is stuck in DOCSIS 2.0 until they do massive upgrades. Now, my service usually runs OK during the day. I can get about 3 mbps down / 300 kbps up. Sometimes, my upstream rate drops to around ~180 kbps during the day. At night, I see crappy upload rates and lots of dropped pings. Now, people aren't using BT 24/7, and I'm not even sure if the night-time slowdown is BT, but there is definitely slowdown. For all I know, it's due to poor line quality (heaven knows I haven't suffered through 3 different episodes of poor line quality, each lasting 1 to 3 weeks).
I do know one thing. Some days, I can run a couple seeds doing 3 KBps each (about 53 kbps), and see no TCP_RSTs. Other days, I barely see 1 KBps, lots of TCP_RSTs, and my terminal program lags its echoes severely.
Now, to talk about oranges. I can get 1.5/384 kbps DSL service with dedicated bandwidth for only $55/mo, and no filtering. This is about $2 more than Comcast charges for 3.0/384. But I can run that link 24/7 at 384 upstream. No traffic shaping, no packet loss, no congestion. And within a year, there's going to be a fiber-optic node on my block, so a 10mbps/1mbps plan may be available... but AT&T wants to charge usage based fees, or maybe just different rate groups. The residential 1.5/384 is only $15/mo, but that can get filtered or limited, as it has a no-server clause. The $55 doesn't, it's take-all-you-can.
Offline
The Comcast service is stuck in DOCSIS 2.0 until they do massive upgrades.
Which is the result of shortsighted investments or whatever. The customers pay about the same amount of money as customers for other broadband services, thus it's a fault of the company and the user shouldn't pay for it by restricting his usage.
Az dev
Offline
dave - I had a proposal for a way to circumvent it which did appear to work, though it's somewhat wasteful (and a bit of a last resort).... Greg should (hopefully) know what I'm referring to.
Azureus Developer
Offline
Pages: 1