Subject: Re: [sip-overload] Call for Consensus:draft-gurbani-soc-overload-control as wg item

From: <[email-masked]>
Date: Mon, 4 Oct 2010 18:09:25 +0200

Vijay,

1) Moving the contents of Section 7 would not really help. If this text is retained in the final version, I believe what is missing is the link with the rest of document. Something that explains why the response header solution has been selected, based on the characteristics listed in clause 7.1.1 and 7.1.2.

2) In case of a server farm, even with a round-robin approach, it would not really make sense to have the servers downstream from the load balancer sending their own individual feedback to the upstream SIP entities sending requests. The overload indication that these upstream servers should receive should be based on the load of the entire farm rather than the individual servers. Actually the individual servers do not need to send explicit feedback as the load balancer may have other means to evalaute their work load and derive a compound value. So it seems that for this mechanism (i.e. the one specified in this I-D) to work efficiently the load balancer MUST at least act as a stateless proxy and SIP responses have to go through it. If this is correct, then I believe this should be stated explictly as this means that the risk of overloading the load balancer itself is greater than if it was just working at the IP layer.

Bruno

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Vijay K. Gurbani
> Envoyé : mercredi 29 septembre 2010 21:43
> À : [email-masked]
> Objet : Re: [sip-overload] Call for 
> Consensus:draft-gurbani-soc-overload-control as wg item
> 
> Bruno: Thanks for your comments.  More inline.
> 
> On 09/28/2010 12:28 PM, [email-masked] wrote:
> > Before we take this document as a WG item I would like to make two
> > comments:
> >
> > 1) The document seems to be half-way between a 
> specification document 
> > and a discussion paper (e.g. section 7)
> 
> Section 7 provides some insight into the specific choice of 
> using the proposed explicit overload control feedback 
> mechanism.  I do not believe it distracts from the main 
> thrust of the paper, does it?  If you think so, we can look 
> into inserting the information in Section
> 7 elsewhere, but it seems to me that this information is 
> important background that should be retained.
> 
> > 2) It is unclear to me how the proposed mechanism works in 
> cases where 
> > there is a load balancer in front of a farm of proxies (i.e.
> > RFC5390 REQ23)
> 
> Unfortunately, this depends on the type of load balancer, and 
> I am not entirely sure that we have an authoritative answer 
> that will work with all manners of load balancers.
> 
> If the load balancer is non-adaptive and uses a simple 
> round-robin scheme to forward SIP requests, then the servers 
> downstream from the load balancer will continue to send their 
> own individual feedback to the upstream SIP entitiy sending 
> requests.  The reduction in the arrival rate of the traffic 
> coupled with the normal balancing of receiving only 1/N 
> requests should help the affected server in overcoming the 
> overload situation.
> 
> For a load balancer that is SIP aware, Section 6 of [1] 
> discusses the ramifications.  Here, the overload control 
> could be done either in the load balancer itself (with the 
> assumptions outlined in Section 6 of [1]), or each of the 
> individual servers can continue doing load balancing as normal.
> 
> [1] 
> http://tools.ietf.org/html/draft-ietf-soc-overload-design-01#section-6
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: Volker Hilt <[email-masked]>
Date: Thu, 7 Oct 2010 22:30:32 -0400

Bruno,
>
> 1) Moving the contents of Section 7 would not really help. If this
> text is retained in the final version, I believe what is missing is
> the link with the rest of document. Something that explains why the
> response header solution has been selected, based on the
> characteristics listed in clause 7.1.1 and 7.1.2.
>
I believe it is useful to keep discussions on design decisions in the 
draft. This will help an implementer to better understand the design 
choices made. I agree that text is needed to better tie this to the rest 
of the document.

> 2) In case of a server farm, even with a round-robin approach, it
> would not really make sense to have the servers downstream from the
> load balancer sending their own individual feedback to the upstream
> SIP entities sending requests. The overload indication that these
> upstream servers should receive should be based on the load of the
> entire farm rather than the individual servers. Actually the
> individual servers do not need to send explicit feedback as the load
> balancer may have other means to evalaute their work load and derive
> a compound value. So it seems that for this mechanism (i.e. the one
> specified in this I-D) to work efficiently the load balancer MUST at
> least act as a stateless proxy and SIP responses have to go through
> it. If this is correct, then I believe this should be stated
> explictly as this means that the risk of overloading the load
> balancer itself is greater than if it was just working at the IP
> layer.
>
I don't think it is critical that the load balancer is the entity that 
generates the feedback. If it does, it creates feedback on on behalf of 
the server farm. However, feedback can also be created by servers 
individually. In this case, the feedback should cover the load status of 
the server farm and not the individual server.

