3 ms·

Do usage limitations actually affect the bottom line vs throttling? Maybe I'm wrong, but I imagine it doesn't cost much more to run a network that is 80% satur

Do usage limitations actually affect the bottom line vs throttling? Maybe I'm wrong, but I imagine it doesn't cost much more to run a network that is 80% saturated vs a network that is 5% saturated? Basically, why can't they just fairly throttle high usage users when utilization ramps up, and then unthrottle them when usage lowers? Edit: I'm not talking about them reneging on their guarantees, which they've already done by asking the user to cut their usage.

worldofmatthew 4y ago
They claim the bandwidth is guaranteed on servers costing less than 50 euros a month. They appear to have simply got caught out by people actually using what they paid for.
- googlryas 4y ago
  Sure, I just mean regardless of their guarantees, why network operators don't seem to operate like this, instead they look at total transfer over a period of time, and cut you off or charge more, even if the bytes you're sending were essentially free and didn't affect other users.
dvfjsdhgfv 4y ago
And this would be fair to your customers how? Where you draw the line who is who? How would you feel if your services started to be less responsive for no apparent reason, even though you paid for them and did nothing wrong?
- foobiekr 4y ago
  Imagine the AWS EBS bursting/credits applied to networking. It would be awful. (It's also awful with EBS)
  - banana_giraffe 4y ago
    Many do, https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst... : > Typically, instances with 16 vCPUs or fewer (size 4xlarge and smaller) are documented as having "up to" a specified bandwidth; for example, "up to 10 Gbps". These instances have a baseline bandwidth. To meet additional demand, they can use a network I/O credit mechanism to burst beyond their baseline bandwidth. Instances can use burst bandwidth for a limited time, typically from 5 to 60 minutes, depending on the instance size.
toast0 4y ago
Traffic prioritization is expensive, but traffic accounting isn't. It's a lot less work to bill on usage (or cancel accounts for high usage) than to throttle high usage users to keep the network responsive for all users. The operators are likely paying for usage as well on their paid connections, or indirectly in that as connections fill up, they need faster or more ports and that comes at a cost. It's one thing if your peak traffic comes at their off peak times, but it's more typical to have peaks around the same time as everyone else.
- deleted 4y ago
  [deleted]
foobiekr 4y ago
The traditional solution to this problem is to sell a fractional circuit with bursting and average billing for overage to let the economics work things out. It actually is quite a bit harder to run a network _well_ at 80% than at, say, 60% because you have to deal with reboots/etc. in your network as well as routing issues if your peering changes and the excess capacity hides a world of sins. Lots of issues.

worldofmatthew 4y ago

They claim the bandwidth is guaranteed on servers costing less than 50 euros a month. They appear to have simply got caught out by people actually using what they paid for.

googlryas 4y ago
Sure, I just mean regardless of their guarantees, why network operators don't seem to operate like this, instead they look at total transfer over a period of time, and cut you off or charge more, even if the bytes you're sending were essentially free and didn't affect other users.

dvfjsdhgfv 4y ago

And this would be fair to your customers how? Where you draw the line who is who? How would you feel if your services started to be less responsive for no apparent reason, even though you paid for them and did nothing wrong?

foobiekr 4y ago
Imagine the AWS EBS bursting/credits applied to networking. It would be awful. (It's also awful with EBS)
- banana_giraffe 4y ago
  Many do, https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst... : > Typically, instances with 16 vCPUs or fewer (size 4xlarge and smaller) are documented as having "up to" a specified bandwidth; for example, "up to 10 Gbps". These instances have a baseline bandwidth. To meet additional demand, they can use a network I/O credit mechanism to burst beyond their baseline bandwidth. Instances can use burst bandwidth for a limited time, typically from 5 to 60 minutes, depending on the instance size.

toast0 4y ago

Traffic prioritization is expensive, but traffic accounting isn't. It's a lot less work to bill on usage (or cancel accounts for high usage) than to throttle high usage users to keep the network responsive for all users. The operators are likely paying for usage as well on their paid connections, or indirectly in that as connections fill up, they need faster or more ports and that comes at a cost. It's one thing if your peak traffic comes at their off peak times, but it's more typical to have peaks around the same time as everyone else.

deleted 4y ago
[deleted]

foobiekr 4y ago

The traditional solution to this problem is to sell a fractional circuit with bursting and average billing for overage to let the economics work things out. It actually is quite a bit harder to run a network _well_ at 80% than at, say, 60% because you have to deal with reboots/etc. in your network as well as routing issues if your peering changes and the excess capacity hides a world of sins. Lots of issues.