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

From: Volker Hilt <[email-masked]>
Date: Wed, 21 Jul 2010 14:54:27 +0200

Geoff,

thanks for the detailed comments. More inline.
>
> 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.

Yes, the mechanism described in section uses 503 to signal overload, 
i.e., an explicit signal. I've changed the wording in Section 3 to 
better accommodate this mechanism.

> 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,

Yes.

> 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
>
The idea was to cover both with the term explicit control. I think 
having this as a single category is probably fine grained enough, in 
particular, since we only have one example for the descriptive case. 
Please feel free to send text if additional clarification is needed.

> 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?

Yes. Implicit overload control (as any other overload control mechanism) 
does not affect retransmissions. I've added text to Section 12 on that.

> 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.
>
Done.

> 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.
>
I believe this is what is in the draft. Please feel free to send text 
for additional clarification.

> 5) Section 7, "Fairness". Maybe add a forward reference to Section 12 on
> the related topic of prioritisation of emergency calls?
>
Section 7 describes fairness of feedback sent to different servers. This 
is different than prioritization of messages described in Section 12. 
For message prioritization, the main concern is about dropping messages 
with the least impact on performance. Fairness among uses is probably 
only a secondary concern.

> 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.
>
Yes. Changed from end user to call attempt.

> 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.
>
For leaky-bucket throttles there is a similar requirement if a server is 
assigned a higher load, e.g., because other servers have become 
inactive. I agree that the key requirement is that the mechanism stops 
rejecting calls if overload disappears.

> 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.
>
Changed the wording to align with 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.
>
I agree. The algorithm provided is a simple example. It is not intended 
to guarantee a specific 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.
>
The draft doesn't discuss fairness for any of the mechanisms in section 
9. In the end, basic fairness will be more natural for loss-based 
control, customized fairness based on a fixed call-per-seconds rate will 
be more natural for rate or window based controls.

Thanks!

Volker