dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5451
share rss forum feed

34764170

join:2007-09-06
Etobicoke, ON
reply to Guspaz

Re: Changes in Bell AGAS network

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.

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.


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23

said by 34764170:

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

UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
·Bell Sympatico

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.


UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
·Bell Sympatico

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


Cpuroast

join:2000-07-23
canada
reply to TSI Marc

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



Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

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)


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to TSI Marc

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



HiVolt
Premium
join:2000-12-28
Toronto, ON
kudos:21

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!!!



Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to TSI Marc

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


UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
·Bell Sympatico

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


UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
·Bell Sympatico

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


InvalidError

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

said by 34764170:

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.

UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
·Bell Sympatico

1 edit
reply to UK_Dave

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



Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

Typo : Upstream 8000 should be 800


UK_Dave

join:2011-01-27
Powassan, ON
kudos:2
Reviews:
·TekSavvy DSL
·Bell Sympatico

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


34764170

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

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.

InvalidError

join:2008-02-03
kudos:5

said by 34764170:

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.

34764170

join:2007-09-06
Etobicoke, ON

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.

InvalidError

join:2008-02-03
kudos:5

said by 34764170:

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.


Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

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.

UnixMan

join:2012-10-14
reply to TSI Marc

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!



squircle

join:2009-06-23
Oakville, ON

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



TwiztedZero
Nine Zero Burp Nine Six
Premium
join:2011-03-31
Toronto, ON
kudos:5

1 edit

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

MaynardKrebs
Heave Steve, for the good of the country
Premium
join:2009-06-17
kudos:4
reply to TSI Marc

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



Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

 
It's giving ME A-GAS attack.