Methods for traffic rate control and devices thereof

This application claims the benefit of U.S. Provisional Patent Application No. 61/905,011, filed on Nov. 15, 2013, which is hereby incorporated by reference in its entirety.

This technology generally relates to methods and devices for controlling the rate of network traffic and, more specifically, to controlling or shaping the rate of network traffic to reduce overhead and increase scalability.

Transmission Control Protocol (TCP) is used to facilitate communication between applications of a transmitting network device and a receiving network device using the Internet Protocol (IP). In particular, when a transmitting network device transmits data across a network (e.g., the Internet), application layer software on the transmitting network device issues a request using the TCP layer. The TCP layer handles routing and SEND/ACK details to ensure delivery of the data to the receiving network device.

Network congestion, traffic load balancing, or unpredictable network behavior can cause data packets to be lost, duplicated, or delivered out of order between transmitting and receiving network devices. The TCP layer detects these problems, requests retransmission of lost packets, rearranges out-of-order packets, and/or minimizes network congestion to mitigate anomalous activity. Once the receiving network device has reassembled data packets sent from the transmitting network device, it passes the data packets to the application running on the receiving network device.

When data packets are transmitted between transmitting and receiving network devices, rate or traffic shaping is used by a rate shaper of the transmitting network device to control the rate of flow at which data is transmitted. Typically, the receiving network device continually informs the transmitting network device as to how much data it can receive. When a buffer of the receiving network device fills with data, a subsequent acknowledgment sent to the transmitting network device includes a notification to suspend or stop sending data until the receiving network device is able to process the previously received data packets.

Network performance is generally maintained by using Quality of Service (QoS) functionality performed by the rate shaper, including as a QoS queue. Typically, a transmitting network device packetizes data in accordance with the TCP and sends the data packets to the QoS queue associated with a receiving network device (also referred to as a subscriber). The QoS queue stores the packetized packets and buffers them before transmitting them to control the traffic flow based on predetermined handling parameters. However, this process generally requires performing an enqueue and a dequeue of every packet, which can introduce significant overhead to the process. Additionally, QoS queues, as well as associated token buckets and timers, are not efficiently scalable, and therefore require significant resources to manage a large number of subscribers, which is undesirable.

A method for traffic rate control, the method includes allocating, by a traffic management computing device, a proportional subset of an amount of tokens to each of one or more currently active subscribers of a plurality of subscribers. The proportional subset of the amount of tokens is allocated based on an estimated number of the plurality of subscribers that will be active in a next sampling period and is based on an established bandwidth profile and a token recharge rate. A request to transmit a first packet is received, by the traffic management computing device, from one of the currently active subscribers. A determination is made, by the traffic management computing device, when a current time is prior to an expiration of the proportional subset of the amount of tokens allocated to the one currently active subscriber. Next, a determination is made, by the traffic management computing device, when a length of the first packet is less than a size corresponding to an available portion of the proportional subset of the amount of tokens allocated to the one currently active subscriber, when the current time is determined to be prior to the expiration of the proportional subset of the amount of tokens allocated to the one currently active subscriber. The first packet is transmitted, by the traffic management computing device, when the length of the first packet is determined to be less than a size corresponding to an available portion of the proportional subset of the amount of tokens allocated to the one currently active subscriber.

A traffic management computing device includes configurable hardware logic configured to be capable of implementing, or a processor, and a memory coupled to the processor, which is configured to be capable of executing programmed instructions comprising and stored in the memory to allocate a proportional subset of an amount of tokens to each of one or more currently active subscribers of a plurality of subscribers. The proportional subset of the amount of tokens is allocated based on an estimated number of the plurality of subscribers that will be active in a next sampling period and is based on an established bandwidth profile and a token recharge rate. A request to transmit a first packet is received from one of the currently active subscribers. A determination is made when a current time is prior to an expiration of the proportional subset of the amount of tokens allocated to the one currently active subscriber. Next, a determination is made when a length of the first packet is less than a size corresponding to an available portion of the proportional subset of the amount of tokens allocated to the one currently active subscriber, when the current time is determined to be prior to the expiration of the proportional subset of the amount of tokens allocated to the one currently active subscriber. The first packet is transmitted when the length of the first packet is determined to be less than a size corresponding to an available portion of the proportional subset of the amount of tokens allocated to the one currently active subscriber.

