Slashdot Mirror
Ask Slashdot: Holding ISPs Accountable For Contracted DSL Bandwidth
mcleland writes "I'm not getting the bandwidth I paid for from my DSL connection. My '3mbps' fluctuates between about 2.7 during the day down to 0.1 or 0.2 in the evening according to speedtest.net. Let's assume DSL is the only viable option for broadband at my house and I can't really move right now (rural area, on north face of the mountain, no cable service, very poor cell coverage). This was discussed 6 years ago, but I'd like to see if there are any current thoughts on whether I'm just stuck or if there is some way to make the ISP hold up its end."
Get a lawyer. But, of course, the lawyer will be prohibitively expensive.
So realistically, no, there's nothing you can do short of terminating service.
I don't respond to AC's.
Does what you signed guarantee you a certain bandwidth, or is is an "up to x" sort of thing? I strongly suspect the latter. It's unlikely they're going to put another DSLAM (or increased backhaul) in because you complain, it's cheaper for them to lose you as a customer.
"National Security is the chief cause of national insecurity." - Celine's First Law
If you did, then "up to" means anything in between. You'd be getting exactly what you're paying for as part of the "up to" modifier.
this is my sig
You are only "guaranteed" what you are getting. However, I have been in that boat, and there was a physical problem. Just call your provider, explaining what is happening. If they have 24/7 support, wait until it starts happening, then call them -- so when they test it, they will see the problem.
Unfortunately, for me it took three different calls. The first call the technician came out and just swapped out some hardware. Elapsed time for him: Maybe half an hour. The second time they checked the wires from the house to the modem, and gave me different hardware ("that other one has problems with some old wiring").
Finally, with the third guy to come out, he traced it to some intermittent problem with wires. He swapped pairs from the house to the box (or the box to the DSLAM, can't remember exactly), and from then on my downloads quickly went up near the maximum and stayed there.
If you have already called the ISP and you got one of the responses above, you can always call back and complain again. They do seem to track that you called before, and will try something different. I was with BellSouth / ATT, so your mileage may vary. (I keep using past tense; I upgraded to U-Verse when it became available, and the speeds are great).
If complaining directly to them doesn't work, you might try griping about them on Twitter. My mother-in-law was able to get Comcast to make good on a bad deal that way.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Not obnoxious, but keep calling each time you have the problem. Eventually they'll be able to track it down. If there's no problem and that is just "works as expected" they'll eventually tell you that too. In that case, maybe look at a new provider.
I had intermittent droupouts with my cable, which they always seemed to have trouble seeing on their end. Finally after a number of calls a technician was dispatched who found errors on the line. He put in the appropriate ticket and said "Call me directly in a week if it isn't fixed." It wasn't, I called he came back, tested and found errors again, and went back to the ticket. It got fixed.
It is possible that your DSLAM just has a tiny line to it and lots of people and is getting overloaded, but I find it at least equally likely there is a problem. However you have to make them aware of it, and you have to keep calling when there is a problem. Remember two things:
1) You are dealing with low level call center people who don't know what the fuck is happening. Their troubleshooting ability is limited, and who are discouraged from escalating things if there isn't a problem. Hence the need to get multiple data points with multiple calls.
2) Most people are morons and the problem is firmly on their end, so the ISP is inclined to disbelieve you from the beginning, hence the need to work at convincing them through multiple calls and documentation.
I work for an ISP. I've been a lowly tech support agent all the way up to NOC admin to my current position as a DB Admin. I know the ins and outs of ISPs infrastructure, why things are the way they are as well as am now involved with the lawyers due to projects I'm involved in, so I've gotten a heavy dose of the way policy is written and why.
First let me say, I don't want to defend your ISP, they are most assuredly one of my employers competitors. So yes, they suck, switch to us... but I wont tell you who my employer is... so whatever. The point being, I'm not trying to defend the industry here, I'm probably one of the biggest advocates for what your complaining about at my company and I'm not shy to bring it up with executives. But if you had a better understanding of the situation it might help you improve your situation and possibly relive some of your anger.
US telecommunications companies have been task with bringing broadband to rural areas by both the FCC and the President himself. They are under constant pressure to increase broadband availability to customers. Just a few years ago it was well under 50% of people had access to broadband. Now it's well over 90%. Recently the broadband stimulus package basically paid ISPs to put in even more rural broadband. For an understanding of how much it cost I think they invested around 8 BILLION dollars and that raised the percentage of the public capable of getting broadband by about 2% to 3% The cost is enormous.
Now, you may think that's great... and it is. But there is a problem with that. In your case you live on the side of a mountain. I would love to live there myself, you probably don't have a lot of neighbors and having broadband out there is a great thing. But networks are called networks for a reason. You'd at the end of a loop... that loop leads back to a DSA along with all of your neighbors, and then that DSA has a trunk that leads back to the CO along with all the other DSAs in your area. So what's the problem? Distance. Depending on the service you have, there is a limited distance that you can be from that DSA to actually get any service at all. This distance also limits the number of people that DSA can serve because their homes must be within that distance to get service. In areas like you describe, I've seen DSA's serve as few as 10 homes. When you're dealing with a phone line that's not a big deal. Strait dialtone fits on a relatively cheap card, and when trunking back to the CO uses a fixed, almost unnoticeable amount of bandwidth. Then you have the local customers come in and want internet. The ISP says no. Then the local government gets involved and DEMANDS internet... the ISP still says no. I've even seen local governments file (and lose) lawsuits trying to force the ISP into these situations. Then the Feds come and offer to pay for the DSL cards and the new truck... well ok... if you're going to pay for it.
Now you have a DSA with 10 customers on it, 5 wanted 3MB service, the feds paid to have 2 T1 lines installed. That will work, and they likely wont have any bandwidth problems. Fast forward 3 years. You now have 10 customers on the DSA, they ALL have 5MB service and ALL have netflix accounts. Hence the situation you are in. The customers demand the ISP upgrade. Those 10 customers combined are paying about $350/month total. To add more trunks to the DSA will cost $300k. It's not hard to do the math there... it's not going to happen. So then they go to the local government and ask them to complain again... the local government says "You have internet, what are you complaining about?" and the feds? They got their 95%+ served number for the next election, they don't care about you.
Your only hope is your ISP. Period. I absolutely guarantee your service agreement was worded in such a way that your speed is not guaranteed. It probably says something like "Up to 3MB of data!" etc... What you can do is get a local technician out there on a service call... talk to him about your DSA. He'll likely tell you. How many other
I too used to work for Speakeasy, roughly 1.5 years ago before they were bought out. If your connection drops down to 0.1 or 0.2 at night then I would call your ISP when you're having the issue and request that they run a loop length test (aka plugged/unplugged test. This is the test where they have you unplug your modem for a couple of minutes, then plug it back in but with the power unplugged on the modem). Have them compare the results to when you first signed up for service. Theoretically they should know what to do from here, based on the results of the test, but if they don't then I would ask them what the results were and whether it's reporting any issues like metallic noise on the line, tip to ring, tip to ground, etc. I'd also ask them if they've installed any bridgetaps on the line, and if so, if they can remove them as this can impact service. If they don't find an issue on the line than I would ask them if their backhaul is currently over-saturated, and if it is, to be switched to another backhaul. They can often view this information by logging into Cacti or some other bandwidth monitoring program they use to see the current usage. Anywho, I glanced at this article and this guy does a pretty good job at explaining how DSL works and what some of the common issues are: http://www.techpowerup.com/forums/showthread.php?t=113143 Hope this helps!
I couldn't think of a good conventional way, so obviously the answer was a Kickstarter project. Here's the gist.
Open a call center in India tasked as customer support -support. For $60 yearly or $40 for 6 months you can subscribe. You call or e-mail with an issue with service with a vendor, give them the appropriate vendor support number and your details as needed (you've paid, so they keep your personal information secure). You even have the option to setup a profile where all this is available to the service, speeding up your time logging the ticket (vendor names / numbers / account numbers).
THEY (India call center techs) call your vendor to handle the complaint process on your behalf. They handle the time waiting on hold, arguing, negotiating, demanding, etc. They could even call you back to conference you in as necessary (authorizing them to speak on your behalf, etc.). They will handle all of the uncomfortable discussions, demanding to be escalated to a manager, getting credits to your account, everything.
In many cases, the business model would even save money because the calls would be local!!!
Further, they could e-mail you links to recordings of the calls for your approval later. "Calls may be monitored or recorded for quality assurance." YOU BET!
For particularly difficult situations, like a vendor with a horrible cancellation policy, captive market, or just crappy service, they can call up to 4 times daily on your behalf, brow-beating the vendor's support infrastructure. For $10 extra, we will "call bomb" them with a minimum of 10 calls a day for a week.
You're absolutely right.
The only time you're going to see otherwise is if you have a commercial service with reliability spelled out in the contract. The whole CDR thing is nice. I pay for 500 Mb/s, they don't provide 500 Mb/s, I can bitch and get reimbursement for time that it isn't available. They'll jump through hoops to resolve it or lose some serious revenue.
One residential customer, one of many, with "best effort" spelled out in the contract, they don't care much if the contract is lost. More importantly, there's usually a binding contract for a period, which they did not violate. So a month into the contract, they aren't servicing as expected, you're SOL. You still owe the term of the contract or the penalty described in the contract for early termination.
The only way they care is if there is an embarrassment. Blog it, talk about it, make lots and lots and lots of noise. Then they might just do something. Not necessarily though. They may also sue.
The best choice is probably to consider other options. The range with wifi, using narrow beam high gain antennas and amplifiers is pretty good. Then he just has to figure out how to get high enough to get line of sight to somewhere that he can get service. It's not rocket science, but it does take a bit of science. :)
There are FCC restrictions to consider. I won't give further advice since I'm not an expert, and haven't had to do it lately. I'll just say that I've had good luck going miles with easily available consumer grade gear, and a strong signal at both ends. The hardest part was making sure I got the right connectors for the devices I already had.
Here, here are a couple hints. :)
Serious? Seriousness is well above my pay grade.
I have yet to see a DSL provider that does not state in very small print that the connection is "burst" or "variable" or "up to".
Burst is actually kind of silly. It really screws with data rate prediction required to get smooth performance in multi-player games. So, you start playing, the game figures out the rates, everything's smooth, then the burst is over, you lag all to hell, as the game has to renegotiate the data rate. For downloads, no big deal, but for real time stuff like games or voice/video chat this is a problem... It's not that you connection is too slow after the throttle either, after a while you'll get smoother connection -- It's that initial period of "increased" performance that's screwing up the rate guesstimation.
OK, so here's the silly thing: If you have "bursting", start a D/L of a largeish file. Then, watch the data rate drop after a little while. Now, hit the pause button on the download. Wait a sec, then resume it. Tada! You can burst the whole D/L by re-establishing the HTTP connection -- Not that the pipes have changed at all, just that they throttle on a per connection basis. (How else would you do "bursting"?)
So, two things:
0. Use a Download Accelerator. I use the Firefox plugin: DownThemAll. Acceleration works by opening multiple connections to the source at different parts of the file -- per connection throttle? Increase connections until max bandwith is reached, heh. If one part of the file gets done before the onthers, it splits a remaining segment and starts a new connection; That actually boosts DL speed even more. It's too bad DTA doesn't have an option to open N connections each only S size chunks, and roll across the file... Guys? There's a viable plugin idea if you need one.
1. My new game client / server code has a "rolling" connection system to bypass time based throttling (bursting). It's all about the port numbers -- that's how they identify the connection. In my games I use UDP, but it falls back to TCP; Point is: this also works on TCP. What I do is open a new connection every once in a while, and send some data across it while the current connection is open (It's just port number changing in UDP). I track the speeds and latency of each connection (port number), and detect the timer duration at which the throttling happens by tracking data rates, then I set the connection roll over rate to be less than that. So, on non bursting lines, rolling rarely happens. I can also have more than just two ports open -- I can max my neighbor's 10Mbps bursting DSL line with just 6 concurrent rolling connections. Note: The server port doesn't have to change, seems that most per connection throttling is based on client port number.
It's weird, but shorter connections seem to cope with buffer bloat a bit too; Not sure why...You'd think the buffers were connection independent? Tuning the data rates helps combat BB lag even more though.
I'd write a RFC for this maximal bandwidth optimization technique, but let's just keep it between us geeks, OK?
P.S. My game server defaults to port 80, and displays a simple TCP / HTTP / HTML page about the current game in progress and where to D/L the game if you hit it with a browser. If you hit it with the game client, then the client's HTTP header tells the server to go into game protocol mode. Note: it's not a full HTTP 1.1 stack, just canned response with inserted real time stats, to reduce attack surface while giving the server a bit of info for HTML browsers & apps. Yeah, that's kind of weird eh? Except when you consider that to a deep packet inspection my game protocol initially looks like a "high priority" TCP/HTML query... heh.