Bypassing congestion on a carrier network

We have seen much debate on net neutrality of late, and this even relates to the ways in which various ISPs prioritise various types of traffic.

One would hope that this does not apply to a wholesale carrier network. Ideally they charge for usage (as our favourite telco does) and so they always have enough revenue to run an un-congested network. There will be exceptions, but in general the network should cope with no problems. This means that there should be no need to have any priority for certain traffic.

You certainly would not expect a major telco wholesale carrier network for broadband lines to have (a) any links that are regularly congested, and (b) priority of certain traffic types over others.

Well, with the new FireBricks which do PPPoE at the customer end we now have control over both ends of the PPP link on a broadband line. We can change the traffic type of the packets that are carried. To our surprise the result is a massive improvement in performance on some lines that have congested back-haul links.

We are not alone in noticing something odd. Another ISP has noticed this as well and they, and we, mentioned it at an ISP forum working group last year. The telco denied there was anything going on.

So we set about testing this. It has been hard work - we needed the PPPoE code in the new FB2500 and FB2700 FireBricks; We had to find a really good example line that was congested every single evening; We had to set up testing to confirm the level of congestion clearly; Finally, we had to make code to allow use of different PPP packet types and test the results.

The result is a unique combination allowing us to give A&A customers that have FB2500 and FB2700 an advantage at no extra cost for the service. Please don't rush out and spend money on a FireBrick if you do not need one - they are not cheap and usually only make sense for small business customers and not home users. But if you do have congestion, especially on a 20CN line, and the premium option on the line is not helping, it is another step we can try if you are prepared to invest in a FireBrick. The main example we have tried this on was bonding three lines where one was heavily congested in the back-haul - this fix helped massively.

We cannot suggest anything underhand is going on here - it could just be a consequence of the way the equipment is designed and set up to handle a congested link.

The real fix is for the telco to stop running congested links and believe us when we tell them there are problems. They have clearly stated they will happily put 400 ADSL customers (up to 7.15Mb/s each) on a 10Mb/s back-haul. That is crazy. Thankfully most of the links are OK, but there are a few that are a problem, or were until now...

A&A support staff know to watch out for this type of congestion and we will be adding more tools that end users can access over the next few months which will highlight congested links more clearly.

Of course A&A are no longer alone in using the FireBrick FB6202 LNS. The FireBrick team will be happy to explain the details to any of the other ISPs that use FireBricks. Any ISPs wanting to try them - contact FireBrick or me.


  1. does this need to be Firebrick for the CE or could anything with control over the PPP packets do?

  2. does this need to be Firebrick for the CE or could anything with control over the PPP packets do?

  3. Someone has already made a kernel patch for this for Linux/pppd. As on our irc channel for more details. It is not rocket science, honest.

  4. So does this hackery work with multiple carrier networks, or is it simply a consequence of a set of bugs in one of the older carrier networks you deal with (the one whose name suggests it's from the previous millennium)?

  5. It's not just BT -- in Canada Bell has had the same issues with congestion on its wholesale links. Rather than expand the necessary middle mile and backhaul, they use ITMP aka "traffic management" (http://www.wholesale.bell.ca/internetman.asp and http://www.dslreports.com/shownews/Bell-Backs-Off-Throttling-116665) and UBB (usage-based billing). Yes, UBB for their wholesale customers!

    Bell claims that they don't do ITMP for new links, effective November 2011.

  6. Only seeing the congestion on the one network.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

TOTSCO moving goal posts, again!

One of the big issues I had in initial coding was the use of correlationID on messages. The test cases showed it being used the same on a se...