A non-transitory computer readable medium having stored thereon instructions for traffic rate control comprising executable code which when executed by a processor, causes the processor to perform steps including allocating a proportional subset of an amount of tokens to each of one or more currently active subscribers of a plurality of subscribers. The proportional subset of the amount of tokens is allocated based on an estimated number of the plurality of subscribers that will be active in a next sampling period and is based on an established bandwidth profile and a token recharge rate. A request to transmit a first packet is received from one of the currently active subscribers. A determination is made when a current time is prior to an expiration of the proportional subset of the amount of tokens allocated to the one currently active subscriber. Next, a determination is made when a length of the first packet is less than a size corresponding to an available portion of the proportional subset of the amount of tokens allocated to the one currently active subscriber, when the current time is determined to be prior to the expiration of the proportional subset of the amount of tokens allocated to the one currently active subscriber. The first packet is transmitted when the length of the first packet is determined to be less than a size corresponding to an available portion of the proportional subset of the amount of tokens allocated to the one currently active subscriber.

This technology provides a number of advantages including more efficient and effective methods, non-transitory computer readable media, and devices for controlling the rate of network traffic. With this technology, all packets are not queued in order to manage the rate at which packets are transmitted. Accordingly, enqueue and dequeue methods are not performed for every packet, thereby reducing overhead. Additionally, reduced throughput due to trail dropping of packets associated with TCP connections is mitigated at least in part by implementing an early drop policy. Moreover, packets that are unable to be transmitted immediately are advantageously queued and resubmitted based on expiration of a flow timer, thereby reducing the amount of time required to transmit a packet that may have otherwise been dropped.

FIG. 1 is a block diagram of a network environment with an exemplary traffic management computing device;

FIG. 2 is a block diagram of the exemplary traffic management computing device illustrated in FIG. 1 ;

FIG. 3 is a flowchart of an exemplary method for allocating bandwidth and processing requests to transmit packets received from a subscriber;

FIG. 4 is a flowchart of an exemplary method for sweeping subscriber contexts to maintain active and inactive states and an active subscriber count; and

FIG. 5 is a flowchart of an exemplary method for processing dropped packets.

Referring to FIG. 1 , a block diagram of an exemplary network environment 10 including an exemplary traffic management computing device 12 is illustrated. In this example, the traffic management computing device 12 is coupled to a plurality of client computing devices 14 ( 1 )- 14 ( n ) through a local area network (LAN) 16 and a wide area network (WAN) 18 and a plurality of server computing devices 16 ( 1 )- 16 ( n ) through another LAN 20 , although the traffic management computing device 12 , client computing devices 14 ( 1 )- 14 ( n ), and server computing devices 16 ( 1 )- 16 ( n ) may be coupled together via other topologies. The network environment 10 may include other network devices such as one or more routers and/or switches, for example. Although, the traffic management computing device 12 implements the traffic rate control described and illustrated herein in this example, any other type of device running applications configured to handle HTTP communications by transmitting data using TCP connections, for example, can also be used. This technology provides a number of advantages including methods, non-transitory computer readable medium, and devices that facilitate relatively scalable bandwidth control for a large number of subscribers without using QoS queues and other resources dedicated to each subscriber.

Referring to FIGS. 1-2 , the traffic management computing device 12 may perform any number of functions in addition to implementing traffic rate control, such as optionally optimizing, securing, and/or load balancing the network traffic exchanged between the client computing devices 14 ( 1 )- 14 ( n ) and the server computing devices 16 ( 1 )- 16 ( n ), for example. The traffic management computing device 12 includes a processor 22 , a memory 24 , optional configurable hardware logic 26 , and a communication interface which are coupled together by a bus 32 or other communication link, although the traffic management computing device 12 may include other types and numbers of elements in other configurations.

