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

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP