We are going to upgrade and download some WAN links. Colleagues want to know if the pre-configured traffic-shape rate limit is higher than the actual bandwidth, the configuration is not effective ? since network traffic never goes higher than the actual bandwidth, traffic will be dropped or retransmitted, right ?
e.g. we configured "traffic-shape rate 5M 5M 5M 1000", but the actual bandwidth is 2M...then this configuration will not be effective, and traffic will not be affected ( no drop but just slow speed ) ?
if you send 3m of traffic into a 2m pipe, then something has to give once you fill up any buffers and packets will be discarded.
If you want to have some packets that are more likely to make it thru the link (ie they get QoS higher priority treatment than some others), then you have to manage the traffic to make that happen. Exactly what mechanisms you have to use depends on the equipment and CPU / hardware installed.
the idea is you need to have 2 or more "levels" of traffic handling.
top level handles shaping to a given overall rate, which matches the limitations of the pipe you have because the "pipe" has a bottleneck somewhere which is lower capacity than the port you connect to (think of a 10M Ethernet port, which terminates a WAN delivered over microwave / SDH where there may be only 2M of actual bandwidth)
then you do your QoS priority handling inside that traffic limiter - you decide what get high priority and what gets thrown away when there is an overload, what can burst, whether you use WRED for some traffic, and how many levels etc.
The rule of thumb is the higher the priority of a set of traffic flows then the tighter the limits on that QoS level should be if you want other traffic to get through at all. If you dont do that, then some traffic gets only intermittent access (which might make sense sometimes, but would be unusual).
Think if this as a tradeoff - you want QoS to get more control over what happens to some traffic, so you limit the total traffic and impose QoS within that. The flip side is you cannot let your traffic "free run" into the WAN bottleneck without potentially having the bottleneck break your assumptions about what is important and your QoS model.
1 related issue.
If you let traffic pile up at someone elses WAN choke point, you usually dont have much control over how much buffering is there - and too much can be as bad as none at all.
I recently had to look at an international link where when it was overloaded, the round trip time rose from 100 mSec to 4000 mSec. not good for apps that dont like high latency (or even the users trying to work at the remote site).
Good luck
The input packet handler at the constriction may not understand QoS / care about your markings etc, and when it throws away packets they may be what you regard as high priority.
this is happening more and more with WAN links presented as Ethernet.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.