Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item

From: Salvatore Loreto <[email-masked]>
Date: Mon, 10 Jan 2011 16:18:25 +0100

Hi there,

so far we have received just two replies to this call,
both in favor to adopt it.

To take in consideration the fact that the call was almost in coincidence
with the Christmas vacations,

we have decided to extend it until this Friday, January 14th.

cheers
/Sal

On 12/15/10 4:51 PM, Salvatore Loreto wrote:
> Hi folks,
>
> during the last Interim (Interim II) on December 1st,
> Charles Shen presented the draft-shen-soc-load-control-event-package
> and asked about the possibility to adopt it as wg item,
> due to the comments received during the presentation we decided to wait
> for a new version before to check in the mailing list the consensus to
> adopt it.
>
> Charles has posted a new version of the draft
> ( http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt )
> addressing the comments from the Interim
> (see in the Interim minutes:
> http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/Interim20101201/notes.txt
> )
> and also other previous comments received in the mailing list.
>
> It is time to check in the ml the consensus to adopt the
> draft-shen-soc-load-control-event-package as wg item.
>
> So, as chairs Volker and I want to check the consensus to adopt it as
> baseline for the wg item
> addressing the derivable number 3 in the charter:
>
>     Aug 2011 - Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard
>
>
> This consensus call will end on Friday January 7th, 2010.
>
> cheers
> /Sal

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 10 Jan 2011 11:43:53 -0500

Yes, I am in favor of adopting this as a working group item.  I do not 
necessarily agree with all the text in section 9- but it is there which 
was my main concern.  We can work on refining those details later

Janet

[email-masked] wrote on 01/10/2011 10:18:25 AM:

> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-
> event-package as wg item
> Salvatore Loreto 
> to: sip-overload
> 01/10/2011 10:19 AM
> Sent by: [email-masked]
> 
> Hi there,
> 
> > ( 
http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt )
> >     Aug 2011 - Specification for a SIP load filtering mechaism to 
> IESG for publication as Proposed Standard
> >
> >
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 10 Jan 2011 13:11:01 -0600

> we have decided to extend it until this Friday, January 14th.

Sal, Charles: I support the adoption of this work as a WG item for
"A specification for a SIP load filtering mechanism."

I do have one observation, the importance of which did not
quite strike me until I read the draft: it appears that the
filtering mechanism will also impact a core proxy.  Thus, the
core proxy must be prepared to handle the explicit overload
control mechanism as well as the filtering mechanism.

Is it the intent to mandate the support of both algorithms?
Are we going to put tacit support for one algorithm in the
other?  In other words, consider CPa1 and CPb1 in Figure
1 of the draft. Can CPb1 ask CPa1 to perform overload
control based on [1] and later upload a filter criteria
based on [2]?  I suspect from S8.2 of [2] that the answer
is yes ... however, right now, [1] is silent on [2].

