The Traffic Manager (TM) on the forwarding plane houses high-speed buffers, for which all interfaces have to compete. To prevent traffic interruptions due to long-time loss in the buffer battle, the system allocates a small buffer to each interface and ensures that each queue on each interface can use the buffer.
The TM puts received packets into the buffer and allows these packets to be forwarded in time when traffic is not congested. In this case, the period during which packets are stored in the buffer is at microsecond level, and the delay can be ignored.
When traffic is congested, packets accumulate in the buffer and wait to be forwarded. The delay greatly prolongs. The interval from the time when a packet enters the buffer to the time when the packet is forwarded is called the buffer delay or queue delay.
The buffer delay is determined by the buffer size for a queue and the output bandwidth allocated to the queue. The format is as follows:
Buffer delay = Buffer size for the queue/Output bandwidth for the queue
The buffer size is expressed in bytes, and the output bandwidth (also called the traffic shaping rate) is expressed in bit/s. Therefore, the preceding format can also be expressed as follows:
Buffer delay = (Buffer size for the queue x 8)/Traffic shaping rate for the queue
As the format indicates, the larger the buffer size, the longer the buffer delay.
Jitter refers to the delay-difference between packets in the same flow. Typically, packets are sent at evenly spaced intervals. However, this interval may fluctuate and cause an irregularity of delay-difference between the packets. This irregularity is known as a jitter. Jitter negatively affects real-time services, such as voice and video services, by creating noticeable intermittence. A voice/video receiving terminal generally uses a buffer mechanism to minimize jitters. However, if jitters are too severe for the buffer mechanism to mitigate, the receiving terminal may experience voice or video distortion and intermittence.
Severe jitters are mainly caused by the following two scenarios: 1. Route status on IP networks frequently changes, causing packets to be transmitted through different routes. 2. Packets are buffered on various nodes during traffic congestion, resulting in different delays. Scenario 2 is commonly seen on live networks.
Jitters increase when packet delays become increasingly varied. If packet delays are controlled at lower levels, jitters are then also controlled. Therefore, you can control jitters by controlling delays. For example, if delays are controlled below 5 us, delay variations (jitters) are definitely below 5 us.
As described in Impact of Queue Buffer on Delay, large buffer sizes increase buffer delays. Controlling buffer sizes means control over packet delays.
The maximum buffer size can be set on NetEngine 8000 Fs.
The buffer size cannot be set too small. If the length of a queue is too small, the buffer is insufficient even if the traffic rate is low. As a result, packet loss occurs, triggering jitters.
The buffer size cannot be set too large. If the length of a queue is too large, the delay increases along with it. Especially when a TCP connection is set up, the sender sends a packet and waits for a response. If no response is received within the timer timeout period, the sender retransmits the packet. If a packet is buffered for a long time, the packet has no difference with the dropped ones.
As described in Impact of Queue Buffer on Delay, Buffer delay = (Buffer size for the queue x 8)/Traffic shaping rate for the queue.
The following format can be inferred:
Buffer Size for a Queue (bytes) = Traffic shaping rate (bit/s) x maximum delay that is allowed (s)/8
High-priority services require that the delay be shorter than or equal to 10 ms, and low-priority services require that the delay be shorter than or equal to 100 ms. Therefore, setting the buffer size to a value (10 ms x traffic shaping rate) is recommended for high-priority queues (CS7, CS6, and EF); setting the buffer size to a value (100 ms x traffic shaping rate) is recommended for low-priority queues.