dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5624
share rss forum feed

InvalidError

join:2008-02-03
kudos:5
reply to HeadSpinning

Re: Changes in Bell AGAS network

said by HeadSpinning:

10G AGAS and/or LAG would help significantly.

LAGs would indeed help, as long as multiple links are connected to the same chassis at both ends. If links are spread across 3+ routers at either end, it becomes that much less effective since many may end up being orphans.

Makes you wish Nortel's SMLT became standard. It would make this sort of situation so much simpler.

Liberty25

join:2013-02-01
reply to Old Martin
Hi TSI_Martin,

Since I seem to be having the same problem as many people (I'm on DSL near ottawa; things slowing down during peak time, then back to fine off peak; especially noticeable with video sites like youtube, vimeo, streaming gaming sites like twitch, gomtv, tou.tv, news sites, etc.. they all pretty much become unusable unless you let it buffer forever, etc) and it seems to be a known issue, is it really useful that I spend the time filing one more individual ticket?

I'm honestly asking. I know in theory it could be something else, but it seems really obvious to me that this is congestion on the network and that this needs to be fixed on your side.

But if you think it's worth it and it can help, I'll take the time and create a post in the TSI direct forum.

Thanks.

HeadSpinning
MNSi Internet

join:2005-05-29
Windsor, ON
kudos:6
reply to InvalidError
said by InvalidError:

said by HeadSpinning:

10G AGAS and/or LAG would help significantly.

LAGs would indeed help, as long as multiple links are connected to the same chassis at both ends. If links are spread across 3+ routers at either end, it becomes that much less effective since many may end up being orphans.

Makes you wish Nortel's SMLT became standard. It would make this sort of situation so much simpler.

We use MC-LAG between Extreme and Foundry gear, and it works just fine.

»en.wikipedia.org/wiki/MC-LAG
--
MNSi Internet - »www.mnsi.net

InvalidError

join:2008-02-03
kudos:5
said by HeadSpinning:

We use MC-LAG between Extreme and Foundry gear, and it works just fine.

I had no doubt companies had their own proprietary implementations of SMLT-like features. I was just saying it was a shame that there still isn't a standard for SMLT/MC-LAG more than a decade after the first proprietary implementations on Ethernet gear.

Then again, I suppose a standard is not absolutely required since router/switch manufacturers can achieve almost the same result by bending the LACP/LAG rules a little to allow proxying.


openvz_ca

join:2008-12-13
canada
reply to TSI Marc
At this rate, why even bother with 10G...

Telus and Bell are already implementing 40G and 100G backbones.

TSI should go for gold and think longer than 3 months down the road!

Demand 100G aggregation links!


Phibian

join:2009-06-01
Ottawa, ON
+1

Funny but still +1


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply to TSI Marc
ok so yesterday the config changes were made.

Things will start to balance out.

We also added another gig link. So that's a total of 30 gig links.

By looking at the traffic across all of them, we should have plenty of capacity. Now it's a matter of balancing the load evenly. Some links I can see last night were overloaded but most were not.. i.e. the balance is the problem... we're going to see what we can do to force people off the congested ones over to the lower used ones..

we are also waiting on confirmation from Bell on a few links that may also have issues on their end. We're not sure if it's an actual problem or if they are simply being proactive.
--
Marc - CEO/TekSavvy

InvalidError

join:2008-02-03
kudos:5
reply to openvz_ca
said by openvz_ca:

Demand 100G aggregation links!

While 100G may be available, it is not cost-effective for small clients.

TSI has only ~30Gbps of peak traffic on Bell's side so if TSI put everything on a single 40G/100G link, all of TSI's Bell-GAS would go down on a single-point failure. So 40G will not make much sense until TSI gets over 80Gbps, which may take a while at the rate this seems to be growing since so many people have switched to TPIA.

Another problem with 40G/100G is that most routers have only 160Gbps of backplane bandwidth per slot so using 40/100Gbps for small clients who use only a fraction of it wastes a lot of precious rack and chassis space: with 4x10G links on a router populated with 16x10G line cards, TSI would use 1/4th of a single card while with 2x40G (minimum for redundancy), it would use between half to a full slot depending on whether the line card has 2x or 4xQFP slots.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to TSI Marc
Right, so when is Bell going to start activating 10 gig links as the crtc has mandated they do?
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
I'm not aware that there is any such mandate.

we keep knocking on that door but nobody's ever let us in.
--
Marc - CEO/TekSavvy


Phibian

join:2009-06-01
Ottawa, ON
Reviews:
·TekSavvy DSL
reply to TSI Marc
Click for full size
I'll reconnect this evening and see if it makes any difference.

Any chance you could tell us which links / areas are potentially impacted by the Bell issue?


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
said by Phibian:

I'll reconnect this evening and see if it makes any difference.

Any chance you could tell us which links / areas are potentially impacted by the Bell issue?

I had a look at that yesterday and I dont see it if there is an issue...

from your end, there's no way you could tell one way or another what link you were on...

if you have issues though I would say that the best thing is to turn your equipment off for 10 minutes and reconnect and hopefully you'll land on an other link that's fine. There are now two pools (this may change) with 15 links in each.. so each time you connect you land on one of 15 links.. the plan will potentially be to have all of ontario in one pool and all of quebec in another...

the problem we ran into with the tunnel end points was that each pool was at the limit of 32.. so now we have some breathing space.

obviously 10gig links would greatly help but I'm not sure how they would provision things on their end.. they may still want many end points per 10gig link even if we had those available... this is probably why they've held off for so long to date.
--
Marc - CEO/TekSavvy


squircle

join:2009-06-23
Oakville, ON
reply to TSI Marc
said by TSI Marc:

I'm not aware that there is any such mandate.

Dunno if this helps, but para. 72 of 2012-636 seems to indicate there is a mandate:

72. With respect to CNOC’s request to require all incumbents who have not already done so to file tariff proposals for 10 GE interface ports, the Commission determines that all incumbents with WHSA services that do not currently offer 10 GE and support 10 gigabit-per-second transmission speeds in the provisioning of their own services should be required to do so once an independent service provider makes a firm request for such service.
So if you ask, they should be required to comply. Of course, IANAL.


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

I'm not aware that there is any such mandate.

we keep knocking on that door but nobody's ever let us in.

Can TekSavvy or CNOC as a group file something with the CRTC about it? Or is it the incumbents that can only file tariff related stuff...
--
F**K THE NHL. Go Blue Jays 2013!!!


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to TSI Marc
In 2012-636 (»crtc.gc.ca/eng/archive/2012/2012 ··· -636.htm), CNOC requested that the CRTC require incumbents to provide the 10 gig access. The CRTC ruled:

72. With respect to CNOC’s request to require all incumbents who have not already done so to file tariff proposals for 10 GE interface ports, the Commission determines that all incumbents with WHSA services that do not currently offer 10 GE and support 10 gigabit-per-second transmission speeds in the provisioning of their own services should be required to do so once an independent service provider makes a firm request for such service.


--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org
Expand your moderator at work


Jethro86

join:2005-05-27
Winchester, ON
Reviews:
·TekSavvy DSL
reply to TSI Marc

Re: Changes in Bell AGAS network


InvalidError

join:2008-02-03
kudos:5
reply to Guspaz
said by Guspaz:

In 2012-636 (»crtc.gc.ca/eng/archive/2012/2012 ··· -636.htm), CNOC requested that the CRTC require incumbents to provide the 10 gig access. The CRTC ruled:

72. With respect to CNOC’s request to require all incumbents who have not already done so to file tariff proposals for 10 GE interface ports, the Commission determines that all incumbents with WHSA services that do not currently offer 10 GE and support 10 gigabit-per-second transmission speeds in the provisioning of their own services should be required to do so once an independent service provider makes a firm request for such service.

If incumbents are not using 10GbE (or OC192 and beyond) within their own network then they are being seriously retarded... the CRTC definitely should not have been this vague about it.

Looks like the new chairman and his crew still have lots of catching-up to do with ~10 years old technology. Even if incumbents could prove that they use mostly 1GbE, this is so outdated they would deserve a kick in the pants for not refreshing their equipment sooner. IIRC, this sort of equipment is on a 6-years amortization schedule, so the last of Bell's 1GbE-only gear should have been phased out 3-4 years ago. (Except for DSLAMs which are still mostly 1GbE today.)


squircle

join:2009-06-23
Oakville, ON
reply to Guspaz
said by Guspaz:

In 2012-636 (»crtc.gc.ca/eng/archive/2012/2012 ··· -636.htm), CNOC requested that the CRTC require incumbents to provide the 10 gig access. The CRTC ruled:

Look two posts up
Expand your moderator at work


creed3020
Premium
join:2006-04-26
Kitchener, ON
kudos:2
reply to TSI Marc

Re: Changes in Bell AGAS network

I am the only one thinking now that CNOC totally missed this point when the CRTC released this decision? Or just that nobody has acted on it...


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to squircle
Wups, missed that.

34764170

join:2007-09-06
Etobicoke, ON
reply to InvalidError
said by InvalidError:

Even if incumbents could prove that they use mostly 1GbE, this is so outdated they would deserve a kick in the pants for not refreshing their equipment sooner.

Except none of the incumbents would be so its a moot point.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply to TSI Marc
Ok, I just received word from Bell about those 4 links. It turns out they are being proactive and that there is nothing going on with the existing links. Which makes sense since I could see it...

So as it stands now, the links are increasingly balancing out, we keep tweaking to try to make sure the capacity is best used but some links are still running a bit hot while others are not at all. Once everything balances out fully we should should be good for a while.
--
Marc - CEO/TekSavvy


zacron
Premium
join:2008-11-26
canada
COuld you please flesh this out a little more?

Thanks,
Zacron
--
"Recognize, Realize, and Repent"


rodjames
Premium
join:2010-06-19
Gloucester, ON
reply to Guspaz
"and had to constantly appologize for the stream freezing to buffer."

First World Problems

InvalidError

join:2008-02-03
kudos:5
reply to zacron
said by zacron:

COuld you please flesh this out a little more?

In the past, this used to mean they kill sessions on overloaded links and hope they will come back on one of their more over-used links.

Even earlier than that, I think it used to be pushing the "Big Red Button" and wiping all sessions on either a whole link or a whole ERX.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to TSI Marc
I never understood that. Why not simply stop accepting new logins on the overloaded links? If a customer randomly gets assigned to it by the round-robin, it fails, their PPPoE client retries seamlessly to the client, and they connect elsewhere.

Over time, the load balances out.

By this mechanism, a wholesale ISP can pretty effectively keep any link from getting overloaded, even stuck with round-robin; if any link goes above a certain threshold, stop accepting new connections on it.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

34764170

join:2007-09-06
Etobicoke, ON
reply to rodjames
said by rodjames:

"and had to constantly appologize for the stream freezing to buffer."

First World Problems

Saying that doesn't make it any more acceptable.

UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
reply to TSI Marc
So now I'm confused - it doesn't take much at the best of times.

Are you saying there is a defined problem, and it's affecting DSL capacity, and it's going to be fixed? Or is it a "I thought there was a problem to fix but actually there isn't"?

An unworkable internet all evening, seven days a week, is starting to take it's toll. And I mean unusuable - 800ms to 1000+ms pings - means no gaming, no browsing, no web-based email, no videos even at lowest resolution

Is there a date I can wait for? A project about to go live?