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

[Volker Hilt <[e-mail]>]

Bruno, Vijay,

please see inline.

>> -----Message d'origine-----
>> De : Vijay K. Gurbani [mailto:[e-mail]]
>> Envoyé : lundi 7 février 2011 19:31
>> À : CHATRAS Bruno RD-CORE-ISS
>> Cc : [e-mail]
>> Objet : Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted
>>
>> 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.
>
There is already text in the draft that says that AS-A can forward 
overload control feedback considering AS-Bs status if it knows that AS-B 
is the only server it forwards traffic to.

If AS-A forwards traffic to other destinations, generating overload 
feedback would be harmful as it would throttle traffic to these 
destinations as well as Vijay has pointed out. This will get us into the 
domain of multi-hop overload control, which is difficult.

> [BC] I was trying to find a solution for the case where the proxy has been upgraded to support filtering of messages but not AS-A. I believe this will frequently happen in real networks (e.g. AS-A is an old system hosting basic telephony applications for user A while AS-B is a new system hosting a new overload control sensitive application, the core network proxies are upgraded).
>
If AS-A is not upgraded to support overload control, how would it 
forward the oc parameter?

>>
>>> 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.
>
> [BC] They can do it if they have access to this information. However, in some cases they will be aware of their own load rather than the load of the virtual server.
>
>> 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."
>
> [BC] I agree. However this indeed requires that load distribution be configured in such a way that all upstream neighbors are periodically served by server E
>>
>> 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.
> [BC] I agree under certain assumptions REQ-23 can be met. That's why I think that "partial" is more suitable than "Yes". "Yes under certain assumptions" would be fine as well.
>
Vijay, Bruno, following the discussion above - I believe that REQ-23 can 
in fact be met for load balancers that are not SIP aware. Of course, 
there is always a way to build a system that does not work. But the key 
point is that this requirement can be met with the correct design.

My suggestion would be to document these approaches in the draft as this 
will be very relevant for implementers.

I think with this documentation, a "Yes" to REQ-23 is appropriate.

Thanks,

Volker (as individual)