Given that:
- We are only talking about INBOUND traffic.
- This is a hosting situation.
Full-Server hosting:
The ISP is measuring traffic going to your server. Even if you configure a filter in the IP stack of your operating system to drop traffic that you do not wish to 'pay' for, your ISP has no idea how clever you have been. You just drop the packets and they charge you for traffic 'delivered' to your node. There is no mechanism to tell them that you did not accept and therefore do not wish to pay for a packet.
Partial-Server hosting:
All the above applies, plus you probably can't even configure the IP stack.
Site hosting:
Everything from both preceding scenarios plus, you are dependant on the ISP to apply the proper patches. You get 'owned', it may be their fault, not yours.
'So' you say?
- Hosting customers are unable to control incoming bandwidth.
- No matter how diligent you are in patching, you still get every packet addressed to your IP. Even if your OS discards the packet, it still was delivered to your machine and you still 'used' that available bandwidth.
Summarily:
You can't control your incoming bandwidth in an hosting environment. How can it be appropriate to do a metered billing based on this factor?
I propose something like this:
Bill for outgoing bandwidth rather than incoming bandwidth. Outgoing bandwidth can be controlled.
If you must bill for incoming bandwidth, generate the amount with a small percentage of outgoing bandwidth. Since this is a server, its outgoing packets will generally be larger than the incoming packets. (Ex: HTTP request from client, VS. HTTP response from client. Another Ex: data packet from server and TCP ACK from client.) This is the amount of incoming traffic that is 'controllable' by the customer of the ISP.
Other incoming traffic like port scans and virus attack traffic is not within the control of a hosted customer, and it does not seem right to bill for it.
Beyond this, I imagine that telephone companies already have an established approach for just this situation. Toll-free telephone lines present the same opportunity for abuse outside the control of the customer. Anyone know how this would work in that scenario? It would be good precedent for the eventual real-world solution for this one.
Slashdot Mirror
Given that: - We are only talking about INBOUND traffic. - This is a hosting situation. Full-Server hosting: The ISP is measuring traffic going to your server. Even if you configure a filter in the IP stack of your operating system to drop traffic that you do not wish to 'pay' for, your ISP has no idea how clever you have been. You just drop the packets and they charge you for traffic 'delivered' to your node. There is no mechanism to tell them that you did not accept and therefore do not wish to pay for a packet. Partial-Server hosting: All the above applies, plus you probably can't even configure the IP stack. Site hosting: Everything from both preceding scenarios plus, you are dependant on the ISP to apply the proper patches. You get 'owned', it may be their fault, not yours. 'So' you say? - Hosting customers are unable to control incoming bandwidth. - No matter how diligent you are in patching, you still get every packet addressed to your IP. Even if your OS discards the packet, it still was delivered to your machine and you still 'used' that available bandwidth. Summarily: You can't control your incoming bandwidth in an hosting environment. How can it be appropriate to do a metered billing based on this factor? I propose something like this: Bill for outgoing bandwidth rather than incoming bandwidth. Outgoing bandwidth can be controlled. If you must bill for incoming bandwidth, generate the amount with a small percentage of outgoing bandwidth. Since this is a server, its outgoing packets will generally be larger than the incoming packets. (Ex: HTTP request from client, VS. HTTP response from client. Another Ex: data packet from server and TCP ACK from client.) This is the amount of incoming traffic that is 'controllable' by the customer of the ISP. Other incoming traffic like port scans and virus attack traffic is not within the control of a hosted customer, and it does not seem right to bill for it. Beyond this, I imagine that telephone companies already have an established approach for just this situation. Toll-free telephone lines present the same opportunity for abuse outside the control of the customer. Anyone know how this would work in that scenario? It would be good precedent for the eventual real-world solution for this one.