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

Jean-Francois Mule wrote:
> 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.
> 
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).

> Should there be a requirement that the overload mechanism should help
> 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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP