dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
3223
JMJimmy
join:2008-07-23

JMJimmy to henry128

Member

to henry128

Re: ATTN TSI, Please raise the cap to 400GB for higher speed tiers

We're talking apples and oranges. Read the example I gave... in context of TSI, lets say they have 300k users and an aggregate peak capacity use of 50% and they go with a 20% buffer, and for ease of understanding every single one of those users sets their speed to 10Mbps during peak times. TSI would buy 1.8Tbps from the vendor at $5,000/Gbps (not actual market rate atm). They'd spend $9mil/m on capacity and take in $15mil/m charging a rate of $5/Mbps.
JMJimmy

JMJimmy to henry128

Member

to henry128
said by henry128:

"Congestion" is exactly this, where user throughput is reduced because demand exceeds supply. In the worst case where everyone is using their maximum throughput, the "potential damage" is no worse than what they've oversold. And this only occurs only at the instants when it's needed, not pre-emptively as you're suggesting.

Don't worry about a "single bad day" wiping out a company. They know how much they're willing to spend and the ISP will carefully balance congestion vs. annoying users vs. expenses.

That's true, they have a lot of potential damage though - if they don't buy capacity to meet demand they run the risk of alienating customers - especially if it's an event which has some sort of social impact (ie: critical mass participating so if you miss it you're on the outside socially... things like World Cup/Stanley Cup/etc. those sorts of things will cause people to switch when they find that another group didn't have a problem while with another ISP)
henry128
join:2010-09-03
Hillsboro, OR

henry128 to JMJimmy

Member

to JMJimmy
So that would lead to $30/mo for 10 Mbps in costs only. But you're off by a factor of 2-4, so that's $60-120/mo for 10 Mbps before other costs and profit. That's not competitive pricing.

You've chosen an oversell ratio of 1.6. Since it's oversold, you still run the risk of congestion. You choose the oversell ratio to balance the risk of congestion vs. utilization. The actual oversell ratios are closer to 10-20x, so you're asking your customers to pay ~10x more than they need to, to leave the pipe ~10% utilized during the peak period, just to avoid once-a-year events that lead to congestion. Yes, there should always be a safety margin in the oversell ratio, but because the gap between worst-case and average is so big, it's impractical to size the oversell ratio based on worst-case demand.

And if you accept that the oversell ratios should be based mostly on average throughput rather than worst-case throughput, then the impact on the ISP's cost is better approximated by usage than user-capacity, since average throughput depends on the duration you're downloading, not just the speed. 1 Mbps for 2 seconds is a much lower impact than 1 Mbps for 4 hours.
henry128

henry128

Member

Hm... I'd like to revise my estimate of the oversell ratio upwards to 30x or so.

If I take Teksavvy's retail price (for the 300 GB plans), subtract the per-end-user tariff, then divide what's left over by the CBB tariff, that provides a lower bound for the oversell ratio, assuming Teksavvy has no costs other than paying the incumbent and makes zero profit.

This ranges from 9x for Rogers 10 Mbps ($34.95 customer price, Rogers charges $19.25 per user, with the remaining $15.7 paying for 1.12 Mbps at $1400/100Mbps) to 46x for Rogers 150 Mbps, and between 14x (10 Mbps) and 21x (15 Mbps) for Bell DSL (The other Bell plans are in between 14x and 21x). TSI obviously has many other costs and a profit margin, so the real oversell ratios are going to be somewhat higher than this calculation.

TSI hasn't had major congestion problems, and did not rely on peak-hour rate limiting until very recently. So I would regard TSI's current oversell ratios to be about reasonable.
JMJimmy
join:2008-07-23

JMJimmy to henry128

Member

to henry128
[facepalm] The numbers were completely arbitrary since I don't know what they actually run at. I don't know how you're doing your math because you're making no sense at all.
said by henry128:

$30/mo for 10 Mbps in costs only. But you're off by a factor of 2-4, so that's $60-120/mo for 10 Mbps before other costs and profit.

I did state that I was not using actual market rates because I don't know what they are.
said by henry128:

to leave the pipe ~10% utilized during the peak period

I was talking a 70-80% utilization of purchased capacity during peak times. No idea where you're getting 10% from.
said by henry128:

You've chosen an oversell ratio of 1.6. The actual oversell ratios are closer to 10-20x

1.5 but lets use your low end oversell of 10 times and your high end rate of 4 times the vendor price I listed before for the TSI example:

Users 300,000 all at 10Mbps during peak at oversell of 10 times = 300Gbps

300Gbps + 20% buffer at $20,000 per Gbps: $7.2 million per month in vendor costs. Lets also DOUBLE my estimate of what TSI makes so they want $7.2 million to cover their costs/profit - there's $14.4 million per month... or $4.80/Mbps

Oh, also - in the above, I have all users using 100% of their 10Mbps where before I had it at 50%... if I included that we're talking $2.40/Mbps or $24/m. If I were to take your high end oversell and low end vendor pricing it'd be $1.20/Mbps. I think my earlier numbers are a little more accurate, though I know vendor pricing was low.
henry128
join:2010-09-03
Hillsboro, OR

henry128

Member

I'm not entirely sure where you're going with the argument now. My understanding was that you were proposing to lower the (peak-hour) oversell ratio by reducing the throughput given to each customer. The idea itself makes theoretical sense, the issue is that you have to use ~real numbers to estimate whether it's practical.

In the above post, I argued that currently, during peak hours, the oversell ratio is around 30 and that this was a good match between the aggregate peak-time demand and the ISP's needed capacity. That means on average, about 3% of the total users' "nameplate throughput" is being used during peak times.

If you believe the oversell ratio should be kept unchanged, that leads to the current pricing scheme (i.e., $30 for 7 Mbps, $33 for 15 Mbps, etc.). If not, then your scheme is equivalent to choosing a different oversell ratio, and the question becomes what is practical, and what problem are you trying to solve by lowering it?
henry128

henry128 to JMJimmy

Member

to JMJimmy
To come up with the estimate of the current oversell ratio, I used numbers from Teksavvy's retail pricing, and Rogers and Bell's tariff documents (I didn't calculate for the other incumbents).
* Rogers, TN36: »www.crtc.gc.ca/8740/eng/ ··· /r28.htm
* Bell General Tariff item 5440: »www.bce.ca/aboutbce/regu ··· 440_____

The costs I included in the calculation were the per-user cost for the line and the capacity cost. All costs are per month:
Rogers:
* 10 Mbps: $19.25
* 30 Mbps: $22.50
* 60 Mbps: $28.65
* 150 Mpbs: $34.57
* Capacity cost: $1400 per 100 Mbps

Bell
* 7 Mbps: $25.47
* 10 Mbps: $25.61
* 15 Mbps: $25.61
* 25 Mbps: $25.62
* 50 Mbps: $25.62
* Capacity cost: $1036.49 per 100 Mbps

To get a lower bound of the current oversell ratio, I take the retail price for a package (I used the 300 GB plan prices), subtract out the cost for the line for that package (it's a fairly big cost and can't be ignored), and then assume the rest goes to pay for capacity cost.

For example:
For 25 Mbps DSL, TSI charges $40/month.
$25.62 goes straight to Bell to pay for the DSL line, $14.37 pays for capacity.
$14.37 buys you 1.39 Mbps at Bell's capacity cost rate. This is 1/18 of 25 Mbps, so the oversell ratio of the 25 Mbps 300GB/mo plan is at least 18x.

Following the above calculation, you get the following lower bounds for oversell ratio:
* Rogers 10 Mbps: 8.9
* 30 Mbps: 18.7
* 60 Mbps: 26.8
* 150 Mbps: 46.3
* Bell 7 Mbps: 16.1
* 10 Mbps: 14.0
* 15 Mbps: 21.1
* 25 Mbps: 18.0
* 50 Mbps: 17.6

Allow for some fuzziness because I don't know what other costs TSI has, what their profit margin is, and also which plans are subsidizing which. For example, it looks like their 7 Mbps 75GB/mo plan is a loss because the retail price ($25) is lower than the $25.47 needed to pay for the line even before considering usage.

It's interesting to see that the higher-speed Rogers plans are oversold quite a bit more than the lower speed plans. People with higher speeds probably do use a lower fraction of their capacity, but this also partly explains why the ZTC speed limits are relatively so much lower for the highest speed plans, to try to pull down the oversell ratio.

Davesnothere
Change is NOT Necessarily Progress
Premium Member
join:2009-06-15
Canada

1 edit

Davesnothere to JMJimmy

Premium Member

to JMJimmy
said by JMJimmy:

My point exactly - UBB wouldn't make sense in that perfect storm.

CBB would limit the potential damage to an IISP to what they've oversold at most, which is a lot easier to eat than the current scheme, where a single bad day could wipe out a company, maybe not the likes of TSI but some of the smaller ones for sure.

 
But the current scheme IS CBB, and at an unfair rate.

From MY perspective, UBB is the better model, subject to the 'natural congestion' factor of whatever bulk data lines to which the IISP has committed to pay the incumbent.

CBB would allow the actual demand to raise the monthly fee for only a moment's max demand in a month, which is much more ri$k to an IISP, even to one who tries to plan prudently.

Charging UBB (at a reasonable rate) on the bulk wholesale data transfer during a whole month would be more fair, as I see it, as it would not harbour any surprises for anybody in the data flow chain, except an occasional bit of 'natural congestion'.

Of course, it has also been validly said that a more reasonable rate for CBB (possibly coupled with what is called '95th percentile' evaluation of the demand) would also be fine.

The true problem is that the incumbent providers are too greedy, pure and simple, no matter what the basis of billing, the CRTC rubber-stamps it, and Industry Canada looks the other way and whistles.
Davesnothere

Davesnothere to henry128

Premium Member

to henry128
said by henry128:

Actually, the current system already achieves what you're attempting to do, but with less impact to the users. "Congestion" is exactly this, where user throughput is reduced because demand exceeds supply.

In the worst case where everyone is using their maximum throughput, the "potential damage" is no worse than what they've oversold. And this only occurs only at the instants when it's needed, not pre-emptively as you're suggesting.

Don't worry about a "single bad day" wiping out a company. They know how much they're willing to spend and the ISP will carefully balance congestion vs. annoying users vs. expenses.

 
This thing called 'natural congestion' has the capability to self-limit the traffic regardless of the basis of billing.

As I understand the current CBB model, the cost to the IISP would become risky well BEFORE 'natural congestion' kicked in.
henry128
join:2010-09-03
Hillsboro, OR

henry128

Member

Not quite. There is no risk because the ISP must choose how much capacity to order a few weeks in advance. The incumbent provisions capacity (and there is congestion if you under-estimate your needs), it doesn't charge based on actual usage. The procedures are stated in the tariff documents.

e.g., Bell (tariff item 5440, last page):
(d) When the customer requests that the Company provision
additional capacity, that additional capacity will be
provisioned within three weeks from the date that the
customer's request is received by the Company. When the
customer requests that the Company remove existing
capacity, that existing capacity will be removed within three
weeks from the date that the customer's request is received
by the Company. The Company is not responsible for
ensuring that the number of capacity increments ordered by
the customer is appropriate for the customer's network, or
other requirements.
 
System

to the cerberus

Anon

to the cerberus
This topic has been closed. Reason: run its course