Slashdot Mirror


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?"

2 of 595 comments (clear)

  1. Act of God or Act of Man by rivendahl · · Score: 1, Redundant

    Perhaps ISP's can include an Act of Man clause similar to an Act of God. When tragedy strikes and service(s) are down it's expected that the ISP will do everything it can to rememdy the situation. The ISP is not responsible for the customers portion of the problem however. Therefore, if an Act of Man (mailicous code) causes unecessary spikes for incoming traffic the ISp is responsible for stopping it on their networks as best possible and alerting the customers that unless they do something about it they will be charged. "Doing something about it" includes maintaining logs that can be used to prove the customer did NOT incur those spikes and therefore will NOT be responsible for the bill. This can be handed upward as well. For example, if Joe Customer uses Public Internet Access (PIA) as an ISP and PIA uses Qwest, SWB, AT&T, UUNET, or some other backbone provider ultimately the backbone provider eats the costs. This is unfortunate but like an Act of God no ones true responsibility. If the backbone provider has enough evidence to point at a person or group for the malicious code causing serious downtimes and outages then by all means, customers support your backbone provider in court and pay some of the bill to help further ensure that malicious coders will be prosecuted. As for me I'd hate to eat those costs but if I signed as SLA that I didn't like it's partially my fault.

    Rivendahl

    --
    ... there is nothing that has not already been thought ...
  2. SQL Slammer example by doormat · · Score: 0, Redundant

    First, the client has no control over the virus going around, giving them craploads of incoming data. The ISP ought to filter port 1341 (or whatever it was), and then have customers notify them if they need that port opened up. I figure you prolly dont need MS SQL outside of your internal network, so blocking the port at the ISP's level not only sends that data to /dev/null, as well as making the customer more secure.

    --
    The Doormat

    If you're not outraged, then you're not paying attention.