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

From: <[email-masked]>
Date: Wed, 23 Jun 2010 18:01:13 +0100

Vijay, All,

Here are some comments on the draft.

1) The proposed mechanism limits traffic without regard for destination.
Network overloads can usually be classified into general overloads, and
focused overloads to a specific destination or a small number of related
destinations. General overload might be caused by everybody calling
family on 4th July, or a civil emergency, focused overload might be
caused by a ticket line opening for a huge sports event, or a TV vote.
In a general overload it's reasonable to restrict calls equally
(excepting emergency calls), as this proposed mechanism does. However in
a serious focused overload the traffic to the target destination is
usually far above destination capacity, and if this specific traffic can
be reduced near its source then the other users of the network can get
good service - actually without impacting service to the overloading
traffic, because its effective throughput is limited by destination
capacity for simultaneous calls, not network signalling capacity.
Although automated algorithms to identify focused overload are not fully
mature they are on the way. How easy would it be to extend the proposed
mechanism to support a restriction scheme which can discriminate by
destination? (Don't get me wrong - it would be great to have any
overload control scheme which works and is widely implemented, as this
proposal might be, but it would be even better to have one which works,
is widely deployed, *and* can easily support likely developments in load
control)

2) Section 1, Introduction. The Intro might say something about the
structure of the document, for example Section 6 is an informational
discussion of design considerations, but it's not mentioned here, even
though it justifies some of the decisions taken to arrive at the
normative material in Section 3 through Section 5.

3) Section 1, para 3, "...due to resource constraints." Could this be
clarified to "...due to control plane resource constraints." to reflect
discussion on the list?

4) (General) There's lack of consistency throughout on whether the new
parameters start with "oc-" or "oc_" (hyphen or underscore)

5) Section 3.1, paras 1 and 2. Para 1 has "A SIP server that supports
this specification MUST..." but para 2 has "A SIP server MUST...".
Presumably the text may mandate behaviour only for SIP servers which
support the specification, so the para 2 text seems appropriate. If it's
necessary to clarify that the specification applies only to SIP servers
which support it, should the para 1 style of text be used everywhere?

6) Section 3.1, i'm not a security expert but it seems insecure to rely
on the integrity of Via processing in servers downstream of the
immediate downstream server to provide a reliable return path for
oc-accept. Should the immediate downstream server instead detect the
presence of oc-accept in a request and hold the "oc capability" as state
against the upstream server? It's only in a request that the immediate
downstream server can be sure that the oc-accept actually originated
from the upstream server.

7) Section 3.2 para 4. "The default value of the 'oc_validity' parameter
is 500." This seems extremely short compared with the decay timescale of
most overloads. What happens for a server with high fan-in receiving
only a low calling rate per source, where gaps longer than 500ms may be
quite common? I would have thought it would be better to default to a
longer persistence of several seconds. Servers which know all their
sources send at high rates (so the restriction will be refreshed before
it expires) can always supply a shorter time if they wish. See also next
comment.

8) Section 3.2 para 4 "A SIP server SHOULD use a shorter 'oc_validity'
time if its overload status varies quickly" This seems unnecessary if
the value of oc is over-ridden by a subsequent value of oc received in a
later response.

9) Section 3.2 para 5, top of page 6, typo "...be different then the
ones..."

10) Section 3.2 para 5, top of p6, maybe use "...previous
transmissions..." rather than "...previous retransmissions..."?

11) Section 3.2 para 6 "server MAY forward the content  of an 'oc'
parameter..." This paragraph might be either too much or too little
guidance - there is a bigger design question over whether, and how, to
distribute restrictions upstream, and you've made a design choice to do
load control hop-by-hop. The use of Vias in the protocol mechanism
prevents forwarding by default, so presumably anyone who takes the
trouble to do copying would have to know what they are doing. This
paragraph seems to undermine your (simple and justifiable) design
choice.

12) Section 3.3 para 2. It should be clarified that any existing loss
percentage which has been communicated upstream needs to be taken into
account when calculating the new loss percentage to be communicated
upstream. For example if I'm 50% overloaded despite a current 'oc' of
40%, my next 'oc' should be 60% rather than 33%.

13) Section 3.3 para 2. "...by which the load forwarded to this SIP
server should be reduced." Why did you choose to send a percentage to be
dropped rather than the percentage to be admitted? Calculations based on
admitted fraction look simpler, e.g. I'm admitting 30% but I'm still
overloaded by factor 1.5, I should send out a new admitted fraction of
30/1.5=20. I guess this is just a matter of personal taste!

14) Section 3.3, "OPEN ISSUE" This issue could be fixed, in a way, with
a short informational section justifying the choice of the loss-based
scheme in preference to a rate-based or a window-based scheme.

15) Section 3.4 para 1 "...topmost Via header." Does this "topmost" need
definition? The topmost as received is the one the local server will
obey to determine the loss rate it applies (and will not be forwarded),
the topmost as transmitted is the one it will modify itself to inform
upstream servers of its own loss rate preference. I assume you mean the
topmost *outgoing* Via header going upstream, that is, topmost as
transmitted. But presumably a SIP entity should remove any oc and
oc-validity parameters *received* in this Via header? It wants to set
these values itself, not forward values inserted by a downstream entity
(which must be accidental or malicious).

16) Section 3.4 para 2 "...overwrites the 'oc' value" The "overwrites"
semantic (which is obviously correct) makes it unnecessary to use the
very short default oc-validity you propose in Section 3.2 above. I would
be much more worried about losing a restriction (because it wasn't
refreshed soon enough) than about allowing it to persist a little longer

