JP2024518019A - Method and system for predictive analytics based buffer management - Patents.com - Google Patents

Abstract

A method and computer program product for managing traffic in a communications network, the method including the steps of receiving a plurality of traffic units to be transmitted by a switch through a port, the port having an associated queue, extracting features from the plurality of traffic units, providing the features to a first engine to obtain a class for the plurality of traffic units, obtaining an indication of a predicted traffic volume for the class for a future time and for a physical location of the switch that will transmit the plurality of traffic units using a second engine associated with a traffic model for the class, allocating a queue of a size corresponding to the indication of the predicted traffic volume, and allocating at least one traffic unit to a buffer.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. Provisional Patent Application No. 63/187,916, entitled "Finding Segments of Relevant Objects Based on Free-Form Text Description," filed May 12, 2022, and claims the benefit of that U.S. Provisional Patent Application, which is hereby incorporated by reference in its entirety without creating a denial.

The present disclosure relates generally to buffer management, and more particularly to methods and systems for buffer management within and between data centers.

Data centers are used to handle the workload generated by the ever-increasing amount of available applications (also due to the growing number of end users) and overall data migration in the cloud. The challenges in designing data center networking play a major role in the performance of various cloud applications. Data center operators face extreme challenges in utilizing the available bandwidth for multiple applications of various types. Each of the applications has its own requirements, such as different throughput, quality of service (QoS) requirements, acceptable latency, etc., that may vary over time.

Generally, if a communication channel or a transmitting/receiving end is loaded to its maximum capacity, traffic units such as packets may be stored in buffers, either before being transmitted or after being received, until the channel or destination can accommodate and handle them. However, when the buffer is full, packets may be lost, which can result in serious problems.

One exemplary embodiment of the disclosed subject matter is a method for managing traffic in a communication network, the method including receiving a plurality of traffic units to be transmitted by a switch through a port, the port having an associated queue, extracting features from the plurality of traffic units, providing the features to a first engine to obtain a class for the plurality of traffic units, obtaining an indication of a predicted traffic volume for the class for a future time and for a physical location of the switch transmitting the plurality of traffic units using a second engine associated with a traffic model for the class, allocating a queue of a size corresponding to the indication of the predicted traffic volume, and allocating at least one traffic unit to a buffer. In the method, the traffic unit is a packet. The method may further include receiving a preliminary plurality of traffic units to be transmitted, extracting features from each of the preliminary plurality of traffic units to obtain a plurality of feature vectors, clustering the plurality of feature vectors into a plurality of classes, and training the first engine to receive the plurality of traffic units and output a class from the plurality of classes. The method may further include training a second engine based on a subset of the feature vectors assigned to a particular class such that the second engine is adapted by the traffic model to provide an indication of a predicted traffic volume for the class. In the method, the predicted traffic volume is optionally predicted for a future time t+τ, where t is the current time and τ is a time interval. In the method, the predicted traffic volume is optionally predicted for a future time t+τ, where t is the current time and τ is a time interval, and the traffic volume is predicted based on available buffer sizes at the current time and at the future time. In the method, the predicted traffic volume is optionally predicted for a future time t+τ, where t is the current time and τ is a time interval, and the traffic volume is predicted based on a number of congested queues of the priority of the class at the future time. In the method, the predicted traffic volume is optionally predicted for a future time t+τ, where t is the current time and τ is a time interval, and the traffic volume is predicted based on a normalized dequeue rate of the queue at the future time. In the method, a predicted traffic volume is optionally predicted for a future time t+τ, where t is a current time, and τ is a time interval, and the traffic volume is predicted based on a priority of an application or site associated with a plurality of traffic units. In the method, a predicted traffic volume is optionally predicted for a future time t+τ, where t is a current time, and τ is a time interval, and the traffic volume is predicted based on a coefficient associated with a class. In the method, a predicted traffic volume is optionally predicted for a future time t+τ, where t is a current time, and τ is a time interval, and the traffic volume is predicted based on a physical location of a switch. In the method, a predicted traffic volume is optionally predicted by the following formula:
T ⁱ _c (t, t + τ, location) =
α _c · 1 / Np '(t, t + τ, location) · γ _i ^c '(t, t + τ, location) · (B - Boc '(t, t + τ, location))
where i is the port index, c is a class of traffic units, t is the current time, τ is the time difference to a future time, α _c is a coefficient assigned to class c, Location is the physical location of the switch in the data center, Np'(t,t+τ,location) is the variation or combination of Np(t,location), the number of congestion queues of class priority p at time t for the switch, and Np(t+τ,location), the number of congestion queues of class priority p at time t+τ for the switch, B-B _oc '(t,t+τ,location) is the variation or combination of B-B _oc (t,location), the remaining buffers at time t for the switch, and B-B _{oc (} t+τ,location), the remaining buffers at time t+τ for the switch, ^and '(t,t+τ,location) is the variation or combination of γ ⁱ _c (t,location), the per-port normalized dequeue rate of a queue of class c at time t for the switch, and γ ⁱ _c (t+τ,location), the per-port normalized dequeue rate of the i-th queue of class c at time t+τ for the switch. In the method, the queue is optionally not emptied in a first-in-first-out manner. In the method, multiple traffic units are optionally dequeued from the queue simultaneously.

Another exemplary embodiment of the disclosed subject matter is a non-transitory computer-readable medium bearing program instructions that, when read by a processor, cause the processor to: receive a plurality of traffic units to be transmitted by a switch through a port, the port having an associated queue; extract features from the plurality of traffic units; provide the features to a first engine to obtain a class for the plurality of traffic units; obtain an indication of a predicted traffic volume for the class for a future time and for a physical location of the switch that transmits the plurality of traffic units using a second engine associated with a traffic model for the class; allocate a queue of a size corresponding to the indication of the predicted traffic volume; and assign at least one traffic unit to a buffer. In the computer program product, the traffic unit is optionally a packet. In the computer program product, the program instructions optionally further cause the processor to receive a preliminary plurality of traffic units to be transmitted, extract features from each of the preliminary plurality of traffic units to obtain a plurality of feature vectors, cluster the plurality of feature vectors into a plurality of classes, and train a first engine to receive the plurality of traffic units and output a class from the plurality of classes. In the computer program product, the program instructions optionally further cause the processor to train a second engine based on a subset of the plurality of feature vectors assigned to a particular class, such that the second engine is adapted by the traffic model to provide an indication of a predicted traffic volume for the class. In the computer program product, the predicted traffic volume is optionally predicted for a future time t+τ, where t is the current time and τ is a time interval. In the computer program product, the predicted traffic volume is optionally predicted based on one or more items selected from the enumeration: available buffer size at the current time and at a future time; number of congested queues for a class priority at a future time; normalized dequeue rate of the queue at a future time; priority of an application or site associated with a number of traffic units; a coefficient associated with the class; and physical location of the switch.

The subject matter disclosed will be more fully understood and appreciated from the following detailed description taken in conjunction with the drawings in which corresponding or like numbers or symbols indicate corresponding or like components. Unless otherwise indicated, the drawings provide exemplary embodiments or aspects of the disclosure and do not limit the scope of the disclosure. In the drawings:

FIG. 1 is a generalized diagram of a spine-leaf type data center. FIG. 2 is a schematic diagram of an Approximate Fair Dropping (AFD) scheme. FIG. 3 is a schematic diagram of a conventional static switch architecture deployed in a data center. FIG. 4 is a performance graph of the dynamic thresholding scheme. FIG. 5 is a flowchart of steps in a method for training an engine for classifying transmissions and determining buffer sizes according to some example embodiments of the present disclosure. FIG. 6 is a flowchart of a method for determining a queue threshold according to some embodiments of the present disclosure. FIG. 7 is a block diagram of a system for determining queue thresholds according to some embodiments of the present disclosure.

In all computerized networks, especially in data centers that can be heavily loaded due to a large number of applications and users, packets can be lost when all buffers are full. Packet loss can cause significant problems. The severity of the problem can depend on several factors, including the type of sending/receiving application, the type of data being sent, and the Service Level Agreement (SLE) of the application or service.

The discussion below refers interchangeably to traffic units and packets, but it will be understood that the discussion is equally applicable to other traffic units as well.

Thus, one technical problem of the present disclosure relates to the need to manage port queues and buffers in a data center to optimize transmission performance so that the risk of serious damage caused by the loss of critical transmissions is reduced.

Some known techniques for avoiding packet loss allocate multiple buffers from the available buffer space. In some embodiments, one or more buffers may be allocated for large transmissions, such as transmissions that contain more than a predetermined number of packets, also known as elephant flows, and one or more buffers may be allocated for smaller transmissions, referred to as mice flows.

Further known techniques allocate buffers statically from an available pool and therefore may fail to respond effectively and efficiently to transmission bursts. Further techniques use dynamic allocation depending on the load and requirements at the time of transmission. However, this still does not provide a reasonable solution because conditions may change drastically during transmission such that performance may become drastically worse.

One technical solution of the present disclosure involves setting queue thresholds, i.e., the amount of each queue, and thereby dynamically allocating buffers to store the queue from the available pool. However, queue thresholds are determined and buffer allocation is performed not only according to the current situation and load, since this may change due to, for example, a current transmission and transmissions that may occur or at least start during that transmission. Rather, queue threshold settings and allocation of buffers from the available pool are driven by the predicted load, which is expected at a later time during the time that the transmission is expected to occur. Buffer allocation may further take into account the class or type of packets to be transmitted, the amount of expected transmissions, SLE, the physical location of the transmitting switch, or other factors that may be related to the sending or receiving application.

Another technical solution of the present disclosure includes training a first engine, such as a classifier, to classify packets in a transmission to obtain their class, such that the corresponding queue threshold and allocated buffer size are according to the class. For example, a transmission including packets associated with an application may be classified into a class that transmits a large amount of data and may be allocated a larger buffer than a transmission associated with an application classified into the class that transmits a large amount of data, and vice versa.

Yet another technical solution of the present disclosure includes training a second engine, also referred to as a traffic model, for each such class, which is adapted to calculate, for a particular class, an appropriate queue threshold from the available pool at a future time when a transmission is expected to take place.

One technical effect of the present disclosure is the optimization of queue thresholds and increased effectiveness of buffer allocations because they are adjusted to the requirements at the time the transmission is occurring, rather than to requirements some time earlier. By setting queue thresholds and allocating a proportion of buffers that is appropriate for the type of application and requirements in force, fewer packets are dropped and service levels can be increased.

Referring now to FIG. 1, a partial generalized diagram of a spine-leaf type data center is shown, which consists of multiple points of delivery (PODs) 100, each of which includes a top of the rack switch 108 and one or more aggregate switches 116. The data center may further include multiple core switches 120. Each POD 100 may include multiple racks, such as rack 1 (104), rack 2 (104'), etc.

Rack 1 (104) may include multiple servers, such as server 112, server 113, etc. Rack 1 (104) may further include a top-of-rack (ToR) switch 108. The ToR switch 108 is responsible for providing data to any of the servers 112, 113, etc., as well as receiving data from any of the servers 112, 113, etc., to be provided to a destination.

The POD 100 may include one or more aggregate switches 116, each responsible for providing data to any of the servers 112, 113 in two or more racks, such as rack 1 (104) and rack 2 (104'), and for receiving data from any of the servers 112, 113 in the two or more racks to be provided to a destination.

A data center may include one or more core switches 120 that enable communication and data transfer between two or more aggregate switches 116 of one or more PODs 100, and thus between multiple racks and multiple servers in the data center.

The data center may include data center core switches (not shown) to enable communication and data transfer between two or more PODs 100, and data center edge switches (not shown) to enable communication between the data center and other data centers or servers anywhere in cyberspace.

It will be understood that the disclosed structure is merely exemplary and that any other structure that connects various servers and enables them to send and receive data between themselves or between any of them and another source or destination computing platform in cyberspace may be used.

It will be appreciated that the higher a switch is in the switch hierarchy, the more types of data the switch may be required to provide to or from more types of applications, at more distributed times, etc. For example, data center core switch 120 may accommodate a greater variety of transmissions than ToR switch 108.

Each application and transmission situation is different, and so are their needs. Some applications need to send small amounts of data, but need to do so with as little latency as possible, while others, such as backup transmissions, need to send large amounts, but can tolerate longer latencies. Also, the criticality of each transmitted packet may vary. For example, in a music distribution application, the loss of a few packets may be less severe and more tolerable than in a banking application.

The technical problems disclosed above may apply to any of the switches shown or discussed in connection with FIG. 1, such as the ToR switch 108, the aggregate switch 116, the core switch 120, the data center core switch, and the data center edge switch. When data is required to be transmitted and the channel is busy, the data to be transmitted may be buffered, and similarly for data to be received when the destination is busy.

Thus, one existing technique involves splitting the available space for buffers into two: a first buffer for handling small transmissions, called a miceflow queue, which may be used to store the first packet of each transmission, and a second buffer, called an elephantflow queue, for handling large transmissions, specifically all packets associated with a transmission except for the first packet assigned to the miceflow queue. It will be understood that the terms buffer and queue are used interchangeably.

A known mechanism to address the discard problem is Approximate Fair Discard (AFD) with Dynamic Packet Prioritization (DPP). AFD focuses on conserving buffer space for mice flows, especially for absorbing microbursts that are aggregated mice flows, by limiting the buffer usage of aggressive elephant flows. The scheme may further enforce fairness of bandwidth allocation among multiple elephant flows, as detailed below. DPP provides the ability to separate mice flows and elephant flows into two different queues, such that buffer space can be allocated to them independently and different queue scheduling can be applied to them.

The AFD algorithm is characterized by a fair allocation of bandwidth among multiple elephant flows based on their data rates. This has two main components: data rate measurement and fair rate calculation.

Data rate measurement involves measuring the arrival rate of each elephant flow on the ingress (i.e., incoming) port and passing it to a buffer management mechanism on the egress (i.e., outgoing) port.

Fair rate computation involves dynamically calculating per-flow fair rates for egress queues using a feedback mechanism based on the occupancy of the egress port queues.

When a packet of an elephant flow enters an egress queue, the AFD algorithm compares the measured arrival rate of the flow with the calculated fair share rate per flow.

If the arrival rate is less than the fair rate, packets will be queued and eventually sent to the egress link.

If the arrival rate exceeds the fair rate, packets will be randomly dropped from that flow in proportion to the amount by which its arrival rate exceeds the fair rate. The drop probability is then calculated using the fair rate and the measured flow rate. The more a flow exceeds the fair rate, the higher the drop probability for that flow, and therefore all elephant flows will achieve their fair rate.

AFD, a flow-aware early-discard mechanism that signals network congestion by discarding packets and engages TCP congestion mechanisms on application hosts, is an improvement over earlier methods such as weighted random early discard or weighted random early detection (WRED). WRED applies weighted random early discard to class-based queues, but does not utilize flow awareness within classes, which means that all packets, including mice flows that are susceptible to packet loss, must be subject to the same discard probability, and therefore packets from mice flows are as likely to be discarded as packets from elephant flows. Elephant flows may use discards as a congestion signal to back off, but discards may have a detrimental effect on mice flows. In addition, the same discard probability may cause elephant flows with higher rates (due to shorter round-trip times) to obtain more bandwidth.

Therefore, the egress bandwidth may not be divided evenly among multiple elephant flows traversing the same congested link. As a result, flow completion times for mice flows vary and elephant flows do not have fair access to link bandwidth and buffer resources.

However, AFD takes into account the flow size and data arrival rate before making the discard decision. The discard algorithm is designed to protect mice flows and to provide fairness among multiple elephant flows during bandwidth contention.

2, an AFD scheme is shown with a pair of queues: a miceflow queue 204 and a regular (elephant flow) queue 208. In the example of FIG. 2, the miceflow queue may be limited to streams of at most N packets (N=5). A short stream of packets, such as stream 212 containing four packets, may be stored exclusively in the miceflow queue 204 and sent onward when possible. The same is true for stream 216, which is in the process of being stored in the miceflow queue 204. However, stream 220 is longer. Thus, the first N packets are indeed assigned to the miceflow queue 204, while the remainder of the packets, starting with packet N+1 (224), are assigned to the regular queue 208. Both queues output the packets stored in them through egress port 228.

Thus, traditional network management simply allows for the deployment of a predefined set of buffer management policies whose parameters can be adapted to specific network conditions. The incorporation of new management policies requires complex control and data plan code changes, and sometimes redesign of the implementing hardware.

However, current developments in software-defined networking have largely ignored these challenges, concentrating on flexible and efficient representation of packet classifiers, and have not adequately addressed aspects of buffer management.

Traditionally, queues implement a first-in, first-out (FIFO) processing order, and as is known, there are no deterministic optimal algorithms for single-queue (SQ) architectures, weighted throughput objectives, and FIFO processing.

Referring now to FIG. 3, a schematic diagram of a conventional static switch architecture deployed in a data center having a central packet processing and classification engine is shown.

The architecture uses a centralized classification engine 304 that classifies the incoming packet stream. When a packet is received at the switch, the engine looks up the destination and source addresses, compares them to a table of network segments and addresses, and determines a class for the packet.

Corresponding to the determined class, the packet is forwarded to one of the queuing engines according to the classification, such as queuing engine 1 (308), queuing engine 2 (312), queuing engine N (316), etc., where N is the number of classes. In addition, the centralized classification engine 304 prevents bad packets from scattering by not forwarding them.

Each queuing engine places relevant packets in its static buffers, such as static buffer 1 (320), static buffer 2 (324), etc., and in the relevant queues, specifically by port associated with each packet. For example, static buffer 1 (320) has a first queue 328 associated with Q0 of port 1, an Nth queue 332 associated with QN of port 1, etc.

So, static buffers are partitioned with a fixed buffer size for each queue. As packets are processed within the switch, they are stored in the buffer.

In this arrangement, the dynamic buffers are split into separate virtual buffer pools, with each virtual buffer assigned to each port. In each virtual buffer, packets are organized into logical FIFO queues.

If the destination segment is congested, the switch stores the packet, waiting for bandwidth to become available on the congested segment. In a static buffer, if the buffer is full, additional incoming packets will be discarded. Therefore, to support any application on a computer network, it is important to reduce the packet loss rate. To achieve this goal, the buffer size may be increased, and the core network may have very large static buffers, but this may add significant cost, operational complexity, less deterministic and predictive application performance, as well as longer queuing delays to the system. Thus, this arrangement may even produce poor results.

Therefore, an advanced dynamic buffer management scheme should support (1) low queuing delay, (2) queue length control to prevent overflows and underflows, and (3) lower packet loss ratios.

In such a scheme, the size of each queue, called the dynamic threshold (DT), needs to be determined by a threshold applicable to the queue, which may be proportional to the remaining space in the buffer. The scheme may use parameters such as the average queue length, and minimum and maximum threshold values for the queue length.

When congestion levels are low, the threshold value may be automatically increased to delay activation of congestion control, and when congestion levels are high, the threshold value may be automatically decreased to trigger congestion control earlier.

When the average queue length is below a minimum threshold, none of the packets are dropped, when the queue length is between the minimum and maximum thresholds, packets may be dropped with a linearly increasing probability, and when the queue length is above the maximum threshold, all packets are dropped. Thus, such a scheme may avoid congestion by not allowing the queue to fill up.

In a further scheme, a network device may share buffers across multiple priority queues to avoid drops during transient congestion.

While cost-effective most of the time, low-priority traffic can cause increased packet loss relative to high-priority traffic. Similarly, long flows can prevent buffers from absorbing incoming bursts even if those bursts do not share the same queue. Hence, buffer sharing techniques cannot guarantee isolation across multiple (priority) queues without statically allocating buffer space.

Congestion control (CC) algorithms and scheduling techniques can mitigate the shortcomings of DT, but these algorithms and techniques cannot fully address them.

In fact, CC may indirectly reduce buffer utilization, leaving more space for bursts, while scheduling may allow preferential treatment of certain priority queues over those priority queues that share a single port. Nonetheless, each of these techniques may sense and control separate network variables, as follows:

First, the CC can only sense per-flow performance (e.g., loss or delay), but has no regard for the state of the shared buffer and the relative priority across multiple competing flows. Worse yet, the CC controls the rate of a given flow, but cannot affect the rate at which other flows are sending out. Thus, the CC cannot resolve buffer conflicts across multiple flows sharing the same device.

Second, scheduling can only sense per-queue occupancy and control the transmission (dequeue) of packets through a particular port after, and only if, those packets are enqueued. As a result, scheduling cannot resolve buffer conflicts across multiple queues that do not share the same port.

To reduce costs and maximize utilization, network devices often rely on shared buffer chips, whose allocation across multiple queues is dynamically adjusted by buffer management algorithms, e.g., DT.

DT dynamically allocates buffers per queue in proportion to the buffer space still unoccupied. As a result, the more queues that share a buffer, the less buffer each of those queues is allowed to occupy. Despite its wide deployment, DT does not meet the requirements of multi-tenant data center environments for three main reasons:

First, DT cannot reliably absorb bursts, which is especially important for application performance. Second, DT cannot provide any isolation guarantees, which means that traffic performance, even high-priority traffic, is dependent on the instantaneous load on each device through which the traffic passes. Third, DT cannot react to sudden changes in traffic demand because it keeps buffers highly utilized (to improve throughput) even though this brings little benefit.

Worse yet, more advanced approaches that allocate a portion of the buffer space to queues effectively waste valuable buffer space that could be put to better use, such as absorbing bursts.

DT dynamically adapts the instantaneous maximum length of each queue, i.e., the threshold T ⁱ _c (t) for that queue, depending on the remaining buffer space and a configurable parameter α, e.g., according to the following formula: T ⁱ _c (t)=α ⁱ _c ·(B−Q(t)), where
T ⁱ _c (t) is the queue threshold, i.e., the allocated queue size, of class c at port i;
c is the class associated with the transmission,
α ⁱ _c is the parameter of class c at port i,
B is the total buffer space,
Q(t) is the total buffer occupancy at time t.

The alpha parameter of a queue affects the maximum length of the queue and the length of the queue relative to other queues.

Thus, operators are likely to set higher alpha values for high priority traffic classes compared to low priority traffic classes.

However, there is no systematic way to configure α, despite its importance, which means that different data center vendors and operators may use different α values. Suppose that the data center operator groups traffic into classes, where each class exclusively uses a single queue on each port to achieve cross-class delay isolation. As an illustration, storage, VoIP, and MapReduce may belong to separate traffic classes. Furthermore, suppose that each traffic class is of high or low priority, categorizing classes into high and low priority facilitates prioritization of certain classes over others during times of high load.

This priority setting is related to the use of shared buffers and does not affect scheduling.

An operator may configure multiple low priority classes and multiple high priority classes. In a cloud environment, traffic that must comply with a service level agreement (SLA) will be high priority.

Now referring to FIG. 4, a performance graph 400 of the DT scheme is shown. At time t0, an incoming burst Q2 causes an abrupt change in the buffer occupancy. In the transient state (t0...t2), the threshold of Q1 is lower than the length of Q1. Hence, all incoming packets of Q1 are dropped to free up the buffer for Q2. Nevertheless, Q2 experiences drops before reaching its fair steady-state allocation (times t1...t2).

It is observed that high priority bursts (for Q2) were discarded before the buffers reached steady state. These discards could have been avoided if (i) there had been more buffers available when the bursts arrived (steady state allocation), or (ii) the buffers could have been emptied more quickly to make room for the bursts (transient state allocation).

Thus, DT exposes the following inefficiencies:
1. DT does not provide minimum buffer guarantees: DT enforces the dominance of queues or classes over others through a static parameter (α). Nevertheless, α provides no guarantee because the actual per-queue threshold depends on the overall remaining buffer, which can reach arbitrarily and uncontrollably low values even in steady state.
2. DT does not provide burst tolerance guarantees: In addition to the unpredictability of its steady-state allocation, its transient state allocation is uncontrollable. This is especially problematic when it comes to burst absorption. The main reason for this limitation is that DT perceives buffer space as a scalar quantity, ignoring the expected occupancy of that buffer space over time.

The improved dynamic scheme relies on both queue-level and buffer-level information to limit the buffer space each queue can use.

In particular, a threshold may be defined that is the maximum length of each queue and an amount of buffering may be allocated as follows:
T ⁱ _c (t) = α _c · 1 / N _p (t) · γ ⁱ _c (t) · (B - B _oc (t))
here,
c is the class associated with the transmission.
T ⁱ _c (t) is the threshold size, ie, the length of the queue assigned to the ith port of class c.
α _c is the value assigned to the class to which the queue belongs.
_Np (t) is the number of congested (non-empty) queues of the priority (low or high) to which the class belongs. If there are a small number of non-empty queues, a larger threshold can be assigned, and vice versa.
γ ⁱ _c (t) is the per-port normalized dequeue rate of the queue associated with the port, ie, the clearing rate of the particular queue.
B is the total buffer, B _oc (t) is the occupied buffer, and hence B−B _oc (t) is the remaining buffer.

This formula may handle situations such as high load overall, little load for a particular class, where a smaller space would suffice for that queue, high load but a relevant queue has a high dequeuing rate, and a smaller space would suffice for that queue.

Np(t) bounds the steady-state allocation. Per-queue thresholds are divided by Np. The importance of this factor to the allocation is twofold: (i) it bounds per-class and per-priority occupancy, and (ii) it allows weighted fairness across multiple classes of the same priority.

γ ⁱ _c (t) indicates the duration of the transient state. A buffer is allocated to each queue in proportion to the dequeuing rate (γ) of that queue. The γ factor combined with the upper bound can vary the duration of the transient state. In effect, given some amount of buffer per priority, the buffer is split among multiple queues in proportion to the draining rates of those queues, thereby effectively minimizing the time it takes for the buffer to be emptied. In essence, the time required to transition from one steady-state allocation to another is reduced.

The above scheme thus improves throughput and reduces queuing delays while ensuring absorption of a given burst by handling situations such as high overall load but little load for a particular class, high load but high dequeuing rate for the relevant queue, etc.

However, as can be clearly seen from the above formula, all time-related factors are calculated based on the current time when the packet is received, but once the transmission has started and is underway, the factors may change and the values of those factors may therefore be less relevant and useful, hence leading to flawed results. This formula therefore does not yield a satisfactory solution as well.

Therefore, in accordance with the present disclosure, a dynamic threshold for a buffer, i.e., queue length, may be determined by the time at which it is expected to occur and the particular transmit switch. For example, the threshold may be calculated by the following formula:
T ⁱ _c (t, t + τ, location) =
α _c · 1/N _p '(t, t + τ, location) · γ ⁱ _c '(t, t + τ, location) · (B - B _oc '(t, t + τ, location))
here,
i is the index of the port to which the traffic unit is destined.
c is a class of traffic units.
t is the current time.
・τ is the time difference to the future.
α _c is the coefficient assigned to class c.
Location is the physical location of the switch within a data center, provided, for example, as a combination of a top-of-rack switch identifier and a core switch identifier.
Np'(t,t+τ,location) is the variation or combination of Np(t,location), the number of congestion queues of class priority p at time t for a particular switch, and Np(t+τ,location), the number of congestion queues of class priority p at time t+τ for a particular switch. For example, the value may be equal to any of the numbers, the average of those numbers, etc.
B is the overall buffer, B _oc (t, location) is the occupied buffer at time t, B _oc (t+τ, location) is the occupied buffer at time t+τ, and B-B _oc '(t, t+τ, location) is the variation or combination of B-B _oc (t, location), which is the remaining buffer at time t for a particular switch, and B-B _oc (t+τ, location), which is the remaining buffer at time t+τ for a particular switch. For example, the values may be equal to any of the numbers, the average of those numbers, etc.
γ ⁱ _c ′(t,t+τ,location) is the normalized dequeue rate per port of the i th queue of class c at time t for a particular switch, γ ⁱ _c (t,location), and γ ⁱ _c (t+τ,location), the variance or combination of the normalized dequeue rate per port of the i th queue of class c at time t+τ for a particular switch. For example, the values may be equal to any of the following: numbers, averages of those numbers, etc.

The values of Np(t+τ,location), Boc(t+τ,location), and γ ⁱ _c (t+τ,location) may be obtained from an artificial intelligence engine, e.g., a neural network, that is trained based on multiple transmissions at various times, switches, etc.

In some embodiments, a preferred value of τ may be further learned based on t, which may include, for example, hours, days, months, etc., and the location of the switch, which may also entail the specific behavior of that switch at the relevant time. Generally speaking, τ may vary between milliseconds, seconds, and minutes, which is the time frame for most transmissions, such that setting a threshold may help eliminate or reduce dropped packets. The location of the switch may be represented as a specific switch identifier.

In some implementations of the present disclosure, the queue clearing rate γ ⁱ _c (t+τ,location) can be higher than in conventional methods because the rate is not limited by a first-in, first-out (FIFO) mechanism since multiple packets can be output simultaneously.

Referring now to FIG. 5, a flowchart of steps in a method for training an engine for classifying transmissions and determining buffer sizes is shown, in accordance with some example embodiments of the present disclosure.

The method may be performed by any computing platform, whether or not associated with a particular switch or a particular data center.

In step 504, features may be extracted from the incoming training traffic data, including traffic units such as packets. The traffic units will be transmitted by the switch through ports, which have associated queues. Features may include, for example, source addresses, destination addresses, packet arrival rates, time and date, a particular switch and a particular data center, priority levels (e.g., service level agreements associated with t-parallel computing or MapReduce will entail high priority), etc. Features may be extracted from a packet or a sequence of packets that arrive within a predetermined time interval.

In step 508, the feature vectors may be clustered into separate clusters, each cluster having properties that are more similar to the properties of the other feature vectors assigned to it than to the properties of the feature vectors assigned to the other clusters. Any currently known or to become known clustering algorithm may be applied, such as, but not limited to, K-means, Gaussian mixture models, support vector machines, density-based, distribution-based, centroid-based, or hierarchical-based.

A classifier can then be trained on the feature vectors and the clusters assigned to each vector, so that given another vector, the classifier will output the most appropriate cluster.

In step 512, a data set relevant to each of the clusters may be generated based on the traffic data assigned to the cluster. The data set may include a feature vector assigned to each particular class. The data set may be divided into a training data set, a validation data set, and a test data set.

In step 516, an artificial intelligence (AI) engine, also referred to as a traffic model, implemented as, for example, a neural network, a deep neural network, etc., may be trained on the training dataset. The traffic model is used to predict the load on a particular queue Np(t,t+τ,location), available memory Boc(t,t+τ,location), and drain rate ^γi _c (t,t+τ,location) at a future time +τ for a switch at a particular location. Each dataset from the training dataset, including one or more feature vectors, may be associated with relevant values, referred to as ground truth. For example, for multiple τ values and location values that identify a switch, each vector in the training dataset may be associated with calculated (using predictive analytics) values of Np(t,t+τ,location), Boc(t,t+τ,location), and ^γi _c (t,t+τ,location). The value can be calculated from a large amount of information accumulated about the switch and time t.

Each traffic model is thus trained on the feature vectors of one cluster to output values of Np(t,t+τ,location), Boc(t,t+τ,location), and ^γi _c (t,t+τ,location) for each feature vector and one or more values of τ, which indicate that said values are at a time interval τ after time t. The engine can also be trained to output the τ value that results in the best value or combination of values. Such a value may indicate, for example, that by postponing transmission by a small τ, it may be possible to obtain a larger queue and avoid the risk of losing packets. Each such engine is a spatio-temporal engine, since it receives the time and the switch location.

Once the engine is trained and represents a traffic model, the engine may be validated using a validation dataset for tuning the model's hyperparameters and tested using a test dataset to avoid overfitting.

It will be appreciated that in further embodiments, the same engine can be adapted to process combinations of feature vectors of various classes and operate according to the classes that are related by class designation.

Referring now to FIG. 6, a flowchart of steps in a method for determining a queue threshold, i.e., the amount of buffer to be allocated to a particular queue, is shown, in accordance with some example embodiments of the present disclosure.

The method may be performed by any computing platform, such as a computing platform belonging to or in communication with a particular switch, to obtain results quickly without adding unacceptable delays to the transmission.

In step 604, features may be extracted for the incoming traffic, similar to step 504 above.

In step 608, the feature vectors may be provided to a classifier trained in step 508 above to obtain a class for a set of one or more feature vectors. The class may correspond to one of the clusters into which the training traffic data of FIG. 5 was clustered. Once the feature vectors have been assigned to a class, this may entail the AI engine selecting the relevant class.

At step 612, a particular engine may be applied to the feature vector to obtain one or more sets of values, an indication of predicted traffic volumes. For example, for one or more values of τ, each set of predicted values may include Np(t,t+τ,location), Boc(t,t+τ,location), and γ ⁱ _c (t,t+τ,location). In some embodiments, the engine may also output the τ value that results in the best combination of Np, Boc, and γ ⁱ _c . In an alternative embodiment, the class may be provided to a single engine along with the feature vector, which will operate the particular engine internally according to the class.

In step 616, the results may be combined for a particular feature vector. For example, the value for the current time, i.e., τ=0, may be compared to one or more sets of values obtained for other values of τ, or the value for the current time may be combined, e.g., averaged, with relevant values for other values of τ.

The resulting thresholds can then be applied and the relevant port's queues can be allocated amounts according to the thresholds.

As disclosed above, γ ⁱ _c can be higher than in conventional methods if the queues are not limited to operating in a first-in, first-out (FIFO) paradigm, which can be made possible, for example, by using optical transmission, as detailed in U.S. patent application Ser. No. 63/167,082, entitled "Optical Switch with All-Optical Memory Buffer," assigned to the same assignee as this application.

Referring now to FIG. 7, a block diagram of a system for determining queue size for one or more buffers is shown, in accordance with some example embodiments of the present disclosure.

The block diagram of FIG. 7 may be configured to perform the methods of FIG. 5 and FIG. 6 above. The system of FIG. 7 may include one or more computing platforms 700. Although FIG. 7 shows a single computing platform, it will be understood that the method may be performed by various computing platforms, each including one or more of the components detailed below. Thus, the computing platform of FIG. 7 may be realized as one or more computing platforms that may be operatively connected, or data may be provided directly or indirectly from one computing platform to another. For example, one computing platform 700 may be part of an access switch, aggregate switch, or core switch of a data center and may perform the method of FIG. 6, while another computing platform 700 may be a remote computing platform, such as a server, desktop computer, laptop computer, etc., and may perform the method of FIG. 5.

The computing platform 700 may communicate with other computing platforms via any communication channel, such as a wide area network, a local area network, an intranet, the Internet, or memory storage device transfers.

The computing platform 700 may include a processor 704, which may be one or more central processing units (CPUs), microprocessors, electronic circuits, integrated circuits (ICs), etc. The processor 704 may be configured to provide the required functionality, for example, by loading into memory and activating modules stored on a storage device 716, which will be described in more detail below. It will be appreciated that the processor 704 may be implemented as one or more processors, whether or not located on the same platform.

The computing platform 700 may include input/output (I/O) devices 708, such as a display, speakerphone, headset, pointing device, keyboard, touch screen, etc. The I/O devices 708 may be used to receive input from and provide output to a user, such as receiving preferences, displaying performance statistics, etc.

The computing platform 700 may include a communication device 712 for communicating with other computing platforms, such as other switches, servers, PoDs, data centers, etc. The communication device 712 may be adapted to communicate over any communication protocol and over any channel, such as the Internet, an intranet, a LAN, a WAN, etc.

The computing platform 700 may include a storage device 716, such as a hard disk drive, a flash disk, a random access memory (RAM), a memory chip, etc. In some exemplary embodiments, the storage device 716 may hold program code operable to cause the processor 704 to perform operations associated with any of the modules listed below or to perform the steps of the methods of FIGS. 5 and 6 above. The program code may include one or more executable units, such as functions, libraries, stand-alone programs, etc., adapted to execute instructions as detailed below.

The storage device 716 may include a feature extraction component 720 for extracting features from a single traffic unit, such as a packet, or from a sequence of two or more such units. Features may be, for example, source addresses, destination addresses, packet arrival rates, time and date, a particular switch and a particular data center, priority level (e.g., a service level agreement or MapReduce would be of high priority).

The storage device 716 may include a clustering component 724 that receives feature vectors extracted from traffic units and clusters the extracted feature vectors into groups, also referred to as classes or clusters, such that feature vectors assigned to the same group are more similar to each other according to a predetermined metric than feature vectors assigned to different groups.

The storage device 716 may include a classifier component 728 for receiving one or more feature vectors, such as those extracted by the feature extraction component 720, and classifying those feature vectors into classes or clusters created by the clustering component 724.

The storage device 716 may include a prediction engine training component 732 for receiving, for each such class, the relevant feature vector, as well as one or more ground truth values, such as Np(t,t+τ,location), Boc(t,t+τ,location), and ^γi _c (t,t+τ,location), for various τ and location vectors. After training, each such trained engine is configured to receive as input the feature vector, possibly τ and location values, and output the relevant Np(t,t+τ,location), Boc(t,t+τ,location), and ^γi _c (t,t+τ,location). In some embodiments, the engine may not receive a τ value, but rather output a set of Np(t,t+τ,location), Boc(t,t+τ,location), and ^γi _c (t,t+τ,location) values for each of a small number of values of τ, or for a particular τ value and associated values that result in a preferred combination. The training engine may partition the available feature vectors into training vectors, validation vectors, and test vectors. The engine being trained may be a neural network, a deep neural network, a recurrent neural network (RNN), a long short-term memory, or any other artificial intelligence engine.

A gated recurrent unit (GRU) is a gating mechanism in an RNN. In some embodiments, GRUs can be used to improve performance. The use of GRUs is described in "Evolution: from vanilla RNN to GRU &LSTMs", published on August 21, 2017 and available at https://towardsdatascience.com/lecture-evolution-from-vanilla-rnn-to-gru-lstms-58688f1da83a, https://theaissummer.com/lecture-evolution-from-vanilla-rnn-to-gru-lstms-58688f1da83a. "Recurrent Neural Networks: building GRU cells VS LSTM cells in Pytorch" by Ikolas Adaloglou, published on September 17, 2020 at http://www.google.com/gru; and
This is further detailed in the associated slide show available at https://docs.google.com/presentation/d/1UHXrKL1oTdgMLoAHHPfMM_srDO0BCyJXPmhe4DNh_G8/pub?start=false&loop=false&delayms=3000&slide=id.g24de73a70b_0_0, all of which non-patent literature is incorporated by reference in its entirety for any purpose. It is contemplated that the read and forget gates in the GRU will depend on the traffic at a particular time and location.

The storage device 716 may include a control and data flow component 736 for managing the flow so that each of the components detailed above receives the expected input, their respective outputs are directed to their output destinations, and the required calculations are performed. For example, the control flow component 736 may receive traffic units, invoke the feature extraction component 720 to extract features, classify the features, invoke relevance engines for the classes, calculate applicable values, e.g., based on current and predicted values, and provide values for buffer allocation.

The storage device 716 may include an engine 740 that is trained by the classifier training component 728 and the prediction engine training component 732 and used to classify further feature vectors and predict desired values.

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to implement aspects of the present invention.

A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with recorded instructions, and any suitable combination of the foregoing. A computer-readable storage medium as used herein should not be construed as being essentially a transitory signal, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse traveling through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to the respective computing/processing device or to an external computer or storage device via a network, e.g., the Internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.

The computer readable program instructions for implementing the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source and object code written in any combination of one or more programming languages, such as "C", C#, C++, Java, Phyton, Smalltalk, etc. The computer readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing apparatus create means for implementing the functions/operations specified in one or more blocks of the flowcharts and/or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium in which the instructions are stored may direct a computer, a programmable data processing apparatus, and/or other device to function in a particular manner to produce an article of manufacture that includes instructions that implement aspects of the functions/operations specified in one or more blocks of the flowcharts and/or block diagrams.

The computer-readable program instructions may also be loaded onto a computer, other programmable data processing device, or other device to produce a computer-implemented process in which a series of operational steps are performed on the computer, other programmable device, or other device such that the instructions executing on the computer, other programmable device, or other device perform the functions/operations specified in one or more blocks of the flowcharts and/or block diagrams.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may be performed out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially in parallel, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Furthermore, it is pointed out that each block of the block diagrams and/or flowchart diagrams, as well as combinations of blocks in the block diagrams and/or flowchart diagrams, may be realized by a dedicated hardware-based system that performs the specified functions or operations, or that implements a combination of dedicated hardware and computer instructions.

The terms used herein are merely for the purpose of describing particular embodiments and are not intended to be limiting of the present invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "comprises" and/or "comprising", as used herein, specify the presence of the described features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step-plus-function elements in the following claims are intended to include any structure, material, or act for performing a function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the form disclosed. Many modifications and variations will become apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described to best explain the principles and practical application of the invention, and to enable others skilled in the art to understand the invention for various embodiments with various modifications as suited to the particular use contemplated.

Claims (20)

1. A method for managing traffic in a communications network, comprising:
receiving a plurality of traffic units to be transmitted by the switch through a port, the port having an associated queue;
extracting features from the plurality of traffic units;
providing the characteristics to a first engine to obtain a class for the plurality of traffic units;
obtaining an indication of a predicted amount of traffic for the class for a future time and for a physical location of a switch transmitting the plurality of traffic units using a second engine associated with a traffic model for the class;
allocating a queue of a size corresponding to said indication of said expected traffic volume;
and allocating at least one of said traffic units to said buffer. The method of claim 1, wherein the traffic unit is a packet. receiving a preliminary plurality of traffic units to be transmitted;
extracting features from each of the preliminary plurality of traffic units to obtain a plurality of feature vectors;
clustering the feature vectors into a plurality of classes;
and training the first engine to receive the plurality of traffic units and output the class from the plurality of classes. 2. The method of claim 1, further comprising: training the second engine on a subset of a plurality of feature vectors that are assigned to a particular class, such that the second engine is adapted by the traffic model to provide the indication of the predicted traffic volume for the class. The method of claim 1, wherein the predicted traffic volume is predicted for a future time t+τ, where t is the current time and τ is a time interval. The method of claim 1, wherein the predicted traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval, and the traffic volume is predicted based on available buffer sizes at the current time and at the future time. The method of claim 1, wherein the predicted traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval, and the traffic volume is predicted based on a number of congested queues of the priority class at the future time. The method of claim 1, wherein the predicted traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval, and the traffic volume is predicted based on a normalized dequeue rate of the queue at the future time. The method of claim 1, wherein the predicted traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval, and the traffic volume is predicted based on a priority of an application or site associated with the plurality of traffic units. The method of claim 1, wherein the predicted traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval, and the traffic volume is predicted based on coefficients associated with the class. The method of claim 1, wherein the traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval, and the traffic volume is predicted based on the physical location of the switch. The predicted traffic volume is calculated using the following formula:
T ⁱ _c (t, t + τ, location) =
α _c · 1 / Np '(t, t + τ, location) · γ _i ^c '(t, t + τ, location) · (B - Boc '(t, t + τ, location))
is predicted by
here,
i is the index of the port,
c is a class of the plurality of traffic units;
t is the current time,
τ is the time difference to the future,
α _c is the coefficient assigned to class c,
Location is the physical location of the switch within a data center;
Np'(t, t+τ, location) is
Np(t,location), the number of congested queues of the class of priority at time t for the switch; and
Np(t+τ,location) is the number of congested queues of priority p of the class at time t+τ for the switch.
is a variation or combination of
B-B _oc '(t, t+τ, location) is
B-B _oc (t, location), the remaining buffer for the switch at time t; and
B-B _oc (t+τ, location) is the remaining buffer at time t+τ for the switch.
is a variation or combination of
γ ⁱ _c ′(t, t+τ, location) is
γ ⁱ _c (t,location), the normalized dequeue rate per port of the queue of class c at time t for the switch; and
γ ⁱ _c (t+τ,location) is the normalized dequeue rate per port of the i-th queue of class c at time t+τ for the switch.
The method of claim 1, wherein the α-amino acid is a variation or combination of The method of claim 1, wherein the queue is not emptied in a first-in, first-out manner. The method of claim 12, wherein multiple traffic units are dequeued from the queue simultaneously. 1. A computer program product including a non-transitory computer-readable storage medium bearing program instructions, the program instructions, when read by a processor,
receiving a plurality of traffic units to be transmitted by the switch through a port, the port having an associated queue;
extracting features from the plurality of traffic units;
providing the characteristics to a first engine to obtain a class for the plurality of traffic units;
obtaining an indication of a predicted amount of traffic for the class for a future time and for a physical location of a switch that transmits the plurality of traffic units using a second engine associated with a traffic model for the class;
allocating a queue of a size corresponding to said indication of said expected traffic volume;
and allocating at least one of the traffic units to the buffer. The computer program product of claim 15, wherein the traffic unit is a packet. The program instructions include:
receiving a preliminary plurality of traffic units to be transmitted;
extracting features from each of the preliminary plurality of traffic units to obtain a plurality of feature vectors;
clustering the feature vectors into a plurality of classes;
16. The computer program product of claim 15, further causing the processor to: train the first engine to receive the plurality of traffic units and output the class from the plurality of classes. The program instructions include:
16. The computer program product of claim 15, further causing the processor to: train the second engine based on a subset of feature vectors that are assigned to a particular class, such that the second engine is adapted to provide the indication of the expected traffic volume for the class by the traffic model. The computer program product of claim 15, wherein the predicted traffic volume is predicted for a future time t+τ, where t is a current time and τ is a time interval. The predicted traffic volume is
the available buffer size at the current time and at said future time;
the number of congested queues of said class of priority at said future time;
a normalized dequeue rate for the queue at the future time;
a priority of an application or site associated with said plurality of traffic units;
a coefficient associated with the class; and
20. The computer program product of claim 15, wherein the prediction is based on at least one item selected from an enumeration consisting of the physical location of the switch.

Images