The processor 22 of the traffic management computing device 12 may execute programmed instructions stored in the memory 24 of the traffic management computing device 12 for the any number of the functions identified above and/or described herein for controlling traffic rate and, optionally, managing network traffic and/or optimizing service of resource requests, for example. The processor 22 of the traffic management computing device 12 may comprise one or more central processing units and/or general purpose processors with one or more processing cores, for example.

The memory 24 of the traffic management computing device 12 stores these programmed instructions for one or more aspects of the present technology as described and illustrated herein, although some or all of the programmed instructions could be stored and executed elsewhere. A variety of different types of memory storage devices, such as a random access memory (RAM) or a read only memory (ROM), hard disk drives, solid state drives, or other computer readable medium which is read from and written to by a magnetic, optical, or other reading and writing system that is coupled to the processor, can be used for the memory 24 .

In this example, the memory 24 further includes a token allocation table 32 and a subscriber context table 34 . The token allocation table 32 includes information regarding allocation and available amount of tokens for each subscriber which corresponds to the allocated and available amount of bandwidth for the subscribers, as described and illustrated in more detail later. The subscriber context table 34 includes information regarding a state of each subscriber (e.g., active or inactive) and a transmission count for the current and/or any number of previous sampling periods, for example, as described and illustrated in more detail later.

The optional configurable hardware logic 26 of the traffic management computing device 12 may comprise specialized hardware configured to implement one or more steps of this technology as illustrated and described with reference to the examples herein. By way of example only, the configurable hardware logic 26 may comprise one or more of field programmable gate arrays (FPGAs), field programmable logic devices (FPLDs), application specific integrated circuits (ASICs) and/or programmable logic units (PLUs). In this example, the configurable hardware logic 26 includes a bandwidth controller 36 configured to implement one or more steps of this technology including processing packet transmission requests as described and illustrated in more detail later.

The communication interface 28 operatively couples and communicates between the traffic management computing device 12 , the client computing devices 14 ( 1 )- 14 ( n ), and server computing devices 16 ( 1 )- 16 ( n ), which are all coupled together by the LANs 16 and 20 and WAN 18 , although other types and numbers of communication networks or systems with other types and numbers of connections and configurations to other devices and elements. By way of example only, the LANs 16 and 20 and WAN 18 can use TCP/IP over Ethernet and industry-standard protocols, including NFS, CIFS, SOAP, XML, LDAP, and SNMP, although other types and numbers of communication networks, can be used.

The LANs 16 and 20 in this example may employ any suitable interface mechanisms and network communication technologies including, for example, teletraffic in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Ethernet-based Packet Data Networks (PDNs), combinations thereof, and the like. The WAN 18 may comprise any wide area network (e.g., Internet), although any other type of traffic network topology may be used.

Each of the client computing devices 14 ( 1 )- 14 ( n ) and server computing devices 16 ( 1 )- 16 ( n ) includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and types of network devices could be used. The client computing devices may run interface applications, such as Web browsers, that may provide an interface to make requests for and receive content associated with applications hosted by the server computing devices 16 ( 1 )- 16 ( n ) via the LANs 16 and 20 and/or WAN 18 .

The server computing devices 16 ( 1 )- 16 ( n ) may provide content or other network resources in response to requests directed toward the respective applications hosted by the server computing devices 16 ( 1 )- 16 ( n ) from the client computing devices 14 ( 1 )- 14 ( n ) via the LANs 16 and 20 and/or the WAN 18 according to the HTTP-based application RFC protocol or the CIFS or NFS protocol, for example. The server computing devices 16 ( 1 )- 16 ( n ) may be hardware or software or may represent a system with multiple server computing devices 16 ( 1 )- 16 ( n ) in a server computing device pool, which may include internal or external networks. Various network processing applications, such as CIFS applications, NFS applications, HTTP Web Server applications, and/or FTP applications, may be operating on the server computing devices 16 ( 1 )- 16 ( n ) and transmitting data (e.g., files or web pages) in response to requests from the client computing devices 14 ( 1 )- 14 ( n ).

