Abstract:
Systems for providing feedback to sending entities are provided. In some embodiments, systems for providing feedback to a sending entity that sends a request for session are provided, the systems comprising: a receiving entity that receives the request for session from the sending entity, wherein the request for session is used to establish a communication session that takes place after processing the request for session, and wherein the receiving entity comprises at least one hardware processor that: assigns a freed processing slot to the sending entity in response to determining that the request for session has been processed by the receiving entity and that a number of requests for sessions to be processed is less than a first limit.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 12/565,096, filed Sep. 23, 2009, which claims the benefit of U.S. Provisional Patent Application No. 61/099,560, filed Sep. 23, 2008, each of which is hereby incorporated by reference herein in its entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    The disclosed subject matter relates to systems for providing feedback to sending entities. 
       BACKGROUND 
       [0003]    Modern communication networks, such as computer networks, telephone networks, television networks, etc., are frequently subject to situations in which a component is overloaded and consequently unable to perform the function that component is requested to provide. For example, in networks employing the Session Initiation Protocol (SIP), such as networks providing Voice over Internet Protocol (VoIP), servers can be overloaded when used to established call sessions between user agents (such as mobile telephones) in high call-demand situations, such as during wide-spread emergencies, contests, newly on-sale situations (such as when concert tickets go on-sale), call-in television programs, etc. As a result, with increasing overload, these servers can realize a rapid decrease in their ability to establish any call sessions, not just those above an overload threshold. 
         [0004]    While attempts to address such overload situations have made, these attempts have not adequately provided a mechanism for responding to such overload situations. 
       SUMMARY 
       [0005]    Systems for providing feedback to sending entities are provided. In some embodiments, systems for providing feedback to a sending entity that sends a request for session are provided, the systems comprising: a receiving entity that receives the request for session from the sending entity, wherein the request for session is used to establish a communication session that takes place after processing the request for session, and wherein the receiving entity comprises at least one hardware processor that: assigns a freed processing slot to the sending entity in response to determining that the request for session has been processed by the receiving entity and that a number of requests for sessions to be processed is less than a first limit. 
         [0006]    In some embodiments, systems for providing feedback to a sending entity that sends a request for session are provided, the systems comprising: a receiving entity that receives the request for session from the sending entity, wherein the receiving entity comprises at least one hardware processor that: determines a session service rate for the receiving entity; determines a number of sessions to be serviced by the receiving entity; determines a target rate limit for each of the sending entity based on the session service rate and the number of sessions to be serviced; and provides an indication of the target rate limit to the sending entity. 
         [0007]    In some embodiments, methods for providing feedback to a sending entity that sends a request for session are provided, the methods comprising: receiving, using a hardware processor, the request for session from the sending entity, wherein the request for session is used to establish a communication session that takes place after processing the request for session; determining whether the request for sessions has been processed using the hardware processor; and assigning, using the hardware processor, a freed processing slot to the sending entity in response to determining that the request for session has been processed and that a number of requests for sessions to be processed is less than a first limit. 
         [0008]    In some embodiments, methods for providing feedback to a sending entity that sends a request for session are provided, the methods comprising: receiving the request for session from the sending entity using a hardware processor; determining a session service rate for the receiving entity using the hardware processor; determining a number of sessions to be serviced by the receiving entity using the hardware processor; determining a target rate limit for each of the sending entity based on the session service rate and the number of sessions to be serviced using the hardware processor; and providing an indication of the target rate limit to the sending entity using the hardware processor. 
         [0009]    In some embodiments, non-transitory computer readable media containing computer-executable instructions that, when executed by a hardware processor, cause the processor to perform a method for providing feedback to a sending entity that sends a request for session are provided, the method comprising: receiving the request for session from the sending entity, wherein the request for session is used to establish a communication session that takes place after processing the request for session; determining whether the request for sessions has been processed; and assigning a freed processing slot to the sending entity in response to determining that the request for session has been processed and that a number of requests for sessions to be processed is less than a first limit. 
         [0010]    In some embodiments, non-transitory computer readable media containing computer-executable instructions that, when executed by a hardware processor, cause the processor to perform a method for providing feedback to a sending entity that sends a request for session are provided, the method comprising: receiving the request for session from the sending entity; determining a session service rate for the receiving entity; determining a number of sessions to be serviced by the receiving entity; determining a target rate limit for each of the sending entity based on the session service rate and the number of sessions to be serviced; and providing an indication of the target rate limit to the sending entity. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]      FIG. 1  is a diagram of a Session Initiation Protocol network connecting user agents, sending entity servers, and receiving entity servers in accordance with some embodiments. 
           [0012]      FIG. 2  is a diagram of a Session Initiation Protocol call set-up in accordance with some embodiments. 
           [0013]      FIG. 3  is a diagram of a connection between a sending entity server and a receiving entity server incorporating feedback in accordance with some embodiments. 
           [0014]      FIG. 4  is a diagram of a first process for generating feedback in accordance with some embodiments. 
           [0015]      FIG. 5A  is a diagram of a second process for generating feedback in accordance with some embodiments. 
           [0016]      FIG. 5B  is a diagram of a third process for generating feedback in accordance with some embodiments. 
           [0017]      FIG. 6A  is a diagram of a fourth process for generating feedback in accordance with some embodiments. 
           [0018]      FIG. 6B  is a diagram of a fifth process for generating feedback in accordance with some embodiments. 
           [0019]      FIG. 7  is a diagram of a sixth process for generating feedback in accordance with some embodiments. 
           [0020]      FIG. 8  is a diagram of a process for enforcing feedback in accordance with some embodiments. 
           [0021]      FIG. 9  is a diagram of a connection between a sending entity server and a receiving entity server incorporating feedback and feedforward in accordance with some embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0022]    In accordance with various embodiments, mechanisms for providing feedback to sending entities are provided. These mechanisms can be used in a variety of applications, such as to control a load received by a receiving server from one or more sending servers in some embodiments. As a more particular example, such mechanisms can be used in a Session Initiation Protocol (SIP) environment to control the number of sessions accepted by a receiving entity server from user agents proxied by one or more sending entity servers, in some embodiments. 
         [0023]    Turning to  FIG. 1 , an example  100  of such a Session Initiation Protocol (SIP) environment in accordance with some embodiments is shown. As illustrated, environment  100  includes sending user agents  102 ,  104 ,  106 ,  108 ,  110 , and  112 , sending entity servers  114 ,  116 , and  118 , a receiving server  120 , and receiving user agents  122  and  124 . User agents  102 ,  104 ,  106 ,  108 ,  110 ,  112 ,  122 , and  124  can be any suitable devices, such as mobile phones, Voice over IP (VoIP) phones, special purpose computers, general purpose computers, cameras, microphones, audio systems, audio and/or video conferencing systems, or any other suitable device. Although eight user agents are shown, any suitable number of user agents can be used in some embodiments. Servers  114 ,  115 ,  118 , and  120  can be any suitable servers in some embodiments, such as proxy servers, registrations servers, etc., and, although four servers are shown, any suitable number can be used. Servers  114 ,  115 ,  118 , and  120  can include any suitable hardware or physical components (such as one or more processors, such as microprocessors, digital signal processors, programmable logic devices, etc. for performing, among other things, the processes described herein), memory, interfaces, displays, input devices (such as keyboards, mice, etc.), storage devices (such as disk drives, etc.), etc. User agents  102 ,  104 ,  106 ,  108 ,  110 , and/or  112  can establish a call session with user agents  122  and/or  124  for any suitable purpose, such as telephone calls, multimedia distribution, video conferencing, presence service, instant messaging, etc. 
         [0024]    As described above, when sending user agents  102 ,  104 ,  106 ,  108 ,  110 , and  112  are actively trying to establish a session with one or more of user agents  122  and  124 , receiving entity server  120  can be overloaded by messages from sending entity servers  114 ,  116 , and  118  which are proxying the sending user agents.  FIG. 2  illustrates an example  200  of a process for establishing a session between user agents  230  and  234  via one or more intermediate servers  232  in accordance with some embodiments. As shown, an INVITE message  202  is initially sent from user agent  230  to servers  232 . In response, servers  232  send an INVITE message  204  to user agent  234  and then send a 100 Trying message  206  back to user agent  230 . User agent  234  responds to message  204  by sending a 180 Ringing message  208  back to servers  232 , which forward the message as 180 Ringing message  210 . Once the session has been accepted at user agent  234  (for example, by a user picking up the handset of a telephone user agent), a 200 OK message  212  is sent from user agent  234  to servers  232 , and the message forwarded to user agent  230  as 200 OK message  214 . Upon receiving the 200 OK message  214 , user agent  230  acknowledges the session acceptance by sending an ACK message  216  to servers  232 , which forward the message as an ACK message  218 . Once the session has been established in this way, media  220  can flow between user agents  230  and  234 . For example, this media can be a telephone conversation&#39;s two-way audio. Once the session is completed (for example, because the callers are done with their conversation), a BYE message  222  can be sent by one of the user agents (for example, here user agent  230 ) to servers  232 , and forwarded to the other user agent (for example, here user agent  234 ) as BYE message  224 . Upon receipt of BYE message  224 , the other user agent can then send a 200 OK message  226  to servers  232 , which can then forward the message as 200 OK message  228 . 
         [0025]    As mentioned above, in various scenarios, a receiving entity server can become overloaded with session acceptance messages from sending entity servers. For example, when a very large number of callers attempt to call the same telephone number at the same time, such as in a contest or in connection with a call-in television show, one or more sending entity servers can overload a receiving entity server corresponding to that telephone number. 
         [0026]    As shown in  FIG. 3 , in accordance with some embodiments, a mechanism  300  for controlling server load can provide feedback  316  from a receiving entity server  304  to one or more sending entity servers  302 . This feedback can be generated in a feedback generation mechanism  314  in server  304  and be provided to a feedback enforcement mechanism  318  in server  302 . When messages from user agents  306  are received at sending entity  302 , based on the feedback, the feedback enforcement mechanism can control how many sessions are established as part of a regulated load  310  to receiving entity  304  and then onto user agents  308 . For example, in some embodiments, the feedback can indicate the number of sessions that can be established during a control interval. Based on the load received from the one or more sending entity servers, feedback generation mechanism  314  can update the feedback provided to the sending entities to compensate for any increase or decrease in load at the receiving entity server. 
         [0027]    Any suitable processes for generating feedback and enforcing feedback in mechanisms  314  and  318 , respectively, can be used in some embodiments. Turning to  FIGS. 4-6B , examples of processes for generating feedback that can be used in some embodiments are illustrated. 
         [0028]      FIG. 4  shows a first example  400  of a process that can be used to provide feedback from a receiving entity server to one or more sending entity servers. In process  400 , this can be performed at the end of each of a series of control intervals. 
         [0029]    After process  400  begins at  402 , the process can first set initial values at  404 . These initial values can include any suitable values to be initialized, such as an initial number of sessions that can be established (i.e., a window size) for the first control interval. This initial number of sessions that can be established for each sending entity i can be set as: 
         [0000]    
       
      
       w 
       i 
       0 
       :=W 
       0  
      
     
         [0000]    wherein:
       w i   0  is the window size for sending entity i during the initial control interval; and   W 0  is the initial positive, non-zero-valued window size, such as W 0 =μ eng T c , where μ eng  is a server&#39;s engineered service rate, and T c  is the length of the control interval.       
 
         [0032]    Next, the window size can be sent, at  406 , from the receiving entity server to each sending entity server. This can be performed in any suitable manner, such as sending the feedback in an out-of-band channel or in an in-band channel (such as in the next, or an upcoming, message to be sent from the receiving entity server to the corresponding sending entity server). 
         [0033]    At  408 , it can then be determined if an INVITE message has been received by the receiving entity server. If it is determined that an INVITE message has been received, then, at  410 , the number of sessions available for the corresponding sending entity server for the present control interval can be decremented as follows: 
         [0000]        w   i   k   :=w   i   k −1
 
         [0000]    wherein: 
         [0034]    w i   k  is the window size for sending entity i during the current control interval k. 
         [0000]    The receipt of INVITE messages, and corresponding BYE messages, can also be tracked for subsequent determination, at  414 , of session service rates. 
         [0035]    After decrementing the number of sessions available at  410 , or after it is determined that an INVITE message was not received at  408 , it can be determined, at  412 , if the current control interval k has expired, or is about to expire. This expiration can occur at the end of each period having a duration of T c , which can be 200 ms or any other suitable value in some embodiments. If it is determined that the current control interval k has not expired, or is not about to expire, then process  400  can determine whether to update the number of sessions available at  413 . Any suitable criteria or criterion can be used to determine whether to update the number of sessions available. For example, in some embodiments, the number of sessions available can be sent every nth message to the sending entity server (where n is any suitable value). If the number of sessions available is to be updated, process  400  can branch to  406 . Otherwise process  400  can branch to  408 . 
         [0036]    If it is determined at  412  that the control interval has expired, process  400  can proceed to  414  where it can determine the session service rate. Any suitable mechanism for determining the session service rate can be used. For example, in accordance with some embodiments, the session service rate can be determined by performing a “full session check” by counting how many sessions have been started and completed within a measurement interval. As a more particular example, this full session check can be accomplished with SIP call sessions by monitoring the number of sessions including an INVITE message and a BYE message during the measurement interval. As another example, in accordance with some embodiments, the session service rate can be determined by performing a “start session check” by counting how many sessions have been started—for example, by counting the number of new INVITE messages received—during the measurement interval. As a more particular example, this start session check can be accomplished by calculating the current session service rate, μ k , as: 
         [0000]      μ k   =N   inv   accepted   /T   m  
 
         [0000]    wherein:
       N inv   accepted  is the number of INVITE messages accepted; and   T m  is the length of the measurement interval and can have a value of 100 ms or any other suitable value, and, in some embodiments, T m  has a value between 100 ms and the length,   T c , of the control interval.
 
