Topic 'Changes in Bell AGAS network' in forum 'TekSavvy' - dslreports.com

Re: Changes in Bell AGAS network

Sun, 17 Feb 2013 02:30:31 EDT

Davesnothere posted :
It's giving ME A-GAS attack. :o

Re: Changes in Bell AGAS network

Sat, 16 Feb 2013 19:45:23 EDT

MaynardKrebs posted : All this talk about Bhell is giving me a pain in the AGAS

Re: Changes in Bell AGAS network

Sat, 16 Feb 2013 09:31:19 EDT

TwiztedZero posted :

said by squircle:

Aggregated Gateway Access Service. GAS is Bell's wholesale DSL system, see »www.wholesale.bell.ca/pdfs/GASDSL.pdf

Someone should put all these various TPIA terms to the Terminology FAQ's section, for both DSL and Cable lingo, especially the alphabet soup bits for the newcomers then we can just point 'em all there.
--
----|- From the mind located in the shadows of infinity -|----
Nine.Zero.Burp.Nine.Six
Twitter = Twizted Zero
Chat = irc.teksavvy.ca

Re: Changes in Bell AGAS network

Sat, 16 Feb 2013 09:28:15 EDT

squircle posted : Aggregated Gateway Access Service. GAS is Bell's wholesale DSL system, see »www.wholesale.bell.ca/pdfs/GASDSL.pdf

Re: Changes in Bell AGAS network

Sat, 16 Feb 2013 01:47:39 EDT

UnixMan posted : I am really sorry for popping this discussing up again but ... just for my curiosity as for a person with 20+ years of experience in S/W development mostly focused on UNIX-like operating systems and TCP/IP networking... can somebody tell me what AGAS stands for?

It seems to me like all kids playing games in Windows and never heard about the Internet details but joint this thread are absolutely familiar with the "AGAS". I'm feeling myself as an idiot because all attempts to find any info by 'google'-ing etc. had no success. Is it a kind of Bell and TekSavvy proprietary term I never heard about?

Thanks!

Re: Changes in Bell AGAS network

Tue, 12 Feb 2013 05:00:25 EDT

Davesnothere posted :

said by InvalidError:

....The way costing rules are arranged, they do not reward incumbents trying to be more efficient, so Bell naturally tries very hard not to do it.

And why do Cats kill Birds ?

Because they are Cats. ;)

Re: Changes in Bell AGAS network

Tue, 12 Feb 2013 00:45:02 EDT

InvalidError posted :

said by brad:

They can add all the capacity they want but it doesn't resolve the poor balancing and poor utilization.

You were talking from TSI's perspective, I was talking from Bell's perspective. From Bell's perspective, making things more efficient makes them lose revenue because GAS ISPs would not need to over-purchase as many links and as much CBB.

The way costing rules are arranged, they do not reward incumbents trying to be more efficient so Bell naturally tries very hard not to do it.

Re: Changes in Bell AGAS network

Tue, 12 Feb 2013 00:38:28 EDT

brad posted :

said by InvalidError:

If most of the equipment is already there and largely under-utilized anyhow, whether or not it is used efficiently makes little difference since this is still likely cheaper than upgrading it.

I'm referring to TSI's perspective.. and it does result in somewhat poor utilization with the current setup. The "upgrading" is them adding some 10Gb line cards into the chassis on Bell's side. Not a big deal.

said by InvalidError:

Also, with the CBB rates as they are now (or even if they got dropped to ~10k$/Gbps), it will be profitable regardless of how bad efficiency might be so no pressure there - the inefficient setup forces ISPs to buy more capacity than they really need so upgrading could actually cut into profits beyond the upgrade costs themselves.

They can add all the capacity they want but it doesn't resolve the poor balancing and poor utilization.

Re: Changes in Bell AGAS network

Tue, 12 Feb 2013 00:20:30 EDT

InvalidError posted :

said by brad:

Some vendors have extended LACP to allow for up to 16 group members, but IMO its still a poor use of equipment and resources.

If most of the equipment is already there and largely under-utilized anyhow, whether or not it is used efficiently makes little difference since this is still likely cheaper than upgrading it.

