Subject: [sip-overload] Review of draft-hilt-sipping-overload-07

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 1 Dec 2009 14:17:10 -0500

Overall the draft is in pretty good shape and I hope it can move forward
quickly. It is needed :-)

A few comments/questions:

1) Why is there a need to remove oc_accept from the topmost Via header.
Wouldn't that Via header be removed by the next-hop upstream element
(which has inserted this Via header together with oc_accept)? 

2) What are the exact semantics for oc_validity? For example if an
element receives a response with oc_validity=1000, is it supposed to
ignore the oc values in responses received during the next 1000ms?

3) It could be useful to mention that with retransmissions of the
response an oc value consistent with the overload condition at the time
of retransmission must be used.

4) Forwarding oc parameter: Even mentioning this sounds a bit risky to
me. If some text is seen as necessary, I would prefer something like:
"An element may consider the oc parameter values it received from
downstream elements, when deciding for the oc parameter value it is
going to send to its upstream neighbors. This, for example, could be
meaningful in cases where an element knows that all traffic to the
downstream elements in questions flow through itself."

5) About the OPEN ISSUE: I think it is important to agree on a single
way of communicating overload information for the sake of better
interoperability. I think loss ratio is a good choice (considering also
design issues).

6) oc parameter value is used in a way where it is applied to all
requests. Dropping a percentage of dialogue initiating requests could be
a more useful semantic. This requires that oc parameter is
generated/consumed with this new meaning. Has this been already
considered?

7) It may be too aggressive to stop traffic with a single timeout error.
It may be best not to specify how many timeout errors should cause
stopping traffic.

8) According to RFC3261 503 without Retry-After needs to be handled as
500 Server Error. I just wanted to pint this out as for upstream
elements, which don't support the overload control mechanism defined in
this draft, this will be the effective response code. I think the
rationale behind not using Retry-After is to prevent oscillation but I
don't know what the behavior is going to be with 500.

9) It could be nice to say a few words about servers being careful about
preventing oscillation when calculating oc values. I am not really
looking for an exact algorithm but just pointing this out explicitly.

10) I also want to add that I share the concerns listed in the draft
about using an event package.

Thanks,
Tolga