Traffic shaping at home on an ADSL connection

With regard to Question 1, just adding to my router alternatives: Cisco 837. Cheapest option but will it do the job?

You can determine whether traffic shaping is supported by researching the IOS image & platform on the Cisco website. A 1720 is fine with a WIC-1ADSL with 16MB flash/48MB DRAM, but the cost of those items purchased used ($500+) would far exceed the cost of a used 837 on eBay for around ($350). I think that you can also do traffic shaping on and

827/827-4v with a late 12.3/12.4 IOS.

It also depends what other functi>With regard to Question 1, just adding to my router alternatives: Cisco 837.

have a look at the new 1801 - $1000 list bundle including ADSL (and ISDN backup if you want that) - no embedded Voip interfaces - which is the only reason you would have gone for 1751 over a 1721.

Yes

usually you dont - HTTP is well behaved compared to many protocols, so voice, streaming and various others tend to be given higher priority.

The big problem here is that shaping / priority only works if your router can control which packets get sent into the bottleneck on a path

with an Internet feed (which is what this sounds like), you cannot apply priority to the stuff you get sent by your ISP - they would have to do that.

Thank you both.

It looks like I may settle for the 837 as I don't really need any additional bells and whistles offerred by the other models and cost is the main factor here since this is only a router for home use. That makes the 1800s bit too pricey for my wallet :(

I understand that in a corporate environment one would want to prioritise delay sensitive traffic such as voice but in my home environment where the majority of traffic is related to large data transfers and email and http, I need to make http #1 to counteract the link saturation that occurs at times of large file movements. This is the main reason why I need a router that is QoS-capable.

With regard to an internet connection, why would I not be able to prioritise the traffic entering my LAN? Does that mean that I would have to have 2 routers connected in series to one another before splitting the feed to my local PCs? Seems a bit of an overkill...

it's not what's entering your lan that's the problem, it's what the ISP pushes down your pipe. You have no control over what they push.

I don't follow. How can an ISP be pushing something down my pipe that I did not request? If I'm downloading files and requesting web pages what else is there in the equation?

The bottom line is: I want to give HTTP traffic the top priority irrespective if what's entering or exiting my LAN.

Ooops...typo...the latter should have read: "...irrespective if it's entering or exiting my LAN."

The "bottom line" is you can't control what enters your link. Send me your IP address and I can send you unsolicited traffic. I can fake the source address so that you don't even know the origin of the traffic.

I bring up new internet connections from time to time and unsolicited traffic to the address range usually appears right away. I assume that the source is malicious code loaded into millions of computers that are scanning the whole address space looking for new machines to infect.

Even in the case where the traffic is requested by you you cannot control to achieve effective traffic shaping. A simple example is you request a file download. You have no direct control of how TCP manages the download.

That is interesting:- In principle, in the case of TCP, it should be possible to regulate the receive window to manage the network load. I have never heard of this being done (but then I don't listen very hard:).

With UDP though this control is not possible even in principle.

Hmmm...this thread has taken a detour.

I agree that unsolicited traffic hits my router on a daily basis. However, at any given time such traffic does not take up a noticeable amount of my bandwidth. Hence, as far as I'm concerned, and for the purposes of my original question, the traffic going across my internet connection is ONLY traffic that I have requested.

So once again let me re-iterate what I am trying to achieve here:

1) If I do not perform any data downloads/transfers from PC #2 to the internet and back, then PC #1 can browse web pages, send emails and do whatever it likes. This is irrespective of whether there is any unsolicited traffic going across my link or not. As such, for the purposes of the exercise, bringing up the notion of me being unable to control what my ISP sends me is irrelevant. Why? Because any unsolicited traffic that I may get does not in any way have an impact on my ability to use PC #1 for the tasks outlined above.

2) Once PC #2 starts performing heavy data transfers, the internet link gets saturated and PC #1 starts having problems. Web pages take a very long time to load or they just simply time out. Emails are unable to be sent or received as the connection to an external mail server times out. If I stop the data transfers on PC #2, PC #1 can once again perform its tasks.

So, in summary, there's only one reason why my link gets saturated and only one reason why PC #1 cannot perform its normal web related tasks: heavy data transfers on PC #2.

As such, I would like to go back to my original question, that is, what is the best way to control MY traffic going across the internet connection so that the web related tasks of PC #1 are unafffected?

Apologies if only now I am making myself clear on what I am trying to achieve and thanks to everyone that has responded so far.

Thanks, Voitec

yes - and that assumes all the traffic is TCP. Streamed audio or video often doesnt react to network conditions at all.

This is practical, and devices like the Packeteer boxes use TCP parameter manipulation to try to regulate the stuff coming down a link. Since the TCP parameters are "end to end"

in principle you can do this anywhere on the path between the end points, unlike conventional traffic shaping in a router, which acts on streams of packets leaving its interfaces and only directly affects downstream traffic.

The problem is TCP can have a control loop with a long reaction time - imagine a UK PC pulling HTTP data from the US west coast, where the round trip time is a good fraction of a second. So, any actions your device took on TCP going out of your ISP link wont have any affect until at least the packets and any reaction to it traverse all the hops along the connection.

Since HTTP TCP connections in general dont last all that long (often just a few round trip exchanges of packets), TCP manipulation is not as effective as shaping the flow directly in the intermediate routers.

