Downstream QoS on an Internet ADSL - 877W

Unanswered Question
Sep 10th, 2007

Hi,

I'm running an 877W at home and I'm trying to configure QoS on my downstream link. The theory is if I set my downstream bandwidth to 80% of the link speed, the choke point is under my control and I can choose what gets discarded. It works just fine on the Linksys that I just replaced (google wondershaper if you're curious).

I have my upstream service policy working fine on the dialer interface, but cannot figure out how to apply one downstream. Obviously I can't apply queueing inbound on the dialer interface and my ethernet and wireless interfaces are bridged together with IRB. I don't want to apply the QoS on the hardware because I have 2 downstream interfaces (so how do I split the bandwidth?) and I don't want to limit ethernet to wireless traffic. I've tried applying both LLQ and GTS policies to the BVI and the interface will accept neither. I've also thought about marking the packets inbound and then applying something like WRED downstream but again this won't work on the BVI. I really don't want to rate limit my classes as this won't allow efficient use of the bandwidth when there is no congestion.

Any suggestions please.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Mon, 09/10/2007 - 03:09

Hi,

in short, you can't do absolutely anything for the downstream QoS. it is not a limitation of the router but a consequence of the "physics" of the itnernet where unless you controller a point of congestion, you can't set QoS on that.

So you can just hope the ISP gives priority to DSCP EF, that is becoming more and more frequent.

If it was working with the linksys, we should understand what and why was working, because there is no easy explanation.

joe.bennett Mon, 09/10/2007 - 03:25

>but a consequence of the "physics" of the itnernet where unless you controller a point of congestion, you can't set QoS on that

That's exactly the point, if we rate limit at below our downlink speed then the queue (usually) moves under our control, and we can choose to allow interactive traffic, and drop bulk traffic. It's not perfect (we can't guarantee what happens elsewhere), but it stops our ISP queueing/dropping and moves it to our control.

Re-reading http://lartc.org/howto/lartc.cookbook.ultimate-tc.html actually talks about just rate limiting downstream - but I'm sure that we should be able to do something better. That script is what runs on the Linksys, at least with 3rd party firmware.

Paolo Bevilacqua Mon, 09/10/2007 - 03:33

Not exactly. If you rate limit input, that will not prevent the upstream node to still send data at his desire. Remember, when a packet has arrived already at the interface, it doesn't help that you throw it aways, as it will not prevent other packets to arrive.

If you want to control all what the router received, you can set a GRE tunnel, and do all the shaping/LLQ on there. As long the 877 only received from the tunnel, you effectively have control.

joe.bennett Mon, 09/10/2007 - 03:36

but if we start throwing away TCP packets then the flow throttles back - as in WRED. So we can throttle back the bulk traffic and let the interactive continue rather than let them all lose packets and throttle back.

Paolo Bevilacqua Mon, 09/10/2007 - 03:59

This is the method that packeteers and other "bandwidth manageres" uses - throw away stuff on input and/or output in the hope to slow down the senders.

Sometime it works, sometime it doesn't, for sure it messes with the nature of a TCP connection badly enough.

The difference is that when doing the "packeteer way" properly, it keeps track of each flow and drops or shapes with intelligence. Doing the same on the router with wred or policing will not attain the same effect, as the router will act practically random.

And, in any case, it will not have effect on UDP senders.

Conclusion, sorry, unless you want to add a device or software that uses the techniques above mentioned, and be prepared to be potentially disappointed, sorry, the router won't be able to fix the issue for you.

For your reference, the list of feature that you can do on the VLAN1 interface, is listed here:

http://cisco.com/en/US/products/hw/routers/ps380/products_white_paper0900aecd8064c9f4.shtml

Actions

This Discussion