Thanks,

Volker

>> -----Message d'origine----- De : [email-masked]
>> [mailto:[email-masked]] De la part de Vijay K.
>> Gurbani Envoyé : mercredi 29 septembre 2010 21:43 À :
>> [email-masked] Objet : Re: [sip-overload] Call for
>>> Before we take this document as a WG item I would like to make
>>> two comments:
>>>
>> Section 7 provides some insight into the specific choice of using
>> the proposed explicit overload control feedback mechanism.  I do
>> not believe it distracts from the main thrust of the paper, does
>> it?  If you think so, we can look into inserting the information in
>> Section 7 elsewhere, but it seems to me that this information is
>> Unfortunately, this depends on the type of load balancer, and I am
>> not entirely sure that we have an authoritative answer that will
>> work with all manners of load balancers.
>>
>> If the load balancer is non-adaptive and uses a simple round-robin
>> scheme to forward SIP requests, then the servers downstream from
>> the load balancer will continue to send their own individual
>> feedback to the upstream SIP entitiy sending requests.  The
>> reduction in the arrival rate of the traffic coupled with the
>> normal balancing of receiving only 1/N requests should help the
>> affected server in overcoming the overload situation.
>>
>> For a load balancer that is SIP aware, Section 6 of [1] discusses
>> the ramifications.  Here, the overload control could be done either
>> in the load balancer itself (with the assumptions outlined in
>> Section 6 of [1]), or each of the individual servers can continue
>> doing load balancing as normal.
>>
>> [1]
Thanks,
>>
>> - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web:
>> http://ect.bell-labs.com/who/vkg/
>> _______________________________________________ sip-overload
>> mailing list [email-masked]
> _______________________________________________ sip-overload mailing
> list [email-masked]

---

From: <[email-masked]>
Date: Fri, 8 Oct 2010 08:43:06 +0200

> [mailto:[email-masked]] De la part de Volker Hilt
> Envoyé : vendredi 8 octobre 2010 04:31
> I believe it is useful to keep discussions on design 
> decisions in the draft. This will help an implementer to 
> better understand the design choices made. I agree that text 
> is needed to better tie this to the rest of the document.

=>BC: Fine
> > balancer may have other means to evalaute their work load 
> and derive a 
> > compound value. So it seems that for this mechanism (i.e. the one 
> > it. If this is correct, then I believe this should be 
> stated explictly 
> > as this means that the risk of overloading the load 
> balancer itself is 
> > greater than if it was just working at the IP layer.
> >
> I don't think it is critical that the load balancer is the 
> entity that generates the feedback. If it does, it creates 
> feedback on on behalf of the server farm. However, feedback 
> can also be created by servers individually. In this case, 
> the feedback should cover the load status of the server farm 
> and not the individual server.

==>BC: It sounds a bit uncommon for an individual server to be aware of the load status of the server farm. 

> >> Section 7 provides some insight into the specific choice 
> of using the 
> >> proposed explicit overload control feedback mechanism.  I do not 
> >> believe it distracts from the main thrust of the paper, 
> does it?  If 
> >> you think so, we can look into inserting the information 
> in Section 7 
> >> elsewhere, but it seems to me that this information is important 
> >> background that should be retained.
> >>
> >> not entirely sure that we have an authoritative answer 
> that will work 
> >> scheme to forward SIP requests, then the servers 
> downstream from the 
> >> load balancer will continue to send their own individual 
> feedback to 
> >> the upstream SIP entitiy sending requests.  The reduction in the 
> >> arrival rate of the traffic coupled with the normal balancing of 
> >> receiving only 1/N requests should help the affected server in 
> >> overcoming the overload situation.
> >>
> discusses the 
> >> ramifications.  Here, the overload control could be done either in 
> >> the load balancer itself (with the assumptions outlined in 
> Section 6 
> >> of [1]), or each of the individual servers can continue doing load 
> >> balancing as normal.
> >>
> >> [1]
> >> 
> >> - vijay -- Vijay K. Gurbani, Bell Laboratories, 
> Alcatel-Lucent 1960 
> sip-overload mailing 
> sip-overload mailing

---

From: Volker Hilt <[email-masked]>
Date: Fri, 8 Oct 2010 10:39:15 -0400

> ==>BC: It sounds a bit uncommon for an individual server to be aware of the load status of the server farm.
It is not necessary that all servers generate feedback - in the simplest 
case only one server reports the overall load.

Volker

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 11 Oct 2010 16:50:51 +0530

Volker/Bruno,
 
IMO, load balancer has to report its feedback value to the upstream server rather than the overall load of server farm in case of load balanacer scenario. The individual load balanacer report feedback to the upstream server will scale well for mesh network wherein the multiple load balancer exists to the upstream servers.
 
Thanks
Partha
 
________________________________

From: [email-masked] on behalf of Volker Hilt
Sent: Fri 10/8/2010 8:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sip-overload] Call for Consensus:draft-gurbani-soc-overload-control as wg item

