TOKEN BUCKET WITH ACTIVE QUEUE MANAGEMENT

Abstract

A computer-implemented procedure that includes the following: Receiving a data packet (202A) at a network device (140) comprising a token bucket (505), wherein the data packet is processed by the token bucket at the network device; Adjusting the number of tokens allocated to the token bucket, adding tokens based on a configured rate and subtracting them in conjunction with processing the data packet; Determine the number of tokens allocated to the token bucket, including: If the token bucket contains zero tokens, initiate an initial action with the data packet; and if the token bucket contains more than zero tokens: Determine an active queue management (AQM) technique that includes a variable for the length of the queue; Replacing the queue length variable with a difference between the token bucket size and the number of tokens to create an improved AQM technique; Implementing the improved AQM technique on the network device to determine a tagging probability; and Initiating a second action based on the marking probability.

Description

[0001] The transmission of data packets over communication networks is widespread. When a large number of data packets are transmitted simultaneously, their processing can be delayed if the available network devices cannot handle the processing capacity. The sheer number of data packets then leads to an overload of the entire communication network.

[0002] One metric for minimizing network congestion is to set a predetermined rate of incoming packets. However, the rates of incoming packets can vary among the various network devices in the communication network. If a network device involved in processing data packets receives packets at a higher rate than it can handle, the data packets can back up, potentially leading to a delayed data packet queue.

[0003] Large-scale data processing congestion can occur when network devices are overloaded and the number of data packets queuing up becomes too large. A simple example: Network routers have a finite amount of buffer space for packets waiting to be transmitted over outgoing network paths. If the rate of incoming packets is too high, the queues can become so long that the routers' buffers are too full to adequately handle the incoming and outgoing traffic. In some cases, data packets are dropped, which can lead to data loss or further delays.

[0004] Traditionally, communication networks offer "best-effort" services, where all network users receive the same level of service. However, a network Quality of Service (QoS) policy allows the network to offer different levels of service to different users, connections, data types, protocols, requesting devices, network environments, geographic locations, and so on. For example, some users might receive higher priority, higher bandwidth, or lower latency from the network. QoS can be implemented through network devices and network traffic rules using QoS primitives implemented in the network devices.

[0005] A QoS primitive runs on a network device and performs various tasks related to QoS policies. In some examples, the QoS primitive can process packets and enforce QoS policies across the network. In other examples, in a platform-independent implementation, the QoS primitive can inform devices about QoS requirements, process data packets, and make decisions that affect the packet's service level, such as when the packet is forwarded by the device. Some examples of QoS primitives include a priority queue (e.g., each data packet has an assigned priority value, and the highest-priority packet is transmitted / processed first) and a policer (e.g., monitoring traffic to enforce the associated QoS policy and dropping or marking non-compliant traffic).

[0006] US 2014 / 0301195 A1 relates to methods and devices for allocating contributions to the overload of a shared resource to the respective user registers.

[0007] US 2020 / 0053018 A1 refers generally to the field of communications and, in particular, to techniques for managing the flow of data over wireless and wired access networks. Brief description of the drawings

[0008] The present revelation is described in detail in accordance with one or more different examples, with reference to the following figures. The illustrations are for illustrative purposes only and show only typical examples. Fig. Figure 1 shows a communication network that uses a QoS policy, according to some examples from the disclosure. Fig. Figure 2 shows the processing of packets to be added to a queue using active queue management (AQM) according to some examples from the revelation. Fig. Figure 3 shows the processing of packets to be added to a queue using an AQM technique with a PI controller according to some examples from the revelation. Fig. Figure 4 shows the processing of packets, replenishing tokens and removing tokens from a policer implemented with a token bucket, in accordance with some examples from the revelation. Fig. Figure 5 shows various components of the Token Bucket with Active Queue Management (TBAQM) and how it processes packets, according to some examples from the Revelation. Fig. Figure 6 shows a process implemented by the Token Bucket with Active Queue Management (TBAQM) in accordance with some examples from the revelation. Fig. 7 is an example of a computer component that can be used to implement various features of the examples described in the present disclosure. Fig. Figure 8 shows a block diagram of an exemplary computer system in which various examples described here can be implemented.

[0009] The illustrations are not exhaustive and do not limit the present disclosure to the exact form that is revealed. Detailed description

[0010] The present invention is defined by the attached claims.

[0011] Existing QoS primitives have their limitations. For example, priority queues can struggle to scale to a large number of QoS classes (e.g., more than a thousand). Another example is the potentially poor performance of policers with ordinary TCP / IP (Transmission Control Protocol / Internet Protocol) traffic.

[0012] The use cases describe a token bucket with active queue management (TBAQM), which can correspond to a new type of QoS primitive offering better performance than traditional QoS primitives. TBAQM can limit the transmission or acceptance rate of network traffic by not using a queue (like most standard QoS primitives), but rather a policer implemented with a token bucket (e.g., when the policer takes the token bucket state as input). When the TBAQM policer processes packets, it can, for example, immediately make one of the following decisions: let the packet pass unchanged, modify a header value and then let the packet pass, or drop the packet. Which action is taken depends on the number of tokens in the token bucket and the output of the TBAQM.

[0013] TBAQM also improves upon standard QOS primitives by incorporating an arbitrary AQM algorithm (e.g., for a queue and based on a standard queue length or an estimated dequeue rate to manage traffic or packet processing). For example, TBAQM is implemented with a proportional integral control algorithm where the queue length variable is replaced by the difference between the area size and the number of tokens, and the estimated dequeue rate is replaced by the configured rate of the token bucket.

[0014] The TBAQM QoS primitive can reduce jitter and bursts in the communication network, resulting in smoother TCP traffic flow, minimizing network congestion, and reducing the time TCP is unable to utilize the bandwidth provided by the QoS primitive. In some examples, the TBAQM QoS primitive acts as an improved policer and, being a policer, can offer greater scalability than priority queues.

[0015] Technical improvements are realized through disclosure. For example, the token bucket with active queuing management (TBAQM) described here can reduce congestion, implement a large data packet burst size to increase the efficiency of packet transmission across the network, and decrease packet loss. This can improve the data network overall. These technical improvements can also be used by users who rely on the communications network. For example, real-time applications (e.g., video streaming) will be less frequently affected by high network utilization, and the number of dropped data packets or network transmission problems by TCP applications can be reduced.

[0016] Furthermore, TBAQM can create a scalable QoS primitive that performs well with TCP congestion control. It can replace traditional token buckets, which are less sensitive to burst size configuration, better regulate TCP throughput, and better support burst traffic.

[0017] Furthermore, TBAQM can be implemented in hardware and software on any network device to implement QoS control and rate limiting. By implementing packet processing as a service, TBAQM can enhance the QoS offering for users and enable them to better manage their network. Improved scalability can be achieved with more granular QoS implementations, and it can support a large number of tenants or applications.

[0018] Fig. Figure 1 shows some conventional forms of implementing a communication network using a QoS policy, according to some examples from the disclosure. In the computer environment 100 shown, there is a sender computer device 110, a network 120, and a receiver computer device 130.

[0019] In this figure, the sending computer device 110 transmits one or more data packets over networks 120 (represented as the first network 120A and the second network 120B) to the receiving computer device 130. The sending computer device 110 and the receiving computer device 130 (e.g., clients, servers) can be endpoints in a communication network that connects the endpoints. Different sending computer devices can send data packets to different receiving computer devices, although for simplicity, a single sending computer device and a single receiving computer device are shown.

[0020] The computer environment 100 can connect these and other computer devices (e.g., client devices or servers) to forward data packets and enable data transfers between the sending computer device 110 and the receiving computer device 130 over the network 120. Each of these devices can forward data packets from a source to a destination, regardless of whether the source is the original device that generated the data packet or the original receiver that will ultimately receive the data packet. Each of these devices can be located along the network path, which may traverse multiple network devices.

[0021] The default forwarding behavior of a network device's computer environment (100) can correspond to a "best effort" approach for transmitting the data packet. Each packet is forwarded in the same way, ensuring that every network user receives the same level of service when transmitting their data. The network's best effort approach is typically based on data packets, giving each user an equal chance to forward their data packet.

