dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1105
share rss forum feed

smbtamu

join:2009-08-11

Traffic Shaping for SharedBand Traffic

Hi All,

I have four 3Mbps DSL lines through AT&T and I'm using a line bonding service from SharedBand.com to combine the lines into one big pipe.

Recently I've been seeing significantly lower speeds through the SharedBand network, and have done some troubleshooting with their tech support. They have told me that they are seeing classic signs of traffic shaping of the SharedBand packets on my lines and that I need to reach out to my ISP (AT&T).

I called AT&T tech support last night, and they had no idea how to handle my issue. They insisted on going through normal troubleshooting techniques as if there was a problem with the modems or the lines.

You guys are my last resort. Any advice you can give me? I'm afraid that AT&T's traffic shaping rules are determined at a very high level and I just might be out of luck on this one.

Note that I'm only seeing slower speeds during the afternoon and evening hours, and only through the SharedBand network. If I do a speed test connected straight to the modem, speed is completely normal. Speed tests through SharedBand in the early morning hours are also normal.

From the SharedBand site:

"Due to the ever increasing use of the internet, ISPs are finding that at peak times, normally between 3PM and 11PM, that traffic is many times what is actually available, this causes contention issues (see contention above). To minimize disruption during peak periods, some ISPs prioritise web and email traffic but penalise other traffic like VPN, Gaming, P2P and other unknown programs. Because sharedband is still relatively unknown it sometimes gets categorised with all the other “undesirable” traffic."



NormanS
I gave her time to steal my mind away
Premium,MVM
join:2001-02-14
San Jose, CA
kudos:11
Reviews:
·SONIC.NET
·Pacific Bell - SBC

If AT&T is shaping traffic, it is a very new process. I had DSL from February, 2001 (when it was offered as, "Pacific Bell DSL Service" through April, 2011 (when it was, "at&t Yahoo! HSI Pro"). I never knew them to "shape" traffic. I've run both "glasnost" and "shaperprobe" on that line with no evidence of traffic shapers.

I have been with another ISP since April, 2011, and can't test an AT&T DSL connection at present.



d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
kudos:7
reply to smbtamu

AT&T never did traffic shaping; however, they did have problems with gateway congestion (the exhausted router syndrome) years ago. This problem has mostly been cleared up, but it does reappear from time to time as certain gateways (BRAS or redbacks) become overloaded. Typically AT&T now will switch the customer to another gateway, a less congested one if one is available, once they realize this is happening. The migration to UVerse and the defections due to bandwidth caps have also diminished this congestion problem.

I suspect that ShareBand can't tell the difference between traffic shaping and gateway congestion.
--
TCE Weather -- Mt. Rose Cam


smbtamu

join:2009-08-11
reply to smbtamu

They did suggest congestion also as a possible problem. "the issue you are seeing is a classic sign of contention on the ISP lines or traffic shaping"

How would I go about asking them to change all of my lines to a different gateway? Is that something direct support may be able to help me with?



d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
kudos:7
reply to smbtamu

If you can prove gateway congestion to Direct, then they can initiate the switch process.

Frankly, I don't know how you could do it with bonded lines or if it is even possible. If you had just a single line, you would use Wireshark to prove it: »SBC DSL FAQ »How to measure throughput speeds on individual packets?
--
TCE Weather -- Mt. Rose Cam


smbtamu

join:2009-08-11

Well, I had assumed based on d_l's post that I had hit a wall over here, so I asked Sharedband to switch me from their Dallas aggregation server to their Atlanta aggregation server.

I did a speed test before making the switch and got 600 Kbps down over 2 bonded lines. After pointing the Sharedband routers at the Atlanta server (5 minutes later) I got 5 Mpbs down over 2 bonded lines. I have gotten 5 Mpbs consistently over the past 12 hours.

Based on this information, is gateway contention still the likely issue or am I back to square one?



d_l
Barsoom
Premium,MVM
join:2002-12-08
Reno, NV
kudos:7
reply to smbtamu

How exactly does the bonding work with regards to the AT&T system?

If you had a single line with AT&T, your DSL line connects to a DSLAM which then connects to a gateway (redback or BRAS). between the DSLAM and gateway, your data traffic consists of ATM cells and after the gateway it is TCP/IP packets.

So does the bonding simply aggregate/disaggregate the packet traffic across the four lines at Shareband routers which would be manipulating the data beyond ("above") the AT&T gateway or is there any way they could fragment the TCP/IP packets so that it would affect the ATM cells "below" the gateways?

If it is the former, I don't see how this could be a gateway problem. More likely it seems that it might be transmission delay problem over an internet backbone or the routers along the backbone after the packets leave your NOC and before they arrive at the Shareband routers.

For curiosity's sake, you might try the Wireshark test and post the results here. I'd expect the results to be incomprehensible due to the added complexity of the line bonding, but you never know what might show up.
--
TCE Weather -- Mt. Rose Cam



NormanS
I gave her time to steal my mind away
Premium,MVM
join:2001-02-14
San Jose, CA
kudos:11
Reviews:
·SONIC.NET
·Pacific Bell - SBC
reply to smbtamu

said by smbtamu:

Based on this information, is gateway contention still the likely issue or am I back to square one?

I've been looking at the Sharedband site, and trying to sort out how it works. On their "technology" page, they show multiple routers on the customer premises. Each has a separate WAN connection, which can be a mix of DOCSIS (cable), DSL, and fiberoptic services. It looks like they do load balancing tricks on their servers at step 4. Even with multiple DSL connections from the same provider, as you have, packets traveling between the CPE and the Sharedband aggregation servers may take different routes.

d_l See Profile can probably explain the AT&T transit better than I, but you have four DSL modems on four lines. They ride ATM from the DSLAMs (could be as many as four; one port on each) to the AT&T aggregation routers. They are switched from ATM to TCP/IP there, and ride AT&T TCP/IP transit to the Sharedband aggregators. Those could easily be four different routes, and even complicated more if Sharedband is not peering directly with AT&T; your packets could be running on Level 3, or XO, or Cogentco between AT&T and Sharedband. I can't begin to guess how many peering choke points could introduce congestion which isn't on a gateway.

I am sorry, this is complicated beyond my expertise.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum

smbtamu

join:2009-08-11

1 edit
reply to d_l

Thanks so much for your help guys. I really appreciate it.

If I had to guess, I'd say the statement about aggregating/disaggregating the packet traffic sounds right. I'm not exactly sure what technology they are using for the bonding. Maybe VPN?

I have the WAN port of my wireless LAN router connected to one of the sharedband router's LAN ports. The sharedband (Linksys WRT54GL) routers are all hooked together via ethernet on their LAN ports. Each WAN port on the sharedband routers are connected to a DSL modem.

The Linksys routers with custom Sharedband firmware work together to split up the traffic and send it out through the DSL modems and over the Internet to an aggregation server running SharedBand's software (right now in Atlanta). The aggregation server then combines the traffic and sends it on its way to the destination.

This process reverses itself for the return packets.

I will run a wireshark test later on tonight.

Does any of the above help?