Volker

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 16:53:24 +0200

Hi Partha,
 
What does the load balancer feedback value represent in this case? I still think that what should be reported to the upstream servers is the load of the server farm seen as a black box.
 
Bruno

De : Parthasarathi R (partr) [mailto:[email-masked]] 
Envoyé : lundi 11 octobre 2010 13:21
À : Volker Hilt; CHATRAS Bruno RD-CORE-ISS
Cc : [email-masked]
Objet : RE: [sip-overload] Call for Consensus:draft-gurbani-soc-overload-control as wg item

	Volker/Bruno,

	Thanks
	Partha

	
	Volker

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Mon, 11 Oct 2010 22:14:26 +0500

Yes agreed. But a blackbox view might create problems in some scenarios below.

Server farm consists of servers but they are divided into groups which cater to pretty different type of traffic. Say a group handle subscriptions and other handles messaging and other group handles INVITE e.g.  a server farm is divided into equiavalence classes.
Then overload for each type of class is a different.

Or this question presuppoes in a server farm all servers handles all types of traffic and they are just mirror images of each other?
If thats the case I think this is a restrictive definition of a "server farm"?

My take on this issue is to divide a server farms into equivalence classes and each equialence classes should report their status to upstream servers collectively/individually.
The key is how to divide a farm into equivalence classes. 
This can be implentation defined or standardized and knowledge of these classes should be available to upstream servers so they can calculate properly. 

Standard should support both collectively/indivudally. 

Regards,
Rahul

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: [email-masked]
Date: Monday, October 11, 2010 8:23 pm
Subject: Re: [sip-overload]	Call	for Consensus:draft-gurbani-soc-overload-control as wg item
To: [email-masked], [email-masked]
Cc: [email-masked]

> Hi Partha,
> 
> What does the load balancer feedback value represent in this case? 
> I still think that what should be reported to the upstream servers 
> is the load of the server farm seen as a black box.
> 
> Bruno
> 
> 	IMO, load balancer has to report its feedback value to the 
> upstream server rather than the overall load of server farm in 
> case of load balanacer scenario. The individual load balanacer 
> report feedback to the upstream server will scale well for mesh 
> network wherein the multiple load balancer exists to the upstream 
> servers.         
> 	Thanks
> 	Partha
>         
> 	>>> load balancer sending their own individual feedback to the 
> upstream	>>> SIP entities sending requests. The overload 
> indication that these
> 	>>> least act as a stateless proxy and SIP responses have to go 
> through	>>> it. If this is correct, then I believe this should be
> 	>> stated explictly
> 	> ==>BC: It sounds a bit uncommon for an individual server to be 
> aware of the load status of the server farm.
> 	>
> 	It is not necessary that all servers generate feedback - in the 
> simplest	case only one server reports the overall load.
> 	
> 	Volker
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	>>>> If the load balancer is non-adaptive and uses a simple round-
> robin	>>>> scheme to forward SIP requests, then the servers
> 	>> downstream from the
> 	>> http://tools.ietf.org/html/draft-ietf-soc-overload-design-
> 01#section-
> 	>>>> 6
> 	>>>>
> 	>>>>
> 	>>>>
> 	>> Thanks,
> 	>>>>

---

From: <[email-masked]>
Date: Mon, 11 Oct 2010 21:24:19 +0200

> De : RahulSrivastava 71616 [mailto:[email-masked]] 
> Envoyé : lundi 11 octobre 2010 19:14
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]; [email-masked]; 
> [email-masked]
> Server farm consists of servers but they are divided into 
> groups which cater to pretty different type of traffic. Say a 
> group handle subscriptions and other handles messaging and 
> other group handles INVITE e.g.  a server farm is divided 
> into equiavalence classes.

==>BC: This is correct but this problem exists even in the basic case of a single server. When there is a need to differentiate different classes of traffic, the clean answer is to use the second approach described in the SOC Charter: i.e. use filters to specify different rates for different SIP messages.