[0022] The computer environment 100 can enable the transmission of data packets using QoS policies. These QoS policies can offer different service levels for data packets transmitted over the network 120. In some examples, the QoS policies can correspond to a number of QoS classes or QoS policies, with each QoS class being the management unit for QoS policies. Each QoS class can also correspond to a different service level. For example, one QoS class might receive higher priority, higher bandwidth, or lower latency than another QoS class. User and network device traffic can be assigned to the different QoS classes based on complex policies implemented by the network device 140.

[0023] The network device 140 can be roughly divided into three parts: the QoS controller 142, the QoS classifier 144, and the QoS primitives 146. In some examples, the QoS controller 142 is implemented outside of the network device 140, and a single QoS controller 142 can manage a variety of QoS devices. In some examples, the QoS primitives 146 may include a scheduler. In some examples, the network device 140 can be thought of as comprising these three QoS-related parts: the QoS controller 142, the QoS classifier 144, and the QoS primitives 146. The QoS primitives 146 generally process packets, implement the QoS class, and enforce the QoS policy. The QoS primitives (146) determine a packet's priority, when it should be forwarded, or whether it should be dropped. These primitives can be configured manually by an administrator or dynamically via the QoS controller (142).

[0024] The QoS controller 142 is configured to manage QoS policies. It can assign users to a class based on their identity, needs, and QoS policies, and verify that users are not violating the policy terms. It can manage QoS policies and modify the overall allocation of network resources to achieve the objective of each policy. In some examples, the QoS controller 142 is not implemented programmatically, and the network administrator configures the QoS policies statically on the network devices.

[0025] The QoS classifier 144 is configured to detect traffic and assign it to the appropriate QoS class. There are many different ways to implement such a classifier. In some cases, the application on the sending device can label the traffic with the QoS class by, for example, populating the DSCP (Differentiated Services Code Point) field of the TCP header with the appropriate value. In other cases, the network device can use sophisticated packet analysis and deep packet inspection to derive the QoS class from the traffic itself.

[0026] QoS primitives (146) can be implemented in network devices that process packets, implement the QoS class, and enforce the QoS policy. They determine a packet's priority, when it can be forwarded, or whether it should be dropped. QoS primitives can be configured either manually by a management user or dynamically via the QoS controller (142).

[0027] In some examples, the computing environment 100 can implement one or more network queues and scheduling in the QoS primitives 146. A scheduler can be part of the QoS primitives. The scheduler can be implemented with a single queue or a set of queues and can decide the order in which packets are processed and how often packets are processed. With a suitable set of queues and a QoS classifier, very complex and sophisticated QoS policies can be implemented.

[0028] Fig. Figure 2 shows the processing of packets to be added to a queue using active queue management (AQM), according to some examples from the revelation. In this Fig. The active queue management (AQM) 230, the queue 240, and the scheduler 250 are intended to process one or more packets 202 in an updated QoS primitive 210 of the network device 140. The remaining devices and networks can be assigned to the Fig. The example shown in 1 remains similar, including the sender computer device 110, the network 120, the receiver computer device 130, and the other components connected to the network device 140 (e.g., QoS controller 142 and QoS classifier 144).

[0029] In some cases, Scheduler 250 can prioritize packets. For example, some queues are given priority over others. The classifier can decide which queue the received packet should be placed in. Scheduler 250 can then reduce the queues, starting with the highest priority queue. These packets in the higher-priority queues can be forwarded before packets in the lower-priority queues and thus have lower latency.

[0030] In some examples, Scheduler 250 can also control bandwidth. The bandwidth control process by the scheduler can involve allocating a specific amount of bandwidth to specific queues, with each queue being assigned a QoS class. This allocation can be managed individually (e.g., by a management user) and maintain a specific service level.

[0031] The disadvantage of queues and Scheduler 250 is that they are complex and expensive to implement and do not scale well to a large number of classes. Theoretically, Scheduler 250 can be configured to query all queues for each packet to be forwarded in order to make a decision, and this scales linearly with the number of queues. To reduce the overhead of Scheduler 250, some schedulers remove packets from the queues in batches rather than individually; however, this reduces the effectiveness of QoS and can lead to performance issues with TCP congestion control.

[0032] The number of queues managed by Scheduler 250 can be a trade-off between the need for a larger number of QoS classes and the overhead associated with more queues. In most hardware and software implementations, the number of queues can be around 1024. Since the number of tenants and applications in a data center is constantly increasing, this number is insufficient to assign a QoS class to every tenant or application.

[0033] In some examples, queue 240 is implemented as a FIFO (first in, first out) queue. Incoming packets are simply added to the end of the queue (input) and retrieved by scheduler 250 from the head of queue 240 (output) for forwarding.

[0034] Some FIFO queues may have a maximum size, which corresponds to either a maximum number of packets or bytes. If packets arrive in the queue faster than Scheduler 250 can process them, packets can accumulate in the queue, and the queue can become longer. When the queue is full, incoming packets may be dropped, a phenomenon sometimes called "tail-dropping." During periods of heavy network traffic, queues may need to be large enough to handle high traffic volumes without dropping too many packets during normal operation.

[0035] In some cases, tail dropping can be avoided. One reason for avoiding tail dropping is that the discarded packet might need to be retransmitted to prevent data loss. This retransmission can take additional time and slow down processing for other packet transmissions. The congestion caused by discarded packets can indicate that too many packets are being sent to the queue over network 120.

[0036] Some traditional systems implement a version of TCP congestion control that relies solely on packet loss to regulate data transfer rates and prevent network congestion. These versions of TCP congestion control can detect network path congestion through repeated tail-dropping, and packet loss can then detect when the network is congested and trigger TCP congestion control.

[0037] In some cases, tail dropping and large queues can lead to performance issues with TCP congestion control. With tail dropping, TCP congestion control can stop forwarding data when the queue is full, so the queue is almost full on average (e.g., within a threshold of a maximum queue size). This results in high queue latency because newly transmitted data packets may have to wait for the entire queue to be processed. The congestion signal, represented by packet drop, may wait for the entire queue to be cleared, increasing the latency of the TCP control loop and potentially leading to TCP oscillations and starvation.

[0038] In some examples, active queue management (AQM) can address the shortcomings of tail dropping. AQM can implement a congestion signal with lower latency and finer granularity. AQM can add extra processing to the queue to discard packets before it becomes full. TCP congestion control responds to these losses by reducing its sending rate. The end result is that the sending computer device can slow down data transmissions before the queue is full, and the average queue size can be smaller. AQM can reduce overall packet latency and congestion signaling, which can improve TCP performance.

[0039] In some examples, AQM 230 can be implemented using random early detection (RED). RED can set a drop probability based on queue occupancy. For example, if queue 240 is nearly empty, the probability value can be close to zero, making packet loss very unlikely. Conversely, if queue 240 is nearly full, the probability value can be higher, making packet loss more probable.

[0040] Other methods can also implement AQM 230, such as Blue, Adaptive Random Early Detection (ARED), Proportional Integral Controller Enhanced (PIE), and Controlled Delay (CoDel). These methods can maintain low queue 240 occupancy by proactively and preventively dropping packets. The probability of dropping a packet can be based on the queue delay. For example, CoDel attempts to maintain the queue delay for data packets that are below a configured threshold.

[0041] In some examples, the use of AQM 230 can reduce packet loss, but not eliminate it entirely, because packet loss can slow down TCP congestion control. Explicit Congestion Notification (ECN) can incorporate a mechanism into the TCP protocol to transmit a congestion signal without dropping packets. A bit or flag in the TCP header portion of the packet can be updated from zero to one to indicate congestion. For example, the sending computer device 110 can set this bit to zero. In some examples, other network devices can also detect congestion by setting the bit or flag as well. The receiving computer device 130 can then pass the bit to the sending computer device 110. When the sending device 110 sees that the bit is set, it can assume that congestion is present and reduce its sending rate as if the packet had been dropped.

[0042] In some examples, ECN can be combined with a form of AQM 230 without implementing tail-dropping. If AQM 230 detects congestion in queue 240 and the packet supports ECN, the sending computer device 110 can set the ECN bit in the TCP header to signal this congestion instead of dropping the packets.

