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

From: <[email-masked]>
Date: Mon, 7 Feb 2011 16:55:54 +0100

Two comments:

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. 

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.

Bruno

> -----Message d'origine-----
> De : [email-masked] [mailto:sip-overload-
> [email-masked]] De la part de Vijay K. Gurbani
> Envoyé : jeudi 20 janvier 2011 18:54
> À : [email-masked]
> Objet : [sip-overload] draft-ietf-soc-overload-control-01 submitted
> 
> Folks: Pursuant to our virtual meeting in December-1-2010 [1],
> an update to draft-ietf-soc-overload-control has been submitted
> [2].
> 
> There are some substantive changes that have been discussed on
> the mailing list.  These are:
> 
> 1) The need to support algorithm agility (i.e., negotiate different
>   overload control algorithms).  This discussion resulted in the
>   addition of the "oc-algo" parameter and is discussed in Sections 4.2
>   and 5 of the -01 draft. [2]
> 
> 2) The caveats of sending overload control parameters in a 100-
>   Trying.  This discussion is captured in Section 12 of [2].
> 
> 3) The relationship of SIP overload control mechanism with other
>   overload control mechanisms.  This discussion is captured in
>   Section 13.
> 
> 4) A new appendix (Appendix B) has been added that tracks the
>   requirements of RFC5390 and how they apply to this draft.
> 
> 5) Miscellaneous changes to aid in readability.
> 
> The diff between -00 and -01 is available in [3].
> 
> Please take a look at the new revision and provide comments on
> the mailing list.
> 
> [1] http://www.ietf.org/mail-archive/web/sip-
> overload/current/msg00498.html
> [2]
> http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-
> 01.txt
> [3]
> http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-
> soc-overload-control-00.txt&url2=http://www.ietf.org/id/draft-ietf-soc-
> overload-control-01.txt
> 
> Thank you,
> 
> - 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} / [email-masked]
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 07 Feb 2011 12:30:47 -0600

> 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

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 14:55:52 +0100

Hi Vijay,

See below

> De : Vijay K. Gurbani [mailto:[email-masked]]
> Envoyé : lundi 7 février 2011 19:31
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]
> Objet : Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted
> 

[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). 

> 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.

> all upstream neighbors are periodically served by server E to received

[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
> assumptions REQ-23 can be met even when the load balancer is not SIP-
[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.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 Feb 2011 07:55:39 -0600

On 02/08/2011 07:55 AM, [email-masked] wrote:
> [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).

Bruno: I see.  The thing that bothers me about this approach --- and I
readily subscribe to your assertion that this may happen in real
networks --- is that (a) we are essentially performing overload control
for AS-B two hops away, and (b) we are attempting to codify B2BUA
behaviour in the context of overload.

Even then, the proxy must have a filter so only those messages that
AS-A will send to AS-B will be quenched.  What is the nature of this
filter?  Is it prescribed anywhere?  Is loading this filter an
administrative task or will AS-A automatically send it to the proxy?
And if so, how?  These are all questions that arise in the context of
your scenario.  To what extent do we need to flesh these out if we go
this route?

> [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.

I agree; that is probably the best we can do.  Unless someone else has
any objections, I will update REQ-23 to read "Partial".

Thank you,

- vijay

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 17:37:40 +0100

> Envoyé : mardi 8 février 2011 14:56

[BC] That's a bit tricky indeed. I think I understand you point as well. May be we should just add a warning that filtering must be performed by the adjacent nodes or is this stated somewhere already?

---

From: Volker Hilt <[email-masked]>
Date: Tue, 8 Feb 2011 17:10:19 -0500

Bruno, Vijay,

please see inline.

>> it is best that AS-A assume the role of dampening messages towards
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…
If AS-A is not upgraded to support overload control, how would it 
forward the oc parameter?

> [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)

---

From: Volker Hilt <[email-masked]>
Date: Tue, 8 Feb 2011 17:25:01 -0500

> [BC] That's a bit tricky indeed. I think I understand you point as well. May be we should just add a warning that filtering must be performed by the adjacent nodes or is this stated somewhere alrea…
This is essentially going down the path of end-to-end overload control, 
which is discussed in the design considerations draft.

If AS-A is not updated to support overload control, it will drop the 
feedback from AS-B, which is exactly what it needs to do. If AS-A would 
blindly copy the feedback from AS-B to the proxy, it will throttle all 
traffic to AS-A even if that would not hit AS-B at all.

The proxy would have to be specifically updated to copy the oc 
parameter, which would be unwise to do. If an update is performed, it 
should be updated to support regular overload control.

Volker (as individual)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 09 Feb 2011 09:11:23 -0600

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

OK, this is more work for me then simply changing a "Yes" to "Partial".
But, I will go ahead and do so.  If we need more discussion around
this, we should hold it now before I update the draft and summarize
the current discussion ...

Thanks,

- vijay