Understanding OLC

The OLC function takes effect once the CPU usage reaches the OLC start threshold. OLC uses the multi-level leaky bucket algorithm to control the monitored protocol packets and tasks. A token bucket is used to determine whether the monitored protocol packets or tasks are allowed to be sent to the CPU, while multi-level leaky buckets determine the rate at which they are sent.

Currently, the tasks monitored by OLC include the ACL task and ARP broadcast task. For details about the OLC-monitored protocol packets and whitelisted protocol packets, see OLC-Monitored Protocol Packets and Whitelisted Protocol Packets.

Token Bucket

A token bucket is used to hold tokens, with the maximum number of tokens allowed in a token bucket representing the maximum packet processing capability of the CPU. A leaky bucket can only send packets to the CPU after being allocated tokens by the token bucket, which in turn is allocated a certain number of tokens by the system at an interval of 1 second. To control the number of packets sent to the CPU, OLC automatically adjusts the number of tokens allocated to the token bucket based on the CPU usage. That is, when the CPU usage exceeds a specified threshold, the system reduces the number of allocated tokens. After tokens in the token bucket are used up, new packets entering the leaky buckets cannot be sent to the CPU, thereby reducing the load on the CPU.

Multi-level Leaky Buckets

The analogue of a leaky bucket is a counter, which increments by 1 every time a packet enters the leaky bucket and a token is obtained for the packet. If the counter reaches the preset threshold, subsequent packets may be discarded. The counter is also decremented by 1 after a packet leaves the leaky bucket. The rate at which the counter is decremented is equivalent to the rate at which the leaky bucket sends packets to the CPU.

The multi-level leaky buckets used by OLC include the top, middle, and bottom leaky buckets. The top leaky bucket controls the leaky buckets in the entire system. Middle leaky buckets include the task leaky bucket and protocol leaky bucket. Bottom leaky buckets are associated with specific monitored protocols and tasks. According to the priorities of services, OLC assigns each leaky bucket a weight, which determines the number of resources, or tokens, that it can apply for. This mechanism ensures that different services are processed in a fair manner.

Figure 1 shows how multi-level leaky buckets can be implemented. The capacity of the top leaky bucket is equivalent to the maximum processing capability of the CPU. OLC takes effect when the CPU usage reaches the OLC start threshold. Before the monitored protocol packets and tasks are sent to the CPU, they enter the corresponding bottom leaky buckets, which apply for tokens from upper-level leaky buckets. These packets and tasks can be sent to the CPU only after tokens are obtained. In addition, the multi-level leaky buckets adjust the leak rate to control the rate of packets sent to the CPU.

Figure 1 Implementation of multi-level leaky buckets

• Weighted water level of multi-level leaky buckets

  OLC assigns each leaky bucket a weight, which determines the number of resources, or tokens, that it can apply for. The resources allocated to each leaky bucket determine its weighted water level. Figure 2 shows an example of weighted water level allocation for multi-level leaky buckets. The initial weighted water level of the top leaky bucket is equivalent to the total number of tokens that can be applied for when the CPU usage is 95%. The weighted water level resources of the top leaky bucket then are allocated downwards to leaky buckets level by level according to weights of the leaky buckets. At each level, the sum of the weighted levels of all leaky buckets is the same as the weighted water level of the top leaky bucket.

  Figure 2 Weighted water level allocation for multi-level leaky buckets
  

• Water level update for multi-level leaky buckets

  The water level of a leaky bucket refers to the number of packets for which the leaky bucket needs to apply for tokens. The water levels of leaky buckets at each level are updated according to the token applications and weighted water levels. The detailed water level update process is as follows:

  1. After monitored protocol packets or tasks enter the corresponding bottom leaky buckets, tokens need to be applied for and the water levels of the bottom leaky buckets raise. Accordingly, the water levels of the middle and top leaky buckets raise by the same degree.
  2. The bottom leaky bucket checks whether the current water level exceeds the weighted water level. If not, tokens are successfully obtained and the packets are sent to the CPU. If so, the system applies for resources from the upper-level leaky bucket. If the water level of the upper-level leaky bucket does not exceed the weighted water level, tokens are successfully obtained and the packets are sent to the CPU.
  3. After packets leave the bottom leaky buckets, the water levels of the bottom, middle, and top leaky buckets fall by the same degree.

• Idle resource allocation to leaky buckets that lack resources

  If the water level of the top leaky bucket exceeds the weighted water level, the entire system lacks resources. The system updates the water levels of leaky buckets every second and calculates the resources that the leaky buckets at each level lack. The idle resources of leaky buckets can be assigned to those that lack resources.

  

  The idle resources of leaky buckets can only be assigned to the same type of leaky buckets, that is, protocol leaky buckets or task leaky buckets.

  Figure 3 shows an example of idle resource allocation to a leaky bucket that lacks resources.

  1. The system calculates the differences between the current water level and the weighted water level of each leaky bucket to find the leaky buckets with idle resources and those that lack resources.
  2. Idle resources of upper-level leaky buckets are allocated to those lacking resources level by level based on weights of the leaky buckets.
  3. If all idle resources in the system are used up and there are still leaky buckets lacking resources, excess protocol packets are discarded or tasks are delayed.
  Figure 3 Idle resource allocation to a leaky bucket that lacks resources
  

• Water level threshold setting for leaky buckets

  If a protocol or task leaky bucket consumes all of the resources of the top leaky bucket, the system may process other services unfairly. To prevent this, the system calculates and sets the water level threshold for a leaky bucket that lacks a lot of resources based on the resources of leaky buckets at each level. After the water level threshold is set for a leaky bucket, it is not allowed to apply for resources from the upper-level leaky buckets if the current water level of the leaky bucket is greater than its weighted water level and the water level threshold.