[0043] However, ECN may not be supported by all implementations. Therefore, if the network is congested, the device implementing AQM 230 can mark packets that must carry the congestion signal. If the packet supports ECN, it can be marked. This marking may cause the packet to be modified to set the ECN bit. Otherwise, marking the packet may cause it to be dropped.

[0044] The ECN bit can detect network congestion and compensate for packet loss. The ECN bit can have a statistical property. In particular, packet loss can be kept low to avoid network inefficiencies, so the probability that AQM 230 will drop a packet or set the ECN bit can be low (e.g., about one to two percent in practice).

[0045] Such a low probability of an overload signal can be problematic in practice. The overload signal can be generated at a relatively high level of overload. The overload can build up for some time before the ECN signal is sent. The response of the sending computer device 110 to such a signal can be strong, as it indicates a significant overload. In practice, this can lead to the signal not being sent frequently in accordance with the stored instructions and rules. This can cause a delay in notifying the sending computer device 110 about the new level of overload. This delay can make the entire feedback loop of the control system quite slow and unstable.

[0046] In some examples, the signal congestion experienced (SCE) method can be implemented as a more granular congestion signal. For instance, SCE can correspond to an adjustment of the congestion signal in Data Center TCP (DCTCP) that is not associated with packet loss. When implementing SCE, a bit / flag can be sent more frequently than with ECN and be associated with a lower degree of congestion. In some examples, the probability of SCE in the packet stream can encode the actual degree of network congestion. SCE can help TCP congestion control adapt more closely and quickly to the actual congestion, for example, by detecting network congestion without waiting until the queue is full.

[0047] Fig. Figure 3 shows the processing of packets to be added to a queue using Active Queue Management (AQM) with a PI controller, in accordance with some examples from the revelation. For example, the packets to be processed can be configured using the Proportional Integral Controller Enhanced (PIE) or Quadratic Proportional Integral Enhancement (PI) algorithms. 2 ) can be added to a queue, which can correspond to AQM techniques using the PI controller.

[0048] In illustrative example 300, both PIE and PI are used. 2AQMs are represented. For example, when a packet arrives, the PI controller 350 can calculate a packet marking probability, "p", and estimate the queue delay 342. The queue delay 342 can be based on the queue length 370 and the estimated dequeue rate 340. The PI controller 350 can then compare the queue delay 342 with the target delay 322 and determine the difference between the queue delay 342 and the target delay 322. A standard police controller might not implement a marking probability based on the number of tokens or a second action based on the marking probability.

[0049] The PI controller 350 can calculate the probability of marking packets "p" 360 based on the difference between the waiting time 342 and the target delay 322, using the parameters Alpha and Beta. Thus, Alpha and Beta can, for example, configure the strength of the PI controller 350's response. In some examples, Alpha and Beta can be set so that the PI controller 350 responds quickly enough but does not overreact.

[0050] The rejection probability "p" is compared with a pseudorandom process 320 324. This comparison helps decide whether the incoming packet should be marked. If it is determined that the incoming packet needs to be marked, the marking block 330 marks the packet, for example by either "discarding the packet" or "changing the ECN bit in the header". If it is determined that the incoming packet is not marked, it is passed unchanged to queue 370.

[0051] In some examples, a proportional-integral (PI) controller 350 can be implemented in the computer environment 300 to support the transmit computer unit 310 and the receiver computer unit 312. The PI controller 350 can maintain a process variable (PV) at a specific setpoint (SP). The PI controller 350 can, for example, measure the control deviation (e.g., the difference between PV and SP) and include two feedback components: one proportional to the control deviation and one that uses the integral of the control deviation. The proportional component can provide a larger correction when the two values ​​are far apart and a smaller correction when the two values ​​are close together (e.g., within a threshold). The integral component can eliminate sensing and actuation biases by tracking how the proportional component deviates from the target.

[0052] The Proportional-Integral-Enhanced Process (PIE) can apply the PI controller 350 and control theory to the AQM. The goal of the PI controller 350 is to keep the waiting time 342 of packets below a certain duration. PIE may not have a direct effect on the sending rate of packets at the sending computer device 310; therefore, the PI controller 350 can generate congestion signals using packet loss or setting ECN to achieve its goal. In some examples, the queue delay 342 may not be measured but derived from the queue length 370 and the estimated queue output rate 340. The PIE process can derive the optimal probability of packet marking from the predicted queue delay 342. Packet marking can be performed by discarding the packet or by setting the ECN bit in the packet header.

[0053] The PI procedure 2PIE can be improved by using the same PI controller 350 and modifying the formula and heuristic for deriving the packet tag to make it more universal and simpler. The PI 2 The process can generate finer-grained overload signals, roughly similar to the SCE process.

[0054] In some examples, a rate limiter is implemented in QoS primitive 146 of Computing Environment 100. Rate limiting can help enforce network policy. For example, the rate limiter can be used to ensure that traffic does not exceed a certain rate. This might be for policy reasons (e.g., as a result of a contractual agreement) or to smooth out the burst nature of network traffic.

[0055] Rate limiting can be implemented as a shaper. The shaper can correspond to a queue in which the scheduler cannot process packets faster than the promised rate. The queue within the shaper can help manage the burst nature of traffic and smooth it out, but it can also introduce delays. The shaper can behave like other queues discussed here and may present the same scalability issues.

[0056] Rate limiting can be implemented using a counter or a police controller. The police controller enforces the set rate by discarding excess traffic. The police controller does not need a queue; instead, it can process packets immediately and decide whether to keep the packet, discard it, or modify part of its header.

[0057] One of the challenges for the policeman is handling frequent traffic bursts. For example, when traffic arrives in a burst, the instantaneous rate can exceed the promised rate during the burst. When traffic arrives between bursts, the policeman may be inactive for a period of time, and the instantaneous rate may be lower than the promised rate. In some examples, the policeman may include a bursting mechanism that allows for average bandwidth usage across bursts. The policeman may also allow traffic to exceed the promised rate in the short term, as long as the longer-term average traffic does not exceed the promised rate.

[0058] In some examples, a token bucket or leaky bucket can be implemented. The token bucket can implement a rate limiter, a shaper (e.g., with a queue), or a policer (e.g., by dropping packets). The leaky bucket can be used as a shaper, similar to a token bucket.

[0059] Fig. Figure 4 shows the processing of packets, the replenishing of tokens, and the removal of tokens from a policer implemented with a token bucket, in accordance with some examples from the revelation. The policer 400 shown includes a token bucket 405 containing a multitude of tokens 415, which are added to and removed from the token bucket 405 as described here.

[0060] The 405 token bucket of the 400 police server can attempt to enforce a long-term rate for traffic passing through it (e.g., sometimes called a target rate or fixed rate). Enforcement can be achieved by dropping packets that exceed the fixed rate. Since some network traffic may be discrete (e.g., packets may not be split) or in bursts, the 405 token bucket may include a mechanism for enforcing average rates.

[0061] Policer 400 can perform an action 425 on the packet. Action 425 can enforce an existing rule to, for example, keep, drop, or modify the packet in some way (such as the packet header). In some examples, action 425 can be implemented by dropping packets that exceed the specified rate. Alternatively, action 425 can be implemented by changing the Drop Priority value in the DSCP field of the packet header, which may cause these packets to be dropped during subsequent processing.

[0062] Token bucket 405 can be a container for virtual credits or tokens 415, which allow for the smoothing and averaging of momentary fluctuations in incoming traffic. For example, when a packet is ready for forwarding, a number of credits or tokens 415 can be removed from token bucket 405 in block 410.

[0063] In some examples, an action 425 can be performed based on the number of tokens in token bucket 405. If token bucket 405 is empty (e.g., zero tokens), no tokens can be removed, and the packet can be discarded as action 425. Token bucket 405 can be replenished with tokens 415 at a constant rate (e.g., the desired binding rate) in block 420, and the size of token bucket 405 can correspond to a burst size (BS) and / or a maximum capacity. When token bucket 405 is full, new tokens can be discarded to prevent the token bucket from growing beyond its maximum size BS and to avoid excessively long bursts of packets.

