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

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Fri, 10 Dec 2010 10:39:24 -0500

Vijay,

A few comments on draft-ietf-soc-overload-control-00 below. I tried to go over past comments to ensure no duplication, if such
cases arise please accept my apologies.

Thanks,

Eric

====================================

(1) Should the SIP client respond with an ack in Via parameter in response to "oc-validity" and "oc-seq"?
This would make it possible to catch failure scenarios where SIP client received message but failed to read oc parameter.
Note that there is already an implicit ack to "oc support", namely "oc value". Perhaps this is not needed as Via parameter already
include such a mechanism(?)

(2) There have been already several discussions on the need to support multiple overload control algorithms, if so, other
 algorithms may require more than 1 parameter. Hence, in addition of different overload control algorithms, I would suggest
to allow for multiple parameters in "oc value" (do not have good example though).

(3) In addition of having "oc-validity" be ignored when received without accompanying "oc" parameter, should not any "oc" parameters
by ignored by SIP clients if it did not send "oc support" in the first place? (corner case)

(4) Should not there be some  "oc-refresh" capability that would make it possible for servers to force clients to send "oc support" regularly
(clearly not too often). This would be catch failures/out of synch situations or unknown corner cases.

(5) In section 4.5, should not you be more specific when leaving it up to local policies to chose what messages get rejected. For instance,
it  may good to mention (though obvious) any messages that create "new work" should be rejected in favor of messages that end "existing work".

(6) In section 5, should not you require oc-validity to be at least as long as the SIP client + SIP server maximum queueing delay?

(7) When I read section 5.2, I interpret fairness as load balancing. Moreover, it is unclear to me that if a server  does not support any
 overload control, it should basically receive the same load as servers that support overload control (carried plus rejected). What if the servers
 have different capacities or routing of messages result in non uniform load across servers?

(8) In section 7.1.2, I always worry of restarts that could trigger NOTIFY storms. There should be a mechanism to stagger NOTIFY's so as to prevent
storms.

======================================