Bad Behavior on the 'Net - Who Pays the Bandwidth Bill? 654
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?"
Charge on sent traffic. (Score:5, Interesting)
Alas, unless every ISP participated, this model wouldn't work well.
Simple policy (Score:5, Interesting)
Any massive bandwidth they log after that, is their responsibility. You notified them, and they did not listen.
After a few incidents like that, they will start to listen to your warning messages.
contract... (Score:3, Interesting)
Since DiffServ and other standards based solutions are ready to be implemented, perhaps you should consider talking to your most whiney clients about it?
Yes I know it doesn't apply to all clients, and not every provider has the extra router/switch cpu power to implement them on all links...
But wouldn't such a solution be a good way to keep the more demanding clients(increasing the value they get: bandwidth for the right traffic) and decreasing the tax hackers and Distributed DOS and misconfigured systems make them pay (for undesirable traffic). Maybe you should suggest this as a customer retention measure, for those clients where it makes business sense.
The place where I colo.... (Score:2, Interesting)
I was happy they cared and they where happy to have me care enough about them and me not to run M$.
To eat or not to eat (Score:4, Interesting)
Re:Simple policy (Score:5, Interesting)
This is a thorny issue. The real answer is that the twit whose server got owned and is spewing garbage out on the net should be responsible for paying. But enforcing that is going to be a problem.
OT: What makes up bandwidth costs? (Score:3, Interesting)
Can someone give me an idea of where the price for bandwidth ultimately comes from?
Throttle (Score:2, Interesting)
Re:In other words (Score:5, Interesting)
*/. did NOT warn the page
*The page in question NEVER receives the amount of traffic necessary to bring it down.
*Let's assume it happened on a Saturday, when they had minimal support
*The company can PROVE they lost revenue.
It Depends (Score:3, Interesting)
If you want to keep that customer, you do what it takes to keep the customer. Remember the golden rule, 1 bad customer experience gets passed onto 20 people. If you think that this customer is going to put with this, fine go ahead and charge them. If you don't you should suck it up. If they leave, not only will the money that you get from them goes to zero, but they will bad mouth you to enough other people that it does have a negative impact on you attempting to acquire more customers.
In other words, be a good guy, suck it up and the customer will trust you more the next time you attempt to raise their bill. Blow them off and the only that you might get from them is the finger.
Monitoring and Opting Out (Score:5, Interesting)
We adjusted our monitoring process to detect these spikes early and contact our ISP to deny traffic from the offending subnets. Luckily, our ISP was willing to do this, even though they still incurred traffic from inbound packets. Luckily, these attacks originated from a few subnets that could be isolated.
As a further kludge, we eventually disabled ICMP altogether on our routers, and lived without ping and traceroute.
Having a host on the net is a risky proposition. You pay for inbound and outbound traffic, regardless of the source, packet type, or quantity. DDoS attacks can not only prevent your server from being accessable, they could literally bankrupt you if you become a target and don't take preventative measures.
Hmm... One click bankruptcy. I wonder if anyone has tried to patent this yet...
Our ISP was technically capable of detecting and thwarting various attacks. Ultimately, the policy of monitoring and contacting an ISP when traffic exceeds a certain threshold seems like a workable solution for average co-locaters.
Given the architecture of the Internet, it's difficult to see how we could shift the burden to pay away from the server to the client. It seems like a problem remarkably similar to the problem of spam.
Re:analogous to water/electric company IMHO (Score:2, Interesting)
This would be another way to encourage people to patch and protect publicly available servers--which is in everyone's interest (cf. slammer).
Look at it historically (Score:5, Interesting)
Re:analogous to water/electric company IMHO (Score:5, Interesting)
Of course my small scale situation may not translate to a large business account.
Utility Billing.. (Score:3, Interesting)
Re:Charge on sent traffic. (Score:3, Interesting)
When I thought of getting a burstable line from Digex, their billing process was to bill my incoming/outgoing data rate based on my peak usage EXCLUDING the top 10% of our usage time. That way if there's a usage spike (or a SQL Slammer spike), then it would be considered an anomaly and wouldn't be billed for. That seems like a rather fair system for me, since there's no real way to distinguish wanted traffic from unwanted traffic and bill based on that.
Re:I say charge the customer (Score:5, Interesting)
For one thing, the packets go down the wire wether the service is running or not. Thousands of requests per second to a box that isn't running the service still has to respond and say "sorry, not running here". Even if it's a few bytes per, it adds up quickly.
Should a customer be charged for requests coming in for a service they don't offer? No, that's the point of the firewall (or packet filter really).
ISPs could have a new revenue stream by looking at this problem differently.
They can offer a firewall for a per-month fee and waive any bandwith increases as a result of DDOS attack or other work-checking that could be blocked by the firewall. An active firewall could proxy HTTP requests, also filtering out common IIS exploits.
User doesn't want the firewall? Fine, you're responsible for all charges.
This would at least give end users an option instead of what will border on collusion when all the AUP/TOSs change to read the same thing.
Fairer - sent or solicited - a modest proposal: (Score:5, Interesting)
Good idea but it doesn't quite go far enough.
You should be billed for the traffic you CAUSE or SOLICIT, and thus have control over. Much of internet traffic is things like web browsing, which invovles a small request soliciting a large reply. If you suck down 60 megabytes of web porn, MP3s, or ftp downloads, it's your bill. Similarly if you host a server, which accepts little requests and pours out data, it's your bill.
But if somebody starts sending you unsolicited packets, that's like somebody making nuisance calls or pages. (You will notice that pagers, at least, are generally NOT billed by the page. They tried that, and the customers rebelled because they had no way to block idiots with autodialers.)
So something with a little deeper visibility is in order. Here's a fair approach:
TCP: You get billed if you make, attempt to make, or accept, a connection. You don't get billed for attempted connections you refuse or that don't get completed (i.e. SYN and other DOS attacks).
UDP: You get billed for outgoing UDP packets. If the billing machine is sufficiently stateful, you might also be billed for incoming UDP packets that ARE replies to a recent outgoing UDP request using a well-known UDP request/reply protocol. (This would prevent cheating but still protect you against getting billed for both DOS attacks and forged-reply billing attacks.)
ICMP: All are free except outgoing EHCO REQUEST (ping), because they're a mandated part of the network overhead. (You don't want to bill inbound ECHO REPLIES to prevent billing for forged reply attacks. But you might bill ECHO REQUEST as if it went both inbound and outbound, to cover the expected ECHO REPLY without making the billing machine stateful about ping "connections".)
That should pretty much cover it. Customers would:
- be fairly billed for the bandwidth they used, caused to be used, or allowed to be used,
- not be billed for unsolicited "phone calls", DoS attacks, or mandated network overhed, and
- have a strong financial incentive to keep their system secured against crackers and malware (such as viruses and worms).
And installing a get-around-the-billing hack (like PPP-over-ECHOREPLY) would be a violation of terms-of-service and cause for disconnection - or changing the billing of that customer back to "all bandwidth co$t$" B-)
ITU rule on charging (Score:4, Interesting)
Big attacks should be reported to Homeland Security. [nipc.gov] (Really. Effective March 1, Homeland Security runs the National Infrastructure Protection Center. ISPs are going to be dealing with them on a regular basis.)
Just like in real life (Score:5, Interesting)
Suppose you live on a crosspoint of several countries. Your house happens to be located in a dangerous curve on the road. Also for some reason your house looks to some kiddies like it asks to be vandalized.
For these reasons you get a lot of breakin attempts, occasionally a truck crashes through your walls. All this is not only by people from your own country, but from neighbouring countries as well.
You install warning lights and other measures so cars and trucks don't come in crashing. You call the police when kiddies vandalize your home, but they says they can't do anything.
All this costs you a lot of money and headaches.
In real life there are several ways to defend yourself:
Now apply these principles to your hosting server.
Suppose your house is rented. Is the person renting you the house responsible for every breach? Did he warn you before you signed the contract? Is it his responsability to call you every time some vandals are passing on the road? Or some truck may crash into your home?
Of course your ISP can warn you for every threat that may be coming, but what if there's no warning time? Or he misses a small thing that happens to affect your server bigtime? Is the ISP really responsible?
Be careful out there...
Re:Simple policy (Score:5, Interesting)
If you are hosting business internet lines give the customers 2 options.
1. Wide open internet. Nothing is filtered on the ISP end, as it stands today, and the customer is 100% liable for ANY traffic circulating between the internet and the customer, solicited or not.
2. Abuse Managed Internet. Charge a fee to the customer per month, which get the customer:
- Any abuse, aka DOS attempts removed from the monthly bandwidth
- The ISP will filter abuse attempts before they occur, so if there is a code red floating around, allow a transparent proxy / firewall throw the packets away before it causes your customers harm.
The trade off for the customer is more assured price, and quality of service for the price of flexability and a nominal charge.
Hrm (Score:5, Interesting)
ISP A has customer X. ISP B has malicious user Y. Malicious user Y sends huge quantities of packets to user X.
The question seems to be, should ISP A eat the cost, or should customer X eat it? Why the hell are those the only two options?! It seems to me like ISP *B* should eat the cost, since the malicious packets were sent through their network in the first place. ISP B can attempt to recover their loss directly from malicious user Y.
The ISP *and* the customer are both victims in a DOS attack. Whoever runs the network which *initiated* the attack should be responsible.
Re:analogous to water/electric company IMHO (Score:4, Interesting)
spike insurance (Score:2, Interesting)
This might look like extortion, but you could work out ways it wouldn't. For example, you could offer 3 choices:
1) customers pays for all the bandwith as usual.
2) customer pays regular flat fee plus small addendum as insurance for major traffic spikes (hire a statistician to get this to work out just barely in ISP's favor over time, and be honest about the process)
3) customer pays regular flat monthly fee and gets shut down upon hitting bandwidth threshold. With permission from customer, site can be restored at regular cost for additional bandwidth.
I think if you were really honest about how you came up with the cost of the insurance, customers would like it. For a lot of people, it's easier to pay $100/month for 12 months ($1200), than it is to pay $80/month for 11 months plus $300 for one month ($1180). Just because you can plan ahead, even if it costs more.
Pay the ISP and sue the one who caused it like IRL (Score:2, Interesting)
You can then turn around and sue the person who caused the damage.
The ISP cannot decide in many cases if the extra bandwidth usage is legit or not, so has no business cutting your line.
Re:analogous to water/electric company IMHO (Score:3, Interesting)
1. If someone floods my house with water or punctures my pipe, they pay not me.
2. If the gas company has a leak and blows my house up they dont get to bill me for the gas (although famously gas companies have tried to do this to people!)
If you bill people for incoming traffic you have a problem, and its going to make a nasty mess when it hits, be it by losing all your customers, whatever.
If you bill people for outgoing traffic with bursting do your customers a favour, you've got traffic shaping so let them set maximum billing costs. The customer can relax a lot more if they know the "worst case bill" for each month and suffer nothing more than loss of burst when its exceeded.
You can even have sales phone them and try and sell them more burst bandwidth. All of a sudden your caring ISP wants to offer you some extra options instead of customers phoning the evil bastards at the ISP who scammed them, two perceptions for the same thing. The difference is the customer has the control so feels happy
This is the same whole reason that an ISP who shapes customers who exceed a bandwidth cap right down does better than one who goes around cutting people off. Given then 1/2 speed at 75% usage, and 28.8 at 100% and they are normally happier than getting the boot.
Whats to stop e-embezzelment? (Score:3, Interesting)
No law against this. It like me providing you with a doorbell service. If I want more money, I just keep pushing the button. If you were dumb enough to sign up for this then you'd better trust me.
Perhaps the backbone should eat the 'cost' (Score:3, Interesting)
However, if you think about it - the ISP wont be having to pay its provider more if it does "Above 1Mb/s on *this* pipe.. above
What if the ISP doesnt hit the utilisation required for it to be charged extra, but individual systems within its network get hit hard by a particular virus? (Slammer for example didn't pick IPs properly at random, so some IPs would be hit, others wouldn't)
In this situation, I think the ISP should let them off the fee. The ISP hasn't been charged any extra for the slammer traffic, so it should let the customer off the charge. It'll do wonders for loyalty if you can see your provider is fair and reasonable about things.
The other situation to consider is when an ISP does get billed by its backbone provider heavily for extreme and unsual utilisation.
Alright, hold that thought. Right at the top levels of backbone providers, there is no direct cost associated with using 80% or 10% of a backbone line. It simply is. It's at this stage I think, that they should possibly relieve their clients of bills that are easily attributed to big viruses that are doing the rounds. Granted, then what do you do about spam? Where do you draw the line as to what is 'unsolicted/extreme/garbage' traffic?
Another solution I've just thought of is to extend the period that an average is worked out over, so that over the year if you're under 1Mb/s, you don't get charged extra. It should even out massive, but short lived spikes from worms such as Slammer.
Yes, I know contracts are normally clear about traffic levels and bills that you will receive if you break them, but I do think it's unfair for a small site that has just gone colo to suddenly get a bill 10x its normal bill since the latest worm has been targetting its machine, primarily since there is no direct cost to the ISP, or the ISPs provider, that can be attributed to this extra traffic (as long as there is spare capacity!).
People should be accountable (Score:5, Interesting)
In addition, Making the people responsible for their personal worm/virus traffic would make folks would be more proactive about virus prevention and more cautious of which sites they visit. This IMHO is a Good Thing.
Another potential positive would be that people might start wondering "Why does my friend/relative who runs Linux never complain about viruses?" and "Gee with all these viruses that only affect microsoft products, maybe I should look elsewhere for my software needs."
At least in my state, you are responsible for your car's emissions. If your car is polluting above the state limit, regardless of the reason, it is your responsibility to fix it. They don't care what the reason is for your excessive emissions, whether it was rust, hungry chipmunks, incompetant redneck mechanics, or just a poorly built ford suv. And they have a system of mandatory repairs and/or fines in place to enforce this. This is a Good Thing.
Perspective from an ISP/hosting company owner... (Score:2, Interesting)
If a site hosted within our systems suddenly spikes because of slashdot or whatever, I will administratively throttle it down a bit to prevent it from consuming all available bandwidth. If it's caused by a vulnerability in our systems (all BSD-based), we will eat it, as we should.
If a co-lo'd customer, or someone paying for bandwdth, starts to spike we will examine the cause. ALL of my customers are required to go through a firewall managed by us. They do not have access to it. If a new virus comes out, it goes in the blacklist rule and those inbound connections are not allowed. We will also block certain outbound (all netbios ports by default, plus virus ports, and those which things like rootkits would use) connections unless explicitly requested by the customer - in that case, they are made to understand that they are using a port which is known to be related to security risks, and it's on them if they get hacked/infected and spike their usage.
We don't shut people off. And if it's a small overage I'll usually let it slide. However part of their contract includes an agreement by them to keep their systems virus free and patched to current security levels. If they triple their usage because they were lazy, they will pay. As a security engineer I simply cannot accept the "we didn't know" excuse - there are multitudes of notification email lists you can get on to find out if your systems are vulnerable. This also forces people to take a more proactive stance on security, and prevent these things from happening in the first place.
Been there, done that, got the t-shirt (Score:1, Interesting)
A) You can't stop it inbound packets, the packets travel across the ISPs link, you get charged for it period, and they barrage you machine with the full force of the network link (10 or 100 Mbs)
B) The attacks are coordinated, I have seen many many servers pound a single server into the ground, the result is the customer usually ends up cancelling and being down for 48 or more hours.
C) ISPs have a shitty business model, billing should ONLY occur for outbound bandwidth, inbound bandwidth on a server is usually minimal and should be built into the cost of the server
So, if you have this problem, and many people with dedicated servers WILL have it, get a T1, if you use that up, get another T1 and set up BGP, keep adding T1s until you are in the ballpark for one of the links to be a frac T3.
The deal you see from a dedicated host or colo facility really isn't a deal when you see the other side of the coin and pay coin for the convience.
Re:The customer always pays (Score:1, Interesting)
There are three possible targets: customers, shareholders, employees. Who foots the bill is a matter of determining how best to do it depending upon the business. Affecting any one of these three also tends to affect the others as well, so it becomes a balancing act.
If you stick it to the shareholders, they may start to sell out which means that the value of the company decreases, employees may get laid off and customers may get less product for their money.
If you raise customer prices, customers may go to competitors which means employees get laid off, and shareholder value decreases.
If you lay off employees, attitudes among employees get worse and quality suffers ultimately affecting customers and shareholder value.
There's never an easy answer.
The joys of running a web server over DSL (Score:3, Interesting)
Two days ago I put my personal web-site up. It's sitting on a linux box (Apache) behind my firewall, which only lets incoming connections initiated on port 80 through.
In two days I have had maybe 100 hack attempts. All using variations on "GET
But, WTF... they're using up MY bandwidth. Why can't ISPs take some responsibility for detecting script kiddies. There can be exactly no un-patched useless WinNT boxen out there. Why shouldn't Mr ScriptKiddy be asked to pay for the bandwidth?
In telephones (in the UK, at least), calling party pays. If someone is hammering my bandwidth malicously (or at least dumbly) why should they pay?
And why can't get an ISP that "traps" stupid requests, and reports them to the users ISP. Too many issues and that ISP is blocked.
Why not?
(I'm thinking about setting up a DDOS system on anybody that tries to 'hack' my server. Just for a laugh, obviously.)
Re:I say charge the customer (Score:1, Interesting)
Well, actually, in the case of Slammer, that's not quite correct. Slammer sent a UDP packet which is stateless and requires no response. Depending on the configuration of the network, it's a possible scenario that an ISP could log that traffic even if the server was turned off.
Re:analogous to water/electric company IMHO (Score:3, Interesting)
If you flood, you pay
If you get hacked and your machine used for flooding, you pay (afterall its your own fault your machine was insecure)
If you GET flooded, then you take it up with your isp and take action against the culprit.
Re:Blame the ISPs (Score:3, Interesting)
"Half the problem here is that we bill for bandwidth in the wrong way. By billing on traffic, we open ourselves to exactly this sort of problem - it would be like billing for water consumption based on pressure (rather than volume)."
This doesn't make sense to me. Pressure is like access... nothing flows until you make it flow. It is just the potential for flow. Volume of water flowing (think of it as molecules=packets) is analogous to packets flowing and is a much fairer way of charging for bandwidth since the person pays for what they used (exactly like they pay for the water they use).
"The reason ISPs bill per megabyte is so they can bill multiple customers for the same piece of infrastructure... and at the same time, over-subscribe that piece of infrastructure."
I think you have this backwards. When you charge for a connection ("access") then you can bill multiple customers because you can safely assume that not all of them will be utilizing their access fully. We had an upstream provider that had 19 PVCs on one T1 connection upstream... and was charging every one of its downstream customers for a T1! This is what is meant by "oversubscription". How, exactly, would you double bill for a measured amount of packets?
According to your theory the grocery store should only charge the first customer because then his "infrastructure" costs would be met.
"Strangely enough, paying a fixed fee based on the size of your connection is where the whole thing started. Paying per byte is a relatively recent (several years, but still recent) concept, thought up by greedy providers who realised they can charge many customers for something that is essentially free."
Bandwidth measurement was (and still is) more expensive to count and to bill than simple access. A simple connection is simple; you just provision the PVC and start billing. That's why everyone started out that way. Once the technology was in place (cheaply enough) to allow ISPs to measure bandwidth, then - and only then - could they charge for it.
I don't know how you can think that it's "free". Is your transportation free even though you've paid off your car? ISPs have to charge enough to pay their engineers, their billing people, their sales people, plus have enough to cover capital expenses for new equipment (which the customers will demand because their needs increase). Plus the ISP has to pay its own uplink charges for bandwidth (usually metered). And then, of course, there's the interest payments on the loans taken out to buy the original equipment. No, you're dead wrong. Bandwidth is not "essentially free".
"Take a look at the profit levels of some of the bigger providers in your country. Here in Australia, Telstra, Optus and Connect all report multi-million (and in many cases billion) dollar profits. Nobody can tell me that the core connectivity of the Internet isn't currently a profitable business."
I don't suppose the plethora of bankrupt US providers would convince you otherwise, either. The profit margin for an ISP is razor thin and getting thinner as providers drop prices in an attempt to gain customer base (and profitability). Even AOL is struggling. No ISP in the US is making billion dollar net profits.
I think your understanding of economics is as weak as your understanding of pressure and volume.
Allow customers to set an "incoming" quota (Score:3, Interesting)
If the users don't set a quota, then they are liable. If they do, then you are the insurance carrier. (I guess that it has to be an extra cost service.)
It is important to customers that they be able to predict the size of their connection bill. If they can't, this can cause a lot of trouble. But you could offer an insurance policy that basically says "You won't have to pay more than X amt. I'll bounce the excess if a spike happens." You might want to think carefully, though, about what your cost exposure would be, before you decide on the cost of the policy. (Even having an expensive policy, though, should be a reasonable answer to the current customer complaints.)
It's a slightly misleading question (Score:2, Interesting)
So the real question is "who should pay for each unexpected bandwidth consumption event - the person who owned the site that got hit, or all customers, indirectly?" If the answer is "the person who owns the site", then if an individual becomes the victim of malicious or unpreventable attack, they lose out financially. This could be seen to be unfair. If the answer is "all customers", then all customers lose out financially from the actions of a few customers who fail to manage their sites properly. So if I completely fail to patch my SQL server, get hit by Slammer, and claim that that's an malicious attack and not my financial responsibility, then every other customer pays for my laziness. That could be seen to be unfair. The (apparently) fairest answer is a combination of the two - if I'm the victim of an attack, I shouldn't have to pay for the increased bandwidth and the whole community bears the cost; but if I fail to take appropriate action to prevent an attack/surge/whatever, it's my problem and I should bear the cost. However, that answer means that the ISP has to define the criteria for what consitutes appropriate action, then police that. Which costs them a lot of money. Which the whole community pays for :-)
Disclaimers:
1) I don't work for an ISP
2) I don't even have a website
therefore
3) I probably don't know what I'm talking about :-)
Pinching The Customer (Score:2, Interesting)
I COMPLETELY disagree with the concept of public space and the user takes their risks. It doesn't cost me $70.00 (CDN) to walk in the park and I assume the risks of that action. I PAY $70 (CDN) for a certain level of bandwidth and service quality with very little risks.
Why should I pay for bandwidth that my network did not request. FOR EXAMPLE: on average I am billed for 300MB of traffic that my network or users never request. This calculation was done by reviewing OVERNIGHT usage logs (1AM - 7AM) which indicated approx. 9MB daily of unrequested traffic. This is traffic that is hitting my modem but not passing through my router so I can be sure its not being requested by my network.
While this unrequested traffic my seem small by many standards it is still unrequested traffic that is impacting my monthly bandwidth usage limit of 7GB or 12GB. I know some may think, hell its only 300MB but my point is I'm being limited by the total amount of traffic I can send and receive and if I do not request this traffic why should I pay for it.
That's like suggesting someone pay to watch the advertising on my TV because its in the same pipe as my television signal. Bullshit!
ISPs big and small need to grow up and start providing real service to their customers and STOP throwing their hands up, saying we only provide access! BULLSHIT! You provide access to a commodity and there is the VERY BIG difference. Ask AT&T!
And thats where M@'s at!
Re:analogous to water/electric company IMHO (Score:2, Interesting)
I agree wholeheartedly, however in the case of the internet, the technology doesn't allow us to see who is the "sender" and the "receiver" as such. Simply determining this based on the direction of traffic flow wouldn't be appropriate for the majority of protocols used on the internet.
One critical factor is detrmining who initiated the traffic flow. In the case of a an email message being transmitted, the sender has initiated the traffic and one would think, ideally, that the cost would be born by that party. In the case of a web page being transferred on the other hand, as the traffic was initiated by the party receiving the data, it would seem unfair to charge the "sender" for the transmission (obviously there are exceptions eg popups).
What this boils down to is that downloaders and uploaders should pay alike, but in many cases it is difficult for all parties involved (billing-wise) to tell which is which.
Assuming we were able to determine this information, spammers, crackers and their ilk would be transmitting at their own expense, and the cost of worms would only be significant to those who fail to correct vulnerabilities quickly, and whose systems continue to transmit the worm. People would be able to host services on their home broadband connections and only pay for traffic they actually initiated.
Such a system would be almost ideal, and the technology may one day allow it. However additoional problems arise at the interconnect points between large networks. There is validity to the claims in this thread that service providers manipulate traffic flows to their advantage.
Consider the case of a large ISP/Webhost, connected to three other very large networks. Network A bills the ISP only for traffic inbound to the ISPs network. Network B bills all traffic in both directions. Network C also bills traffic in both directions, but with a percentile rule.
The ISP/webhost knows that traffic flows roughly equally in both directions across the borders of its network. They also know that networks A, B & C maintain large interconnects, and that a significant proportion of remote users that access locally hosted material are customers of Network B.
In the interest of reducing traffic costs, the ISP decides to advertise all routes to its borders thorugh Network A, confident that remote users on networks B & C will be able to reach it via network A.
Unfortunately, Network B sees that it is being done out of the oppurtunity to bill the ISP for traffic, and staticly routes all trafic to the ISPs network through the link to the ISPs network. This has the effect of making all traffic from Network B to the ISP billable, and also makes the ISPs network unavailable to most of Network B's customers during outages on the link between Network B and the ISP. Network B is ultimately able to bill the ISP and its other customers for the same traffic.
My point here is that simply that the technology that is at work here does not easily fit with a black and white billing policy - there are many complexities. In some places it is legislation that you cannot bill people for recieving phone calls. Hopefully one day it will be technically possible to enact similar policies in relation to the internet. Presently it is not.
Re:Internet = Public space? LOL! (Score:3, Interesting)
The internet is not a public space all the time (irc and message boards would be public spaces), but if you allow yourself to be on the internet, you are allowing others to access your space. If you put a computer directly on the internet, it is not your ISPs job to secure that for you. It is YOUR job to maintain the integrity of your own machine. if someone hacks your machine because you failed to close a port, that is your fault. trying to blame the ISP is not going to get you anywhere.
My AT&T (now comcast) cable modem specifically has a clause in the terms of service that say something like, "your connection is your responsibility. if you allow others to use it and they do something illegal, since it is your connection, that means you did something illegal."
Re:Internet = Public space? LOL! (Score:2, Interesting)
It's not a utility, it's a lease... (Score:2, Interesting)
Every contract I've ever dealt with for a colo involves peak usage billing -- 95% percentile of average traffic is typical. Of course this is usually for a half rack, full rack, or cage -- not a single box. But that's been the deal at huge data centers (e.g. Exodus, RIP) and local ISPs(BNSI, my local colo provider).
They provide space, power, and bandwidth. I pay a flat rate for the space and power and a specified rate for the bandwidth -- my BNSI colo takes the higher of inbound or outbound 95% for the monthly charge.
I act as a good tenant -- I keep my boxes (even the windows ones) patched. I have a solid firewall. I put rate limiters on sites that need them. I monitor traffic. Everything a decent sysadmin does.
They act as a good landlord -- they keep things running, they notify me of problems, and they monitor their network well enough that I get a call when they notice (netsaint) my bandwidth spike, like when I upload 9 GB of data files for a client one evening.
We both act like responsible adults and everything is fine. Slammer's an excellent example -- one client at their site had an unpatched sql server -- sort of like letting the grass get 2 feet high in front of your rental house. The ISP cut them off, just like the landlord can step in and cut your grass if you're not maintaining it. Clients of mine at another site lost 6 hours of uptime because the ISP responded poorly to someone's unpatched box. Two days later, that ISP was hit by slammer on ANOTHER box. Not a good landlord -- they're not taking care of the properties they own.
A lot of the billing ideas in this discussion are intellectually sound but hard to implement in practivce -- I mean tracking each packet and throwing it in a particular category for billing? If the ISP is doing that, the costs are going to be $$$$ and those will be passed on. I don't want to pay that because I don't need it -- and the ISP shouldn't raise it's prices to solve a problem that's not really their problem.
So an incoming spike comes in -- I want a phone call/page where they ask me if that's OK. I'll even pay for the service. Whether it's a good (more business) or bad (hacker traffic) spike I need to react to it. I've got systems in place and they have systems in place. We're both good citizens. We both benefit. Max benefit for minimum work. I don't need to be charged properly for each packet -- I just need to be charged properly for my usage trends.
So write it into your contract -- don't use SQL Server, ask the ISP to block it outside your switch. Or keep the records yourself and contract with them to refund the bandwidth if you get excessive traffic you didn't and can't use. It's like saying "How about if I cut the grass and paint this rental house and you reimburse me the expenses if I do a professional job". Win/win for everyone. Clear terms. If I do a crappy painting job, I shouldn't get reimbursed, just like if I do a crappy record keeping job about packet traffic on the server I shouldn't get a refund.
Hacker attacks, etc, is part of the cost of doing biz on the Internet. You open a shop in real life, you deal with shoplifting -- you build it into your costs, either through higher security or anticipated "breakage" or whatever. I charge my clients more for SQL Server than MySQL not only because the license is much more expensive, but because the risks are higher from a security perspective. They'll be some breakage -- plenty of extra TCP 1433 on my firewall -- but it's built into the cost. As is the time I spend upgrading Windows 2000 and SQL Server. When you lease a house, you might call this normal wear and tear.
So it's a lease. Find a good landlord. Be a good tenant. Anticipate wear and tear. Build that into your budget.