dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
share rss forum feed


mazhurg
Premium
join:2004-05-02
Brighton, ON
Reviews:
·MTS
reply to ihatebell21

Re: CNOC R&V of CRTC 2011-703 and CRTC 2011-704

said by ihatebell21:

said by alienzzz:



I think we should all move to Manitoba.

MTS has a squadron of giant Manitoba mosquitos to fly you there.

I't my understanding that they moved to Ontario last year as nary a one was to be found here while friend in eastern Ontario were (figuratively) eaten alive.

A little wetter so far this spring. They may yet come back but you'd think they'd be out by now with all the mild weather.

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

1 edit
Sneak preview:

quote:
Or perhaps the Commission meant to remove the AHSSPI completely since all its costs were factored into the capacity rate but Bell Canada didn't get the memo and still bills it to ISPs ?

quote:
The costing studies were prepared before the January/February "UBB Winter" civil uprising which forced a regime change by toppling the incumbant dictated UBB.



Ott_Cable

@teksavvy.com
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.

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23

1 recommendation

reply to jfmezei
And finally... Vaxination's comments.

Off to bed now.

InvalidError

join:2008-02-03
kudos:5

1 edit
3 - "Vaxination does not see seek any request" ?

14 - there is a reliable manner: create an app that registers the customer's IP with login+password by maintaining a TCP/IP session, now the ISP knows which customer has which IP and can act accordingly Not as transparent to the end-user as the ISP knowing who has which IP beforehand but at least it makes what you claim is impossible possible for an ISP and subscribers who want it badly enough.

17 - ISPs that cater to aunts and so also pay "disproportionately high" capacity rate so heavy-user ISPs don't subsidize them.

18 - peak demand is increasing by 50-60%/year, which is about twice as fast as transit costs are dropping.

20 - for that to happen, Videotron would have to start dropping prices and increase caps... but the trend for most of the past 10 years is to increase prices and leave caps largely unchanged or at the very least, not increasing anywhere near as fast as "natural growth".

21 - "four letter word"? FS is two words and 20 letters...

22a - Cable has diagnostic charges too, it isn't unique to DSL

30 - if ISPs are so sure Bell's rate are hyper-inflated then they should be granted the chance to take the risk of getting retroactively billed ever higher rates if proven wrong... worst case, the higher rates shouldn't be that much higher than current ones.

39 - aggregated and non-aggregated not generating the exact same amount of revenue for a given traffic level does not mean either one is automatically subsidizing the other, it just means that one will be more profitable to Rogers than the other

43 - since 25/7 is only $0.12/month more than 16/1, there effectively is no reason to even bother offering 7Mbps upload as a separate option on slower wholesale tiers

50 - I doubt many people bothered with the 7Mbps upload option, most of those who wanted 7Mbps likely opted for the full 25/7

80 - the definition of AHSSPI is in the GAS tariffs where they are defined as "burstable to X Mbps" and makes no mention of any particular sustainable bandwidth commitment

106 - a Fibe50 subscriber won't cost ISPs $1106.50 unless he happens to be active at maximum speed during every peak every day of the month, which is highly unlikely on a 100GB cap

109 - the bulk of wholesale costs are "first-mile" costs (from the copper loop to the BRAS' interface with Bell's backbone, all of which being broadband-specific costs) so the "gargantuan amounts of capacity" on Bell's backbone are not of much significance here

111/113 - before Youtube, Netflix and friends, P2P was one of the major traffic drivers and load was more evenly distributed 24/7 at a growth rate of about 30% any time of day but now, peak-hour traffic grows at rates in excess of 50%/year which is well in excess of any efficiency or cost reduction gains

116 - Since the current rates were based on 10-years study periods that factor in future cost/efficiency improvements, going to bi-annual and forfeiting 8 years of future improvements will offset a large chunk of any gains from reviewing current rates assuming such a revision is in our favor at all


HiVolt
Premium
join:2000-12-28
Toronto, ON
kudos:21
Reviews:
·TekSavvy DSL
·TekSavvy Cable
reply to jfmezei
said by jfmezei:

And finally... Vaxination's comments.

Very good stuff, JF, as usual.

freejazz_RdJ

join:2009-03-10
kudos:1
reply to Ott_Cable
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
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
join:2008-03-10
North York, ON
kudos:10
Damn JF.. Loving your submission.. Really poking at the stupidities with the R&V, and the incumbents pathetic practices.

InvalidError

join:2008-02-03
kudos:5
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.
Expand your moderator at work


alienzzz
Kill Bell

join:2011-02-17
Verdun, QC
reply to jfmezei

Re: CNOC R&V of CRTC 2011-703 and CRTC 2011-704

JF, got to take a look at your comments now... I know that if KvF were still there, he'd be going over the underlying concept of each question "vat do you mean 25 metrabytes... i sot you vere talking about 7 mumblehertz"... Wonder how Katz will deal with this now. Basically they'd want the principles behind every point re-explained in detail so the whole thing would drag on for months or years, which it well may.