In some embodiments, standard smoothing functions can be applied to μ k .
       
 
         [0040]    Next, at  416 , the number of sessions remaining to be serviced during the next control interval from the previous control interval can be determined. For example, in accordance with some embodiments, the number of sessions remaining to be serviced can be estimated as follows: 
         [0000]    
       
         
           
             
               N 
               sess 
             
             = 
             
               
                 N 
                 inv 
               
               + 
               
                 
                   N 
                   noninv 
                 
                 
                   
                     L 
                     sess 
                   
                   - 
                   1 
                 
               
             
           
         
       
     
         [0000]    wherein: 
         [0041]    N inv =the number of INVITE messages in the receiving entity server&#39;s queue; 
         [0042]    N noninv =the number of non-INVITE messages in the queue; and 
         [0043]    L sess =the average number of messages per session. 
         [0000]    The average number of messages per session, L sess , can be determined based on whether a full session check or a start session check is used to determine the session service rate. When a full session check is used, the length of each individual session can be counted by checking the start and end of each individual session, reflected, for example, by SIP INVITE and BYE messages. With the start session check, the session length can be obtained by counting the actual number of messages N msg   proc  processed during the same period the session acceptance rate is observed, and estimating the session length as: 
         [0000]        L   sess   =N   msg   proc   /N   inv   accepted . 
         [0044]    The number of active sources, N SE   k , for each sending entity can next be determined at  418 . For example, in some embodiments, the number of active sources can be determined by maintaining a table of sources of incoming load for each sending entity, expiring each entry in the table every second (e.g., to reduce the memory state), and maintaining a count of the sources. 
         [0045]    At  420 , the number of sessions each sending entity is able to accept in the next control interval can be determined. In some embodiments, this number of sessions can be determined as follows: 
         [0000]        w   k+1 :=μ k   T   c +μ k   D   B   −N   sess   k  
 
         [0000]        w   i   k+1 :=round( w   k+1   /N   SE   k ) 
         [0000]    wherein:
       w i   k+1  is the window size for sending entity i during the next control interval k+1;   μ k  is the current estimated session service rate determined at  414 ;   T c  is the length of the control interval and can have a value of 200 ms or any other suitable value;   D B  reflects the allowed budget message queuing delay and can have a value of 200 ms or any other suitable value;   N sess   k  is the estimated number of sessions remaining in the system at the end of the current control interval k determined at  416 ; and   N SE   k  is the number active sources in the current control interval k determined at  418 .       
 
         [0052]    Once the number of sessions each sending entity is able to accept in the next control interval has been determined, process  400  loops back to  406  to send the updated window sizes to the sending entity servers. 
         [0053]      FIG. 5A  shows a second example  500  of a process that can be used to generate feedback to be provided from a receiving entity server to one or more sending entity servers. In process  500 , this can be performed in response to one or more recurring events defining the bounds of periods t of time, such as any message being processed by the receiving entity server, an INVITE message being processed by the receiving entity server, etc. 
         [0054]    After process  500  begins at  502 , the process can first set initial values at  504 . These initial values can include any suitable values to be initialized, such as an initial number of sessions that can be established (i.e., a window size) for the period prior to the occurrence of the first event. This initial number of sessions that can be established for each sending entity i can be set as: 
         [0000]    
       
      
       w 
       i 
       0 
       :=W 
       0  
      
     
         [0000]    wherein:
       w i   0  is the initial window size for sending entity i; and   W 0  is the initial positive, non-zero-valued window size, such as W 0 =μ eng T c , where μ eng  is a server&#39;s engineered service rate, and T c  is the estimated length of the initial period t.
 