[0064] Token bucket 405 can cause fluctuations in the instantaneous output rate. If the incoming traffic rate remains below the target rate for a period of time, token bucket 405 can fill up. When new traffic arrives in token bucket 405, the output rate can be unlimited as long as tokens are available in token bucket 405. The packet burst can have a rate much higher than the target rate (e.g., the burst rate). When token bucket 405 is finally empty, the target rate can be enforced for the traffic and / or other new data packets. In some examples, Policer 400 does not have a queue to handle traffic fluctuations and burst rates (e.g., token bucket 405). In these examples, token bucket 405 can use a bursting mechanism that allows traffic to briefly exceed its promised rate.

[0065] In some examples, the Policer 400 may not have a queue to handle traffic fluctuations and bursts (e.g., as in Fig. 2 and Fig. (3 shown). Instead, the Policer 400 can use a bursting mechanism that allows traffic to temporarily exceed its promised rate. This configuration of the bursting mechanism uses the burst size BS, the maximum number of tokens that can accumulate in token bucket 405. The burst size BS can represent a number of packets or bytes.

[0066] The configuration of the bursting mechanism can sometimes lead to poor policer performance. If the burst size (BS) is too small, policer 400 might not be able to handle a shared traffic burst. For example, the end of the burst might exceed the number of tokens available in token bucket 405, and the end of the packets might be dropped. Packet dropping can impact TCP, which can reduce the transmission rate. On the other hand, the idle time between bursts might not be fully credited towards the average rate because not enough tokens can accumulate in token bucket 405. In this case, the policer might not be fully utilized, and traffic might not use all of its allocated bandwidth.

[0067] If the burst size (BS) is too large, Policer 400 can generate long sequences of packets that exceed the set rate. During the burst, Policer 400 might not protect the downstream network from the excess traffic, and the long sequences can degrade the quality of service of other downstream traffic types. The excess traffic can cause downstream queues to overflow. In some examples, the long sequences can also increase TCP response time, as it may take longer for TCP to detect congestion loss. This can make TCP congestion control unstable, as TCP alternately sees a congested and an uncongested path.

[0068] The burst size (BS) can be configured as a compromise between being too small and too large. Some compromises may depend on traffic characteristics, such as the type of TCP congestion control, the total round-trip time of that particular path, and the timing behavior of other network devices (e.g., devices upstream of the Policer 400, devices that are not known in advance, or devices that may change over time). In some cases, the Policer 400 may not be configured to provide both good TCP performance and minimal impact (e.g., downstream network paths with high bandwidth latency).

[0069] Therefore, conventional network solutions may be unsuitable for managing packet delays (e.g., due to the difficulty of managing the bursting mechanism and the preference for using shapers, which are much more predictable and offer better performance).

[0070] The Policer 400 can implement rate limiting of network traffic using the Token Bucket 405. For example, the Token Bucket 405 can immediately decide whether to perform one of the following actions: allow the packet to pass unchanged, modify a header value and then allow the packet to pass, or drop the packet. The system's determination of a specific Action 425 can be based on the number of tokens in the Token Bucket 405. In some examples, Action 425 is only executed if the number of tokens in the Token Bucket 405 is zero. In other examples, Action 425 is executed depending on the Policer configuration and information present in the packet header (e.g., the value of the drop precedence in the DSCP field of the packet header or other values ​​in the data packet header).

[0071] Fig. Figure 5 shows various components of the Token Bucket with Active Queue Management (TBAQM) and how it processes packets according to some examples from the disclosure. The TBAQM 500 can be an updated QoS primitive 502 of network device 140. The QoS primitive 502 can implement TPBIC 500. The remaining devices and networks connected to network device 140 can be subject to the requirements outlined in Figure 5. Fig. The example shown in 1 remains similar, including the sender computer device 110, the network 120, the receiver computer device 130, and the other components connected to the network device 140 (e.g., QoS controller 142 and QoS classifier 144).

[0072] In some examples, TBAQM 500 implements an improved policyr from the one in Fig. The Policer 400 shown in Figure 4. Because TBAQM 500 implements a policer, it can also offer greater scalability than priority queues implemented as standard QoS primitives. TBAQM 500 can make traffic flow more smoothly, minimize the time the communication network is congested, and minimize the time TCP is unable to utilize the bandwidth provided by a QoS primitive implemented in other systems, such as the one in [reference to relevant documentation]. Fig. 4 Policer 400 units with token bucket as shown, as described here.

[0073] TBAQM 500 can be an enhanced QoS primitive 502 for rate-limiting traffic using a Token Bucket 505 and a PI controller 545 to generate fine-grained congestion signals and better integrate with TCP congestion control. TBAQM 500 can improve traffic queues and police officers by offering both high scalability and good performance with TCP traffic. TBAQM 500 can implement processes to (1) limit traffic to a configured bandwidth, (2) integrate with existing QoS frameworks, (3) increase scalability to support a large number of QoS classes without performance degradation and with a limited implementation footprint, (4) improve performance with a maximum TCP traffic throughput close to the configured bandwidth, and maintain QoS downstream of TBAQM 500 within a small timeframe.

[0074] Token Bucket 505 can be implemented using TBAQM 500. Token Bucket 505 can help implement rate limiting of network traffic by using a Policer 560 with the state of Token Bucket 505 as its input, instead of a queue. When the Policer processes the packets, it can, for example, immediately decide to perform one of the following actions at 525 or 570: let the packet pass unchanged, modify a header value and then let the packet pass, or discard the packet. Which action is performed depends on the number of tokens in the Token Bucket and the output of the TBAQM.

[0075] In some examples, action 525 can perform similar actions to those of action 425. Fig. The 4 actions described. For example, action 525 can enforce an existing rule to, for instance, keep, drop, or modify the packet in some way (e.g., the packet header). In some examples, action 525 can be implemented by dropping packets that exceed the specified rate. Alternatively, action 525 can be implemented by changing the Drop Priority value in the DSCP field of the packet header, which may cause these packets to be dropped during subsequent processing.

[0076] In some examples, action 570 may differ from action 525 in the timing of various actions. Whether action 570 is executed depends, for example, on the output of the PI controller 545. Which specific action 570 is executed may depend on the configuration of the TBAQM 500.

[0077] In some examples, TBAQM 500 can implement early loss mitigation using action 570 by utilizing token bucket 505, instead of waiting for the bursting mechanism to run out of tokens and then applying action 525. For instance, token bucket 505 can implement a bursting mechanism to average burst traffic. Experience with AQM and queues has shown that TCP performs better when the congestion signal (such as the bit / flag or packet loss) is transmitted earlier than the detection that the queue is full. Similarly, TCP can achieve better performance if the congestion signal from TBAQM 500 is transmitted earlier than the detection that the token bucket is empty.

[0078] In some examples, the solutions for eliminating the overload can be implemented gradually and proportionally to the degree of overload. This allows the overload signal to be sent to the sending device 110 earlier than with conventional policyholders, so that the TBAQM 500 can begin the overload notification before the token bucket 505 is empty.

[0079] TBAQM 500 can offer good TCP performance, although the performance of TCP congestion control over a complex network path is very difficult to predict. Many variations of TCP congestion control exist, and the system may not know which TCP congestion control is used for each traffic source utilizing the token bucket. Furthermore, TCP congestion control can be a moving target, as new TCP congestion controls are constantly being developed to better leverage the advantages of modern networks and AQM.

[0080] TBAQM 500 can resemble the existing AQM process that implements a queue instead of a token bucket, as described here. TBAQM 500 can replace the queue with a token bucket 505, which can respond to congestion in the same way as a queue with AQM, but differs from a queue in that it allows smoothing and averaging of instantaneous fluctuations in incoming traffic. In other words, the congestion signal profile for different levels of congestion can be similar to that of the AQM queue. In this way, TBAQM 500 can take parts of an existing AQM designed for use with a queue and adapt them to operate in the context of a token bucket, while simultaneously creating new properties that depend on the traditional queue characteristics.

[0081] An illustrative flow using TBAQM 500 is also provided. For example, tokens can be added to token bucket 505 (e.g., in a first step) in block 520. In some examples, tokens can be added based on a configured rate and subtracted based on the packets processed in block 510.

[0082] When token bucket 505 receives a packet 515, TBAQM 500 can determine if there are still tokens in token bucket 505.

[0083] If tokens are available, TBAQM 500 can calculate a marking probability of 545 based on the number of remaining tokens. In some examples, the marking probability of 545 can be calculated using the PIE or PI processes. 2This corresponds to the algorithms implemented by TBAQM 500 to calculate the marking probability 545 based on the number of tokens. In some examples, the marking probability 545 may correspond to the algorithm that increases the probability as the number of tokens decreases.

[0084] In some examples, TBAQM 500 can determine whether the packet should be marked. TBAQM 500 can use a pseudo-random process 550 to decide whether the packet needs to be marked. The pseudo-random process can be based on the marking probability.

[0085] In some examples, TBAQM 500 can forward the packet unmodified to the receiving computer device 130. This block can allow the packet to pass through in an unchanged state, neither discarding nor marking the packet.

[0086] In some examples, TBAQM 500 can determine whether packet marking is enabled in the packet and / or whether packet marking is implemented and configured in TBAQM. The determination in this block can either discard the received packet as action 570 or modify a value in the header of the received packet as action 570.

[0087] In some examples, TBAQM 500 can be statically configured to only drop packets or to perform only ECN (e.g., modifying the header value of the received packet) as action 570. In another example, packet marking can be achieved by modifying one or more other fields in the packet header. For example, action 570 modifies the SCE bit of the Type of Service (ToS) field in the packet header. In other examples, action 570 modifies the drop preference in the DSCP field in the packet header. In yet another example, a bit in the packet's TCP header indicates whether or not that TCP connection supports ECN. If ECN support is specified, the ECN tag is used. If no ECN support is specified, the packets are dropped.

[0088] In some examples, the packet can be dropped and not sent to the receiving computer device 130 as Action 570. Alternatively, the packet's header value can be modified as Action 570. For example, the bit or flag in the TCP header portion of the packet can be updated from zero to one to indicate congestion (Action 570). Once the packet value is modified, the packet can be transmitted from TBAQM 500 to the receiving computer device 130 as Action 570.

[0089] In some examples, the AQM process can be reimplemented in TBAQM 500, where the queue length variable is replaced by the difference between the size of the token bucket 505 and the number of tokens.

[0090] For example, a traditional AQM process can be at least partially adapted to a token bucket implementation by establishing a correlation between a policyholder and a tail-drop queue. The policies implementing the AQM process can then be applied to the tail-drop queue corresponding to the token bucket. For instance, the AQM process might measure a property of the queue. Therefore, if the policyholder has been replaced by a corresponding tail-drop queue, some properties of that queue can also correlate with the AQM process.

[0091] In Fig. The process can start with a token bucket 505 with rate TR, burst size BS (maximum number of tokens), and the current number of tokens Tn. For simplicity, TR is assumed to be in packets per second, and packets arrive at the token bucket at rate SP. If a queue were implemented instead of the token bucket 505, the corresponding queue would have a maximum size BS. Packets could be removed from the queue at rate TR, and the queue size would be Qn.

[0092] If SP is larger than TR (block 560), tokens can be consumed in block 510 at the rate of SP and replenished in block 520 at the rate of TR, resulting in a net decrease of SP - TR until Tn reaches zero. If a queue were implemented instead of token bucket 505, the corresponding queue would be filled at the rate of SP and emptied at the rate of TR. The net increase can be SP - TR until Qn reaches BS. Once Tn reaches zero in the token bucket, the promised rate can be applied, and packets can be dropped at the rate of SP - TR. For the queue: once Qn reaches BS, the queue can be full (in tail-drop mode), and packets can be dropped at the rate of SP - TR.

[0093] If SP is less than TR, tokens can be replenished in block 520 at the rate of TR and consumed in block 510 at the rate of SP, so the net gain can be TR - SP until Tn reaches BS. If a queue was implemented instead of the token bucket 505, the corresponding queue can be emptied at the rate of TR and replenished at the rate of SP, so the net decrease can be TR - SP until Qn reaches zero. If Tn is not zero for the token bucket, no loss occurs. For the queue: If Qn is not BS, no loss occurs.

[0094] In terms of losses, the token bucket 505 can behave like a tail-drop queue of the same size and rate, according to Qn = BS - Tn. Correlation can hold for losses and queue size between the token bucket and the queue, while packet delay and burst jerkiness can differ between them. The calculation of delay with the queue can depend on the queue size Qn and the rate TR. Correlation between the queue and the token bucket can also hold for the queue's input (e.g., when packets are added to the queue), while the token bucket's output and the queue's output can differ (e.g., the queue adds delays).

[0095] TBAQM 500 can also apply the AQM process to the state of the corresponding queue, which corresponds to the state of token bucket 505. In some examples, a process similar to CoDel can be implemented (e.g., not the CoDel process itself, as it is difficult to adapt to a token bucket). For example, CoDel can periodically remove packets from the queue output. This can be implemented using TBAQM 500, where packets are removed from the queue.

[0096] At PIE and PI 2 Processing at the queue input can be completed when a data packet is received from the queue. When a data packet is received, the PIE or PI decides. 2The process determines whether a task should be marked (e.g., discarded or modified) or placed in the queue. The fact that most of the processing occurs at the queue's entry point makes these processes highly compatible with a token bucket.

[0097] In some examples, PIE and PI measure 2 The queue length and queue output rate are used to estimate the queue delay. For a token bucket, the queue length is the difference between the bucket size and the number of tokens. For TBAQM 500, which implements Token Bucket 505, the queue length in processes PIE and PI is... 2 to be replaced by BS - Tn.

[0098] In some examples, PIE and PI can be used interchangeably. 2Use the average dequeue rate of the queue. Packets cannot be dequeued from the corresponding queue at a rate higher than TR (e.g., the promised rate of token bucket 505). The average output rate of the token bucket (e.g., when it is full) is its promised rate TR, so the output rate of the corresponding queue would be equal to and cannot exceed TR. The rate can be lower than TR if the input rate is lower than TR and the queue becomes temporarily empty.

[0099] However, a temporarily empty queue can lead to queue congestion, which negatively impacts the rate estimation for PIE and PI. 2This has an effect. In some examples, when estimating packet delay in the queue, it is assumed that the estimated rate applies when the queue is fully utilized processing packets, since starving the queue would not increase packet delay. PIE and PI 2 This underestimation of the rate can be ignored, since packet marking is only necessary if the queue is overloaded. Therefore, TR can be the correct estimate of the dequeue rate for the given queue, and when modeling the process according to PIE and PI. 2 The estimated rate can be replaced by TR.

[0100] Packet marking can be implemented if the token bucket is overloaded. In some examples, the average output rate of the token bucket may match its promised rate. The output rate of the corresponding queue may be the same, therefore TBAQM can implement PIE and PI processes. 2 The estimated rate is replaced by TR. In this way, TBAQM 500 can use a token bucket with a modified PIE or PI. 2 -Regulator 545 is included. The queue length variable can be replaced by the reciprocal of the number of remaining tokens, BS - Tn. The estimated rate variable can be replaced by the promised rate, TR.

[0101] In some examples, the PIE and PI can be used. 2The processes also include two configuration parameters, Alpha and Beta, which contribute to controlling the feedback. The PI controller 545 can determine the marking probability "p" based on the PIE or PI. 2 -process and using BS - Tn, TR, Alpha and Beta. These parameters can depend on TCP congestion control and can be implemented using TBAQM 500. For example, PIE and PI 2 The packet is marked by either modifying or discarding it, depending on its support for ECN and SCE in Action 570. This can also occur with a Token Bucket 500 implemented using TBAQM 500. In some examples, TBAQM 500 can generate ECN and SCE signals, which can help reduce packet loss.

[0102] TBAQM 500 allows the implementation of additional functions that complement those of PIE and PI. 2are similar. For example, TBAQM 500 can implement one or more heuristics that are available in PIE. In PI 2 The marking probability can be used with TBAQM 500 to support several types of congestion control (e.g., like classic TCP (probability is quadratic) and DCTCP (probability is non-quadratic)). If PIE and PI 2 When applied to a 505 token bucket in this way, they can modify or discard packets as if the token bucket had been replaced by a queue, so the effects on TCP can be the same.

[0103] TBAQM 500 can improve a policyholder by providing PIE and PI. 2It is used to signal congestion (e.g., send early congestion signals) by properly regulating TCP congestion control. In this example, it may be less necessary to keep the burst size of the Token Bucket 505 small, as the traditional drawbacks associated with a large burst size are much less likely. The burst size can be increased safely, making the Token Bucket 505 more suitable for burst traffic and also reducing packet loss. By using a larger Token Bucket 505 size and ECN and SCE tagging, TBAQM 500 can regulate TCP traffic with almost no packet loss and increase network efficiency.

[0104] Fig. Figure 6 shows a process implemented by the Token Bucket with Active Queue Management (TBAQM) in accordance with some examples from the disclosure. In this figure, TBAQM 500 can be seen from Fig. Perform these 5 steps.

[0105] In block 605, a token bucket 505 with TBAQM 500 can be implemented. In this first step, tokens can also be added to the token bucket based on a configured rate and subtracted based on the processed data packets.

[0106] In block 610, token bucket 505 can receive a data packet.

[0107] In block 615, TBAQM can determine if there are any tokens left in the token bucket. If there are no more tokens, the process can continue with block 620. If there are still tokens, the process can continue with block 625.

[0108] The received data packet is discarded in block 620.

[0109] In block 625, TBAQM can calculate a marking probability based on the number of remaining tokens, if any tokens are still available. In some examples, the marking probability can be assigned to the processes PIE or PI. 2 These correspond to algorithms implemented by TBAQM to calculate a marking probability based on the number of tokens. In some examples, the marking probability may correspond to the algorithm that increases the probability as the number of tokens decreases.

[0110] In block 630, TBAQM can decide whether the data packet should be marked. TBAQM 500 can use a pseudo-random process to decide whether the data packet needs to be marked. The pseudo-random process can be based on the marking probability. If yes, the process can continue to block 635. If no, the process can continue to block 640.

[0111] In block 635, TBAQM can forward the packet unmodified to the receiving computer device 130. This block can allow the packet to pass through unchanged, neither discarding nor marking it.

[0112] In block 640, TBAQM can determine whether packet marking is enabled in the data packet and / or whether data packet marking is implemented and configured in TBAQM 500. The determination in this block can either discard the received data packet or modify a value in the header of the received data packet. If yes, the process can proceed to block 650. If no, the process can proceed to block 645.

[0113] Several implementations are possible for block 640. For example, TBAQM can be statically configured to either discard only data packets or perform only ECN. In another example, a bit in the TCP header of the data packet indicates whether this TCP connection supports ECN. If ECN support is indicated, the ECN tag is used. If no ECN support is indicated, the data packets are discarded.

[0114] In block 645, the data packet can be discarded and not sent to the receiving computer device 130.

[0115] In block 650, the packet value in the header can be changed. For example, the bit or flag in the TCP header portion of the data packet can be updated from zero to one to indicate congestion. Once the packet value has been changed, the data packet can be transmitted from TBAQM to the receiving computer device 130.

[0116] In some examples, the AQM process can be implemented by replacing the variable for the length of the queue with the difference between the token bucket and the number of tokens.

[0117] For example, a traditional AQM process can be at least partially adapted to a token bucket implementation by establishing a correlation between a policyholder and a tail-drop queue. The policies implementing the AQM process can then be applied to the tail-drop queue corresponding to the token bucket. For instance, the AQM process might measure a property of the queue. Therefore, if the policyholder has been replaced by a corresponding tail-drop queue, some properties of that queue can also correlate with the AQM process.

[0118] This diagram assumes a token bucket with a rate of TR, a burst size of BS (maximum number of tokens), and a current number of tokens of Tn. For simplicity, we assume that TR is specified in packets per second and that data packets arrive at the token bucket at a rate of SP. The corresponding queue would then have a maximum size of BS. Data packets can be removed from the queue at a rate of TR, and the queue size would be Qn.

[0119] If SP is greater than TR, tokens can be consumed at the rate SP and replenished at the rate TR, so the net consumption rate is SP - TR until Tn reaches zero. The corresponding queue is filled at the rate SP and emptied at the rate TR. The net inflow can be SP - TR until Qn reaches BS. For the token bucket, once Tn reaches zero, the promised rate can be applied, and data packets can be dropped at the rate SP - TR. For the queue, once Qn reaches BS, the queue can be full (in tail-drop mode), and data packets can be dropped at the rate SP - TR.

[0120] If SP is less than TR, tokens can be replenished at the rate of TR and consumed at the rate of SP, so the net increase can be TR - SP until Tn reaches BS. The corresponding queue can be emptied at the rate of TR and replenished at the rate of SP, so the net decrease is TR - SP until Qn reaches zero. If Tn is not zero, there is no loss for the token bucket. For the queue: If Qn is not BS, there is no loss.

[0121] In terms of losses, the token bucket can behave like a tail-drop queue of the same size and rate, according to Qn = BS - Tn. Correlation can hold for losses and queue size between the token bucket and the queue, while data packet delay and burst properties can differ between the token bucket and the queue. The calculation of delay with the queue can depend on the queue size Qn and the rate TR. Correlation between the queue and the token bucket can also hold for the queue's input (e.g., when data packets are added to the queue), while the token bucket's output and the queue's output can differ (e.g., the queue adds delay).

[0122] TBAQM can also apply the AQM process to the state of the corresponding queue, which corresponds to the state of the token bucket. In some examples, a process similar to CoDel can be implemented (e.g., not the CoDel process itself, as it is difficult to adapt to a token bucket). For example, CoDel can periodically remove data packets from the queue output. This can be implemented with TBAQM, where data packets are removed from the queue.

[0123] At PIE and PI 2 All processing takes place at the queue input when a packet arrives in the queue. When a data packet is received, the PIE or PI decides. 2The process determines whether a task should be marked (e.g., discarded or modified) or placed in the queue. The fact that most of the processing occurs at the queue's entry point makes these processes highly compatible with a token bucket.

[0124] In some examples, PIE and PI measure 2 The queue length and queue output rate are used to estimate the queue delay. For a token bucket, the queue length is the difference between the bucket size and the number of tokens. For TBAQM, the queue length in the PIE and PI processes is... 2 to be replaced by BS - Tn.

[0125] In some examples, PIE and PI can be used interchangeably. 2Use the average dequeue rate of the queue. In the corresponding queue, the data packet cannot be dequeued at a rate higher than TR (e.g., the promised rate of the token bucket). The average output rate of the token bucket (e.g., when it is full) is its promised rate TR, so the output rate of the corresponding queue would be equal to and cannot exceed TR. The rate can be lower than TR if the input rate is lower than TR and the queue becomes temporarily empty. However, this can cause the queue to become overloaded, which negatively impacts the rate estimation for PIE and PI. 2This has an effect. In some examples, when estimating packet delay in the queue, it is assumed that the estimated rate applies when the queue is fully utilized processing data packets, since starving the queue would not increase the packet delay. PIE and PI 2 This underestimation of the rate can be ignored, as packet marking may be required if the queue is overloaded. Therefore, TR may be the correct estimate of the dequeue rate for the given queue, and when modeling the process according to PIE and PI. 2 The estimated rate can be replaced by TR.

[0126] Packet marking can occur when the token bucket is overloaded. In some examples, the average output rate of the token bucket may match its promised rate. The output rate of the corresponding queue may be the same, so TBAQM can be used when implementing the PIE and PI processes. 2 The estimated rate can be replaced by TR. In this way, TBAQM can create a token bucket with a modified PIE or PI. 2 -Regulator included. The queue length variable can be replaced by the inverse of the number of remaining tokens, BS - Tn. The estimated rate variable can be replaced by the promised rate, TR.

[0127] In some examples, the PIE and PI processes can be used. 2It also includes two configuration parameters, Alpha and Beta, which help control the feedback. These parameters can depend on TCP congestion control and be implemented using TBAQM. For example, PIE and PI can be used. 2 The data packet is marked by either modifying or discarding it, depending on its support for ECN and SCE. This can also occur with a token bucket implemented using TBAQM. In some examples, TBAQM can generate ECN and SCE signals, which can help reduce packet loss.

[0128] TBAQM allows for the implementation of additional functions that complement those of PIE and PI. 2 are similar. For example, TBAQM can implement one or more heuristics available in PIE. In PI 2The marking probability can be used with TBAQM to support multiple types of congestion control (e.g., like classic TCP (probability is quadratic) and DCTCP (probability is non-quadratic)). If PIE and PI 2 When applied to a token bucket in this way, they can modify or discard data packets in the same way as if the token bucket had been replaced by a queue, so the effects on TCP can be the same.

[0129] TBAQM can process the PIE and PI signals. 2TBAQM can improve network performance (e.g., prevent TCP from being implemented too early) by properly regulating TCP congestion control. In this example, it may be less necessary to keep the token bucket burst size small, as the traditional drawbacks associated with a large burst size are much less likely. The burst size can be increased safely, making the token bucket better suited for burst traffic and also reducing packet loss. By using a larger bucket size and ECN and SCE tagging, TBAQM can regulate TCP traffic with almost no packet loss and increase network efficiency.

[0130] It should be noted that the terms "optimize," "optimal," and the like, as used here, can be interpreted as making or achieving performance as effective or perfect as possible. However, as any professional reading this document will recognize, perfection cannot always be achieved. Accordingly, these terms can also mean making or achieving performance as good or effective as possible or practical under the given circumstances, or making or achieving performance better than that which can be achieved with other settings or parameters.

[0131] Fig. Figure 7 shows an example of a computational component that can be used to implement a token bucket with active queue management, as shown in various examples. As in Fig. As shown in Figure 7, computer component 700 can be, for example, a server computer, a controller, or another similar computer component capable of processing data. In the example implementation of Fig. The computer component 700 comprises a hardware processor 702 and a machine-readable storage medium 704.

[0132] The Hardware Processor 702 can be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices capable of retrieving and executing instructions stored in the Machine-Readable Memory Medium 704. The Hardware Processor 702 can retrieve, decode, and execute instructions, such as Instructions 706-712, to control processes or operations for implementing an active queue management token bucket. Alternatively or in addition to retrieving and executing instructions, the Hardware Processor 702 can include one or more electronic circuits comprising electronic components for performing the functionality of one or more instructions, such as a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), or other electronic circuits.