Also, with the CBB rates as they are now (or even if they got dropped to ~10k$/Gbps), it will be profitable regardless of how bad efficiency might be so no pressure there - the inefficient setup forces ISPs to buy more capacity than they really need so upgrading could actually cut into profits beyond the upgrade costs themselves.

As Bell discovered for themselves when they disputed the CRTC's dismissal of past network conditioning efforts: the CRTC's costing rules do not reward efficiency.

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 23:06:25 EDT

brad posted :

said by InvalidError:

Without LAG or equivalent, balancing could still be an issue on 10G, just not quite as much of one.

I didn't mean it would resolve the issue all together but it would make it much easier to deal with as opposed to 32+ individual links.

said by InvalidError:

Having 1G links would be a non-issue if Bell's and TSI's equipment could support 16-64 links per LAG and LAG was enabled. They'd have one logical 30+Gbps link with potential for near-perfect balancing.

Some vendors have extended LACP to allow for up to 16 group members, but IMO its still a poor use of equipment and resources.

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 22:43:49 EDT

UK_Dave posted : Here we go, 10.30pm.....

Ping statistics for 206.248.155.70:
Packets: Sent = 626, Received = 626, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 34ms, Maximum = 132ms, Average = 49ms

I know it's not over as many pings, but rest assured it stays like this all night, and all morning, and a little of the early afternoon before it gets to where we were a few posts up the page.

Cheers,
Dave

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 22:37:09 EDT

Davesnothere posted : Typo : Upstream 8000 should be 800

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 22:35:39 EDT

UK_Dave posted : DMT shows my stats to be:

Downstream 7040kbit/s, attenuation 19.0db, SNRM 20.0db txpwr 19.5dBm RCO 63% (11136kbps)

Upstream 800kbit/s, attenuation 10.0db, SNRM 11.0dB, txpwr 11.5dBm RCO 73% (1088kbps).

And says I am on g.992.1 Annex A ADSL interleaved path.

It's all Greek to me, so if anyone wants to throw in an opinion on the interpretation I'd be happy to learn something.

EDIT, thanks for pointing out the typo, DavesNotHere :-)

Cheers
Dave

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 22:31:11 EDT

InvalidError posted :

said by brad:

If Bell offered 10Gb AGAS ports as they should have been 2-3 years ago this wouldn't be an issue.

Without LAG or equivalent, balancing could still be an issue on 10G, just not quite as much of one.

Having 1G links would be a non-issue if Bell's and TSI's equipment could support 16-64 links per LAG and LAG was enabled. They'd have one logical 30+Gbps link with potential for near-perfect balancing.

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 21:59:37 EDT

UK_Dave posted : Hi TSI David.

Thanks for the update.

Here's the numbers for 10pm (same day as above post).

Ping statistics for 206.248.155.70:
Packets: Sent = 4824, Received = 4814, Lost = 10 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 3441ms, Average = 643ms

I'll do one more, in an hour or two - just for comparison.

Cheers
Dave

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 16:00:24 EDT

UK_Dave posted : I just hope something is on the way.

12,000 pings. Minimum is 806ms, average over 1000ms....

TSI David, I hope you're getting somewhere with this - it's getting worse by the week.

---------------------
Ping statistics for 206.248.155.70:
Packets: Sent = 12412, Received = 12411, Lost = 1 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 806ms, Maximum = 1997ms, Average = 1204ms
-----------------------

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 11:37:23 EDT

Guspaz posted : I don't remember the exact percentage anymore, but it was something like 2:1 ON/QC?
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 11:21:27 EDT

HiVolt posted : I wonder what the DSL Ontario/Quebec percentage is for TekSavvy...

Wonder if it would ever make sense for them to open a Quebec POP.
--
F**K THE NHL. Go Blue Jays 2013!!!

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 11:15:24 EDT

Guspaz posted : It wouldn't make as much sense as having 4x10 GigE for all of Bell's territory combined.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 11:12:33 EDT

Davesnothere posted :

said by Cpuroast:

Wouldn't simply having 2x10Gbit links for ON and 2x10Gbit links for QC simplify the situation and solve the issue?

Prob'ly yes, but easier said than done. (Both politics and tech issues)

