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

From: Salvatore Loreto <[email-masked]>
Date: Mon, 20 Sep 2010 17:50:28 +0200

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

-- 
Salvatore Loreto
www.sloreto.com

---

From: <[email-masked]>
Date: Mon, 20 Sep 2010 18:03:19 +0200

Hi,

Is it a correct understanding that the solution described in draft-shen-soc-load-control-event-package-00 addresses deliverable 3 "A specification for a SIP load filtering mechanism" and therefore accepting draft-gurbani-soc-overload-control as a working group item does not imply the former cannot become a working group item as well?

Bruno 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Salvatore Loreto
> Envoyé : lundi 20 septembre 2010 17:50
> À : [email-masked]
> Cc : Volker Hilt
> Objet : [sip-overload] Call for 
> Consensus:draft-gurbani-soc-overload-control as wg item
> 
> 
> 
> Hi there,
> 
> 
> 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.
> 
> 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:
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 20 Sep 2010 14:59:32 -0400

Bruno,

yes, this is correct.

Volker

On 9/20/2010 12:03 PM, [email-masked] wrote:
> Hi,
>
> Is it a correct understanding that the solution described in
> draft-shen-soc-load-control-event-package-00 addresses deliverable 3
> "A specification for a SIP load filtering mechanism" and therefore
> accepting draft-gurbani-soc-overload-control as a working group item
> does not imply the former cannot become a working group item as
> well?
>
> Bruno
>
>> -----Message d'origine----- De : [email-masked]
>> [mailto:[email-masked]] De la part de Salvatore
>> Loreto Envoyé : lundi 20 septembre 2010 17:50 À :
>> [email-masked] Cc : Volker Hilt Objet : [sip-overload] Call
>> for Consensus:draft-gurbani-soc-overload-control as wg item
>>
>>
>>
>> Hi there,
>>
>>
>> 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
>> 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:
>>
>> Ciao Salvatore and Volker
>>
>>
>>
>> -- Salvatore Loreto www.sloreto.com
>>
>> _______________________________________________ sip-overload
>> mailing list [email-masked]

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 20 Sep 2010 15:15:10 -0400

I am conditionally  in favor of making draft-gurbani-soc-overload-control 
a WG item.

However, as noted in my message on Sept 3, I am concerned about linking 
the syntax so closely to the specific  method. 

The design document says:
" With many 
   different overload control algorithms available, it seems reasonable 
   to suggest a baseline algorithm in a specification for a SIP overload 
   control mechanism and allow the use of other algorithms if they 
   provide the same protocol semantics."

The Gurbani document does not seem to acknowledge  this.

While the Gurbani document acknowledges  the existence of rate based 
(rather than loss based) mechanisms, it appears to dismiss them.
"While it would in theory be possible to allow multiple types of
      overload control feedback to co-exist (e.g., by using different
      parameters for the different feedback types) it is very
      problematic for interoperability purposes and would require SIP
      servers to implement multiple overload control mechanisms."

If accepting the Gurbani document as a WG item precludes WG acceptance of 
rate based mechanisms, then I am opposed. 

If accepting the Gurbani document as a WG item permits rate based 
mechanisms (either in Gurbani, or in other WG docs), then I am in favor.

Janet

[email-masked] wrote on 09/20/2010 11:50:28 AM:

> [image removed] 
> 
> [sip-overload] Call for Consensus: draft-gurbani-soc-overload-
> control as wg item
> 
> Salvatore Loreto 
> 
> to:
> 
> [email-masked]
> 
> 09/20/2010 11:50 AM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> Volker Hilt
> 
> 
> 
> Hi there,
> 
> 
> which is in the minutes (
http://www.ietf.org/proceedings/78/minutes/soc.htm),

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 20 Sep 2010 14:42:34 -0500

> the syntax so closely to the specific method.
[...]
> If accepting the Gurbani document as a WG item precludes WG acceptance
> of rate based mechanisms, then I am opposed.
>

Janet: The intent is not to preclude other mechanisms, but rather
to ensure that there is at least a common denominator for inter-
operability.

I did note your message of Sept. 3, and I must confess that I do
not have an answer towards a canonical syntax that will support multiple
approaches.  But, assuming that the draft is chosen as a WG item,
then it becomes the collective responsibility of the working group
to ensure that this is indeed the case.

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/

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 20 Sep 2010 16:12:32 -0400

So I guess the question is 
"Should 'loss based' be the 'common denominator for inter- operability'?"

As long as that question remains open, then I support making it a working 
group item.

Janet

[email-masked] wrote on 09/20/2010 03:42:34 PM:

> [image removed] 
> 
> Re: [sip-overload] Call for Consensus: draft-gurbani-soc-overload-
> control as wg item
> 
> Vijay K. Gurbani 
> 
> to:
> 
> sip-overload
> 
> 09/20/2010 03:41 PM
> 
> Sent by:
>

---

From: <[email-masked]>
Date: Tue, 28 Sep 2010 19:28:34 +0200

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)

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)

Bruno

> De : Volker Hilt [mailto:[email-masked]] 
> Envoyé : lundi 20 septembre 2010 21:00
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> Objet : Re: [sip-overload] Call for 
> > does not imply the former cannot become a working group 
> item as well?
> >
> > Bruno
> >
> >> Envoyé : lundi 20 septembre 2010 17:50 À :
> 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 
> adopt it as 
> >> baseline for the wg item addressing the derivable number 2 in the 
> >> charter:
> >>
> sip-overload mailing 
> >> list [email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 29 Sep 2010 14:43:11 -0500

Bruno: Thanks for your comments.  More inline.

> 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