Subject: [sip-overload] Comments on draft-hilt-sipping-overload-07

From: <[email-masked]>
Date: Tue, 15 Dec 2009 15:10:17 -0000

Hi Volker, All,

Here are some comments on the draft. I've also tried to assess the
proposal by estimating the compliance against the 23 requirements in RFC
5390, and this attempt at a compliance statement is at the end of this
post. I will send some comments on
draft-shen-sipping-load-control-event-package-03 in a separate post.

1) General. The informational design material in section 6 seems out of
place in this normative draft. If design is not final, would it be
better to have competing drafts describing differing candidate
approaches, and seek the community view?

2) General. There is no mention of the UDP retransmission problem in
overload and whether INVITE retransmission should be suppressed towards
an overloaded entity. Is it assumed that a reliable transport is used?

3) Introduction paragraph 2, text "does not have sufficient resources to
process all incoming SIP messages". Should this be qualified with a
statement about delay, for example "within a delay which does not cause
users to abandon and retry their session attempt"?

4) Section 3.1. The first paragraph of 3.1 specified addition of
oc_accept only to a SIP *request* towards downstream neighbours. The
second paragraph refers to removing an oc_accept before forwarding a
*response*. Is an oc_accept ever sent with a response?

5) Section 3.2, third paragraph. Section 3.1 was confusing over whether
oc_accept is in responses or only in requests. Does the text in Section
3.2 paragraph 3 mean that "oc" should be added to responses replying to
requests which contained an "oc_accept"? Or, is the text "A SIP server
SHOULD add an 'oc' parameter to responses, that contain an 'oc_accept'
parameter in the topmost Via header" literally true, that is, implying
that the *response* contains an oc_accept?

6) section 3.2 paragraph 4. text "The 'oc_validity' parameter defines
the time in milliseconds during which the content (i.e., the overload
control feedback) of the 'oc' parameter is valid ." What does the
upstream server do when the period of validity expires? 500 ms seems
very short if the semantics are to cease control - if the downstream
server wants to remove the control, it should send a new current value.

7) section 3.5 paragraph 1. "The SIP server MUST NOT forward more
messages to a SIP server than allowed by the current 'oc' parameter
value from this server." Whilst this statement has a meaning in the
context of a parameter controlling fractional loss, it doesn't have much
normative benefit in terms of load on the downstream server, given that
traffic offered to the control can vary by large factors and that
traffic admitted through the fractional-loss control will vary by the
same factor. The likely underlying requirement to stabilise load is more
easily met by a rate-based control such as a leaky bucket.

8) Section 3.5 paragraph 2, text "An alternative algorithm...
reject/redirect the first X of every 100...". The bursty arrival process
resulting from this algorithm will increase mean processing delay and
may lead to difficulty in estimating load at the overloaded server. It
should not be proposed.

9) Section 4 text "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". This seems dangerous - is any limit placed on the
amount of load which could be stored, and for how long, and how quickly
load is released if the overload is believed to have dissipated? I
favour a "SHOULD NOT" statement about such buffering. If a user wants to
initiate a session, they can always retry.

10) Section 4.2 paragraph 1 text "This response indicates...". 503 was
selected by the overloaded server because it knows that it is
overloaded, but it cannot be said that 503 "indicates" this to an
upstream server, because 503 is ambiguous.

11) Section 4.2 paragraph 2, text "The fraction of requests rejected
SHOULD be equivalent to the fraction of requests the upstream server
would reject/redirect if it did support this specification." This
appears to be an unrealistic objective. If the upstream server does not
support "oc" then the downstream server must bear the cost of rejecting
some session requests as well as the cost of processing other requests
to completion. It would be "fair" to devote the same amount of
processing at the overloaded server to the combination of rejection and
processing, as the overloaded server would devote to processing requests
from an "oc-compliant" upstream server.

12) Section 6.1.1 bullet 2, text " It also enables the use of overload
control mechanisms that use regular feedback such as window-based
overload control ." How is this true given that the semantics of "oc"
are defined specifically as a % loss fraction?

13) Section 6.1.2 bullet 2, text " However, these notifications do
generate additional traffic, which adds to the overall load ." True, but
the notification scheme does not require additional operations on call
request and response messages for every SIP call, which are required by
the scheme favoured in the draft, and the trade-off could go either way.