Re: Changes in Bell AGAS network

Mon, 11 Feb 2013 10:57:41 EDT

Cpuroast posted : Wouldn't simply having 2x10Gbit links for ON and 2x10Gbit links for QC simplify the situation and solve the issue?

Re: Changes in Bell AGAS network

Sat, 09 Feb 2013 14:35:47 EDT

UK_Dave posted : OK, just had a very pro-active TSI David call me on the phone to take ownership.

Thanks TSI - let's hope we get somewhere even if it's just to prove it's Bell's congestion. At least that way I can start rattling the cages of my local MP's, and throwing out a few posters in shop windows to get a petition of complaint to Bell underway.

Not feeling grumpy anymore.

Cheers,
Dave

Re: Changes in Bell AGAS network

Sat, 09 Feb 2013 12:58:43 EDT

UK_Dave posted : So is there at least a date I can wait for, to at least hope if my situation improves?

Telling me that 800ms pings are to do with "something else", doesn't really help me.

Problem. Ownership.

This is my Saturday morning experience:

Ping statistics for 206.248.155.70:
Packets: Sent = 14961, Received = 14949, Lost = 12 (0% loss)
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 1891ms, Average = 310ms

7 days a week, the evenings are worse. If it helps get someones attention, I've just downgraded my TSI Review for the 2nd time. Maybe instead of replying there and saying how sorry you are, someone might get onto this and push somewhere.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 17:56:24 EDT

Guspaz posted :

said by brad:

Measuring for the purpose of generating graphs is not the same thing as feeding the data into your magic mechanism software running on the router. I don't agree about the 5 min polling. Anyway, it's a moot point. This magic mechanism would have to exist within JunOS and I can't imagine anyone bothering to implement something like this. The target market is practically non existent.

The idea is to only use this for extreme cases, where a link really gets out of balance, so the 5 minute window should be sufficient. Typically, most links are balanced enough, and it's only a small number (or even just one) that got out of whack.

Depending on how things are done, it might not have required any changes to JunOS. For example, at some point the auth request hits the RADIUS server. Is there any sort of information at that point that might indicate which tunnel the connection came in on? TSI moved to one tunnel per AHSSPI recently, and the solution could be as simple as having your RADIUS server not respond to authentication requests from any tunnels that are overloaded.

Does it require custom code from the ISP? Yes, but so do many things inside an ISP.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 17:44:40 EDT

brad posted :

said by Guspaz:

TekSavvy already measures the throughput of their AHSSPI links, presumably via SNMP. You don't need real-time measurements to decide if you should enable/disable the behaviour on a particular link, polling every 5 minutes as SNMP graphic software typically does is sufficient.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 17:39:36 EDT

Guspaz posted :

said by brad:

It's not just that. You need to know if those 30 odd links are overloaded and to do so in real-time. AFAIK those links are not directly terminated on the routers. That just adds another level of complexity to the situation when it comes to trying to come up with this magic mechanism. In the end this still would not guarantee that the links could not be overloaded or that the load balancing would still be optimal.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 17:33:48 EDT

brad posted :

said by Guspaz:

said by brad:

and how is that supposed to work exactly? Easier said then done.

Much the same way WE did it on the client end in our MLPPP software. The problem that Gabe points out would make things difficult, however. From a protocol level, there are things you could do to abort the connection without sending a invalid username/password error; simply present the user with a set of parameters that it will find unacceptable during the negotiation. But TSI doesn't use software-based endpoints, so that wouldn't work. All that you're left with the the don't-reply-at-all method, which has issues in that the timeout is rather long and that could seriously degrade the customer experience.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 17:24:11 EDT

Guspaz posted :

said by brad:

and how is that supposed to work exactly? Easier said then done.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 17:15:05 EDT

brad posted :

said by noemails :

this is a teksavvy capacity issue has nothing to do with bell.

Actually it has everything to do with Bell. The connections are spread across the 30 odd links that TSI has and its the poor load balancing from Bell that results in some links being under utilized and others being over utilized. If Bell offered 10Gb AGAS ports as they should have been 2-3 years ago this wouldn't be an issue.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:55:19 EDT

