Slashdot Mirror
Morality of Throttling a Local ISP?
An anonymous reader writes "I work for a small (400 customers) local cable ISP. For the company, the ISP is only a small side business, so my whole line of expertise lies in other areas, but since I know the most about Linux and networking I've been stuck into the role of part-time sysadmin. In examining our backbone and customer base I've found out that we are oversubscribed around 70:1 between our customers' bandwidth and our pipe. I've gone to the boss and showed him the bandwidth graphs of us sitting up against the limit for the better part of the day, and instead of purchasing more bandwidth, he has asked me to start implementing traffic shaping and packet inspection against P2P users and other types of large downloaders. Because this is in a certain limited market, the customers really only have the choice between my ISP and dial-up. I'm struggling with the desire to give the customers I'm administering the best experience, and the desire to do what my boss wants. In my situation, what would you do?"
I agree, but with the caveat that you have to do what your boss tells you to do. By all means, present this idea to the boss, but be absolutely sure that you are complying with the requirements of the job you are assigned: after all, in this economy, you do not want to give your boss a reason to fire you.
You will definitely have to consult your boss about this, and you would be remiss in not telling your boss to send the TOS to your company's attorney and have him advise on the legalities regarding whatever plan you and your boss ends up deciding on. You don't want your company to get sued and you don't want anyone to say it's your fault because that would be another reason you might get fired.
In the end, look over the TOS, and if your boss asked you to shape it and shaping doesn't meet with the TOS, by all means CYA and ask your boss to send his request to you in writing. Preferrably signed. Digitally signed e-mail might be okay, too. Just make sure you have some proof of what you were ordered to do, because you want to be sure if there is any fallout from the shaping that you can prove you were just doing as ordered.
It bears repeating so I'll say it again: always CYA.
My blog
$1 per GB is a little steep, isn't it?
These guys only charge $0.10/GB.
Your suggestion seems like the best way to go. Up here, Telus(big ISP) has caps at 10GB, 60GB, 100GB per month based on how much you're paying.
I've never seen a cable-ISP contract that provided service at a specified rate in Mbps. You can get those contracts as a business user, but they're not the standard ones home users have. Usually home contracts say something along the lines of "up to xx Mbps; actual speeds may vary and are not guaranteed".
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Minor point, but it was an FCC hearing against Comcast not a court case. Part of the problem was that Comcast ran around terminating connections behind your back -- and without notifying customers via TOS or any other method.
When it comes to throttling, seanadams had it exactly right: you have to provide the auto-throttle option so that people don't get slammed with a huge bill at the end of the month. Very few people want to sit around adding up their monthly bandwidth usage, so it's a good idea to start warning users as they approach the limit. Unless, of course, slamming people with a huge overage bill is part of your revenue-maximizing business model.
I thought the problem was also because of they way they did the dropping the connection (via a "reset"); they "masqueraded" as someone else which is a no-no under the law.
Here's a simple diagram:
A is downloading from B.
C (Comcast/ISP) "throttles" by telling A that it's B and makes the changes that way.
Essentially, a "man-in-the-middle" situation.
If Comcast was some poor sap, it would be in the federal pokey...hopefully without soap on a rope.
The solution for better or for worse is for the US to implement download caps like the rest of the world. It'll be unpopular and it'll have disadvantages, but laying cable still costs money and the current all you can eat payment schemes just don't work.
No, the solution is for broadband providers to do what they've already gotten billions of taxpayer dollars to do but didn't, build out broadband. These companies are trying to double dip, first take taxpayer money then bill customers more.
Falcon
Should there be a Law?
One particular Australian ISP I was looking at, I forget who. It may have been Dodo or something, it always seems right to blame Dodo for these things, sold ridiculously low download caps (in the less than a gigabyte range) coupled with reasonable speeds (so as to very quickly eat the allotted cap up), and charged excess usage at 10c per megabyte. And they had the audacity to throttle usage after the cap was exceeded.
I've said it before and I'll say it again: If you think your ISP might not be using lube when it fucks you, try spending some time in Australia.
Admit it. You post strawman arguments as AC so you get modded Insightful for refuting them, rather than Troll
HTB is Hierarchical Token Bucket, a CBQ (Class Based Queueing) discipline for Linux. It lets you create a hierarchy of queues for a network link. The "Token Bucket" part means each leaf and node in the tree has a "bucket" that constantly, slowly fills with tokens. Sending a byte removes a token. So, on average, you're only guaranteed the fill rate, but if you haven't used it for a bit, you can send a burst until your bucket is empty. Extra tokens can be borrowed between nodes if they're not used by the others, up to the max rate. Thus you get minimum guarantees, max limits, and bursts, such as being able to quickly fetch a web page even if the link is full from others' usage, if you haven't used up your tokens.
For instance, you could have Customer A, Customer B, and Customer C at the top level, and then they each have a second level of HTTP, BitTorrent, and SSH. Customer A and B get a rate of 128k, and C gets 512k since he pays extra as a business customer. They all have a max rate of 6M, since that's the speed of their DSL lines, and a burst size of 1MB. Then, they have SSH (with a small rate and a small burst), HTTP (with a high rate and a large burst), and BitTorrent (with a 1k rate, and a small burst).
As long as Customer C isn't using any bandwidth, A and B can use it all. As soon as C wants to use some, he first gets his guaranteed 512k - no matter what - and then they all split any leftovers in proportion to their committed rates (So A gets a share, B gets a share, C gets four shares). If C only wants 512k, A and B each get to split all the leftovers evenly.
If A is using BT like mad, but then opens an HTTP connection, it'll be allowed most of his net connection (it has a high rate, but still lower than the full line speed). BT will automatically (and instantly) be throttled until HTTP is done. When he types on the SSH connection, it'll use little bits of its burst speed to refresh the window instantly, but its small rate won't let it consume the whole net if he accidentally cats /dev/urandom.
Sounds great, right? There are a few gotchas: You can only queue packets like this when *sending*. What're you going to do, receive a packet from the slow link and then delay it before sending it over the fast one that's not saturated? (Well, yes, you can, and it makes a limited amount of sense to fine tune TCP's flow control, in addition to selectively dropping packets to make it back off, and other tricks.) It's good, but it doesn't necessarily make optimal tradeoffs between latency and bandwidth - HFSC is an attempt to address this. Also, this is a moderately heavyweight way to do things. It has to spend some CPU classifying packets, and memory to track the buckets' state, so other queueing disciplines and schedulers exist that work on other methods (such as statistical, instead of discrete tracking), that are more appropriate for very large ISPs. Also, as a large ISP, you're going to be using Cisco, not Linux, for routing. :) But Cisco has sophisticated QOS as well.
Despite how complex this sounds, even using the simplest case on your home router will make a huge improvement in the weak side of your DSL line, the uplink. Several of the open source WIFI router firmwares support it out of the box for this reason. I have survived having my web site on my DSL linked to the front page of a popular site known to bring servers to their knees, without any lag in SSH or games, or interruption of mail or other services. We only noticed because our bulk transfers slowed to a crawl, as intended.
Learn more:
HTB: http://luxik.cdi.cz/~devik/qos/htb/ (the user guide has a good overview and pretty graphs)
HFSC: http://linux-ip.net/articles/hfsc.en/ (More pretty graphs and good explanation)
Linux Advanced Routing and Traffic Control list: http://lartc.org/ (The howto is out of date, but very enlightening)