Temporary variables can also be initialized at this step. For example, the following temporary variable, the use of which is described below at  520 , can be initialized as:
       
 
         [0000]        w   i′   0 :=0 
         [0057]    Next, the window size can be sent, at  506 , from the receiving entity server to the sending entity server. This can be performed in any suitable manner, such as sending the feedback in an out-of-band channel or in an in-band channel (such as in the next, or an upcoming, message to be sent from the receiving entity server to the corresponding sending entity server). 
         [0058]    At  508 , it can then be determined if an INVITE message has been received by the receiving entity server. If it is determined that an INVITE message has been received, then, at  510 , the number of sessions available for the corresponding sending entity server for the present period t can be decremented as follows: 
         [0000]        w   i   t   :=w   i   t −1
 
         [0000]    wherein: 
         [0059]    w i   t  is the window size for sending entity i during the current period t. 
         [0000]    The receipt of INVITE messages, and corresponding BYE messages, can also be tracked for subsequent determination, at  514 , of session service rates. 
         [0060]    After decrementing the number of sessions available at  510 , or after it is determined that an INVITE message was not received at  508 , it can be determined, at  512 , if the specified event, or one of the specified events, has occurred, thus expiring the current period t. If it is determined that the event has not occurred, then process  500  can determine whether to update the number of sessions available at  513 . Any suitable criteria or criterion can be used to determine whether to update the number of sessions available. For example, in some embodiments, the number of sessions available can be sent every nth message to the sending entity server (where n is any suitable value). If the number of sessions available is to be updated, process  500  can branch to  506 . Otherwise process  500  can branch to  508 . 
         [0061]    If it is determined at  512  that the control interval has expired, process  500  can proceed to  514  where it can determine the session service rate. As above, any suitable mechanism for determining the session service rate can be used. For example, in accordance with some embodiments, the session service rate can be determined by performing a “full session check” by counting how many sessions have been started and completed within a measurement interval. As a more particular example, this full session check can be accomplished with SIP call sessions by monitoring the number of sessions including an INVITE message and a BYE message during the measurement interval. As another example, in accordance with some embodiments, the session service rate can be determined by performing a “start session check” by counting how many sessions have been started—for example, by counting the number of new INVITE messages received—during the measurement interval. As a more particular example, this start session check can be accomplished by calculating the current session service rate, μ t , as: 
         [0000]      μ t   =N   inv   accepted   /T   m  
 
         [0000]    wherein:
       N inv   accepted  is the number of INVITE messages accepted; and   T m  is the length of the measurement interval and can have a value of 100 ms or any other suitable value, and, in some embodiments, T m  has a value between 100 ms and the duration of period t.
 