14) Section 6.1.2 bullet 5, text "As overload feedback is sent to all
senders in separate messages, this [event] mechanism is not suitable
when frequent  overload control feedback is needed." Whether this "not
suitable" statement is true depends on how frequently feedback is
needed, and the number of senders. For example a leaky-bucket based rate
control can greatly reduce the frequency at which overload control
feedback is needed, by bounding the rate at which upstream elements send
traffic downstream, independent of the rate of arrival of new traffic at
the upstream servers.

15) Section 6.1, last sentence, " This document defines a new Via header
field parameter for overload control ." This statement seems out of
context. Is it present to convey the message "We have rejected the event
package approach and we define instead a header field"? If so, it might
be better to state this explicitly.

Estimated compliance against 23 requirements of RFC 5390:

R1.	Design would not prevent an OLC algorithm from meeting Req #1.
R2.	Design allows Req #2 to be met - including 3.6 on self-limiting
behaviour in the absence of responses from downstream
R3.	Use of proportional scheme minimises configuration but would not
prevent use, e.g. with configuration to implement a custom fairness
scheme.
R4.	Design covers behaviours in networks containing a mixture of
compliant and non-compliant servers.
R5.	Design includes schemes for dealing with non-compliant or
malicious elements, although proportional control scheme makes it
slightly harder to determine whether an element is complying
R6.	Overload of the server is signalled with a specific message
(header), however the 503 response is still used in response to
individual session requests and is not augmented to reduce the current
ambiguity.
R7.	Graded throttling, compliant
R8.	Retrying, or not, on another element is nodal behaviour, but the
draft recommends that the upstream node should not retry at an
overloaded alternative
R9.	Retrying on another element which is not overloaded is not
prevented by the design
R10.	Design does not cover servers receiving requests from a very
large number of upstream devices, e.g. UAs.
R11.	Design covers servers receiving requests from finite set of
upstream elements
R12.	Design supports control between domains
R13.	The design does not limit nodal behaviours to respect priority
R14.	The mechanism does not provide explicit guidance on when to
retry TCP connection establishment or SIP registration
R15.	The mechanism suggests behaviours to deal with downstream
servers which are broken or isolated
R16.	Given the design choice to include overload information in every
message, the mechanism is fairly lightweight. The alternative of
providing overload control information in parallel, and only as often as
required, is explicitly rejected
R17.	The mechanism probably assists in reducing the impact of DDoS
attacks by throttling traffic close to source and maintaining some
session processing capability in network regions away from the source,
unless the attack is widespread and focused. It's suggested that
fraudulent use of the mechanism may be avoided by use of TLS.
R18.	The mechanism does not state explicitly whether the overload
indication applies to an IP address, host or URI, so an upstream host
may not be able to determine a level at which it should retry. Instead
the indication is hop-by-hop. See also comment re req 23.
R19.	This protocol design does not give guidance on which message
types should be given priority in processing during overload.
R20.	In a mixed environment of elements which do and don't implement
the mechanism, local rejection can prevent disproportionate benefit
accruing to elements which do not implement the mechanism. However local
rejection is more costly than remote rejection so overall throughput
will be reduced by having elements in the network which do not support
the mechanism.
R21.	The mechanism could be used in an overload control mechanism
which, overall, is stable - though the draft does not provide guidance
on algorithms which could achieve this.
R22.	It would be possible to implement a node which could be
configured not to send load information to certain upstream sources
R23.	The mechanism as defined is hop-by-hop so care would be needed
with a load-balancer which is itself not overloaded in front of a farm
of proxies all of which are overloaded. The load balancer should send
control information upstream if, and only if, all of its server farm are
fully loaded. The load balancer should ensure that requests are
forwarded to an individual server in the farm only if the load balancer
expects that the server has sufficient resource to process the request
to completion.

Hope this helps.

Geoff Hunt
BT Design

Tel: 01473 651704
Email: [email-masked]
Web: www.bt.com 
This email contains BT information, which may be privileged or
confidential.
It is meant only for the individual(s) or entity named above. If you are
not the intended
recipient, note that disclosing, copying, distributing or using this
information
is prohibited. If you have received this email in error, please let me
know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000