Although the exemplary network environment 10 with the traffic management computing device 12 , client computing devices 14 ( 1 )- 14 ( n ), server computing devices 16 ( 1 )- 16 ( n ), LANs 16 and 20 , and WAN 18 are described and illustrated herein, other types and numbers of systems, devices, components, and elements in other topologies can be used. It is to be understood that the systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).

In addition, two or more computing systems or devices can be substituted for any one of the systems or devices in any example. Accordingly, principles and advantages of distributed processing, such as redundancy and replication also can be implemented, as desired, to increase the robustness and performance of the devices and systems of the examples. The examples may also be implemented on computer system(s) that extend across any suitable network using any suitable interface mechanisms and traffic technologies, including by way of example only teletraffic in any suitable form (e.g., voice and modem), wireless traffic media, wireless traffic networks, cellular traffic networks, G3 traffic networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, and combinations thereof.

The examples may also be embodied as a non-transitory computer readable medium having instructions stored thereon for one or more aspects of the present technology as described and illustrated by way of the examples herein, as described herein, which when executed by a processor, cause the processor to carry out the steps necessary to implement the methods of the examples, as described and illustrated herein.

An exemplary method for traffic rate control will now be described with reference to FIGS. 1-5 . Referring more specifically to FIG. 3 a method for allocating bandwidth and processing requests to transmit packets received from a subscriber is illustrated. In step 300 in this example, the traffic management computing device 12 initializes the bandwidth controller by generating a common token bucket having a plurality of tokens. The number of tokens in, or the depth of, the common token bucket corresponds with an aggregate rate of all subscribers associated with a particular group or class and a token recharge rate.

The aggregate rate and token recharge rate can be established by a configuration provided by an administrator of the traffic management computing device 12 , for example. The particular class of subscribers can be based on an association of the subscribers with a specific application or a specified network address or location, for example, although any other attributes can be used to identify a particular class of subscribers. Accordingly, in one example, the depth of the common token bucket corresponds with a network capacity for the class of subscribers.

In step 302 , the traffic management computing device 12 allocates a plurality of tokens proportionally to active subscribers based on an estimated number of active subscribers for a next recharge cycle. The number of allocated tokens can be mapped to each active subscriber in the token allocation table 32 . Each of the tokens corresponds with a size of network traffic (also referred to herein as packet length) that can be transmitted by an associated subscriber. Additionally, each token is valid for a specified duration and has an associated expiration.

The number of active subscribers can be estimated based on a moving average of active subscribers in a plurality of prior recharge cycles or based on a number of subscribers currently active at the time of the allocation, for example, although other methods of estimating the number of active subscribers for a next recharge cycle can also be used. A subscriber can be determined to be active based on a state value in an entry of the subscriber context table 34 corresponding to the subscriber and the number of active subscribers can be maintained in an active subscriber count stored in the memory, as described and illustrated in more detail later.

In step 304 , the traffic management computing device 12 receives a request to transmit a packet from a subscriber. The request can be from a TCP stack associated with the subscriber and can be received by the bandwidth controller 36 , for example. In this example, the subscriber can correspond to one of the client computing devices 14 ( 1 )- 14 ( n ), although the subscriber can be any other network device communicating with the traffic management computing device 12 . Accordingly, the packet can be a portion of an application layer message, such as an HTTP request for content stored by one of the server computing devices 16 ( 1 )- 16 ( n ), for example, although any other type of packet with other content or information can also be used.

In step 306 , the traffic management computing device 12 determines whether the subscriber that originated the request is inactive. Accordingly, the traffic management computing device 12 can query the subscriber context table 34 based on identifying information included in the packet, for example, to retrieve a state value. The state value can indicate an active or inactive state for a subscriber, as described and illustrated in more detail later with reference to FIG. 4 . If the traffic management computing device 12 determines that the subscriber is inactive, then the Yes branch is taken to a step 308 .