[0133] A machine-readable storage medium, such as the 704 machine-readable storage medium, can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. The 704 machine-readable storage medium can be, for example, random access memory (RAM), non-volatile random access memory (NVRAM), electrically erasable programmable solid-state memory (EEPROM), a storage device, an optical disk, or the like. In some examples, the 704 machine-readable storage medium can be a non-transient storage medium, the term "non-transient" excluding the transitive transmission signals. As detailed below, the 704 machine-readable storage medium can be encoded with executable instructions, such as instructions 706-712.

[0134] The 702 hardware processor can execute the 706 instruction to receive a data packet. For example, a network device with a controller (which, for instance, implements a token bucket with active queue management (TBAQM)) can receive the data packet. The data packet can then be processed by the TBAQM in the network device.

[0135] The 702 hardware processor can execute instruction 708 to adjust the number of tokens allocated to the TBAQM. For example, the network device can adjust the number of tokens allocated to the TBAQM by adding tokens based on a configured rate and subtracting tokens in conjunction with data packet processing.

[0136] The 702 hardware processor can execute instruction 710 to determine the number of tokens associated with the TBAQM. For example, the network device can determine the number of tokens associated with the TBAQM. If the TBAQM has zero tokens, the network device can discard the data packet. If the TBAQM has more than zero tokens, the network device can determine a marking probability based on the number of tokens.

