Negative. There's no queueing mechanism to manage the order in which packets are processed - marking them won't do anything if the customer link is congested (assuming standard consumer cable/DSL).
Home routers (that I've seen) can only effectively *reserve* bandwidth for an application which is not really desirable for most.
Traffic shaping is the only real way to create a queue which can be managed (apart from TCP fiddling which is not available in consumer devices to my knowledge).
Unfortunately most people see "QoS" in a home router webconfig and think this is how QoS can be enabled. Or they see the feature in an OS/app pkg and think that configuration of same will solve their QoS problems. This is mostly not the case.
Those suggesting DD-WRT, ipcop etc are doing so out of ignorance of the issues surrounding effective QoS. I have experience with provider networks and business implementations of traffic management which has provided me with an understanding of the issues involved.
Without an essay, the root of the issue of effective QoS is queueing. Simply marking packets or applying a queuing strategy will usually not provide effective control.
In a situation where a link is a simple, as-designed ptp situation with no re-encapsulation QoS can be effectively implemented using in-box configuration.
Home routers and OS-based control will work provided QoS is configured at each endpoint.
Unfortunately few people have the kind of service which out-of-box QoS can be used effectively.
Have a read of my blog entry on the subject for further detail: http://benryanau.spaces.live.com/blog/cns!E55F3F5F75B5A7BB!126.entry
There are three options available: implement artificial queuing on a traffic-shaped interface at each end, use software or a router that can 'poison' and manage non-realtime traffic when realtime traffic is present, or the practical solution: buy more bandwidth.
Until the ISP industry gets it together and develops a mechanism for large-scale access networks to provide customer interface queueing at each end of the link, this is the situation we're in. Hope this sheds some light on the topic.
Slashdot Mirror
Negative. There's no queueing mechanism to manage the order in which packets are processed - marking them won't do anything if the customer link is congested (assuming standard consumer cable/DSL). Home routers (that I've seen) can only effectively *reserve* bandwidth for an application which is not really desirable for most. Traffic shaping is the only real way to create a queue which can be managed (apart from TCP fiddling which is not available in consumer devices to my knowledge).
Unfortunately most people see "QoS" in a home router webconfig and think this is how QoS can be enabled. Or they see the feature in an OS/app pkg and think that configuration of same will solve their QoS problems. This is mostly not the case. Those suggesting DD-WRT, ipcop etc are doing so out of ignorance of the issues surrounding effective QoS. I have experience with provider networks and business implementations of traffic management which has provided me with an understanding of the issues involved. Without an essay, the root of the issue of effective QoS is queueing. Simply marking packets or applying a queuing strategy will usually not provide effective control. In a situation where a link is a simple, as-designed ptp situation with no re-encapsulation QoS can be effectively implemented using in-box configuration. Home routers and OS-based control will work provided QoS is configured at each endpoint. Unfortunately few people have the kind of service which out-of-box QoS can be used effectively. Have a read of my blog entry on the subject for further detail: http://benryanau.spaces.live.com/blog/cns!E55F3F5F75B5A7BB!126.entry There are three options available: implement artificial queuing on a traffic-shaped interface at each end, use software or a router that can 'poison' and manage non-realtime traffic when realtime traffic is present, or the practical solution: buy more bandwidth. Until the ISP industry gets it together and develops a mechanism for large-scale access networks to provide customer interface queueing at each end of the link, this is the situation we're in. Hope this sheds some light on the topic.