Subject: [sip-overload] Comments on draft-ietf-soc-overload-design-00

From: <[email-masked]>
Date: Tue, 29 Jun 2010 18:58:56 +0100

Volker, All,

Here are some comments on the draft.

1) Section 3, "Explicit vs. Implicit Overload Control" Does "explicit"
OLC here mean that the overloaded server is somehow requesting a
*specific* rate reduction, e.g. by percentage or by call gap? If so
there is a further option intermediate between "implicit" and "explicit"
as described here. This option requires the overloaded downstream server
to reject INVITEs with a response which is unambiguously attributable to
server overload, so probably 503. Then the upstream server controls the
rate of INVITEs forwarded downstream to achieve a (low but non-zero)
target rate of 503 rejections. This is covered in section 9.4 below but
is not obvious from the text in section 3. Also the term "implicit" is
used in other work on overload control to refer to the upstream device's
determining a rate reduction based on receiving 503-like rejection
indications, so there is potential for confusion. If you want to keep
"implicit" for the ability to handle an unresponsive downstream
neighbour gracefully, you could consider splitting explicit control
using the vocabulary "descriptive explicit control" for the 503 case and
"prescriptive explicit control" for the case where downstream sends a
rate or a window

2) Section 3 paragraph 3, "A SIP server that is sensing such a condition
reduces  the load it is forwarding a downstream neighbor" What is the
relationship between this and retransmission in SIP/UDP? Does upstream
server retransmit a given request until failure is confirmed, but then
back off the number of requests which it initiates to the downstream
device?
3) Section 5.3 para 1. "The fundamental assumption behind local overload
control is that it is less resource consuming  for a server to reject
messages than to process them."  You might repeat here that cost of
rejection is never zero, so if overload is ever "significant" as a
multiplier of session setup rate, the possibility of congestion collapse
should be considered - and may only be avoided by using an external
control.

4) Section 5.3 para 2. "In general, SIP servers should apply other
overload control techniques to control load before  a local overload
control mechanism is activated as a mechanism of last resort." External
load control does not negate the need for internal control. An internal
control should be available to operate quickly to stabilise load (as
well as it can) whilst external controls start to operate, and to manage
transients throughout the duration of the overload. Once external
controls are established, rejections by the internal control may cease,
or may persist at a low level - possibly providing the basis of, or
contributing to, the Monitor function.

5) Section 7, "Fairness". Maybe add a forward reference to Section 12 on
the related topic of prioritisation of emergency calls?

6) Section 7 "With basic fairness a SIP server treats all end users
equally and ensures that each end user  has the same chance of reaching
the destination server. " Should "each end user" here be re-phrased as
"each attempt to initiate a session"? An end user can increase her
chance of reaching the destination server by making multiple attempts,
unless special (more complicated) measures are taken to thwart her.

7) Section 8 para 3, "...should quickly remove  all throttles..." The
importance of this is dependent on the nature of the throttles - e.g.
speed of removal is important for percent-based throttles, much less
important for leaky bucket throttles which have almost no impact on
traffic below their control rate. The requirement is that the mechanism
should quickly stop rejecting calls which can be carried to completion.

8) Section 9.1 para 4. "A server needs to ensure that the sum of all
rate caps assigned to upstream neighbors is not higher than its actual
processing capacity." This is an oversimplification, particularly for
the Crawford gap algorithm described above. Crawford gap admits the
nominal rate only if the offered rate is extremely high. For varying
offered rate which is not extremely high, Crawford gaps deliver a
varying admitted rate which is below the nominal rate. So to ensure full
occupancy of the overloaded server in the face of varying offered load,
the nominal rate must be adjusted continuously. The sum of the nominal
rates will always be in excess of the capacity of the downstream server.
If good internal control is available, the rate may safely be
over-subscribed, ensuring full use of the capacity in the face of
varying calling rate offered to the upstream servers. This is recognised
in the next paragraph (para 5), but the message in this para 4 is
inconsistent with that in para 5.

9) Section 9.1 para 5. "rate cap for each upstream neighbor is using a
fixed proportion of a control variable" Does this mean every upstream
gets the same rate restriction? If upstream neighbours would offer
different calling rates when unrestricted, this mechanism does not
achieve basic fairness.

10) Section 9.2 para 3, "...increase the loss percentage to 55%" I think
it's nearer to 56% if readers want to check your calculation!

11) Section 9.3 para 6, "total available receiver buffer space needs to
be divided among all upstream neighbors" This implies that the protocol
extension will have to convey an explicit window size from the
overloaded target to each upstream source. If the overloaded target
wants to achieve basic fairness it will have to take into account
offered traffic at each upstream server (before restriction!) and
round-trip times from each upstream server to determine a per-server
window size - sounds really difficult.

Hope this helps.

Regards
Geoff