Abstract:
A network controls congestion by monitoring how well packets are actually being received at their respective dataflow destinations. The destination nodes are outfitted with a monitor that returns an acknowledgement (ACK) datapacket to the source node for each reception. The return ACK datapackets are marked according to whether congestion was encountered in the delivery to the destination. If so, a rate limiter at the source node is signaled to slow down the data injection rate. If not, the rate limiter is signaled to dial up the injection rate. Several dataflows can be independently and simultaneously controlled this way.

Description:
FIELD OF THE PRESENT INVENTION  
       [0001]     The present invention relates generally to communication networks, and in particular to exploiting asynchronous network feedback for source responses executed in a source node of a network to control congestion in the network.  
       BACKGROUND OF THE PRESENT INVENTION  
       [0002]     Network congestion develops when the datapacket traffic being sent or injected exceeds the capacity of the network. Congestion causes the throughput of useful traffic to be reduced because each datapacket holds onto network resources longer, or network resources are wasted by handling datapackets that are later discarded.  
         [0003]     A conventional approach to minimizing network congestion uses closed-loop per-flow end-to-end rate control. Congestion feedback is used for updates about network congestion to a source of a traffic flow. A Boolean signal provided to the flow source indicates whether a set of datapackets injected for the flow experienced any network congestion. The source response mechanism adjusts a limit on the rate at which future datapackets of the flow can be injected into the network in response to each congestion feedback signal received for a flow at its source.  
         [0004]     The congestion feedback signal may be implicit or explicit. An implicit signal is one detected at the source without support from the network switches. For example, in transport control protocol (TCP), an acknowledgment time-out at the source is used to detect datapacket losses. Such is interpreted as a signal of network congestion, and the reception of an acknowledgment (ACK) datapacket with an appropriate sequence number is interpreted as a signal indicating no congestion. In contrast, an explicit signal is generated by the switches in the network, for example by sending Explicit Congestion Notification (ECN) datapackets to flow end-devices.  
         [0005]     Some congestion feedback mechanisms favor signaling only the high flow rate sources. For example, some mechanisms send congestion flags only when a switch datapacket buffer exceeds a certain level of occupancy, and the flows that receive the signals are those corresponding to datapackets present in a high occupancy buffer. If the number of datapackets that a buffer can store is less than the number of flows that use the corresponding link, then only some of the flows sharing the link will have datapackets in the buffer when it reaches the threshold occupancy.  
         [0006]     A high rate flow is more likely to have a datapacket in the high occupancy buffer than a lower rate flow, because datapackets of the higher rate flow use the buffer more frequently than those of a lower rate flow. Therefore, when a switch buffer fills, among all the flows sharing the corresponding link, higher rates flow are more likely to receive a congestion flag than lower rate flows. Such bias in congestion signaling is strongest in network with small buffers that can store only a few datapackets, because then, when a buffer becomes highly occupied, the subset of flows represented in the buffer is likely only a small fraction of all the flows that share the corresponding network communication link.  
         [0007]     The source response component of congestion control acts at the flow source end-device to control the flow&#39;s rate limit in response to signals provided by the congestion feedback mechanism. When a received feedback signal indicates no congestion, the source increases the flow&#39;s rate limit. The source receives an ACK datapacket that corresponds to one or more of its prior injected datapackets that experienced no congestion in the network. The increase is based on an increase function, r new =f inc (r), where “r” is the current rate limit, and r new  is the next rate limit setting for the flow. Similarly, on receipt of a congestion flag the source reduces the rate limit based on a decrease function, r new =f dec (r).  
         [0008]     The rate increase and decrease functions should be designed to operate together to enable flows to converge to an operating point that is efficient with high bandwidth utilization, and fair, e.g., approximately equal rates to each flow sharing the same bottleneck link.  
         [0009]     In networks that use biased congestion feedback mechanisms, a high rate flow is more likely than any contending lower rate flow to receive a congestion flag each time a buffer becomes highly occupied. In such networks, if an update occurs for each congestion feedback signal, then higher rate flows perform more frequent rate decrease steps than lower rate flows.  
         [0010]     It is an object of the present invention to enable the use of source responses that use faster increase responses in asynchronous network environments, leading to increased network utilization while still achieving convergence to efficient and fair operating points.  
       SUMMARY OF THE PRESENT INVENTION  
       [0011]     Briefly, a network embodiment of the present invention controls congestion by monitoring how well packets are actually being received at their respective dataflow destinations. The destination nodes are outfitted with a monitor that returns an acknowledgement (ACK) datapacket to the source node for each reception. The return ACK datapackets are marked according to whether congestion was encountered in the delivery to the destination. If so, a rate limiter at the source node is signaled to slow down the data injection rate. If not, the rate limiter is signaled to dial up the injection rate. Several dataflows can be independently and simultaneously controlled this way. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0012]      FIG. 1  is a block diagram of a network embodiment of the present invention;  
         [0013]      FIG. 2  is a flowchart diagram of a rate increase determination process embodiment of the present invention;  
         [0014]      FIG. 3  is a flowchart diagram of a congestion flow rate increase/decrease method embodiment of the present invention;  
         [0015]      FIG. 4  is a flowchart diagram of a rate update method embodiment of the present invention; and  
         [0016]      FIG. 5  is a flowchart diagram of a rate update method embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS  
       [0017]      FIG. 1  represents a network environment  100  in which a source server  102  communicates with a destination client  104  via a network  106 . For example, the network may include the Internet. Embodiments of the present invention operate in such network environments  100 . A computer software application  108  running on source server  102  injects or flows datapackets through a transport layer  110  across the network  106  to a corresponding transport layer  112  on the receiver side. Such traffic ultimately flows to a receiving computer software application  114 . Each source server  102  and destination client  104  can simultaneously support multiple such flows.  
         [0018]     Datapackets from the application  108  are passed down through the transport layer  110  of the sender&#39;s communication protocol stack. The incoming datapacket is passed along to receiving application  114  for processing. The rate of datapacket injection into the network is controlled by a rate limiter  116 . An appropriate rate limit is determined and enforced for each flow. A datapacket receiver network interface  122  generates an acknowledgment (ACK) datapacket automatically each time it receives an incoming datapacket. The ACK is returned to source server  102 .  
         [0019]     A rate limit for each flow is represented at source server  102  by a state variable “crt”. A separate “crt” state variable is updated for each flow. Each ACK datapacket received on path  126  over network  106  is passed to an acknowledgement monitor  128 . The value of a “crt” state variable  130  is updated and maintained for each corresponding flow. The acknowledgement monitor  128  determines whether the relevant flow to which the ACK datapacket relates is contributing to any congestion in the network  106 .  
         [0020]     Such determination can be based on when the ACK datapacket is actually received, or based on information coded within it. The acknowledgement monitor  128  may rely on explicit congestion notification (ECN) techniques. If congestion is detected, the acknowledgement monitor  128  decreases the value of the corresponding flow&#39;s rate limit “crt”. Otherwise, the acknowledgement monitor  128  infers from an apparent lack of congestion that there is available capacity within the network. It increases the rate limit “crt” to allow the rate limiter  116  to set a higher rate of injection into the network for the relevant flow.  
         [0021]     The operation of the acknowledgement monitor  128  is particularly suited to application to the INFINIBAND standard. The INFINIBAND Architecture is an industry standard, channel-based, switched fabric, interconnect architecture for servers. INFINIBAND architecture dictates a new way servers are to be built, deployed, and managed.  
         [0022]     In any network environment, a primary goal is to minimize or avoid network congestion and achieve fairness for contending flows. Such results in higher network utilization than was previous possible.  
         [0023]     Embodiments of the present invention allow source responses in a network source node, e.g., source server  102 , to increase and decrease flow rate (f inc (r) and f dec (r)), to exploit congestion signaling bias in order to improve performance.  
         [0024]     A method embodiment of the present invention provides for controlling a plurality of datapacket flows into a network. Such is based on an asynchronous rate control procedure, receiving network congestion feedback, and adjusting a datapacket injection rate of each of the datapacket flows based on the congestion feedback. The datapacket injection rates are adjusted according to a rate increase function when the congestion feedback indicates no congestion. Following any decrease in the datapacket injection rate, the datapacket injection rate is incremented. The period set for such increases is at least the inverse of the minimum injection rate.  
         [0025]     Method embodiments of the present invention provide network source node responses which converge to fair and efficient networks operating points. Source responses include fast increase multiplicative decrease (FIMD), and linear inter-datapacket delay (LIPD).  
         [0026]     Conventional designs provide convergence under the synchronous update assumption by using conservative responses to congestion feedback signals. Embodiments of the present invention exploit the datapacket marking bias of asynchronous updates to weaken the conditions for fairness convergence. The weakened conditions enable the use of responses that do not improve fairness in a synchronous scenario. The FIMD and LIPD source responses reclaim bandwidth more rapidly than responses that have the same decrease behavior but satisfy the stronger conditions for rate increase. Quicker reclamation of bandwidth using the new functions yields higher network bandwidth and throughput, especially in dynamic environments in which flows come and go.  
         [0027]     In the example congestion feedback mechanism, the network uses datapacket marking to provide a congestion flag. Such is a form of forward explicit congestion notification (FECN). Whenever a switch buffer reaches a state of high occupancy, all the datapackets within the buffer are marked. The datapacket marks are returned by a flow&#39;s destination node to the flow&#39;s source node by marked ACK datapackets. A signal indicating no congestion is communicated to the flow&#39;s source node by unmarked ACK datapackets.  
         [0028]     The source response mechanism controls the injection of datapackets into the network based on the information provided by the congestion feedback mechanism. On receipt of a congestion feedback signal indicating no congestion, the source increases the flow&#39;s rate limit based on an increase function, r new =f inc (r), where “r” is the current rate limit, and r new  is the next rate limit setting for the flow. The source reduces the rate limit based on a decrease function, r new =f dec (r) on receipt of a feedback congestion flag,.  
         [0029]     In the absence of marks, it is desirable for the rate to gradually increase over time. Let F r   inc (t), for t≧0, be a family of continuous monotonic increasing functions, each of which describes the desired flow rate increase behavior as a function of time since the last rate decrease to an arbitrary rate F r   inc (0)=r (R min ≧“r”≧R max , where R min  and R max , are the minimum and maximum values for a flow rate in datapackets/sec, respectively. R min  and R max  are constants for a particular network and implementation. The value of R max  will typically equal the full bandwidth of the network link (e.g., if the link is ten gigabits per second, R max  will also be ten gigabits per seconds). R min  can be any value that is less than R max  and greater than zero and it refers to the lowest rate limit that the implementation of the sending node can support. Determination of R min  and R max  is based on the notion that the rate control implementation can support only a finite set of rates, for example because the rate is represented digitally using a finite-width register. R min  is the smallest value in the finite set of supported rates. The particular values of R max  and R min  for a network rate control implementation will be known or readily determined by the network designer and can be factored into the design of the source responses. Since the increase function f inc (r) is defined as a function of the current rate, the time behavior of the rate increase should be independent of the past history of the flow rate, e.g., it should be independent of the elapsed time since the last decrease. Therefore, the time behavior of the rate for two arbitrary initial rates r 1  and r 2 , (R min ≦r 1 ≦r 2 ≦R max ), should be identical for rates “r”&gt;r 2 , i.e.: 
 
 F   r2   inc ( t )= F   r1   inc ( t+t ′) 
        for t≧0, and t′ such that [1]    F r1   inc (t′)=r 2 .        
 
         [0032]     It follows that the rate increase behavior can be represented by just one member of the family of functions: F inc (t)=F Rmin   inc (t). All other functions F r   inc (t), for R min ≦“r”≦R max , can be obtained by shifting the time origin of F inc (t), as described in Equation [1].  
         [0033]     A recovery time/time duration T rec (r) is defined for a flow at rate “r” as the time elapsed from the time the flow rate is decreased from rate “r”, due to a marked ACK, until the time the flow rate recovers to its original rate “r”, assuming no other marked ACK is received until rate “r” is achieved.  
         [0034]     If the recovery time or time duration of a lower rate flow is longer than that of a higher rate flow, flow rates may diverge and the higher rate flow may take over the entire bottleneck bandwidth, creating an unfair operating point. To avoid this situation and promote fair allocation of bandwidth, source responses must satisfy the relaxed convergence requirement, 
 
 T   rec ( r   1 )= T   rec ( r   2 )= T   rec =1 /R   min ( R′   min   &lt;r   1   &lt;R   max   , R′   min&lt;r   2   &lt;R   max ),   [2]
 
 where f dec (R′ min )=R min . 
 
         [0036]     The recovery time is a constant 1/R min  for all rates higher than R′ min . Such is the highest rate from which a single decrease step assigns to a flow the minimum rate R min . In the case of a synchronous network feedback for rate decrease, the result of satisfying the property in [2] is that any two flows, with rates r 1  and r 2  before the rate decrease, will recover to their original rates r 1  and r 2  at the same time. Therefore, after the recovery, fairness is not decreased but only maintained. While the Chiu and Jain, and the Bansal and Balakrishnan conditions require that fairness be strictly improved in a sequence of decrease/increase phases assuming a synchronous feedback scenario, the presently formulated condition requires only that fairness be maintained in the same scenario.  
         [0037]     The choice of 1/R min  for T rec  follows from the following argument. At the minimum rate R min , the interval of time between two consecutively transmitted datapackets is 1/R min . Thus the expected time interval between the reception of two consecutive ACK&#39;s is also 1/R min . Therefore, assuming a marked ACK causes the rate to be decreased from rate R′ min  to the minimum rate R min , the next rate change can only occur when the next ACK is received, i.e. after an expected time 1/R min . Therefore the minimum possible recovery time for rate R′ min  is 1/R min  (assuming the magnitude of an increase step cannot exceed the magnitude of a decrease step). Since the same recovery time is desired for any rate “r”, 1/R min  is the minimum possible recovery time for any rate “r”, R′ min ≦“r”≦R max . In order to reclaim unused bandwidth as fast as possible, 1/R min  is chosen as this minimum value for the recovery time T rec  (r) for any rate “r”, R′ min &lt;“r”&lt;R max .  
         [0038]     In order to achieve relaxed convergence requirement, the time behavior of a flow rate F inc (t) should satisfy the following condition (difference equation): 
 
 F   inc ( t )= f   dec ( F   inc ( t+T   rec )), or   [3]
 
 F   inc ( t )= f   dec ( F   inc ( t+ 1 /R   min )) 
 
         [0039]     This condition requires that after a decrease event, the increase function recovers the rate limit back to the particular rate prevalent prior to the decrease event in time 1/R min . Such is the constant recovery time T rec  from relaxed convergence requirement, Equation [2].  
         [0040]      FIG. 2  represents a rate increase determination process embodiment of the present invention, and is referred to herein by the general reference numeral  200 . Given an arbitrary decrease function f dec (r), process  200  determines f inc (r) such that relaxed convergence requirement is satisfied. In a step  202 , a continuous monotonically increasing function F inc (t) is found that is a solution for the difference equation described in [3]. Such can be done using conventional techniques for solving difference-differential equations. Then all other functions F r   inc (t) are obtained, for an arbitrary rate “r”, shifting the time origin of F inc (t), according to Equation [1]. At step  204 , these functions are used to generate a look-up table for all possible settings of “crt”. Given F r   inc (t), the increase function f inc (r) is obtained at step  206 . At a given rate “r”, the expected interval between consecutive datapackets, and thus between consecutive ACK datapackets is 1/r. Assuming that at the previous adjustment the flow rate is set to “r”, the next rate adjustment will occur at the reception of the next ACK, e.g., after an expected time 1/r. Thus, f inc (r)=F r   inc (1/r), with a ceiling of R max , 
   f   inc ( r )=min ( F   r   inc (1 /r ),  R   max )   [4] 
         [0041]     In order that the increase function does not cause the injection rate to exceed the maximum injection rate R max , the lesser of the newly calculated increased rate and R max  is chosen as the new rate.  
         [0042]     At source server  102 , the acknowledgement monitor  128  implements the rate increase and decrease functions. To ensure rapid response to changes in network conditions, it is important that the implementation of this logic module be fast enough to adjust the value of the rate limit “crt” each time an ACK datapacket arrives from the network  106 . In a high speed network, the time between consecutive ACK datapacket arrivals at a source node may be very short, for example in the order of a few tens or hundreds of nanoseconds. Since the decrease and increase functions may be complex mathematical expressions involving time-consuming computational operations such as floating point division or exponentiation, there may not be sufficient time to calculate the function outputs unless specialized and expensive hardware is provided. As a less costly alternative, the output of each function can be pre-computed for all possible settings of “crt” and these outputs can be stored in a memory look-up table indexed according to “crt” value.  
         [0043]     During operation, the acknowledgement monitor  128  can then determine the correct rate adjustment and corresponding new “crt” value by performing a fast access to the appropriate look-up table in memory. Such look-up table is effectively part of the functional block of the acknowledgement monitor  128 , although it may not have exactly the same location in hardware.  
         [0044]     The fast increase multiplicative decrease (FIMD) source response function a multiplicative rate decrease function is adopted. Such is the same decrease function used by the traditional additive increase multiplicative decrease (AIMD) function, f dec (r)=Max (r/m, R min ), where m&gt;1 is constant  
         [0045]     From Equation [3], F inc (t) must satisfy, F inc (t+T rec )=m*F inc (t).  
         [0046]     A continuous monotonically increasing function that satisfies this condition with, F inc (0)=R min , is F inc (t)=R min * m t t/Trec . For any rate “r”, R min ≦r≦R max , there exists a t′ for which “r”=F inc (t′)=R min * m t′/Trec . Therefore, 
 
 F   r   inc ( t )= F   inc ( t+t ′)= R   min   *m   t′/Trec   *m   t/Trec   =“r”*m   t/Trec  
 
and 
 
 f   inc ( r )=Min( F   r   inc (1 /r ),  R   max )=Min( r*m    1/(r*Trec)   , R   max )=Min( r*m   R     min     /r   , R   max ). 
 
         [0047]      FIG. 3  represents a procedure  300  used by an FIMD source response mechanism. A flow source end-device or node increases and decreases a flow&#39;s rate limit in response to congestion feedback. Procedure  300  reads and writes the value of a state variable “crt”. Such records the current rate limit setting for a flow. In a hardware implementation of the source response mechanism, the “crt” variable may be implemented as a hardware register. Another procedure at the source end-device reads the value of “crt” and prevents datapackets for the flow from being injected into the network at a higher rate than the value of crt specifies. In a step  304 , an ACK datapacket just received is checked to see marked.  
         [0048]     A marked ACK datapacket indicates congestion, so the source reduces the rate limit “crt” by a constant, m&gt;1 at step  306 . In a step  308 , an updated rate “r” is then checked against the minimum injection rate R min . If the new rate is less than R min , “crt” is assigned the value of R min  at step  310 . If the new rate is not less than R min , “crt” assigned the value of the new rate at step  312 .  
         [0049]     If an unmarked ACK is received, the source increases the rate limit “crt” by a constant, m R     min     /crt , at step  314 . The increased rate is then compared against the maximum injection rate, R max , at step  316 . If the new rate is greater than R max , “crt” is assigned the value of R max  at step  318 . If the new rate is not greater than R max , “crt” is assigned the value of the new rate at step  320 .  
         [0050]     Once the state variable “crt” is assigned the appropriate new rate according to the above steps, the update procedure is ended at step  322  and awaits receipt of a new ACK datapacket at  302  to repeat the update procedure  300 .  
         [0051]     The LIPD response function is based on a decrease function that increases inter-datapacket delay (IPD) linearly. IPD is the idle period length that is inserted between the injections of consecutive datapackets of a flow, expressed in units of datapacket transmission time. A flow operating at an IPD of “ipd” corresponds to a flow rate of R max /(1+“ipd”). A flow&#39;s rate decrease is defined as an increment by one of the flow&#39;s IPD value (which increases the inter-datapacket delay by one datapacket transmission time). Such rate decrease function is intuitively attractive for the following reason. If “n” identical flows share a bottleneck link, the optimal rate for each flow is R max /n , where the IPD is equal to n−1.  
         [0052]     If a new flow is introduced to a link that already has “n” flows that are operating at optimal rate, than one datapacket from each of the “n” original flows receives a mark and each one has its rate limit reduced from R max /n to the new value R max /(n+1). Such becomes the new optimal rate limit for these flows. With a decrease function based on incrementing the IPD by one, when a new flow is introduced, the flow rates of the previously resident flows converge in one decrease step to the new optimal rate value. This, instead of oscillating and slowly converging to the new optimal rate value, as they would with conventional decrease functions. Also, at lower rates this function decreases the rate by smaller steps than a multiplicative decrease function, e.g., FIMD and AIMD.  
         [0053]     When several dynamic flows share a link, smaller decrease steps lower oscillation amplitude and improve overall link utilization. The rate decrease function can be derived using the inverse relationship of flow rate to the flow IPD, e.g., 
 
 f   dec ( r )=Max ( R   max /(1 +R   max   /r ),  R   min ) 
 
 From Equation [2], F inc (t) must satisfy, 
 
 F   inc ( t+T   rec )= R   max /( R   max   /F   inc ( t )−1) . 
 
         [0055]     A continuous monotonically increasing function that satisfies this condition with F inc (0)=R min , is, 
 
 F   inc ( t )= R   max /( R   max   /R   min   −t/T   rec ). 
 
         [0056]     For any rate “r”, R min ≦r≦R max , there exists a t′ for which r=F inc (t′)=R max /(R max /R min −t′/T rec ). Therefore,  
                 F   inc   r     ⁡     (   t   )       =       ⁢         F   inc     ⁡     (     t   +     t   ′       )       =       R   max     /     (         R   max     /     R   min       -       t   ′     /     T   rec       -     t   /     T   rec         )                     =       ⁢       R   max     /     (         R   max     /       F   inc     ⁡     (     t   ′     )         -     t   /     T   rec         )                   =       ⁢       R   max     /     (         R   max     /           “   r   ”         -     t   /     T   rec         )                 
       and   ,     
     ⁢               f   inc     ⁡     (   r   )       =       ⁢     Min   ⁡     (         F   inc   r     ⁡     (     1   /   r     )       ,     R   max       )                   =       ⁢     Min   ⁡     (         R   max     /     (         R   max     /     “   r   ”       -     1   /     (     r   *     T   rec       )         )       ,     R   max       )                   =       ⁢     Min   ⁡     (         R   max     /     (         R   max     /     “   r   ”       -       R   min     /   r       )       ,     R   max       )                   =       ⁢       Min   ⁡     (         “   r   ”     /     (     1   -       R   min     /     R   max         )       ,     R   max       )       .                 
 
         [0057]      FIG. 4  represents a procedure  400  used by a LIPD source response mechanism at a flow source end-device (node) to increase and decrease a flow&#39;s rate limit in response to congestion feedback. Such is similar in nature to update procedure  300  ( FIG. 3 ). Procedure  400  reads and writes the value of a state variable “crt”. Such records the current rate limit setting for the flow. Such description assumes the existence of another procedure at the source end-device that reads the value of “crt” and prevents datapackets for the flow from being injected into the network at a higher rate than the value of “crt” specifies. At step  402  an ACK datapacket is received and, at step  404 , it is checked to determine whether it is marked. If it is a marked ACK datapacket, indicating congestion, the source reduces the rate limit “crt”, at step  406 , to a value that corresponds to an increase of the inter-datapacket delay by one unit of datapacket transmission time 1/R max . The updated rate “r” is then checked against the minimum injection rate R min  at step  408 . If the new rate is less than R min , “crt” is assigned the value of R min  at step  410 . If the new rate is not less than R min , “crt” assigned the value of the new rate at step  412 .  
         [0058]     If it is an unmarked ACK datapacket, the source increases the rate limit “crt” at step  414 . The new value decreases of inter-datapacket delay by a fraction R min /“r” of one datapacket transmission time 1/R max . The increased rate is then compared against the maximum injection rate, R max , at step  416 . If the new rate is greater than R max , “crt” is assigned the value of R max  at step  418 . In a step  420 , if the new rate is not greater than R max , “crt” is assigned the value of the new rate.  
         [0059]      FIG. 5  represents how the LIPD source response mechanism could be deployed in an INFINIBAND, or other network. The network controls the rate limit for a flow by using an integer state variable “ipd”. Such specifies the number of idle datapacket transmission times to insert before transmitting each datapacket. Such description describes how to set the value of “ipd”, but it is assumed that another procedure at the source end-device  102  is operating that reads the value of “ipd” and inserts the delay that it specifies for the flow after each of the datapackets is injected into the network. The LIPD procedure applied to INFINIBAND is similar to that described in relation to  FIG. 4 , except for extra steps ( 522  to  528 ) at the end. Such set “ipd” to an integer value that yields a rate that is closest to the ideal rate limit. Such is represented by variable “crt”.  
         [0060]      FIG. 5  represents a rate update procedure  500  for the LIPD source response function implemented on a network conforming to the INFINIBAND standard. Steps  502  to  520  are similar to steps  402  to  420  ( FIG. 4 ). After a step  522 , the inter-datapacket delay, “ipd”, corresponding to rate “crt” is computed and rounded down to the closest integer value. The maximum injection rate, R max , is divided by “crt” and then subtracting one.  
         [0061]     The rate of a flow can be mathematically represented as R max /(“ipd”+1). In a step  524 , the error in the flow rate due to the rounding down of “ipd” is calculated, given by (R max /(“ipd”+1)−“crt”). Such error value from the rounding down of “ipd” is compared with the error in the rate which would occur if the “ipd” were rounded up (given by “crt”−R max /(“ipd”+2)). Thus if the error from rounding down the “ipd” is greater than that from rounding it up, the “ipd” is incremented by one at step  526 . Otherwise, the rounded down “ipd” is considered to be correct, and the update procedure  500  finishes at step  528 . Steps  522 - 528  ensure the inter-datapacket delay is an integer value.  
         [0062]     In one embodiment, the present invention provides a method for controlling a plurality of datapacket flows into a network based on asynchronous rate control procedure. The method comprises receiving network congestion feedback and adjusting a datapacket injection rate of each of the datapacket flows based on the congestion feedback. The adjusting comprises increasing the datapacket injection rate according to a rate increase function if the congestion feedback indicates no congestion. Following any decrease of the datapacket injection rate, the datapacket injection rate is increased to the particular rate in a time duration which is at least the inverse of a predetermined minimum injection rate.  
         [0063]     Although the present invention has been described in terms of the presently preferred embodiments, it is to be understood that the disclosure is not to be interpreted as limiting. Various alterations and modifications will no doubt become apparent to those skilled in the art after having read the above disclosure. Accordingly, it is intended that the appended claims be interpreted as covering all alterations and modifications as fall within the true spirit and scope of the present invention.