Ok - but the application using UDP may be - things like Real streaming have their own feedback mechanisms within the app.

Hi Voitec,

Completely unrelated to traffic shaping, I see a similar situation here on my ADSL link, IE when 1 machine is performing a task, another machine has a hard time getting a bite of the bandwidth. In fact if I perform 2 bandwidth demanding tasks on one machine, this same issue pops up between those 2 tasks. This never used to happen, it all started happening at exactly the same time as my ISP changed their DSLAM manufacturer...

According to the service provider, the change was made to make more efficient use of the "shared" bandwidth upstream from the DSLAM. This "improvement" was obtained by a huge buffer in the DSLAM and code to slow down the rate of transfer INTO the DSLAM from the source point, to REDUCE DROPPED PACKETS, by providing time for the DSLAM to alter the window size and therefore the data rate used by the source point. This was the "official" reason for their action, but...

In reality what this does is reduce the TCP retransmits, allowing the upstream links to operate at optimum capacity/efficiency. The negative effect of this "Bandwidth management" is to cause multiple streams to one destination point to be queued in an unnatural manner, destroying low latency services such as VoIP, and even audio streaming, from operating effectively. Managing the bandwidth from the end users perspective is almost impossible in this situation. This means the ISP can then charge extra money to provide legacy Telephone services in "Competition" to their ADSL service.

The unanimous agreement from the local ADSL user base here is that the sole purpose of this change was to make more money from the end user.

As we operate here (NZ) in an almost single supplier environment, there is not a lot that can be done about it. This may have absolutely nothing to do with your situation, but I thought it worth mentioning.

Cheers..............pk.

Thanks for the Packeteer and Real networks comments. I had heard of packeteer and heard some outlandish seeming statements about it's capabilities but I hadn't previously realised the previously discussed TCP window management mechanism as a possibility.

Thanks Peter. Well, that has put a nail in the coffin so to speak.

I'm in OZ but am not sure of the DSLAM boxes in use. They are probably either Siemens or Alcatel.

With regard to your mention of DSLAM buffering, I would have thought that if it exists on my exchange then all traffic would be buffered. That includes FTP and HTTP traffic from my PCs. So if the DSLAM does not discriminate against HTTP traffic as it treats all traffic in the same way, then going back to my original question, why can't I then prioritise this traffic on its way out/back?

Example: Traffic leaving PC#2, FTP, is marked with IP Precedence=0 at my gateway router, HTTP traffic from PC#1 is marked with IP Precedence=5 at the same router. Hence HTTP traffic is the first one to leave my side of the link to the ISP. FTP traffic follows. Then the DSLAM buffers the traffic coming from my end slowing it down. However, the IP Precedence of this traffic is not altered and the traffic then moves out to its destination. On the way back ot the DSLAM, the above traffic may or may not be buffered. Irrespective of that, when the HTTP and FTP traffic hits my ADSL interface on the way back, it is again marked with IP Precedence=0 for FTP and IP Precedence=5 for HTTP. As such, PC#1 is the first one to receive its packets.

What I still don't understand is why, with my very limited Cisco QoS knowledge, I'm unable to set up the outgoing ADSL interface of the router to prioritise, let's say, the few struggling HTTP packets attempting to leave my LAN, so that they can overtake the thousands of bytes of ftp traffic, get out to the internet quicker and on their way back overtake the ftp packets coming in.

Sorry if I'm going in circles but I just can't get my head around this...

maybe - the issue is that QoS is basically looking inthe transmit buffer to choose which packet goes next - but that choice only makes any sense when you have multiple packets to choose from.

So, if a transmit oppotunity is there, and there is only 1 packet - QoS is not going to make any difference

finally - most IP devices ignore IP precedence etc unless explicitly configured to do so

Then the DSLAM buffers the traffic coming from

No - the likely slowest link from you to an Internet destination is the ADSL uplink (256 Kbps here in the UK). Once it gets to the DSLAM it hits an aggrgate link, with a capacity in 10s of Mbps.

However, the IP Precedence of this traffic is not

Maybe - some devices dont echo the precedence from incoming packets on outgoing packets on the same stream. And even if they did, QoS processing at intermediate networks may alter the marking.

Finally - the DSLAM is free to ignore IP precedence - and the telco is likely to force that config. Otherwise there is a risk that every clever user would be setting all of their traffic to high precedence, which might starve other users of bandwidth.

QoS is an end to end problem - not a lot of point setting it unless you are altering what happens at the major bottlenecks on the paths involved.

Hi Voitec,

We used to have Alcatel here but I think the aforementioned DSLAM's are Redback, but I can't be 100% certain.

Well the process I described is traffic type insensitive, it affects ALL traffic regardless.

As far as QoS is concerned, if you can't apply QoS rules to the entire path, you are pretty much wasting your time as there is a 99% likelihood your QoS is discarded along the way. Unless you have a specific segment issue that QoS can help with, but then you need to be able to manage the entire segment.

You can do this for what is leaving the end you manage, but that would be all. The real question is, what is going to happen when your data hits the next layer 3 part of the chain...

Cheers.............pk.

Gentlemen,

Thank you very much for the detailed explanations and you patience with me on this.

Cheers, Voitec