No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Qos car and Qos queue miss behavior on NE40E

Publication Date:  2012-07-27 Views:  79 Downloads:  0
Issue Description
NE40E V600R001C00SPC800 +Patch V600R001C00SPC015


3.problem detail:
Config “qos car cir 256 pir 400...” under the GE port of XXX network NE40E router for enterprise services speed limit. The speed limit can not happen properly when using PC to download from DC. The actual speed is less than the cir value.
After changed the configuration to “user-queue cir 256 pir 260” from CAR, the speed limit is OK, but ping latency increased. The latency of packets with load 1476bytes is about 30ms.

Alarm Information
Handling Process
2.The High Latency Of User-Queue.
2.1 a brief overview of equipment to achieve Qos queue mechanism.
As per the following diagram shows, User-queue also use Token Bucket for traffic controlling. But the difference is user-queue use buffer also. When the token numbers in token bucket are less than 0, the packets will be cached in the queue till the token numbers become more than 0. The filling speed of token bucket is same value as cir configured in “user-queue cir XXX pir XXX”, and the filling amount of token is fixed. Suppose the filling amount of token is Nbytes, then the filling time T = N*8/cir(s)

As per above analysis, when the token number is less than 0 in token bucket, (Token Bucket in User-queue allows token number to be negative, as the dotted line shows in the following diagram.) the next packet will be cached in the buffer queue, till the token number become to positive again. As the configured CIR is very small and the filling time T is big, while ping with load 1476Bytes (Packet size is 1504Bytes after L2 header added), the packet fragmented due to the size exceed 1500Bytes, and the first fragment consume the token and make the token number as negative, which cause the second fragment cached in buffer queue till the token number become positive.
This is the root reason of high latency of ping while use User-queue.

Root Cause
1. The Speed Limit Issue Of QOS CAR
1.1 a brief overview of equipment to achieve CAR mechanism.
CAR mechanism is achieved by Token Bucket. When the equipment receive any packets first it will get the proper token use for packets transit. Hence the packets transit required sufficient token in token bucket. If the number of token is less than the packets required, then it will be discard by router.

The command of configuring CAR is “qos car cir XXX pir XXX cbs XXX pbs XXX”. The size of Token Bucket is the CBS value. The filling speed of Token Bucket is the CIR value. Every packet will use several token. The system of equipment will calculate the time interval(△T) of last received packet and first received packet, and complete token filling. The amount of filling packet will equal to CIR*△T.
As per above analysis, system need to record the time of first received packet(t1) and last received packet(t2), in order to calculate △T. △T= t2 – t1. But the buffer used to record the time is limited, which means it will be reset by system periodically. Suppose this period is Nms. If the traffic continued time exceed Nms, after the buffer reseted, the △T calculation will be not correct. The calculated △T will be less than the expecting value, and the filling token also will be less than the expecting value, which will cause some packets discard by equipment, as there is no sufficient token in token bucket.
1.2 cause:
This is the route reason of why packets discarded by equipment while the traffic have not reach the speed limit.

Temporary Solution:

We can use User-queue to instead QOS CAR, but can not avoid the high latency. As per the equipment mechanism can not be changed.
Final Solution:
 Version upgrade.
QOS CAR issue will be resolved in the next version: V600R001C00SPCe00