> 
> Or this question presuppoes in a server farm all servers 
> handles all types of traffic and they are just mirror images 
> of each other?

==>BC; This is indeed the type of architecture I had in mind. However an archictecture with specialized servers should not be precluded. In this case I believe that a filter-based approach is better but the approach described in the gurbani draft may be used as well if the load balancer is able to make a good estimation of the incoming traffic mix and use it to calculate a global restriction percentage.

> My take on this issue is to divide a server farms into 
> equivalence classes and each equialence classes should report 
> their status to upstream servers collectively/individually.
> This can be implentation defined or standardized and 
> knowledge of these classes should be available to upstream 
> servers so they can calculate properly. 
> 
>  This email and its attachments contain confidential 
> information from HUAWEI, which is intended only for the 
> person or entity whose address is listed above. Any use of 
> the information contained here in any way (including, but not 
> limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this email in 
> error, please notify the sender by phone or email immediately 
> and delete it!
>  
> Subject: Re: [sip-overload]	Call	for 
> > I still think that what should be reported to the upstream 
> servers is 
> > the load of the server farm seen as a black box.
> > 
> > Bruno
> > 
> Envoyé : lundi 
> > 11 octobre 2010 13:21 À : Volker Hilt; CHATRAS Bruno 
> RD-CORE-ISS Cc : 
> > [email-masked] Objet : RE: [sip-overload] Call for 
> > Consensus:draft-gurbani-soc- overload-control as wg item
> > 
> > 
> > 
> > 	Volker/Bruno,
> >         
> > 	IMO, load balancer has to report its feedback value to 
> the upstream 
> > server rather than the overall load of server farm in case of load 
> > balanacer scenario. The individual load balanacer report 
> feedback to 
> > the upstream server will scale well for mesh network wherein the 
> > multiple load balancer exists to the upstream
> > servers.         
> > 	Thanks
> > 	Partha
> >         
> > 	Subject: Re: [sip-overload] Call for 
> > 	>>> would not really make sense to have the servers 
> downstream from 
> > the
> > 	>>> upstream servers should receive should be based on 
> the load of 
> > the
> > 	>>>> Unfortunately, this depends on the type of load 
> balancer, and I 
> > am
> > 	>>>> ramifications.  Here, the overload control could 
> be done either 
> > in
> > 	>>>> of [1]), or each of the individual servers can 
> continue doing 
> > load
> > 	>>>> balancing as normal.
> > 	>>>>
> > 	>>>> [1]
> > 	>>>>

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Oct 2010 18:47:21 +0300

Hi there,

the call for consensus ran until October 3rd.
Based on the fact that nobody object we declare consensus on
the adoption of the draft as baseline for the second item we have in the 
SoC charter.

So I would ask the authors to submit a new version as wg item
(of course when it will be possible to submit a 00 version).

Volker and I want take the chance to highlight the fact
that the number of responses were low and for moving forward this wg,
we'd like to encourage everyone on the list to more actively provide 
feedback on calls.

ciao
Sal & Volker

On 9/20/10 6:50 PM, Salvatore Loreto wrote:
>
> Hi there,
>
>
> During the Maastricht meeting, we took a hum for consensus on
> adopting draft-gurbani-soc-overload-control as a WG item.
> The hum was inconclusive primarily because there were other
> documents in the agenda that we had not looked at yet.  Having
> gone through the other drafts, the summary and disposition of
> which is in the minutes (http://www.ietf.org/proceedings/78/minutes/soc.htm),
> we feel that it is it is time to check again for consensus to adopt
> draft-gurbani-soc-overload-control.
>
> Vijay submitted a new revision, version -02 on August 23rd (please see
> http://tools.ietf.org/id/draft-gurbani-soc-overload-control-02.txt)
> that addresses all the issues/comments regarding RPH, reducing the
> parameters, etc. that were raised during the f2f meeting.
>
>
> So, as chairs Volker and I want to check the consensus to adopt it as baseline
> for the wg item addressing the derivable number 2 in the charter:
>
> 2. A specification for an SIP overload control mechanism based on
>       implicit/explicit feedback.
>
>
> The consensus call will run until October 3rd, 2010.
>
>
> Ciao
> Salvatore and Volker
>
>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 21 Oct 2010 14:13:08 -0500

> (of course when it will be possible to submit a 00 version).

Sal: I will submit a -00 as soon after the Beijing IETF.

Thanks,

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