In some embodiments, standard smoothing functions can be applied to μ t .
       
 
         [0064]    Next, at  516 , the number of sessions remaining to be serviced during the next period from the previous period can be determined. For example, in accordance with some embodiments, the number of sessions remaining to be serviced can be estimated as follows: 
         [0000]    
       
         
           
             
               N 
               sess 
             
             = 
             
               
                 N 
                 inv 
               
               + 
               
                 
                   N 
                   noninv 
                 
                 
                   
                     L 
                     sess 
                   
                   - 
                   1 
                 
               
             
           
         
       
     
         [0000]    wherein: 
         [0065]    N inv =the number of INVITE messages in the receiving entity server&#39;s queue; 
         [0066]    N noninv =the number of non-INVITE messages in the queue; and 
         [0067]    L sess =the average number of messages per session. 
         [0000]    The average number of messages per session, L sess , can be determined based on whether a full session check or a start session check is used to determine the session service rate. When a full session check is used, the length of each individual session can be counted by checking the start and end of each individual session, reflected, for example, by SIP INVITE and BYE messages. With the start session check, the session length can be obtained by counting the actual number of messages N msg   proc  processed during the same period the session acceptance rate is observed, and estimating the session length as: 
         [0000]        L   sess   =N   msg   proc   /N   inv   accepted . 
         [0068]    The number of active sources, N SE   t , for each sending entity can next be determined at  518 . For example, in some embodiments, the number of active sources can be determined by maintaining a table of sources of incoming load for each sending entity, expiring each entry in the table every second (e.g., to reduce the memory state), and maintaining a count of the sources. 
         [0069]    At  520 , the number of sessions each sending entity is able to accept in the next period is determined. In some embodiments, this number of sessions, w i   t+1 , can be determined as follows: 
         [0000]                                            N sess   max  := μ t  D B             w left   t  := N sess   max  − N sess             if (w left   t  ≧ 1)             w share   t := w left   t /N SE   t               w i   t , := w i   t , + w share   t               if (w i   t , ≧ 1)               w i   t+1  := (int)w i   t ,               w i   t , := (frac)w i   t ,                        
