Session Initiation Protocol (SIP) Rate Control
Extracted elements (23)
The rate-based algorithm sets an upper bound on request rate that remains constant between server updates, unlike the loss-based scheme where any increase in load is directly reflected in offered load. The trade-off is that the server is more likely to compute a different target rate for each client, increasing algorithmic complexity.
The rate-based overload control scheme was introduced because the loss-based scheme cannot guarantee an upper bound on the load from clients towards an overloaded server and requires frequent updates with implications for stability. Rate-based control guarantees a constant upper bound on request rate between server updates, at the cost of higher algorithmic complexity since the server is more likely to use different targets for each client.
When many client sources activate control simultaneously, synchronized bucket occupancies can cause batched arrivals ('resonance') at the server, leading to control instability, poor delays, and lost messages. Randomizing the bucket occupancy at activation and whenever the bucket empties avoids this resonance phenomenon.
When a client supports only the default loss-based algorithm and not the rate-based algorithm, the server handles that client as specified in Section 5.10.2 of RFC 7339, maintaining backward compatibility with the loss-based scheme.
Support of rate-based control MUST be indicated by clients including the token 'rate' in the 'oc-algo' list. Selection of rate-based control MUST be indicated by servers by setting 'oc-algo' to the token 'rate'.
The server MUST periodically evaluate its overload state and estimate a target SIP request rate beyond which it would become overloaded. The specific internal algorithm for this evaluation is outside the scope of this document.
The server MUST use the 'oc' parameter defined in RFC 7339 to send a target SIP request rate to each of its clients when rate-based overload control is active.
To throttle new SIP requests at the rate specified by the 'oc' parameter, the client MAY use the proposed default leaky bucket algorithm or any other equivalent algorithm that forwards messages in conformance with the upper bound of 1/T messages per second.
Upon detection of overload and the determination to invoke overload controls, the server MUST follow the specifications in RFC 7339 to notify its clients of the allocated target SIP request rate and that rate-based control is in effect.
Priority treatment uses two leaky bucket thresholds TAU1 and TAU2 (TAU1 < TAU2): all requests admitted when counter <= TAU1; only higher-priority requests admitted when TAU1 < counter <= TAU2; all requests rejected when counter >= TAU2. Recommended values are TAU0=0, TAU1=TAU2/2, TAU2=10*T.
The default client algorithm is a leaky bucket based on ITU-T I.371 Appendix A.2. The bucket counter increases by T per forwarded request and drains continuously at rate 1; a request is forwarded only if the provisional counter X' = X - (ta(k) - LCT) is less than or equal to tolerance TAU, otherwise it is rejected.
The 'oc-algo' Via header field parameter is used by clients to advertise supported overload control algorithms and by servers to notify clients of the algorithm in effect. Supported values are 'loss' (default) and 'rate' (optional).
The 'oc-seq' Via header field parameter is a sequence number associated with the 'oc' parameter, enabling clients to detect out-of-order or stale overload control updates.
The 'oc-validity' Via header field parameter indicates the interval in milliseconds that the load reduction should remain in effect. A value of 0 signals the server to stop overload control; a non-zero value is required in all other cases.
The 'oc' Via header field parameter is used by clients to indicate support for overload control and by servers to indicate the maximum rate in messages per second for the rate-based algorithm. For rate-based control, the 'oc' value represents an upper bound on traffic the client may send to the server.
The server may set the same maximum rate for every client or may set different rates for different clients, optionally taking into account the workload (e.g., CPU load per request type) and the expected shift in message-type distribution under overload conditions.
The target inter-SIP request interval T is defined as the inverse of the 'oc' parameter: T = 1 / ['oc' parameter]. This quantity drives the leaky bucket algorithm that clients use to throttle outgoing requests.
The tolerance parameter TAU controls admission burstiness. TAU=4*T is recommended as a reasonable compromise between burst size and throttled rate adaptation. TAU can be any positive real number and is not bounded by T.
To avoid resonance, the bucket increment upon admission is randomized to T + uT where u is uniform on [-1/2, +1/2] when the bucket empties (X'<=0), and u=0 otherwise. At control activation, the initial counter is set to TAU0 + uT instead of TAU0.
When the 'oc' parameter is 0 with a non-zero 'oc-validity', the client should reject 100% of SIP requests destined to the overloaded server. When 'oc-validity' is 0, the client should immediately stop throttling.
IANA registered the 'oc-algo' parameter of the Via header field in the 'Header Field Parameters and Parameter Values' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry, with predefined values Yes, referencing RFC 7339 and RFC 7415.
The rate-based mechanism does not introduce security concerns beyond the general overload control security issues discussed in RFC 7339, with the exception of resonance. Resonance — synchronized bucket occupancies causing peaky arrivals and control instability — is a concern specific to this algorithm, and mitigation methods are described in Section 3.5.3.
The syntax extension adds 'rate' as a valid value in the 'algo-list' production of the Via header field parameters defined in RFC 7339: algo-list =/ "rate". This is the only grammar change this document makes.