The only thing I'd like to point out is that the VDSL modem issues/bugs haven't actually been brought before the CRTC yet, so either they'd want to know more or they will dismiss the point.

And essentially there are 2 different issues here.

One issue is that Bell uses pre-standard ikanos dslams as well as standard alcatel 7330 dslams for its VDSL service. (Kovy also mentioned there could be other less common variations).

Some folks in the TSI forum have found non-bell modem variations that can be purchased at retail and will work (more reliably on their end than bell hw) with a specific DSLAM variant, although I think the Ikanos version compatibility still hasn't been confirmed by them.

Bell ships the Cellpipe 7130 modems to wholesale customers. This modem seems to work with both Ikanos and Alcatel remotes. And here's the second problem.

The cellpipes shipped from bell come with different firmware revisions. It seems that bell recently started reflashing all the modems (locally and remotely) with the infamous v1.0.4.4R3WH firmware revision which seems to be compatible with both ikanos and alcatel dslams, however it is unstable and, from the reports, it causes random modem reboots and sync loss. This is purely a modem issue and has nothing to do with the DSLAM. People have noticed that the modem will reboot on its own even when it's not plugged into the phone line. So it's not a DSLAM bug per sé.

The only DSLAM bug that could be mentioned would be the ADSL2+ upload speed bug on the Ikanos remotes, but I doubt that this has anything to do with the CRTC since it will equally affect both Bell and wholesale customers, and short of replacing the cards with 7330 versions, it can't be fixed.

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23
We'll see how he CRTC reacts to all the submissions. 703 brought out a totally new paradigm without really considering implementation details and now it has to work through all of them.

I suspect there will me done via a CISC committee to look at the technical aspects, ans especially whether it is possible to aggregate capacity instead of counting it at every AHSSPI.

jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23
Looks like CNOC members had too much chocolate for easter...

quote:
April 10, 2012 FILED VIA ACCESS KEY

John Traversy
Secretary General Canadian Radio-television and
Telecommunications Commission
Gatineau, Quebec K1A 0N2

Subject: Canadian Network Operators Consortium Inc. Application to review and vary Telecom Regulatory Policy CRTC 2011-703 and Telecom Regulatory Policy CRTC 2011-704 (CRTC File No. 8662-C182-201202324)
Dear Mr. Traversy,

1. Canadian Network Operators Consortium Inc. (“CNOC”) is in receipt of answers from Bell Aliant Regional Communications, Limited Partnership and Bell Canada (collectively, “Bell Companies”), Cogeco Cable Inc., Quebecor Media Inc., on behalf of its affiliate Videotron G.P., Rogers Communications Partnership and Shaw Communications Inc. (collectively, “Cable Carriers”), MTS Inc. and Allstream Inc. (collectively, “MTSA”), Telus Communications Company and Vaxination Informatique.

2. As matters now stand, CNOC’s reply to these submissions would be due on 16 April 2012. However, there are three factors that make it impossible for CNOC to meet this deadline. First, the collective volume and complexity of the answers cited above submissions is considerable. Second, CNOC’s ability to convene the internal regulatory resources required to analyze the answers and prepare a reply is delayed by the Easter long weekend as a number of relevant resources will not be available until today. This effectively shortens the working period for the preparation of reply by four days. Finally, CNOC’s Annual General Meeting (“AGM”) is taking place tomorrow and some of the same resources required to assist with the preparation of a reply will be tied up today through Thursday of this week with the AGM and related travel.

3. As a result of these factors, CNOC is requesting a delay in the date for filing its reply in this proceeding to 23 April 2012. This is only a delay of five business days but will be of great assistance to CNOC in managing the reply process given all of the circumstances just described.

Yours very truly,
William Sandiford Chair of the Board and President


jfmezei
Premium
join:2007-01-03
Pointe-Claire, QC
kudos:23
This isn't directly related to the CNOC R&V, but here was a response from CNOC on a Videotron Tariff. It appears that Videotron is truly realy to enable 10gbps links, but with conditions CNOC does not approve of.

downloadLetter to Jo···inal.pdf 27062 bytes

InvalidError

join:2008-02-03
kudos:5
Pretty sure Videotron's 3Gbps minimum is about the CBB purchased for the interface, not the actual traffic volume itself. If an ISP is paying for 3Gbps on a 10G link, I doubt Videotron will mind the interface running at 0Mbps since they still get paid for the full unused 3Gbps and get to pocket the spare electrons/photons.


hm

@videotron.ca
reply to jfmezei
said by jfmezei:

It appears that Videotron is truly realy to enable 10gbps links, but with conditions CNOC does not approve of.

Those are conditions *no one* should approve of, not just CNOC.

However, there are ISP's out there who think this is just fine and dandy. Ebox is one of these ISP's that like Videotron telling them what to do and when to do it, as seen in their forum.

No one should put up with Videotron dictating how you run your business, or what you plan on doing that may require more.