[0137] The 702 hardware processor can execute command 712 to initiate an action. For example, the network device can initiate an action based on the marking probability. As described in the revelation, more than one action can be performed.

[0138] In some examples, the marking probability is based on the number of tokens. The network device can implement a pseudo-random process based on the marking probability and, based on this pseudo-random process, determine that the data packet is marked as an action.

[0139] In some examples, when the data packet is selected, the action is set to discard the data packet. In other examples, when the data packet is selected, the action is set to modify a value in a header of the data packet.

[0140] Fig.Figure 8 shows a block diagram of an example Computer System 800, in which several of the examples described here can be implemented. The Computer System 800 comprises a Bus 802 or other communication mechanism for transmitting information, and one or more Hardware Processors 804 connected to the Bus 802 for processing information. The Hardware Processor(s) 804 could, for example, be one or more general-purpose microprocessors.

[0141] The Computer System 800 also includes a main memory 806, such as random access memory (RAM), a cache, and / or other dynamic memory devices connected to the 802 bus to store information and instructions to be executed by the 804 processor. The 806 main memory can also be used to store temporary variables or other intermediate information during the execution of instructions to be carried out by the 804 processor. Such instructions, stored in memory media accessible to the 804 processor, make the Computer System 800 a specialized machine, adapted to perform the operations specified in the instructions.

