Dynamic rate limiting adjustment may be provided by sampling actual output rates from a rate limited device and utilizing this information to modify configured traffic limits. This allows the device to achieve actual output rates much closer to the desired rate limits for users and services.
|
15. An apparatus comprising:
a memory; and
one or more processors configured to:
receive a rate limit for a traffic type through the apparatus;
implement the rate limit for incoming traffic of the traffic type;
sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate; and
repeat implementing and sampling with the rate limit set to a new rate limit, the new rate limit chosen to reduce a difference between the rate limit for the traffic type and the outgoing rate for the traffic type.
1. An apparatus comprising:
an incoming traffic rate limit implementer configured to implement a rate limit for incoming traffic of a traffic type through the apparatus; and
an outgoing traffic sampler coupled to the incoming traffic rate limit implementer and configured to sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate, the apparatus configured to repeat implementing and sampling with the rate limit set to a new rate limit, the new rate limit chosen to reduce a difference between the rate limit for the traffic type and the outgoing rate for the traffic type.
8. An apparatus comprising:
a traffic type rate limit receiver configured to receive a rate limit for a traffic type through the apparatus;
an incoming traffic rate limit implementer coupled to the traffic type rate limit receiver and configured to implement the rate limit for incoming traffic of the traffic type; and
an outgoing traffic sampler coupled to the incoming traffic rate limit implementer and configured to sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate, the apparatus configured to repeat implementing and sampling with the rate limit set to a new rate limit, the new rate limit chosen to reduce a difference between the rate limit for the traffic type and the outgoing rate for the traffic type.
2. The apparatus of
3. The apparatus of
4. The apparatus of
5. The apparatus of
6. The apparatus of
7. The apparatus of
9. The apparatus of
10. The apparatus of
11. The apparatus of
12. The apparatus of
13. The apparatus of
14. The apparatus of
16. The apparatus of
17. The apparatus of
18. The apparatus of
19. The apparatus of
20. The apparatus of
|
|||||||||||||||||||||||||||||||
This application is a continuation of prior U.S. patent application Ser. No. 10/198,703, entitled “Dynamic Rate Limiting Adjustment,” filed on Jul. 17, 2002, now U.S. Pat. No. 7,310,309.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to the field of web switches. More particularly, the present invention relates to dynamically adjusting rate limiting on a switch or router.
Rate limiting involves the setting and implementation of traffic rates such that users or services may not utilize more bandwidth then they have been apportioned. This is especially useful in selling varying levels of traffic allowances to users depending upon how much they want to spend and what services they typically use.
These traffic rates are commonly set by an ISP and the switches within the network have access to these traffic rates, and limit usage accordingly. This may be accomplished by dividing a second into many time intervals, converting the configured rate into credits for each interval, and decrementing the credits for each packet sent or received. However, this mechanism lacks effectiveness in the real world as often the actual rate of traffic flow for a particular user or service varies from the configured limit due to a number of factors. A credit cannot be partially consumed, thus the amount of bandwidth used in a given cycle may be artificially less than or greater than the configured limit. While this may not present a major problem in any particular cycle, over time this variation can become much more pronounced. Additionally, traffic does not always arrive on a consistent basis. A large amount of traffic may arrive in one cycle, only to have none arrive in the next cycle. In this case, the traffic arriving in the first cycle may be subject to the rate limit and packets may be dropped. This leads to an overall rate over the two cycles being perhaps significantly less that the desired rate limit. Furthermore, the application sending the packets, such as a Transmission Control Protocol (TCP) application, may automatically slow down its rate of sending packets when packets get dropped by the switch. These factors result in actual traffic rates varying significantly from configured rates.
Thus, what is needed is a solution which does not suffer from the drawbacks of prior solutions.
Dynamic rate limiting adjustment may be provided by sampling actual output rates from a rate limited device and utilizing this information to modify configured traffic limits. This allows the device to achieve actual output rates much closer to the desired rate limits for users and services.
The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more embodiments of the present invention and, together with the detailed description, serve to explain the principles and implementations of the invention.
In the drawings:
Embodiments of the present invention are described herein in the context of a system of computers, servers, and software. Those of ordinary skill in the art will realize that the following detailed description of the present invention is illustrative only and is not intended to be in any way limiting. Other embodiments of the present invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. Reference will now be made in detail to implementations of the present invention as illustrated in the accompanying drawings. The same reference indicators will be used throughout the drawings and the following detailed description to refer to the same or like parts.
In the interest of clarity, not all of the routine features of the implementations described herein are shown and described. It will, of course, be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, such as compliance with application- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure.
In accordance with the present invention, the components, process steps, and/or data structures may be implemented using various types of operating systems, computing platforms, computer programs, and/or general purpose machines. In addition, those of ordinary skill in the art will recognize that devices of a less general purpose nature, such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed herein.
Dynamic rate limiting adjustment may be provided by sampling actual output rates from a rate limited device and utilizing this information to modify configured traffic limits. This allows the device to achieve actual output rates much closer to the desired rate limits for users and services.
In a specific embodiment of the present invention, the overall rate limiting system may comprise two components: a hardware component and a software component. However, one of ordinary skill in the art will recognize that either component may be implemented in hardware or software. Additionally, the present invention may be viewed as an add-on component to a preexisting hardware rate limiting device.
In a specific embodiment of the present invention, the hardware component is a credit based system which allows up to 128 different traffic classes to be defined in each chip 104. A credit is a hardware token, which is worth a fixed number of bytes. The traffic rate for a defined class is set by software. A time interval I and a credit value Cs can be set for each chip. The software component 102 may then assign a number of credits C for each traffic class using an initial credit calculator 106 and forward it to the hardware component 100. A traffic class may be associated with a physical port, an outgoing queue for a physical port, or a particular flow pattern defined by an access control list (ACL) group. At the end of each interval time, the hardware may scan all applicable traffic classes and either add or store C into a counter K for each class. The decision to add or store C depends in which mode the chip is designed to run: accumulated mode or fixed mode. In accumulated mode, any unused credits at the end of an interval time are carried over to the next interval, whereas in fixed mode, any unused credits at the end of an interval time are lost. For example, assume five credits should be given at the beginning of each interval based on the rate configured and only three credits are actually used by the end of the interval. In accumulated mode, five more credits will be added to the remaining two credits for a total of seven credits available for the next interval. Whereas in fixed mode, the remaining two credits will not be available again and the counter is reset to five by the beginning of the next interval.
As packets arrive for a given class, the hardware component 100 may examine the packet size and divide it by Cs to determine how many credits the packet is worth. It then may read the current value of the total counter K for that class. If the counter is larger than or equal to the number of credits the packets is worth, the packet is forwarded, otherwise the packet is dropped.
In a specific embodiment of the present invention, the software pre-selects the number of time intervals per second and the credit values for each traffic class. For a configured rate Rc, the number of credits C to be issued for each time interval is calculated and sent to the hardware. A dynamic rate adjustor 108 is designed to dynamically adjust the actual output rate by changing the number of credits issued per interval at runtime. The actual average output rate Rs over time period T is sampled every Δt seconds and compared with the Rc. An increment of credit number Δc, may then be computed by the software based on the rate difference Δr=Rc−Rs. If the actual rate is less than the configured rate, Δc is positive. Otherwise, it is negative. The sum of C and Δc may then be sent to the hardware as the new credit allotment. This sampling and adjusting may continue until the actual output rate converges to the rate configured.
An example is provided herein to illustrate the functioning of the provided solution in accordance with a specific embodiment of the present invention. One of ordinary skill in the art will recognize that this is merely an example and the present invention should not be limited by it.
That hardware system may be designed such that the smallest available time interval is 0.0000192 sec. Thus, all configured intervals must be a multiple of that. Suppose pre-selected parameters as follows:
Credit Size Cs=64 bytes/sec=256 bits/sec
Time Interval I=32*0.0000192 sec=0.000614 sec
Number of time intervals Ni=1/0.0006144=1627 intervals/sec
If an output rate limiting policy of Rc=30,000,000 bits/sec is set, the number of credits C that should be issued for each time interval may be calculated as follows:
C=Rc/(Ni*Cs*8)=30000000/(1627*64*8)=36=0x24
Further assume there are four queues for each outgoing port. The mapping between each port and the traffic class for the port based rate limiting may be defined as:
Traffic Class=(port−1)*4+1.
For port and priority based rate limiting, the mapping may be:
Traffic Class=(port−1)*4+q q={1,2,3,4},
where q is the number of the priority queue.
Each rate limiting hardware component, such as a chip, may manage four ports. An output rate limiting policy configured on port 3 in module 1 (port 1/3) may be managed by the first chip in a module. The 9th traffic class in this chip may then be associated with the rate limiting policy.
The default values for all registers may be 0x00000FFF, which is the maximum number of credits that can be issued per time interval. Before any packet is transmitted from port 1/3, the chip may examine credit register 0x1280020, which has a value of 0x24. If the packet size is less than C*Cs=36*64, it may be forwarded, otherwise it may be dropped.
Assume the actual output rate Rs is 20,000,000 bits/sec. The difference of rate Δr and Δc may be calculated as:
Δr=Rc−Rs=30,000,000−20,000,000=10,000,000 bits/sec.
Δc=Δr(Ni*Cs*8)=10000000/(1627*64*8)=12=0xC.
A new credit number of C+Δc=36+12=48 (0x30) may then be set to the credit register at 0x1280020 200. The process may then repeat, while hopefully Δc will reach zero.
At 302, the rate limit may be implemented for incoming traffic of the traffic type. This may comprise sending the rate limit to a rate limiting component at 304. For each time interval, 306-314 may be executed. At 306, a counter may be set equal to the number of credits per time interval. For each packet received in the incoming traffic of the traffic type, 308-314 may be executed. At 308, the size of the packet may be divided by the credit value to determine how many credits the packet is worth. At 310, the number of credits the packet is worth may be subtracted from the counter. At 312, the packet may be dropped if the counter is less than zero. Then the packet may be forwarded if the counter is greater than or equal to zero at 314.
At 316, the outgoing traffic of the traffic type may be sampled to arrive at an outgoing traffic rate. Sampling may comprise measuring the number of bits of the traffic type output each time interval. Then, the implementing 302 and sampling 316 may be repeated with a different rate limit, the different rate limit chosen to reduce a difference between the rate limit for the traffic type and said outgoing traffic rate for the traffic type. The different rate limit may be determined by subtracting the sampled number of bits output each time interval divided by the number of bits per credit from the rate limit and adding the difference to the rate limit.
At 402, the rate limit may be implemented for incoming traffic of the traffic type. This may comprise sending the rate limit to a rate limiting component at 404. This may comprise resetting a counter at 406. Then, for each time interval, 408-416 are executed. At 408, the number of credits per time interval may be added to the counter. For each packet received in the incoming traffic of the traffic type, 410-416 may be executed. At 410, the size of the packet may be divided by the credit value to determine how many credits the packet is worth. At 412, the number of credits the packet is worth may be subtracted from the counter. At 414, the packet may be dropped if the counter is less than zero. Then the packet may be forwarded if the counter is greater than or equal to zero at 416.
At 418, the outgoing traffic of the traffic type may be sampled to arrive at an outgoing traffic rate. Sampling may comprise measuring the number of bits of the traffic type output each time interval. The implementing 402 and sampling 418 may be repeated with a different rate limit, the different rate limit chosen to reduce a difference between the rate limit for the traffic type and said outgoing traffic rate for the traffic type. The different rate limit may be determined by subtracting the sampled number of bits output each time interval divided by the number of bits per credit from the rate limit and adding the difference to the rate limit.
At 514, the outgoing traffic of the traffic type may be sampled to arrive at an outgoing traffic rate Rs in bits per time period, the time period comprising Ni time intervals. At 516, C may then be recomputed to account for Rs by determining C=C+(Rc−Rs)/(Ni*Cs). Then the setting 504, dividing 506, subtracting 508, dropping 510, forwarding 512, sampling 514, and recomputing 516 are all repeated with the recomputed credit number C.
At 616, the outgoing traffic of the traffic type may be sampled to arrive at an outgoing traffic rate Rs in bits per time period, the time period comprising Ni time intervals. At 618, C may then be recomputed to account for Rs by determining C=C+(Rc−Rs)/(Ni*Cs). Then the resetting 604, adding 606, dividing 608, subtracting 610, dropping 612, forwarding 614, sampling 616, and recomputing 618 are all repeated with the recomputed credit number C.
An incoming traffic rate limit implementer 702 coupled to the traffic type rate limit receiver 700 may implement the rate limit for incoming traffic of the traffic type. This may comprise sending the rate limit to a rate limiting component using a rate sender 704. For each time interval, the following may be executed. A counter setter 706 may set a counter equal to the number of credits per time interval. For each packet received in the incoming traffic of the traffic type, the following may also be executed. A packet size by credit value divider 708 coupled to the counter setter 706 may divide the size of the packet by the credit value to determine how many credits the packet is worth. A packet credit value from counter subtractor 710 coupled to the packet size by credit value divider 708 may subtract the number of credits the packet is worth from the counter. A packet dropper 712 coupled to the packet credit value from counter subtractor 710 may drop the packet if the counter is less than zero. A packet forwarder 714 coupled to the packet credit value from counter subtractor 710 may forward the packet if the counter is greater than or equal to zero.
An outgoing traffic sampler 716 coupled to the incoming traffic rate limit implementer may sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate. Sampling may comprise measuring the number of bits of the traffic type output each time interval using a traffic type number of bits per time interval output measurer 718. Then, the implementing and sampling may be repeated with a different rate limit computed using a different rate limit determiner 720 coupled to the traffic type number of bits per time interval output measurer 718 and to the incoming traffic rate limit implementer 702, the different rate limit chosen to reduce a difference between the rate limit for the traffic type and said outgoing traffic rate for the traffic type. The different rate limit may be determined by subtracting the sampled number of bits output each time interval divided by the number of bits per credit from the rate limit and adding the difference to the rate limit.
An incoming traffic rate limit implementer 802 coupled to the traffic type rate limit receiver 800 may implement the rate limit for incoming traffic of the traffic type. This may comprise sending the rate limit to a rate limiting component using a rate limit sender 804. This may also comprise resetting a counter using a counter resetter 806. Then, for each time interval, the following may be executed. A credit number-to-counter adder 808 coupled to the counter resetter 806 may add the number of credits per time interval to the counter. For each packet received in the incoming traffic of the traffic type, the following may also be executed. A packet size by credit value divider 810 coupled to the credit number-to-counter adder 808 may divide the size of the packet by the credit value to determine how many credits the packet is worth. A packet credit value from counter subtractor 812 coupled to the packet size by credit value divider 810 may subtract the number of credits the packet is worth from the counter. A packet dropper 814 coupled to the packet credit value from counter subtractor 812 may drop the packet if the counter is less than zero. A packet forwarder 816 coupled to the packet credit value from counter subtractor 812 may forward the packet if the counter is greater than or equal to zero.
An outgoing traffic sampler 818 coupled to the incoming traffic rate limit implementer 802 may sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate. Sampling may comprise measuring the number of bits of the traffic type output each time interval using a traffic type number of bits per time interval output measurer 820. The implementing and sampling may be repeated with a different rate limit determined using a different rate limit determiner 822 coupled to the traffic type number of bits per time interval output measurer 820 and to the incoming traffic rate limit implementer 802, the different rate limit chosen to reduce a difference between the rate limit for the traffic type and said outgoing traffic rate for the traffic type. The different rate limit may be determined by subtracting the sampled number of bits output each time interval divided by the number of bits per credit from the rate limit and adding the difference to the rate limit.
An outgoing traffic sampler 914 may sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate Rs in bits per time period, the time period comprising Ni time intervals. A credit number recomputer 916 coupled to the outgoing traffic sampler 914 and to the counter setter 904 may recompute C to account for Rs by determining C=C+(Rc−Rs)/(Ni*Cs). Then the setting, dividing, subtracting, dropping, forwarding, sampling, and recomputing may all be repeated with the recomputed credit number C.
An outgoing traffic sampler 1016 may sample the outgoing traffic of the traffic type to arrive at an outgoing traffic rate Rs in bits per time period, the time period comprising Ni time intervals. A credit number recomputer 1018 coupled to the outgoing traffic sampler 1016 and to the counter setter 1004 may recompute C to account for Rs by determining C=C+(Rc−Rs)/(Ni*Cs). Then the resetting, adding, dividing, subtracting, dropping, forwarding, sampling, and recomputing are all repeated with the recomputed credit number C.
While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclosure that many more modifications than mentioned above are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the appended claims.
| Patent | Priority | Assignee | Title |
| 8635381, | Aug 26 2010 | International Business Machines Corporation | System, method and computer program product for monitoring memory access |
| 8930589, | Aug 26 2010 | International Business Machines Corporation | System, method and computer program product for monitoring memory access |
| Patent | Priority | Assignee | Title |
| 6046979, | May 04 1998 | Alcatel-Lucent USA Inc | Method and apparatus for controlling the flow of variable-length packets through a multiport switch |
| 7068602, | Jan 31 2001 | MICROSEMI STORAGE SOLUTIONS LTD | Feedback priority modulation rate controller |
| 7310309, | Jul 17 2002 | AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE LIMITED | Dynamic rate limiting adjustment |
| 20030035374, | |||
| 20030107988, | |||
| 20030223369, | |||
| 20030223370, | |||
| 20030227872, | |||
| 20060209693, |
| Date | Maintenance Fee Events |
| Oct 11 2013 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Feb 10 2014 | ASPN: Payor Number Assigned. |
| Feb 10 2014 | RMPN: Payer Number De-assigned. |
| Oct 16 2017 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Jan 10 2022 | REM: Maintenance Fee Reminder Mailed. |
| Jun 27 2022 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| May 25 2013 | 4 years fee payment window open |
| Nov 25 2013 | 6 months grace period start (w surcharge) |
| May 25 2014 | patent expiry (for year 4) |
| May 25 2016 | 2 years to revive unintentionally abandoned end. (for year 4) |
| May 25 2017 | 8 years fee payment window open |
| Nov 25 2017 | 6 months grace period start (w surcharge) |
| May 25 2018 | patent expiry (for year 8) |
| May 25 2020 | 2 years to revive unintentionally abandoned end. (for year 8) |
| May 25 2021 | 12 years fee payment window open |
| Nov 25 2021 | 6 months grace period start (w surcharge) |
| May 25 2022 | patent expiry (for year 12) |
| May 25 2024 | 2 years to revive unintentionally abandoned end. (for year 12) |