wherein:
       μ t  is the current estimated session service rate determined at  514 ;   D B  reflects the allowed budget message queuing delay and can have a value of 200 ms or any other suitable value;   N sess  is the number of sessions remaining to be serviced determined at  516     N SE   t  is the number active sources for a sending entity in the current period t determined at  518 ;   (int) is an operator which returns the integer part of the operand; and   (frac) is an operator which returns the fractional part of the operand.       
 
         [0076]    Once the number of sessions each sending entity is able to accept in the next period has been determined, process  500  loops back to  506  to send the updated window sizes to the sending entity servers. In some embodiments, before sending the updated window sizes to the sending entity servers, process  500  can determine whether the window sizes for the sending entities for the next period are sufficiently different from the sizes for the previous period. This determination can be made on a server-by-server basis, based on the aggregate change across all sending entity servers, or based on any other suitable criteria or criterion. 
         [0077]      FIG. 5B  shows a third example  550  of a process that can be used to generate feedback to be provided from a receiving entity server to one or more sending entity servers. In process  550 , this can similarly be performed in response to one or more recurring events defining the bounds of periods t of time, such as any message being processed by the receiving entity server, an INVITE message being processed by the receiving entity server, etc. 
         [0078]    After process  550  begins at  552 , the process can first set initial values at  554 . These initial values can include any suitable values to be initialized, such as an initial number of sessions that can be established (i.e., a window size) for the period prior to the occurrence of the first event. This initial number of sessions that can be established for each sending entity i can be set as: 
         [0000]    
       
      
       w 
       i 
       0 
       :=W 
       0  
      
     
         [0000]    wherein: 
         [0079]    w i   0  is the initial window size for sending entity i; and 
         [0080]    W 0  is the initial positive, non-zero-valued window size, such as W 0 =μ eng T c , where μ eng  is 
         [0081]    a server&#39;s engineered service rate, and T c  is the estimated length of the initial period t. 
         [0000]    Temporary variables can also be initialized at this step. For example, the following temporary variable, the use of which is described below at  570 , can be initialized as: 
         [0000]        w   i′   0 :=0 
         [0082]    Next, the window size can be sent, at  556 , from the receiving entity server to each sending entity server. This can be performed in any suitable manner, such as sending the feedback in an out-of-band channel or in an in-band channel (such as in the next, or an upcoming, message to be sent from the receiving entity server to the corresponding sending entity server). 
         [0083]    At  558 , it can then be determined if an INVITE message has been received by the receiving entity server. If it is determined that an INVITE message has been received, then, at  560 , the number of sessions available for the corresponding sending entity server for the present period t can be decremented as follows: 
         [0000]        w   i   t   :=w   i   t −1
 
         [0000]    wherein: 
         [0084]    w i   t  is the window size for sending entity i during the current period t. 
         [0085]    After decrementing the number of sessions available at  560 , or after it is determined that an INVITE message was not received at  558 , it can be determined, at  562 , if the specified event, or one of the specified events, has occurred, thus expiring the current period t. If it is determined that the event has not occurred, then process  550  can determine whether to update the number of sessions available at  563 . Any suitable criteria or criterion can be used to determine whether to update the number of sessions available. For example, in some embodiments, the number of sessions available can be sent every nth message to the sending entity server (where n is any suitable value). If the number of sessions available is to be updated, process  550  can branch to  556 . Otherwise process  550  can branch to  558 . 
         [0086]    If it is determined at  562  that the control interval has expired, process  550  can proceed to  568  where it can determine the number of active sources, N SE   t , for each sending entity. For example, in some embodiments, the number of active sources can be determined by maintaining a table of sources of incoming load for each sending entity, expiring each entry in the table every second (e.g., to reduce the memory state), and maintaining a count of the sources. 
         [0087]    At  570 , the number of sessions each sending entity is able to accept in the next period can be determined. As shown below, this number of sessions, w i   t+1 , can be determined as follows: 
         [0000]                                            w left   t  := RE fb win preset  − N inv in q             if (w left   t  ≧ 1)             w share   t := w left   t /N SE   t               w i   t , := w i   t , + w share   t               if (w i   t , ≧ 1)               w i   t+1  := (int)w i   t ,               w i   t , := (frac)w i   t ,                        
wherein:
       RE fb win preset  is limit on the number of new INVITE messages to be received (e.g., a small number such as 10);   N inv in q  is the number of new INVITE messages in the receiving entity server processing queue;   N SE   t  is the number active sources for a sending entity in the current period t determined at  568 ;   (int) is an operator which returns the integer part of the operand; and   (frac) is an operator which returns the fractional part of the operand.       
 
         [0093]    Once the number of sessions each sending entity is able to accept in the next period has been determined, process  550  loops back to  556  to send the updated window sizes to the sending entity servers. In some embodiments, before sending the updated window sizes to the sending entity servers, process  550  can determine whether the window sizes for the sending entities for the next period are sufficiently different from the sizes for the previous period. This determination can be made on a server-by-server basis, based on the aggregate change across all sending entity servers, or based on any other suitable criteria or criterion. 
         [0094]      FIG. 6A  shows a fourth example  600  of a process that can be used to generate feedback to be provided from a receiving entity server to one or more sending entity servers. In process  600 , this can be performed in response to one or more recurring events defining the bounds of periods t of time, such as any message being processed by the receiving entity server, an INVITE message being processed by the receiving entity server, a window size reaching or being below a certain value, each change in a window size, etc. 
         [0095]    After process  600  begins at  602 , the process can first set initial values at  604 . These initial values can include any suitable values to be initialized, such as an initial number of sessions that can be established (i.e., a window size) for the period prior to the occurrence of the first event. This initial number of sessions that can be established for each sending entity i can be set as: 
         [0000]    
       
      
       w 
       i 
       0 
       :=W 
       0  
      
     
         [0000]    wherein:
       w i   0  is the initial window size for sending entity i; and   W 0  is the initial positive, non-zero-valued window size, such as W 0 =μ eng T c , where μ eng  is a server&#39;s engineered service rate and T c  is the estimate length of the initial period t.       
 
         [0098]    Next, the window size can be sent, at  606 , from the receiving entity server to the sending entity servers. This can be performed in any suitable manner, such as sending the feedback in an out-of-band channel or in an in-band channel (such as in the next, or an upcoming, message to be sent from the receiving entity server to the corresponding sending entity server). 
         [0099]    At  608 , it can then be determined if an INVITE message has been received by the receiving entity server. If it is determined that an INVITE message has been received, then, at  610 , the number of sessions available for the corresponding sending entity server for the present period t can be decremented as follows: 
         [0000]        w   i   t   :=w   i   t −1
 
         [0000]    wherein: 
         [0100]    w i   t  is the window size for sending entity i during the current period t. 
         [0101]    After decrementing the number of sessions available at  610 , or after it is determined that an INVITE message was not received at  608 , it can be determined, at  612 , if a new INVITE message has been processed. If it is determined that a new INVITE message has been processed, then, at  614 , the number of sessions available for the corresponding sending entity server for the present period t can be incremented as follows: 
         [0000]        w   i   t   :=w   i   t +1 
         [0102]    After incrementing the number of sessions available at  614 , or after it is determined that a new INVITE message was not processed at  612 , it can be determined, at  616 , if the specified event, or one of the specified events, has occurred, thus expiring the current period t. If it is determined that the event has not occurred, then process  600  can loop back to  608 . Otherwise, process  600  can loop back to  606  to send the updated window sizes to the sending entity servers. In some embodiments, before sending the updated, increased window sizes to the sending entity servers, process  600  can determine whether the queuing delay for the receiving entity server has exceeded a given threshold (e.g., 250 ms, or half of the SIP T 1  time value for resending an unresponded-to INVITE message). If the queuing delay exceeds this threshold, then the process can select to not send increased window sizes for the sending entities. 
         [0103]    In some instances, it may not be possible or desirable to simply decrement or increment the sessions available for a corresponding sending entity as discussed above in  610  and  614 . For example, this may be the case because the window size of a sending entity may be too small to decrement or because an increment in window size that would be provided for the corresponding entity is needed more for another entity. In such cases, rather than performing what is described in  610  and  614  as discussed above, in some embodiments, a pool of window slots can instead be maintained and, when an empty slot becomes available, the slot can be assigned to a sending entity based on any suitable criteria or criteria, such as equal or proportional allocation. 
         [0104]      FIG. 6B  shows a fifth example  650  of a process that can be used to generate feedback to be provided from a receiving entity server to one or more sending entity servers. In process  650 , this can similarly be performed in response to one or more recurring events defining the bounds of periods t of time, such as any message being processed by the receiving entity server, an INVITE message being processed by the receiving entity server, a window size reaching or being below a certain value, each change in a window size, etc. 
         [0105]    After process  650  begins at  652 , the process can first set initial values at  654 . These initial values can include any suitable values to be initialized, such as an initial number of sessions that can be established (i.e., a window size) for the period prior to the occurrence of the first event, a preset limit on the number of new INVITE messages, etc. The initial number of sessions that can be established for each sending entity i can be set as: 
         [0000]    
       
      
       w 
       i 
       0 
       :=W 
       0  
      
     
         [0000]    wherein:
       w i   0  is the initial window size for sending entity i; and   W 0  is the initial positive, non-zero-valued window size, such as W 0 =μ eng T c , where μ eng  is a server&#39;s engineered service rate and T c  is the estimate length of the initial period t.
 