In step 308 , the traffic management computing device 12 allocates tokens to the subscriber by inserting or modifying an entry of the token allocation table 32 , modifies the context for the subscriber in the subscriber context table 34 to indicate an active state, and increments an active subscriber count stored in the memory 24 . In this example, the number of tokens allocated to the subscriber is equivalent to the proportional number of tokens allocated to the active subscribers in step 302 , although another amount or number of tokens can also be allocated to the subscriber.

Subsequent to allocating the tokens, modifying the corresponding entry of the subscriber context table 34 , and incrementing the active subscriber count in step 308 , or if the traffic management computing device 12 determines that the subscriber is not active and the No branch is taken from step 306 , the traffic management computing device 12 proceeds to step 310 . In step 310 , the traffic management computing device 12 determines whether a current time is less than an expiration time for the tokens identified in the corresponding entry of the token allocation table 32 as available for use by the subscriber to transmit the packet. If the traffic management computing device 12 determines that the token duration or interval has been exceeded and the tokens are expired, then the No branch is taken back to step 300 and the traffic management computing device 12 again fills the common token bucket, as described and illustrated earlier. Optionally, the packet can be dropped or queued and resubmitted, such as described and illustrated in more detail later with reference to FIG. 5 , for example, subsequent to the common token bucket being refilled.

Referring back to step 310 , if the traffic management computing device 12 determines that the token duration or interval has not been exceeded, and that the tokens are not expired, then the Yes branch is taken to step 312 . In step 312 , the traffic management computing device 12 determines whether the length of the packet is less than a size corresponding to one or more available tokens allocated to the subscriber. The tokens available for the subscriber can be identified by querying the token allocation table 32 , for example. Accordingly, if the traffic management computing device 12 determines that the subscriber does have sufficient tokens to transmit the packet in the current recharge cycle, then the Yes branch is taken to step 314 .

In step 314 , the traffic management computing device 12 implements an early drop policy to determine whether the packet should be dropped even though the subscriber has enough available tokens to transmit the packet. By implementing an early drop policy and dropping packets early in a recharge cycle, the traffic management computing device 12 can mitigate the undesirable effect on throughput introduced by tail dropping at the end of a recharge cycle. Pseudocode for one exemplary early drop policy is illustrated as follows:

1. If (bi(t)<bi-min_th) ADMIT

2. Else {

3. p=rand( );

4. If (p<(ri/fi)) DROP;

5.}

In this example, ri is an input rate of packets received from the subscriber, fi is a fair rate for the subscriber, bi(t) is the number of available tokens for the subscriber at time t, bi is the number of tokens allocated to the subscriber in the recharge cycle, and min_th is a minimum threshold number of the tokens allocated to the subscriber that must be used before any packets are dropped pursuant to this exemplary early drop policy. Accordingly, fi and min_th can be established by an administrator of the traffic management computing device 12 , bi(t) can be determined from the token allocation table 32 , and bi can be the predetermined number of tokens allocated in steps 302 or 308 , for example, although the parameters of the early drop policy can have other values and can be determined in other manners.

Pseudocode for another exemplary early drop policy is illustrated as follows:

1. Start: No early drop.

2. Count number of tail drop packets (X) out of N packets.

3. Set drop_window=N/X such that a packet is dropped once in every drop window.

4. If no tail drop then drop_window is increased by a fixed amount.

5. If packets are subsequently tail dropped, then recalculate drop_window.

6. Repeat the third through fifth steps.

Other early drop policies can also be implemented by the traffic management computing device 12 in step 314 . If the traffic management computing device 12 determines that the packet should be dropped based on the implemented early drop policy, then the Yes branch is taken to step 316 .

In step 316 , the traffic management computing device 12 drops or queues the packet depending on a configuration provided by an administrator of the traffic management computing device 12 . For example, if the traffic management computing device 12 is operating as a full proxy and terminating TCP connections from both the client computing devices 14 ( 1 )- 14 ( n ) and the server computing devices 16 ( 1 )- 16 ( n ), then the traffic management computing device 12 can be configured to queue the packet for later retransmission.

