Subject: [Sipping] Re: draft-rosenberg-sipping-overload-reqs

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 8 Nov 2006 16:18:54 -0700

It would good if the overload control mechanism could be designed with
reporting in mind. That is, after the system has recovered from
overload, there is a common set of things that can be reported to
express the overload condition to a sysadmin:
"system x got blasted and turned the overload control mode ON at
<timestamp1>: x requests/responses received in z secs causing cpus to
jump to ... and y transactions to be NACKed; recovered to normal mode at
<timestamp2>"

I have not thought much about this and it may be orthogonal to the
mechanism that deals with overload but it'd be good if the mechanism
could help provide some useful feedback to users or operators to address
the root causes with a more precise view of the pb and oscillation.

Should there be a requirement that the overload mechanism should help
characterize the overload with a well known set of variables? 

Jean-Francois.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Darshan Bildikar" <[email-masked]>
Date: Thu, 9 Nov 2006 10:39:26 +0530

Hello Jonathan,

I have some questions/comments on your overload control draft. 

1) Section 4.1 - "How, a single request from the client, before timing out,
could generate as many as 18 requests and as many responses!"

You're probably going for "However" there? Also, I would appreciate if you
could clarify how the number of requests/responses could go up to 18. 

2) In figure 3, why the assumption that both proxies would try the same set
of servers? If P1 and P2 are being used purely for load balancing purposes
then what is the likelihood that they would route requests to the same set
of servers? 

3) REQ 7 states, "The mechanism shall provide a way for an element to
throttle the amount of traffic it receives from an upstream element. This
throttling shall be graded, so that it is not all or nothing as with the
current 503 mechanism.  This recognizes the fact that "overload" is not a
binary state, and there are degrees of overload."

Reading this line I draw the conclusion that the actual throttling (load
balancing) is done by the element or rather the up stream element (proxy). 

Wouldn't it be better rephrased--

"The mechanism shall provide a way for an element to indicate current load
parameters to an upstream element such that traffic to the element can be
suitably throttled. This throttling shall be graded, so that it is not all
or nothing as with the current 503 mechanism.  This recognizes the fact that
"overload" is not a binary state, and there are degrees of overload."

4) REQ 18 states, "The overload mechanism should be unambiguous about
whether a load indication applies to a specific IP address, host, or URI, so
that an upstream element can determine the load of the entity to which a
request is to be sent"

REQ 19 talks about specific SIP method types that might be desirable to
process in time of overload. 

There is also need for throttling based on service type. For example, a
server might host Prepaid and CRBT services and might wish to indicate loads
separately to proxies based on service type i.e. I cant handle prepaid calls
right now but I can handle CRBT. I would however assume that each service
would be invoked through a different URI. But is this a safe assumption to
make?

Also, throttling based on media would be useful. For example, a server might
wish to indicate that it cannot handle VIDEO and can only handle AUDIO for a
while. 

The examples above are not an exhaustive list. What I am trying to say is
that we need a more EXHAUSTIVE list of parameters based on which over load
control can be more "fine grained". 

Best regards,
Darshan

---

From: Volker Hilt <[email-masked]>
Date: Thu, 09 Nov 2006 10:47:27 -0800

> the root causes with a more precise view of the pb and oscillation.
Yes, I think that reporting overload information to a sysadmin is 
orthogonal to the actual overload control mechanism.

Both the overloaded entity and the upstream entity that receives an 
overload indication will have some information about the overload 
situation (e.g. when it occurred, which server was affected etc.). I'm 
not sure what else these entities would need (in particular what they 
would need from each other).

> characterize the overload with a well known set of variables? 
I think a question is who should report what and how much information is 
needed about the entity on the other end of overload control.

Volker