The preset limit can be set as: RE fb win preset =10 (or any other suitable value).
       
 
         [0108]    Next, the window size can be sent, at  656 , from the receiving entity server to the sending entity servers. This can be performed in any suitable manner, such as sending the feedback in an out-of-band channel or in an in-band channel (such as in the next, or an upcoming, message to be sent from the receiving entity server to the corresponding sending entity server). 
         [0109]    At  658 , it can then be determined if a new INVITE message has been received by the receiving entity server. If it is determined that a new INVITE message has not been received, then process  650  can loop back to  658 . Otherwise, process  650  can next determine, at  660 , whether the number of new INVITE messages in the receiving entity server&#39;s queue is less than the preset limit. If it is, at  662 , the process can assign the freed slot (i.e., the slot freed due to the completion of processing of the INVITE message) to an active sender using any suitable approach. For example, in some embodiments, the freed slot can be assigned using a proportional assignment algorithm (e.g., based on equal assignment, based up load at the sending entity server, etc.). 
         [0110]    After assigning the freed slot at  662 , or after it is determined that the number of new INVITE messages in the queue is not less than the preset limit at  660 , it can be determined, at  664 , if the specified event, or one of the specified events, has occurred, thus expiring the current period t. If it is determined that the event has not occurred, then process  650  can loop back to  658 . Otherwise, process  650  can loop back to  656  to send the updated window sizes to the sending entity servers. In some embodiments, before sending the updated, increased window sizes to the sending entity servers, process  650  can determine whether the queuing delay for the receiving entity server has exceeded a given threshold (e.g., 250 ms, or half of the SIP T 1  time value for resending an unresponded-to INVITE message). If the queuing delay exceeds this threshold, then the process can select to not send increased window sizes for the sending entities. 
         [0111]      FIG. 7  shows a sixth example  700  of a process that can be used to generate feedback to be provided from a receiving entity server to one or more sending entity servers. As illustrated, after process  700  begins at  702 , the process can first set initial values at  704 . These initial values can include any suitable values to be initialized, such as an initial target rate limit for the first control interval. This initial target rate limit that can be established for each sending entity i can be set as: 
         [0000]      λ i   0   :=L   0  
 
         [0000]    wherein:
       λ i   0  is the target rate limit for sending entity i during the initial control interval; and   L 0  is the initial positive, non-zero-valued target rate limit, such as L 0 =μ eng /N SE   0  where μ eng  is a server&#39;s engineered service rate, and N SE   0  is number of sending entities during the initial interval.       
 
         [0114]    Next, the target rate limit can be sent, at  706 , from the receiving entity server to each sending entity server. This can be performed in any suitable manner, such as sending the feedback in an out-of-band channel or in an in-band channel (such as in the next, or an upcoming, message to be sent from the receiving entity server to the corresponding sending entity server). 
         [0115]    At  708 , it can be determined if the current control interval k has expired, or is about to expire. This expiration can occur at the end of each period having a duration of T c , which can be 200 ms or any other suitable value in some embodiments. If it is determined that the current control interval k has not expired, or is not about to expire, then process  700  can branch to  709  where it determines whether to resend the target rate limit to the sending entities. Resending the target rate limit can be performed for any suitable purpose, such as redundancy of messages. If the target rate limit is to be resent, then process  700  can loop back to  706 . Otherwise, process  700  can loop back to  708 . 
         [0116]    If it is determined that the current control interval k has expired, or is about to expire, then process  700  can proceed to  710  where it can determine the session service rate. Any suitable mechanism for determining the session service rate can be used. For example, in accordance with some embodiments, the session service rate can be determined by performing a “full session check” by counting how many sessions have been started and completed within a measurement interval. As a more particular example, this full session check can be accomplished with SIP call sessions by monitoring the number of sessions including an INVITE message and a BYE message during the measurement interval. As another example, in accordance with some embodiments, the session service rate can be determined by performing a “start session check” by counting how many sessions have been started for example, by counting the number of new INVITE messages received during the measurement interval. As a more particular example, this start session check can be accomplished by calculating the current session service rate, μ k , as: 
         [0000]      μ k   =N   inv   accepted   /T   m  
 
         [0000]    wherein:
       N inv   accepted  is the number of INVITE messages accepted; and   T m  is the length of the measurement interval and can have a value of 100 ms or any other suitable value, and, in some embodiments, T m  has a value between 100 ms and the length, T c , of the control interval.
 
