dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
30
share rss forum feed


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

Re: Changes in Bell AGAS network

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

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


TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7
reply to Guspaz
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.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )


nitzguy
Premium
join:2002-07-11
Sudbury, ON
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!!!


Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
reply to 34764170
said by 34764170:

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.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

34764170

join:2007-09-06
Etobicoke, ON
said by Guspaz:

said by 34764170:

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.

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.


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

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.

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.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

34764170

join:2007-09-06
Etobicoke, ON
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
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
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