[0142] The Computer System 800 also includes a read-only memory (ROM) 808 or other static storage device connected to the 802 bus to store static information and instructions for the 804 processor. A storage device 810, such as a magnetic disk, an optical disk, or a USB flash drive, is provided and connected to the 802 bus to store information and instructions.

[0143] The Computer System 800 can be connected via the Bus 802 to a Display 812, such as a liquid crystal display (LCD) (or a touchscreen), to show information to a computer user. An Input Device 814, including alphanumeric and other keys, is coupled to the Bus 802 to transmit information and command selections to the Processor 804. Another type of user input device is the Cursor Control 816, such as a mouse, trackball, or cursor directional keys, for transmitting directional information and command selections to the Processor 804 and for controlling cursor movement on the Display 812. In some examples, the same directional information and command selections as with the cursor control can be implemented by receiving touch inputs on a touchscreen without a cursor.

[0144] The Computer System 800 can include a user interface module for implementing a graphical user interface, which can be stored on a mass storage device as executable software code that is executed by the computer device(s). This and other modules can include components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0145] In general, the terms "component," "engine," "system," "database," "data store," and the like, as used here, can refer to logic embodied in hardware or firmware, or to a collection of software instructions that may have entry and exit points and are written in a programming language such as Java, C, or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It is understood that software components may be called by other components or by themselves, and / or may be invoked in response to detected events or interruptions. Software components configured to run on computer devices may be stored on a computer-readable medium, such as...Software code can be provided on a compact disc, digital video disc, flash drive, magnetic disk, or other tangible medium, or as a digital download (and may initially be stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code may be stored partially or entirely in the memory of the executing computer device so that it can be executed by the computer device. Software instructions may be embedded in firmware, such as an EPROM. Furthermore, the hardware components may consist of interconnected logic units such as gates and flip-flops, and / or programmable units such as programmable gate arrays or processors.

[0146] The Computer System 800 can implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic which, in combination with the Computer System, makes or programs the Computer System 800 to be a special-purpose machine. By way of example, the techniques described herein are executed by the Computer System 800 in response to the Processor(s) 804 executing one or more sequences of instructions contained in the Main Memory 806. Such instructions may be read into the Main Memory 806 from another storage medium, such as the Storage Device 810. The execution of the instruction sequences contained in the Main Memory 806 causes the Processor(s) 804 to perform the process steps described herein.In alternative examples, hard-wired circuits can be used instead of, or in combination with, software instructions.

[0147] The term "non-transitory media" and similar terms as used here refer to all media that store data and / or instructions that cause a machine to operate in a particular way. Such non-transitory media can include non-volatile and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as the Storage Device 810. Volatile media include dynamic memory, such as the Main Memory 806. Common forms of non-volatile media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or other magnetic data storage media, CD-ROMs, other optical data storage media, physical media with hole patterns, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, other memory chips or cartridges, and their networked versions.

[0148] Non-transitory media differ from transmission media but can be used in conjunction with them. Transmission media are involved in the transfer of information between non-transitory media. Examples of transmission media include coaxial cable, copper and fiber optic cables, including the wires that make up the 802 bus. Transmission media can also take the form of sound or light waves, such as those generated in radio and infrared data communication.

[0149] The Computer System 800 also includes a Communications Interface 818, which is connected to the 802 bus. The Communications Interface 818 provides a two-way data communication connection to one or more network connections, which are connected to one or more local area networks (LANs). For example, the Communications Interface 818 can be an ISDN (Integrated Services Digital Network) card, a cable modem, a satellite modem, or a modem to establish a data communication connection to a corresponding type of telephone line. Another example: The Communications Interface 818 can be a LAN (Local Area Network) card to establish a data communication connection to a compatible LAN (or a WAN component for communication with a WAN). Wireless connections can also be implemented.In each of these implementations, the 818 communication interface sends and receives electrical, electromagnetic, or optical signals that transmit digital data streams representing various types of information.

[0150] A network connection typically enables data communication across one or more networks to other data devices. For example, a network connection can establish a connection across a local area network to a host computer or to data devices of an Internet service provider (ISP). The ISP, in turn, provides data communication services over the worldwide packet data communication network, commonly known today as the "Internet." Both the local area network and the Internet use electrical, electromagnetic, or optical signals to transmit digital data streams. The signals across the various networks, the signals on the network link, and the 818 communication interface that transmits digital data to and from the Computer System 800 are examples of transmission media.

[0151] The Computer System 800 can send messages and receive data, including program code, via the network(s), network connection, and communication interface 818. In the Internet example, a server could transmit requested code for an application program via the Internet, the ISP, the local network, and communication interface 818.

[0152] The received code can be executed by the 804 processor upon receipt and / or stored in the 810 memory device or other non-volatile memory for later execution.

[0153] Each of the processes, procedures, and algorithms described in the preceding sections can be embodied in code components and fully or partially automated by them, which are executed by one or more computer systems or computer processors with computer hardware. The one or more computer systems or computer processors can also be operated in such a way as to support the execution of the corresponding operations in a cloud computing environment or as Software as a Service (SaaS). The processes and algorithms can be partially or fully implemented in application-specific circuits. The various features and procedures described above can be used independently or combined in various ways.Various combinations and subcombinations are said to fall within the scope of this disclosure, and certain procedure or process blocks may be omitted in some implementations. The procedures and processes described herein are also not restricted to a particular order, and the associated blocks or states may be executed in other suitable orders, in parallel, or otherwise. Blocks or states may be added to or removed from the examples described herein. The execution of certain operations or processes may be distributed among computer systems or computer processors that are not only located in a single machine but are distributed across a number of machines.

[0154] As used herein, a circuit can be implemented in any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be implemented to form a circuit. In implementation, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be partially or completely distributed across one or more circuits.Even if various features or functional elements are individually described or claimed as separate circuits, these features and functions may be shared by one or more common circuits, and such a description is not intended to require or imply that separate circuits are necessary to implement these features or functions. If a circuit is implemented wholly or partly in software, such software may be implemented to operate with a computer or processing system capable of performing the functionality described with respect to it, such as the Computer System 800.

[0155] As used herein, the term "or" can be understood in both an inclusive and an exclusive sense. Furthermore, the singular description of resources, processes, or structures should not be interpreted as excluding the plural. Conditional expressions such as "may," "could," "might," or "may" are generally intended to convey that certain examples include certain features, elements, and / or steps, while other examples do not, unless explicitly stated otherwise or understood differently in the specific context.

[0156] Unless explicitly stated otherwise, the terms and expressions used in this document, as well as their variations, are not to be understood as restrictive but rather as open-ended. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning are not to be understood as limiting the subject matter described to a particular period or to an item available at a particular time, but should be understood as encompassing conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. The presence of expansive words and expressions such as "one or more," "at least," "but not limited to," or similar expressions in some cases is not to be understood as implying that the narrower case is intended or required when such expansive expressions are absent.

Claims

[1] A computer-implemented method comprising: Receiving a data packet (202A) at a network device (140) comprising a token bucket (505), wherein the data packet is processed by the token bucket at the network device; Adjusting a number of tokens allocated to the token bucket, wherein the tokens are added and subtracted based on a configured rate in connection with the processing of the data packet; Determining a number of tokens associated with the token bucket, comprising: if the token bucket has zero tokens, initiating a first action with the data packet; and if the token bucket has more than zero tokens: Determining an active queue management (AQM) technique that includes a queue length variable; Replacing the queue length variable with a difference between a token bucket size and the number of tokens to produce an improved AQM technique; Implementing the improved AQM technique at the network device to determine a marking probability; and Initiate a second action based on the marking probability. [2] The method of claim 1, when the first action discards the data packet or modifies a header of the data packet. [3] The method of claim 1, when the marking probability is determined based on the number of tokens, the method further comprising: Implementing a pseudo-random process (550) based on the marking probability; and Determine, based on the pseudo-random process, that the data packet is marked as the action. [4] The method of claim 3, wherein when the data packet is marked, discarding the data packet is determined as an action. [5] The method of claim 3, wherein when the data packet is marked, it is determined to change a value in a header of the data packet as the action. [6] The method of claim 1, wherein the determination of the marking probability is based on the number of tokens using a proportional-integral (PI) controller (545). [7] The method of claim 1, wherein the marking probability is determined using a PIE (Proportional Integral Controller Enhanced) algorithm. [8] The method of claim 1, wherein the labeling probability is calculated using a quadratic proportional-integral enhancement algorithm (PI 2 ) is determined. [9] The method of claim 1, wherein the active queue management (AQM) technique further includes a queue dequeue rate variable, the method further comprising: Replacing the queue removal rate variable with the configured rate of the token bucket to create a further improved AQM technique; and Implementing the further improved AQM technique on the network device to determine the marking probability. [10] A network device (140) comprising: a token bucket (505); a memory; and one or more processors configured to execute machine-readable instructions stored in the memory to perform the method, comprising: Receiving a data packet (202A), wherein the data packet is processed by the token bucket at the network device; Adjusting a number of tokens associated with the token bucket, wherein the tokens are added based on a configured rate and subtracted in connection with the processing of the data packet; Determining a number of tokens associated with the token bucket, comprising: if the token bucket has zero tokens, initiating a first action with the data packet; and if the token bucket has more than zero tokens: Determining an active queue management (AQM) technique that includes a queue length variable; Replacing the queue length variable with a difference between the token bucket size and the number of tokens to develop an improved AQM technique; Implementing the improved AQM technique at the network device to determine a marking probability; and Initiate a second action based on the marking probability. [11] The network device of claim 10, when the first action discards the data packet or modifies a header of the data packet. [12] The network device of claim 10, when the marking probability is determined based on the number of tokens, the method further comprising: Implementing a pseudo-random process (550) based on the marking probability; and to determine based on the pseudo-random process that the data packet is marked as the action. [13] The network device of claim 12, wherein when the data packet is marked, discarding the data packet is determined as an action. [14] The network device of claim 12, wherein when the data packet is marked, it is determined to change a value in a header of the data packet as an action. [15] The network device of claim 10, wherein the determination of the marking probability is based on the number of tokens using a proportional-integral (PI) controller (545). [16] A non-transitory computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions, when executed by the one or more processors, causing the one or more processors to: receive a data packet (202A), the data packet being processed by a token bucket (505) in a network device (140); adjust a number of tokens associated with the token bucket, with the tokens being added based on a configured rate and subtracted in connection with the processing of the data packet; determine a number of tokens allocated to the token bucket, comprising: if the token bucket has zero tokens, initiating a first action with the data packet; if the token bucket has more than zero tokens: Determine an active queue management (AQM) technique that includes a queue length variable: Replacing the queue length variable with a difference between a token bucket size and the number of tokens to produce an improved AQM technique; Implementing the improved AQM technique on the network device to determine a labeling probability; and Initiate a second action based on the marking probability. [17] The computer-readable storage medium of claim 16, wherein the determination of the marking probability is based on the number of tokens using a proportional-integral (PI) controller (545). [18] The computer-readable storage medium of claim 16, wherein the marking probability is determined using a Proportional-Integral-Controller Enhanced (PIE) algorithm. [19] The computer-readable storage medium of claim 16, wherein the marking probability is calculated using a quadratic proportional-integral enhancement algorithm (PI 2 ) is determined.

Images