nitzguy posted :

said by TSI Gabe:

said by Guspaz:

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.

I looked into this, it doesn't work, PPPoE doesn't implement any error code mechanism that says "try again", returning invalid username or password makes a lot of clients freak out and not replying at all causes even more problems.

We've got something coming up very soon that will fix all of this, at this point though I'm not sure I'm allowed to talk about it.

Mentioning something....means you've already talked about it ;). Just pointing things out.

There used to be issues on this on the cable side way back in the D1 days....where there might be 4 downstream channels for a certain area but for some reason all the modems locked onto 1 channel overloading it leaving the other channels relatively unused...

But I know its not the same with DSL, but there has to be a way to balance...somehow....somehow!!! :)

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:50:34 EDT

anon posted : this is a teksavvy capacity issue has nothing to do with bell. when i worked at bell we had a capacity issue....they ran out of ips....why did that happen....some manager looked at the ammount of calls related to login errors...to this day they still insist on the bi b1 bl so they deciced to send out modems that could login and retain the user id and password,..worked wonders until those clients snagged every ip bell had,...chris spent over a month running a script that hit al those modems and changed it to connect on demand...this is a capacity issue and teksavvy is snot being honest about it.

if the slowdowns ae just youtube related then they need to come up with a response to that,,,,.if it si everything slow in specific arears then its a capacity issue

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:50:02 EDT

UK_Dave posted : Check the multiple tests and postings on my account.

It's been that way for months.

It's not wiring or hardware. I've replaced the whole damn lot. Including the demarc and internal wiring.

Normal daytime/overnight - I get 35ms to 40ms pings - so I know it's congestion related.

The only question is who is congested, and who has ownership of this problem to get it fixed. I have the ticket number you raised with Bell, but after a "slow speed pattern match" response, nothing has been done despite there supposedly being a marker on my file for someone to be following it up.

As the folks on TSI IRC know - I've actually changed my hours of work to fit in around the unusable connection.

EDIT: In my head, I'm giving it till around spring. At that point, I'm going to have to cancel if it's not in hand.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:46:12 EDT

TSI Gabe posted :

said by Guspaz:

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:44:26 EDT

TSI Gabe posted : 800ms-1000ms? That's not normal at all. You've got something else altogether going on.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:44:25 EDT

brad posted :

said by Guspaz:

and how is that supposed to work exactly? Easier said then done.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:40:05 EDT

UK_Dave posted : 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?

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:35:58 EDT

brad posted :

said by rjbrake:

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

First World Problems

Saying that doesn't make it any more acceptable.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:34:20 EDT

Guspaz posted : 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

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 16:05:12 EDT

InvalidError posted :

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.

Re: Changes in Bell AGAS network

Fri, 08 Feb 2013 09:35:22 EDT

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

First World Problems

Re: Changes in Bell AGAS network

Wed, 06 Feb 2013 21:51:01 EDT

zacron posted : COuld you please flesh this out a little more?

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

Re: Changes in Bell AGAS network

Wed, 06 Feb 2013 21:48:57 EDT

TSI Marc posted : 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

Re: Changes in Bell AGAS network

Tue, 05 Feb 2013 16:38:49 EDT

brad posted :

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.

Re: Changes in Bell AGAS network

Tue, 05 Feb 2013 16:04:14 EDT

Guspaz posted : Wups, missed that.

Re: Changes in Bell AGAS network

Tue, 05 Feb 2013 14:57:12 EDT

c2roth posted : 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...

Re: Changes in Bell AGAS network

Tue, 05 Feb 2013 14:38:00 EDT

squircle posted :

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 :)

Re: Changes in Bell AGAS network

Tue, 05 Feb 2013 14:36:03 EDT

InvalidError posted :

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.)

Re: Changes in Bell AGAS network

Tue, 05 Feb 2013 14:15:36 EDT

Jethro86 posted : I hope this fixes the issues as last night (Feb 4th) was brutal.
»speedtest.net/result/2486560847.png
»speedtest.net/result/2486561861.png
Reboot router\modem
»speedtest.net/result/2486590099.png
»speedtest.net/result/2486603588.png

This is ridiculous. :mad: