| reply to jfmezei
Re: CNOC R&V of CRTC 2011-703 and CRTC 2011-704 I think Bell has make it very clear that the capacity pays for their core + transport cost for spanning the area served and physical facilities and has nothing to do with AHSSPI inside a shelf. This follows that the capacity charges should then be billed as separate items and not to tie to individual AHSSPI.
This allows for IISP flexibility for AHSSPI level link redundancy without paying for capacity that they cannot used under the current rules. |
|
| said by Ott_Cable :I think Bell has make it very clear that the capacity pays for their core + transport cost for spanning the area served and physical facilities and has nothing to do with AHSSPI inside a shelf. This follows that the capacity charges should then be billed as separate items and not to tie to individual AHSSPI.
This allows for IISP flexibility for AHSSPI level link redundancy without paying for capacity that they cannot used under the current rules.
The issue is, if you don't allocate the capacity block to an interface, how will it work? Nobody has been able to demonstrate a setup whereby a fixed quantity of ordered capacity can be dynamically allocated among several links. |
|
| Prior to capacity based billing model, each of the AHSSPI would carry full traffic.
What the capacity based billing model means is that ISP would additionally pay for n x 100Mbps capacity on Bell's network cloud. Only difference now is that the overall rate should capped at n x 100Mbps before distributing that over the AHSSPI just like it before.
May be that take an extra step to do the rate limit, but certainly more sensible than having to pay for all the extra capacity over the cloud that the IISP doesn't ask for. |
|
resa1983Premium
join:2008-03-10
North York, ON
kudos:7 | Damn JF.. Loving your submission.. Really poking at the stupidities with the R&V, and the incumbents pathetic practices. |
|
| reply to freejazz_RdJ
said by freejazz_RdJ:The issue is, if you don't allocate the capacity block to an interface, how will it work? Nobody has been able to demonstrate a setup whereby a fixed quantity of ordered capacity can be dynamically allocated among several links. There is a simple solution for this: don't.
From the early days of capacity-based billing, most people had the impression that we were headed towards a total-capacity billing arrangement similar to 95th, not a per-interface billing scheme.
The incumbent's costs to bring traffic to (or take it away from) the POI is essentially the same regardless of how it gets distributed between the multiple links between the incumbent and ISP, which is one of very few points on which I agree with "the opposition".
If CBB had been on a per-POI commit basis applied to the lumped MRTG total of all interfaces where ISPs get billed extra for exceeding their commitment (punitive markup on that, lets say 100%), we wouldn't have many of dispute items we have now. Of course, this ends up looking a lot like commit+95th - best rate on the committed peak volume, 95th applied to remainder in excess of commit. |
|