17) Section 3.5, last para, "The SIP server SHOULD use the following
algorithm..." SHOULD is too strong when there may be better algorithms.
MAY would be better. For example there is a possible algorithm which
chooses whether to admit or reject based on which choice will leave it
closer to the target loss rate. Use of this can reduce burstiness in the
admitted stream, which may lead to lower mean delay at the overloaded
downstream server for a given mean CPU utilisation.

18) Section 3.5 last para "...may be used as well." Perhaps change to
"...may be used instead."?

19) Section 3.6 para 2. This appears to be an update to RFC 3261 for
servers which support this specification. Should it flagged as such? 

20) Section 4 para 1. "...sending some of the requests to a different
destination." This is not very clear. Does it mean that requests which
would have gone to the overloaded downstream server are classified into
two streams, those which are accepted and those which are rejected by
the throttle control? Then does it mean that accepted requests are sent
to the overloaded downstream server, whilst rejected requests become
candidates for sending to a different destination? If so this should be
made more explicit.

21) Section 4 para 1, "It needs to ensure, however, that this
destination is not in overload and capable of processing the extra
load." There is a close analogy between applying a throttle at an
upstream server to protect an overloaded downstream server, and
receiving a 503 for a request which was actually forwarded to the
downstream server. So I think this statement is correct but at odds (in
spirit) with the statement in RFC 3261 Section 21.5.4 "SHOULD attempt to
forward the request to an alternate server". Should this draft identify
that it updates RFC 3261?

22) Section 4 para 1, "An element can also buffer requests in the hope
that the overload condition will resolve quickly and the requests still
can be forwarded in time." As the buffered requests are played out, this
will lead to an increase in offered traffic above the mean level before
the oc was received. The overloaded device saying "I'm OK again, send me
everything you're getting" is not the same as saying "Send me everything
you're getting, and all that stuff you stored up as well."  So buffering
seems almost always a bad thing to do - and probably shouldn't be
recommended - at least for INVITEs.

23) Section 4 para 1, "...reject these requests." Extending the analogy
between "throttling at the upstream server to protect the overloaded
downstream server" and "receiving a 503 from the overloaded downstream
server", is it correct to say that the upstream server should reject
with a 500? This seems consistent with RFC 3261 Section 6. If so should
this be stated somewhere?

24) Section 4.1 para 1. This section should state unambiguously that on
receiving an 'oc' parameter, the upstream server should reject that
proportion of initial messages (implying immediate and delayed work for
the overloaded downstream server) - to be agreed but possibly including
INVITE, REGISTER, SUBSCRIBE, MESSAGE, NOTIFY.

25) Section 4.2, Rejecting Requests. Repeating my comment above about
the first paragraph of Section 4, there is also the question of the
behaviour of the upstream server when it rejects a request by
throttling. If the request had not been throttled it would have gone to
the overloaded downstream server and probably been rejected with 503. So
the upstream server "SHOULD attempt to forward the request to an
alternate server" according to RFC 3261 Section 21.5.4.  If it doesn't,
and instead rejects the request, Section 6 of RFC 3261 requires that the
upstream server sends 500 upstream. Do we want to update RFC 3261 with
the caution about forwarding to an alternate server if the first target
is in overload?

26) Section 4.2 para 1, need to make it clear that this paragraph refers
to the overloaded server and its internal overload control.

27) Section 4.2 para 1, "...rejects a request because of overload MUST
reject this request with a 503...". Is this an update to RFC 3261
Section 21.5.4, i.e. server is no longer allowed to "refuse the
connection or drop the request"?

28) Section 4.2 para 3, two instances of "100". Should these be "100%"?
Also the actual load at which a server should start rejecting requests
is design-dependent, may be configurable, and in some cases may be a lot
less than 100%. It would be better to say "...a load exceeding its
engineered capacity..."

29) Section 4.2 para 3, last sentence. Rejections due to internal
overload control at the start of an overload event, during transient
within the event, and possibly at a low background level throughout the
event, are likely and would be acceptable as part of a well-engineered
load control scheme - even if all upstream proxies fully implement the
control.

30) Section 6, Design  Considerations. It would be good if this section
also discussed the rationale for the choice of a loss-based rather than
a rate-based (Crawford or leaky-bucket) or a window-based control.
Clearly loss-based can be simple both at the servers and in protocol
terms, can act instantaneously, and can achieve basic fairness without
any need to estimate the distribution of offered traffic across
different upstream servers. However loss mechanisms have difficulty with
streams containing a large fraction of priority requests, or trading the
processing cost of one type of flow against another (for example INVITE
vs MESSAGE). Also it is more difficult to implement types of fairness
other than basic fairness with loss-based control.

31) Section 6.1.1 bullet 2, "...such as window based overload control."
Or loss-based!

32) Section 6.1.2 bullet 5, "...not suitable when frequent overload
control feedback is needed." Whether it's suitable is a matter of
degree, but the event-based mechanism is typically a good fit with
rate-based (preferably leaky-bucket) control which tends not to need
frequent updates, rather than a loss-based or a window-based control
which definitely do need frequent updates. If the update is less
frequent it may be that it can have richer semantics, for example it
might control multiple restrictors for different destinations.

33) Section 6 last para "...use 5xx  responses..." Section 4.2 says
specifically 503. Is there a reason to provide this different (less
specific) guidance here?

Hope this helps.

Best regards
Geoff