Conversely, if the traffic management computing device 12 is not operating as a full proxy, then the traffic management computing device 12 can be configured to drop the packet. In another example, the traffic management computing device 12 can be configured to drop all packets that the traffic management computing device 12 determines in step 314 should be dropped based on the implementation of the early drop policy. Other configurations establishing whether a packet should be dropped or queued, or another action should be taken, can also be used.

Referring back to step 314 , if the traffic management computing device 12 determines that the packet should not be dropped based on the implemented early drop policy then the No branch is taken to step 318 . In step 318 , the traffic management computing device 12 transmits the packet using the communication interface 28 . In step 318 , the traffic management computing device 12 also increments a transmission count for the current recharge cycle for the subscriber. The transmission count can be stored in the subscriber context table 34 and can be used to determine whether the subscriber is currently in an active or inactive state, as described and illustrated in more detail later with reference to FIG. 4 .

Additionally, the traffic management computing device 12 debits the available tokens for the subscriber in step 318 . The amount of tokens allocated to the subscriber and currently available (not yet used) in the current recharge cycle can be maintained in, and debited from, the token allocation table 34 , for example. Subsequent to transmitting the packet, incrementing the transmission count, and debiting the available tokens, or during any of steps 306 - 318 , the traffic management computing device 12 receives another request to transmit a packet from the same or a different subscriber in the third step 304 , as described and illustrated earlier.

Referring back to step 312 , if the traffic management computing device 12 determines that the subscriber does not have sufficient tokens to transmit the packet in the current recharge cycle, then the No branch is taken to step 320 . In step 320 , the traffic management computing device 12 implements an oversubscription policy to determine whether the packet can be transmitted. Packets can be outstanding at the end of a recharge cycle when a subscriber runs out of tokens, the network is congested, and/or many subscribers became active and were allocated tokens in the recharge cycle, for example, although packets can be outstanding for other reasons.

Accordingly, an administrator of the traffic management computing device 12 can establish an oversubscription policy, the parameters of which can be stored in the memory 24 for example. The oversubscription policy generally provides for the borrowing of tokens in the next recharge cycle so that outstanding packets can be transmitted in the current recharge cycle. Outstanding packets can optionally be stored in a queue that is processed based on the oversubscription policy at the end of a recharge cycle, although the outstanding packets can also be stored elsewhere. Pseudocode for one exemplary oversubscription policy is illustrated as follows:

1. If ((Li=Len(packet(i)))<bi) 2. //Check if common token bucket (CTB) can transmit the packet at this instance, 3. If (Li > Ba(t)) 4. DROP; 5. Else 6. //Borrow from EB if possible. Before borrowing can begin one packet must be sacrifices. 7. If (bi >=0 && Li<debt) 8. If (drop_before_excess_burst==FALSE) DROP 9. Else drop_before_excess_burst=TRUE: 10. Debt=(Li−bi) 11. bi=bi−Li; 12. ADMIT 13. Else 14. debt=0; 15. DROP

In this example, bi is the aggregate maximum token depth of the common token bucket, Ba(t) is the available number of tokens at time t, and EB is an excessive burst size per subscriber that is predetermined by an administrator of the traffic management computing device 12 . Other oversubscription policies can also be used.

Optionally, the oversubscription policy specifies a maximum number of tokens that can be borrowed from the next recharge cycle (e.g., an aggregate amount or an amount per subscriber) and the traffic management computing device 12 can maintain the number of tokens utilized to send at least a subset of the outstanding packets in the current recharge cycle. Accordingly, if the traffic management computing device 12 determines based on the implementation of the oversubscription policy that the packet cannot be transmitted, then the No branch is taken to step 316 and the packet is dropped or queued, as described and illustrated earlier. Alternatively, if the traffic management computing device 12 determines in step 320 , based on the implementation of the oversubscription policy, that the packet can be transmitted, then the Yes branch is taken to step 318 and the packet is transmitted, as described and illustrated earlier.