In some embodiments, standard smoothing functions can be applied to μ k .
       
 
         [0119]    Next, at  712 , the number of sessions remaining to be serviced during the next control interval from the previous control interval can be determined. For example, in accordance with some embodiments, the number of sessions remaining to be serviced can be estimated as follows: 
         [0000]    
       
         
           
             
               N 
               sess 
             
             = 
             
               
                 N 
                 inv 
               
               + 
               
                 
                   N 
                   noninv 
                 
                 
                   
                     L 
                     sess 
                   
                   - 
                   1 
                 
               
             
           
         
       
     
         [0000]    wherein: 
         [0120]    N inv =the number of INVITE messages in the receiving entity server&#39;s queue; 
         [0121]    N noninv =the number of non-INVITE messages in the queue; and 
         [0122]    L sess =the average number of messages per session. 
         [0000]    The average number of messages per session, L sess , can be determined based on whether a full session check or a start session check is used to determine the session service rate. When a full session check is used, the length of each individual session can be counted by checking the start and end of each individual session, reflected, for example, by SIP INVITE and BYE messages. With the start session check, the session length can be obtained by counting the actual number of messages N msg   proc  processed during the same period the session acceptance rate is observed, and estimating the session length as: 
         [0000]        L   sess   =N   msg   proc   /N   inv   accepted . 
         [0123]    At  714 , the target load for each sending entity in the next control interval can be determined. In some embodiments, this target load can be determined as follows: 
         [0000]    
       
         
           
             
               λ 
               i 
               
                 k 
                 + 
                 1 
               
             
             := 
             
               
                 
                   μ 
                   k 
                 
                  
                 
                   ( 
                   
                     1 
                     - 
                     
                       
                         ( 
                         
                           
                             d 
                             q 
                             k 
                           
                           - 
                           
                             D 
                             B 
                           
                         
                         ) 
                       
                       
                         T 
                         C 
                       
                     
                   
                   ) 
                 
               
               / 
               
                 N 
                 SE 
                 k 
               
             
           
         
       
     
         [0000]    wherein:
       λ i   k+1  is the target rate limit for sending entity i during the next control interval k+1;   μ k  is the current estimated session service rate determined at  710 ;   d q   k  is the estimate server queuing delay at the end of the last measurement interval k, and can be estimated by: d q   k =N SESS /μ k , where N sess   k  is the estimated number of sessions remaining in the system at the end of the current control interval k determined at  712 ;   D B  reflects the allowed budget message queuing delay and can have a value of 200 ms or any other suitable value;   T c  is the length of the control interval and can have a value of 200 ms or any other suitable value;   N SE   k  is the number of sending entities during interval k.       
 
         [0130]    Once the target rate limit for each sending entity in the next control interval has been determined, process  700  loops back to  706  to send the updated target rate limits to the sending entity servers. 
         [0131]    In some embodiments, in any of these approaches to providing feedback, when the current number of active sessions is below a corresponding minimum threshold and the current maximum allocable window size is smaller than a corresponding minimum threshold, the current maximum allocable window size can be adjusted so that at least one sending entity server receives window size feedback that is greater than one. 
         [0132]    In some embodiments, in any of the approaches to providing feedback in which a window size is provided as the feedback, when a receiving entity receives an INVITE message, the receiving entity can check the corresponding window size value for the corresponding sending entity and determine whether the INVITE message should be recognized and processed. When it is determined that an INVITE message will not be recognized and processed, the INVITE message can be rejected or dropped. In some embodiments, a receiving entity can maintain a single queue for storing all INVITE messages or it can maintain separate queues for INVITE messages from different sending entities or groups of sending entities. 
         [0133]    Turning to  FIG. 8 , an example  800  of a process for enforcing feedback in accordance with some embodiments is shown. As illustrated, after process  800  begins at  802 , the process can receive a window size from the receiving entity server at  804 . Using this window size, a corresponding number of window slots for establishing sessions in the receiving entity server can be configured at  806 . Next, at  808 , session request messages (e.g., INVITE messages) can be received from one or more user agents. Process  800  can then determine at  810  if a slot is available for the requested session. If a slot is available, then the session can be assigned to the next slot at  812 . If a slot is determined to not be available at  810 , then the Session Request can be rejected at  813 . After rejecting the Session Request at  813 , or after assigning a session to a slot at  812 , the process can determine if a window size feedback update is available at  814 . If there is an update, the process can loop back to  804  to receive the update. Otherwise, the process can loop to  808  to receive and queue the next session request message. 
         [0134]    In some embodiments, mechanisms can be provided to provide a measure of fairness as to how window size is allocated among multiple sending entity servers. Fairness at the sending-entity-server level can be realized by allocating the same amount of window size to each sending entity server. Fairness at the end-user level can be realized by allocating a proportional amount of window size to each sending entity server based on the proportion of end users corresponding to each sending entity server compared to the entire pool of end users. 
         [0135]    To enable end-user fairness to be taken into consideration, in some embodiments feedforward information can be provided from the sending entity servers to the receiving entity server as illustrated by feedforward  902  in mechanism  900  of  FIG. 9 . This feedforward information can include the number of end-users (and/or any other suitable information) at each sending entity and can be generated by any suitable feedforward reporting unit  904 . This feedforward can be used to achieve end-user fairness in the example processes of  FIGS. 4 and 5A  by allocating the total receiving entity server capacity among the sending entity servers according to the sending entity servers&#39; incoming load. For example, the following equation calculated at  420  of  FIG. 4 : 
         [0000]        w   i   k+1 :=round( w   k+1   /N   SE   k ) 
         [0000]    can be changed to: 
         [0000]        w   i   k+1 :=round( w   k+1 (feedforward i /feedforward total )) 
         [0000]    wherein: 
         [0136]    feedforward i  is the number of end-users at sending entity i; and 
         [0137]    feedforward total  is the total number of end-users at all sending entity servers. 
         [0000]    As another example, the following equation calculated at  520  of  FIG. 5A : 
         [0000]    
       
      
       w 
       share 
       t 
       :=w 
       left 
       t 
       /N 
       SE 
       t  
      
     
         [0000]    can be changed to: 
         [0000]        w   share   t   :=w   left   t (feedforward i /feedforward total ) 
         [0000]    wherein: 
         [0138]    feedforward i  is the number of end-users at sending entity i; and 
         [0139]    feedforward total  is the total number of end-users at all sending entity servers. 
         [0000]    Alternatively, for the process of  FIG. 5A , the calculations performed at  520  can be changed to: 
         [0000]                                            N sess   max  := μ t  D B             w left   t  := N sess   max  − N sess             w left   t  := w left   t  + w left   t ,           if (w left   t  ≧ 1)             w left   t , := (frac)w left   t               w share   t := (int)w left   t               w i   t  := w share   t  with probability feedforward i /feedforward total                          
wherein:
       w left   t=0 , is initialized at  504  of  FIG. 5A  to zero;   μ t  is the current estimated session service rate determined at  514 ;   D B  reflects the allowed budget message queuing delay and can have a value of 200 ms or any other suitable value;   N sess  is the number of sessions remaining to be serviced determined at  516     (int) is an operator which returns the integer part of the operand;   (frac) is an operator which returns the fractional part of the operand;   feedforward i  is the number of end-users at sending entity i; and   feedforward total  is the total number of end-users at all sending entity servers.       
 
         [0148]    In some embodiments, any suitable computer readable media can be used for storing instructions for performing the processes described herein. For example, in some embodiments, computer readable media can be transitory or non-transitory. For example, non-transitory computer readable media can include media such as magnetic media (such as hard disks, floppy disks, etc.), optical media (such as compact discs, digital video discs, Blu-ray discs, etc.), semiconductor media (such as flash memory, electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), etc.), any suitable media that is not fleeting or devoid of any semblance of permanence during transmission, and/or any suitable tangible media. As another example, transitory computer readable media can include signals on networks, in wires, conductors, optical fibers, circuits, any suitable media that is fleeting and devoid of any semblance of permanence during transmission, and/or any suitable intangible media. 
         [0149]    Although the invention has been described and illustrated in the foregoing illustrative embodiments, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the details of implementation of the invention can be made without departing from the spirit and scope of the invention, which is only limited by the claims which follow. Features of the disclosed embodiments can be combined and rearranged in various ways.