[1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-00
[2] http://tools.ietf.org/html/draft-shen-soc-load-control-event-package-02

Thanks,

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

---

From: Charles Shen <[email-masked]>
Date: Mon, 10 Jan 2011 15:23:50 -0500

Thanks Janet. Will be happy to work together on more details of your concern.

Charles

On Mon, Jan 10, 2011 at 11:43 AM, Janet P Gunn <[email-masked]> wrote:
> necessarily agree with all the text in section 9- but it is there which was
> my main concern.  We can work on refining those details later
>
> Janet
>

---

From: Charles Shen <[email-masked]>
Date: Mon, 10 Jan 2011 15:29:20 -0500

Hi Vijay, I agree with you and I think it will be beneficial that the
possible interaction between [1] and [2] is explicitly laid out in
both documents.

Thanks

Charles

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 11 Jan 2011 17:30:21 -0500

OK, here are my comments on sec 9.  My proposed new text  in italics 
inside [  ]
As far as I am concerned, there is nothing fatally wrong with saying "No" 
when it doesn't meet a specific requirement.  It just means that it must 
or should be used in conjunction with other mechanisms that DO meet that 
requirement.

Here is my first cut at it.

...
Therefore, we categorize the assessment    results into Yes (meet the 
requirement), P/A (partially applicable),[ No (must be used in conjunction 
with another mechanism to meet this requirement)],   and N/A (not 
applicable)
...
REQ 1: The overload mechanism shall strive to maintain the overall
      useful throughput (taking into consideration the quality-of-
      service needs of the using applications) of a SIP server at
      reasonable levels, even when the incoming load on the network is
      far in excess of its capacity.  The overall throughput under load
      is the ultimate measure of the value of an overload control
      mechanism.

  JPG - delete this - Yes. The goal of the load filtering control is to 
prevent overload or
   maintain overall goodput during the time of overload, especially when
   the overload contexts (e.g., time, scope) are known in advance.

JPG add this instead [P/A. The goal of the load filtering control is to 
prevent overload or  maintain overall goodput during the time of overload, 
but it is dependent on the advance predictions of the load. If the 
predictions are incorrect, in either direction, the mechanism will 
throttle too much or too little.]

REQ 2 OK

      REQ 3: The mechanism should seek to minimize the amount of
      configuration required in order to work.  For example, it is
      better to avoid needing to configure a server with its SIP message
      throughput, as these kinds of quantities are hard to determine.

    JPG - delete this - P/A. Since a main purpose of the load filtering 
control approach is
   to provision the appropriate capacity with advanced knowledge,
   configuration cannot be entirely avoided, although minimizing the
   configuration efforts is still desired.

JPG add this instead [ No.  This mechanism is entirely dependent on 
advance configuration, based on advance knowledge.  In order to satisfy 
Req 3, it should be used in conjunction with other mechanisms which are 
not based on advance configuration. ]

      REQ 4: The mechanism must be capable of dealing with elements that
      do not support it, so that a network can consist of a mix of
      elements that do and don't support it.  In other words, the
      mechanism should not work only in environments where all elements
      support it.  It is reasonable to assume that it works better in
      such environments, of course.  Ideally, there should be
      incremental improvements in overall network throughput as
      increasing numbers of elements in the network support the
      mechanism.

  JPG - delete this -  Yes. Servers need to be prepared to work in 
environments where not
   all the upstream neighbors support this load control event package as
   discussed in Section 4.4.

 JPG add this instead [ No. This mechanism is entirely dependent on the 
participation of all possible neighbors.  In order to satisfy Req 4, it 
should be used in conjunction with other mechanisms, some of which are 
described in section 4.4. ]

      REQ 5: The mechanism should not assume that it will only be
      deployed in environments with completely trusted elements.  It
      should seek to operate as effectively as possible in environments
      where other elements are malicious; this includes preventing
      malicious elements from obtaining more than a fair share of
      service.

    JPG - delete this -   Yes. Servers need to be prepared to work in 
environments where not
   all the upstream neighbors conform to this load control event package
   as discussed in Section 4.4.

 JPG add this instead [No. This  mechanism is entirely dependent on the 
non-malicious  participation of all possible neighbors.  In order to 
satisfy Req 5, it should be used in conjunction with other mechanisms, 
some of which are described in section 4.4.]

      REQ 6: When overload is signaled by means of a specific message,
      the message must clearly indicate that it is being sent because of
      overload, as opposed to other, non overload-based failure
      conditions.  This requirement is meant to avoid some of the
      problems that have arisen from the reuse of the 503 response code
      for multiple purposes.  Of course, overload is also signaled by
      lack of response to requests.  This requirement applies only to
      explicit overload signals.

    JPG - delete this -     Yes. The event package defined in this 
document is specifically for
   filter-based overload control.

 JPG add this instead [ N/A.  This mechanism signals anticipated overload, 
not actual overload.  However the signals in this mechanism are not used 
for any other purpose. ]

REQ 7 OK
REQ 8 OK
REQ 9 OK

      REQ 10: The mechanism should support servers that receive requests
      from a large number of different upstream elements, where the set
      of upstream elements is not enumerable.

 JPG - delete this -      P/A: the load filtering control is mainly for 
cases with advanced
   overload contexts and for scenarios with a relatively good knowledge
   of the upstream entities (e.g., core proxy and edge proxy servers)
   where the filters can be installed.  When the set of upstream
   elements is not enumerable, it is expected that the mechanism may be
   more difficult to apply.

 JPG add this instead  [ No.  Because this mechanism requires advance 
configuration of  specific identified neighbors, it does not support 
environments where the number and identity of the upstream neighbors are 
not known in advance.  In order to satisfy Req 10, it should be used in 
conjunction with other mechanisms.]

REQ 11 OK
REQ 12 OK

      REQ 13: The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment, such as not being dropped, being given additional
      retransmission, or being processed ahead of others.

   JPG - delete this -    Yes. Local policies such as honoring RPH are 
specified.

 JPG add this instead [ P/A.  This mechanism does not specifically address 
the prioritizing of work during times of overload.  But is does not 
preclude any particular local policy.]

REQ 14 OK

      REQ 15: In cases where a network element fails, is so overloaded
      that it cannot process messages, or cannot communicate due to a
      network failure or network partition, it will not be able to
      provide explicit indications of the nature of the failure or its
      levels of congestion.  The mechanism must properly function in
      these cases.

     JPG - delete this -    Yes. When the filters are provisioned in 
advance, they do not rely on
   explicit overload feedback indication.

 JPG add this instead [ P/A  Because the filters are provisioned in 
advance, they are not affected by the overload or failure of other nodes. 
But, on the other hand, they may not, in those cases, be able to protect 
the overloaded node (see Req 1) ]

REQ 16 OK

      REQ 17: The overload mechanism must not provide an avenue for
      malicious attack, including DoS and DDoS attacks.

    JPG - delete this -      Yes. Security considerations are discussed, 
in particular, accepted
   filters must be authenticated and authorized.

 JPG add this instead [ P/A. This mechanism does provide a potential 
avenue for malicious attacks, Therefore the security mechanisms for SIP 
event packages in general [RFC3265] and of section 10 of this document 
SHOULD be used.  ]

REQ 18 OK
REQ 19 OK

      REQ 20: In a mixed environment of elements that do and do not
      implement the overload mechanism, no disproportionate benefit
      shall accrue to the users or operators of the elements that do not
      implement the mechanism.

  JPG - delete this -       Yes. For example, an example approach to 
ensure fair server resource
   allocation in an environment with both conforming and non-conforming
   entities is discussed in Section 4.4.

 JPG add this instead [ No. This mechanism is entirely dependent on the 
participation of all possible neighbors.  In order to satisfy Req 20, it 
should be used in conjunction with other mechanisms, some of which are 
described in section 4.4. ]

REQ 21 OK
REQ 22 OK
REQ 23 OK

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

From:
Charles Shen <[email-masked]>
To:
Janet P Gunn/USA/CSC@CSC
Cc:
Salvatore Loreto <[email-masked]>, 
[email-masked], [email-masked]
Date:
01/10/2011 03:23 PM
Subject:
Re: [sip-overload] Call for Consensus: 
draft-shen-soc-load-control-event-package as wg item

Thanks Janet. Will be happy to work together on more details of your 
concern.

Charles

> necessarily agree with all the text in section 9- but it is there which 
was

---

From: Charles Shen <[email-masked]>
Date: Thu, 13 Jan 2011 09:46:45 -0500

Hi Janet,

Thanks for your comments! I have absolutely no problem adding "No" as one of
the assessment results to the requirements that are not met. I will
incorporate your suggested revision in the next update.

Thanks

Charles

On Tue, Jan 11, 2011 at 5:30 PM, Janet P Gunn <[email-masked]> wrote:

>
> OK, here are my comments on sec 9.  My proposed new text  in italics inside
> [  ]
> when it doesn't meet a specific requirement.  It just means that it must or
> should be used in conjunction with other mechanisms that DO meet that
> requirement.
>
> requirement), P/A (partially applicable),[ *No (must be used in
> conjunction with another mechanism to meet this requirement)*],   and N/A
> (not applicable)
> ...
> JPG add this instead [*P/A. The goal of the load filtering control is to
> predictions are incorrect, in either direction, the mechanism will throttle
> too much or too little.*]
>
> REQ 2 OK
>
> JPG add this instead [ *No.  This mechanism is entirely dependent on
> advance configuration, based on advance knowledge.  In order to satisfy  Req
> 3, it should be used in conjunction with other mechanisms which are not
> based on advance configuration.* ]
>
>  JPG add this instead [ *No. This mechanism is entirely dependent on the
> described in section 4.4.* ]
>
>  JPG add this instead [*No. This  mechanism is entirely dependent on the
> non-malicious  participation of all possible neighbors.  In order to satisfy
> Req 5, it should be used in conjunction with other mechanisms, some of which
> are described in section 4.4.*]
>
>     JPG - delete this -     Yes. The event package defined in this document
> is specifically for
>  JPG add this instead [* N/A.  This mechanism signals anticipated
> overload, not actual overload.  However the signals in this mechanism are
> not used for any other purpose. *]
>
> REQ 7 OK
> REQ 8 OK
> REQ 9 OK
>
>  JPG add this instead  [ *No.  Because this mechanism requires advance
> environments where the number and identity of the upstream neighbors are not
> known in advance.  In order to satisfy Req 10, it should be used in
> conjunction with other mechanisms.*]
>
> REQ 11 OK
> REQ 12 OK
>
>  JPG add this instead [ *P/A.  This mechanism does not specifically
> address the prioritizing of work during times of overload.  But is does not
> preclude any particular local policy.*]
>
> REQ 14 OK
>
>  JPG add this instead [ *P/A  Because the filters are provisioned in
> the overloaded node (see Req 1)* ]
>
> REQ 16 OK
>
>     JPG - delete this -      Yes. Security considerations are discussed, in
> particular, accepted
>  JPG add this instead [* P/A. This mechanism does provide a potential
> SHOULD be used.*  ]
>   JPG - delete this -       Yes. For example, an example approach to ensure
> fair server resource
>  JPG add this instead [ *No. This mechanism is entirely dependent on the
> described in section 4.4. *]
>
> REQ 21 OK
> REQ 22 OK
> REQ 23 OK
>
> Janet
>
>
> any order or other contract unless pursuant to explicit written agreement or
> government initiative expressly permitting the use of e-mail for such
> purpose.
>
>
>  From: Charles Shen <[email-masked]> To: Janet P Gunn/USA/CSC@CSC
> Cc: Salvatore Loreto <[email-masked]>,
> [email-masked], [email-masked] Date: 01/10/2011
> 03:23 PM Subject: Re: [sip-overload] Call for Consensus:
> ------------------------------
>
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 15 Jan 2011 18:37:02 +0100

Hi there,

this call for consensus that has been extended until January 14th is now 
over.
Based on the fact that nobody objected,
Volker and I, as chairs, declare consensus on the adoption of the
draft-shen-soc-load-control-event-package as wg item
(baseline for the third item we have in the SoC charter).

So I would ask the authors to submit a new version as wg item,
(and of course updating it to take in considerations all the comments 
that have
been sent out).

we have experienced a very small numbers of responses/feedback.
Once again, we want encourage everyone who cares to progress the wg's 
related issues
to become more active in providing technical feedback as well as on 
providing opinions
on calls.

Ciao
Sal & Volker

-- 
Salvatore Loreto
www.sloreto.com

---

From: Charles Shen <[email-masked]>
Date: Sun, 16 Jan 2011 23:37:26 -0500

Thank you Chairs and all,

An updated version incorporating the comments from the consensus call
has been submitted as
draft-ietf-soc-load-control-event-package.

Thanks

Charles

On Sat, Jan 15, 2011 at 12:37 PM, Salvatore Loreto
<[email-masked]> wrote:
> (and of course updating it to take in considerations all the comments that
> have
> been sent out).
>
>