Referring more specifically to FIG. 4 , an exemplary method for sweeping subscriber contexts in the subscriber context table 34 to maintain active and inactive states and an active subscriber count is illustrated. In this example, the sweeping of the subscriber contexts described and illustrated in FIG. 4 can be performed, such as by the bandwidth controller 36 for example, in parallel with the method of allocating bandwidth and processing requests to transmit packets described and illustrated earlier with reference to FIG. 3 .

Accordingly, in step 400 in this example, the traffic management computing device 12 retrieves one of a plurality of subscriber contexts, which are stored in the subscriber context table 34 in this example. The subscriber contexts in this example include a unique indication of the subscriber, a transmission count for at least a current sampling period and a last sampling period, a state which can indicate an active or inactive state for the subscriber, and a last visit time. Other information can also be stored in the subscriber contexts.

In step 404 , the traffic management computing device 12 determines whether the difference between a current time and the last visit time for the one subscriber context is less than the size of the sampling period. Accordingly, the traffic management computing device 12 essentially determines whether the subscriber context has already been visited/retrieved during the current sampling period. Optionally, the sampling period can correspond with the token recharge cycle configured by an administrator of the traffic management computing device 12 , as described and illustrated earlier with reference to the step 300 of FIG. 3 , although a different sampling period can also be used. Accordingly, if the traffic management computing device 12 determines that the difference between a current time and the last visit time for the one subscriber context is not less than the size of the sampling period, then the No branch is taken to step 404 .

In step 404 , the traffic management computing device 12 determines whether the transmission count for the last sampling period is equivalent to zero. If the transmission count for the last sampling period is equivalent to zero, then the subscriber associated with the one of the subscriber contexts was not active or did not transmit any packets during the last sampling period. If the subscriber associated with the one of the subscriber contexts did transmit one or more packets in the last sampling period, then the transmission count would have been incremented as described and illustrated earlier with reference to step 318 of FIG. 3 and would not be equivalent to zero.

Optionally, in other examples, the traffic management computing device 12 can determine whether the transmission count for a specified number of prior sampling periods, and/or the current sampling period, is also equivalent to zero depending on how many sampling periods of inactivity an administrator of the traffic management computing device 12 would like to require prior to changing the state of the subscriber context to indicate an inactive state. Accordingly, if the traffic management computing device 12 determines that the transmission count for the last sampling period is equivalent to zero, then the Yes branch is taken to step 406 .

In step 406 , the traffic management computing device 12 determines whether the state in the one subscriber context indicates an active state. If the traffic management computing device 12 determines that the state in the one subscriber context indicates an active state, then the Yes branch is taken to step 408 . In step 408 , the traffic management computing device 12 modifies the one subscriber context to indicate an inactive state and decrements an active subscriber count. The active subscriber count can be maintained in the memory 24 , as described and illustrated earlier with reference to step 308 of FIG. 3 , and can be used to generated the common token bucket and/or to allocate the plurality of tokens, as described and illustrated earlier with reference to the steps 300 - 302 of FIG. 3 .

Subsequent to modifying the subscriber context, or if the traffic management computing device 12 determines that the difference between the current time and the last visit time is less than the size of the sampling period in step 402 and the Yes branch is taken, the transmission count for the last sampling period is not equivalent to zero in step 404 and the No branch is taken, or the state in the one subscriber context does not indicate an active state in step 406 and the No branch is taken, the traffic management computing device 12 proceeds to step 410 . In step 410 , the traffic management computing device 12 sets the last visit time of the one subscriber context to the current time. Subsequent to setting the last visit time to the current time, the traffic management computing device 12 proceeds back to step 400 and retrieves another one of the subscriber contexts from the subscriber context table 34 , as described and illustrated earlier.

