Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted

["Vijay K. Gurbani" <[e-mail]>]

On 02/07/2011 09:55 AM, [e-mail] wrote:
> Two comments:

Bruno: Thank you for a close read.  More inline.

> 1) I think we need to say something about the interactions between
> this mechanism and B2BUAs. The configuration I have in mind is the
> following: INVITE requests from multiple end user devices are
> received by a proxy server which forwards them to a first Application
> Server (AS-A) acting as a B2BUA which in turn forwards it to another
> Application Server (AS-B). In case AS-B is overloaded, it makes sense
> to expect the proxy server to drop a percentage of new incoming
> requests based on the oc value rather than to rely on AS-A to do
> that. However, this requires AS-A to copy this parameter from one
> B2BUA side to the other.

This is an interesting case, but I remain unsure on the need to
specify the behaviour of a B2BUA in the draft with respect to
overload control.  Clearly, if AS-B is overloaded, then its
direct upstream neighbour (AS-A) should perform overload control
for request destined to AS-B.

With the suggested model of AS-A copying the overload control
parameters from AS-B, the proxy is performing overload control
for AS-B by reducing all messages going to AS-A, even those
messages that AS-A will not send to AS-B!  For this reason, I think
it is best that AS-A assume the role of dampening messages towards
AS-B.

> 2) On new appendix B: I think Req23 should be changed from Yes to
> Partially. My understanding of the discussion we had on the list is
> that there are configurations where the requirement is hard to meet
> if the load balancer is not SIP-aware.

I am happy to change REQ-23 from "Yes" to "Partial", but I'd like to
have some discussion on this.

Those load balancers that are not SIP-aware will do load
balancing based on (say) destination IP address and destination
port number.  They may also remember the source IP address and
source port number and create a tuple
{src-ip, src-port, dest-ip, dest-port} when the first message from
src-ip:src-port goes to dest-ip:dest-port and use the tuple for
subsequent messages from src-ip:src-port.

Now, such a SIP-unaware load balancer may operate on feedback from
its downstream server or it may operate without any feedback.  If such
a SIP-unaware load balancer receives some feedback from its downstream
server, it may load a policy that reduces traffic going to that down-
stream server.  So it seems that a SIP-unaware load balancer that
receives feedback from its downstream server may work as per REQ-23.
However, if the SIP server downstream from the load balancer supports
overload control, then it may get two treatments of reduced traffic:
one from the load balancer and one from the upstream SIP server (up-
stream of the load balancer as well).

A SIP-unware load balancer that does not receive any feedback at all
from its downstream SIP server will not reduce traffic and it will
continue to send traffic to the downstream server that matches the
tuple (and it will create a new tuple when a new src-ip:src-port
presents itself).  However, the SIP server upstream of the load
balancer will still dampen requests going downstream, so maybe all
is well.

Furthermore, to quote from [1], "...If the load balancer is not a
SIP entity, servers D, E, and F can report the overall load of the
server farm (i.e., the load of the virtual server) in their messages.
As an alternative, one of the servers (e.g., server E) can report
overload on behalf of the server farm.  In this case, not all messages
contain overload control information and it needs to be ensured that
all upstream neighbors are periodically served by server E to received
updated information."

To be frank, there is so much latitude in how a SIP server can
operate when the load balancer is not a SIP-aware entity that I
confess in being unable to articulate a coherent architecture on how
to meet this requirement.  It seems to me that under certain
assumptions REQ-23 can be met even when the load balancer is not SIP-
aware.

Thank you much for continuing to explore the issues around load
balancing.

Thoughts?

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/