dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
14

Ott_Cable
@teksavvy.com

Ott_Cable to jfmezei

Anon

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.
freejazz_RdJ
join:2009-03-10

freejazz_RdJ

Member

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.

Ott_Cable
@teksavvy.com

Ott_Cable

Anon

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.
resa1983
Premium Member
join:2008-03-10
North York, ON

resa1983

Premium Member

Damn JF.. Loving your submission.. Really poking at the stupidities with the R&V, and the incumbents pathetic practices.
InvalidError
join:2008-02-03

InvalidError to freejazz_RdJ

Member

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.