Referring more specifically to FIG. 5 , an exemplary method for processing dropped packets, such as those packets determined to be dropped or queued in step 316 for example, is illustrated. In this example, the traffic management computing device 12 is configured to operate as a full proxy terminating TCP connections between the client computing devices 14 ( 1 )- 14 ( n ) and server computing devices 16 ( 1 )- 16 ( n ), although other operational configurations for the traffic management computing device 12 can also be used. In step 500 in this example, the traffic management computing device 12 creates a data packet for transmission. The packet can be created by a TCP stack associated with a subscriber, for example.

In step 502 , the traffic management computing device 12 ( 1 )- 12 ( n ) submits the packet to the IP layer for processing. The packet can be submitted to the IP layer by the TCP stack, for example. In step 504 , the traffic management computing device 12 receives the packet, such as at the bandwidth controller 36 and from the TCP stack, for example. Accordingly, step 504 in FIG. 5 corresponds with step 304 in FIG. 3 in this example.

In step 506 , the traffic management computing device 12 determines whether the bandwidth controller 36 decided to drop the packet. The packet can be dropped as described and illustrated earlier with reference to step 316 of FIG. 3 , such as when a length of the packet is less than a size corresponding to an available amount of tokens allocated to the subscriber, or based on a result of an implemented early drop policy, for example, although the packet can also be dropped for other reasons. If the traffic management computing device 12 determines that the packet was not determined to be dropped by the bandwidth controller 36 , then the No branch is taken to step 508 . In step 508 , the packet is transmitted as described and illustrated earlier with reference to step 318 of FIG. 3 .

Referring back to step 506 , if the traffic management computing device 12 determines that the packet was determined to be dropped by the bandwidth controller 36 , then the Yes branch is taken to step 510 . In step 510 , the traffic management computing device 12 marks the packet as not transmitted and, optionally, sends the packet back to the TCP stack or places the packet in a queue associated with the TCP stack, for example. In one example, the packet can be marked based on an indication associated with the packet stored in a portion of the memory 24 utilized by the TCP stack to store and retrieve packets, for example. In another example, the bandwidth controller 36 sends a return code to the TCP stack from which the packet was received to indicate that the packet has been marked. Other manners of marking the packet can also be used.

In step 512 , the traffic management computing device 12 sets a TCP flow timer in the memory 24 to schedule resubmission of the packet by the TCP stack to the bandwidth controller 36 . Optionally, the TCP flow timer can be set by the bandwidth controller 36 based on the token recharge rate of the bandwidth controller 36 so that resubmission of the packet occurs in a next recharge cycle during which the subscriber associated with the TCP stack may have available tokens that can be used to transmit the packet.

Accordingly, in step 514 , the traffic management computing device 12 determines whether the flow time has expired. If the traffic management computing device 12 determines that the flow timer has not expired, then the No branch is taken back to step 514 , and the traffic management computing device 12 effectively waits for the flow timer to expire. However, if the traffic management computing device 12 determines in step 514 that the flow timer has expired, then the Yes branch is taken back to step 504 .

Accordingly, when the flow timer has expired, the traffic management computing device 12 notifies the TCP stack and the bandwidth controller 36 receives a second request to transmit the packet. In this example, the packet can then be processed as described and illustrated earlier with reference to the steps 304 - 320 of FIG. 3 and the traffic management computing device can again determine whether the packet was determined to be dropped by the bandwidth controller 36 in step 506 of FIG. 5

By this technology, bandwidth control, traffic rate control, and/or traffic rate shaping policies can be implemented with reduced overhead and increased scalability since each packet does not have to be enqueued and dequeued, and a queue does not have to be maintained for each subscriber. Instead, requests to transmit packets of a specified size can be serviced with tokens and an allocated quota per subscriber per recharge cycle can be used to limit the bandwidth utilized in a time period. Advantageously, an early drop policy can be implemented to mitigate the reduced throughput resulting from tail dropping packets for TCP connections. Additionally, packets determined to be dropped can be more effectively processed and resubmitted based on expiration of a flow timer, thereby reducing the time required to transmit a packet that would otherwise have been dropped to a destination.

Having thus described the basic concept of the invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the invention. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.