Bad Behavior on the 'Net - Who Pays the Bandwidth Bill?

rakolam asks: "I am involved with network management in the hosting department of a fairly large ISP. Constantly we have customers who dispute inbound bandwidth spikes and demand service credits on their burstable connections. Events such as the Slammer Virus literally have everyone knocking on their salesperson's door at the end of the billing cycle. My position is that the internet is a public space, and by placing themselves in that space, one has to realize the consequences (and the implications of burstable billing). I'd like Slashdot's perspective on this. Should ISP's ultimately eat the costs of malicious behavior? Is the customer ultimately responsible for the bandwidth they've generated, regardless if it's desired or not? Is this a new frontier for insurance companies?"

Comments

Re:Users just won't pay

[Gaijin42]

Thats because they pass that cost on to the vendor, for not validating enough information about who the purchaser was.

The CC company doesn't eat that. The vendor does for accepting the stolen card

Re:analogous to water/electric company IMHO

[gmack]

There are several Apache mods that will either limit total useage or shut off files on the end of large spikes.

The original question though is what should the ISP have done. IMO they should have firewalled access to the affected ports and then split the cost.

Re:analogous to water/electric company IMHO

[-Surak-]

Presumably this refers to hosted server connections, rather than a simple virtual web server account. For this sort of connection, I would want a true Internet connection, instead of some firewalled lan port. I would be very upset if the ISP did ANY filtering on my connection without my specific request or knowledge. It's none of the ISP's business what I do with my end of the network cable (aside from spam policies) - they don't need to know if I'm running a web server, SQL server, or some custom game server that happens to use UDP/1443.

Most colo providers I'm familiar with bill on 95th percentile bandwidth, which means that they drop the top 5% of samples (typically 5-minute average) and bill you for the bandwidth of the highest remaining sample. This means that you can absorb short-term heavy bandwidth spikes without being charged, up to about a day and a half worth of time per month.

In any case, the ISP should have no way of knowing WHAT traffic creates the bandwidth spike, unless I specifically request that they monitor my port. Of course, smart ISPs will exploit these incidents by offering firewalling services as a value-add, even if it's just stateless filtering at the router, as a way for customers to "insure against unexpected traffic spikes from virus/worm activity".

Of course, if I was paying for virtual web service, rather than a server colo and bandwidth fee, I should not be charged for non-web traffic, and I doubt any ISP would have the balls to do so.

Re:analogous to water/electric company IMHO

[dhogaza]

The City of Portland Water Bureau will forgive excess water bills due to undetected leaks or the like if you show that you've fixed the problem. Often leaks aren't detectable and a large water bill is the first clue the homeowner sees (western Oregon is very wet, water water everywhere)

How it works here

[ziegast]

I currently work for an ISP that offers shared and dedicated web services. The Terms of Service that the customer signs are pretty explicit about their being responsible for bandwidth usage.

A few notes about charging for bandwidth:

• As a hosting provider, we get charged for traffic in the greater of two directions - outbound. We don't normally charge customers for inbound bandwidth.
  
  
• We rate limit traffic from all servers to 10Mbps as a precaution to protect ourselves. Being a relatively small provider, it is VERY rare that we or a customer of ours runs a server that generates more than 1-2 MBps of traffic. Everyone has a 10/100 port though, so the potential for a customer (or a customer's hacked machine) to do damage is possible. If someone wants the rate limit removed, we warn them again that they are responsible for their traffic.
  
  
• We offer rate limiting to our customers if they are afraid about bandwidth costs. This might normally be a 1.5x the rate they're normally budgeting each month. Many customers find that rate limiting makes their site too slow, but riding a bike with training wheels is slow too (but you're less likely to fall down).
  
  
• We charge by GigaBytes per mo. It's easy to track in web logs and packet counters and customers can write scripts to monitor how much they've used during the month and take appropriate steps toward teh end of the month. This amounts to our charging for average (50th percentile) pricing. We charge enough so that even if they spiked at twice their average, we wouldn't lose money on our bandwidth costs. On average, though, we make money.
  
  
• If a customer doesn't pay, we shut them off and can take them to small claims court based on the TOS agreement.
  

These are some of the steps we use to protect ourselves and our customers. Your milage may vary.

(We use packeteer for rate limiting, but I keep eyeballing OpenBSD/AltQ/PF for both rate limiting and firewalling for our customers).