Subject: [sip-overload] Load Control Event Package Re: December 1st Virtual Meeting

From: Janet P Gunn <[email-masked]>
Date: Wed, 1 Dec 2010 12:41:26 -0500

To follow up the discussion on at the meeting-

This approach (event package) may not comply with the full set of 
requirements in RFC 5390 (especially Req 10).

That is OK, since this is not intended to be a complete solution.  It is 
rather intended to enhance a more comprehensive solution, adding specific 
functionality when there is a known pattern/source of congestion (e.g. 
American Idol voting, or a forecast of a major hurricane).

But there needs to be a discussion, both in the document and on the list, 
of which parts of 5390 this solution does/does not address, and why/why 
not.

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]>
Date: Wed, 1 Dec 2010 16:53:04 -0500

Thanks Janet,

Since the current version of
http://tools.ietf.org/html/draft-shen-soc-load-control-event-package-00
is expiring in a few days, I've re-submitted it as a 01 version. The
comments below and any other further discussions can be documented in
the next version.

Thanks

Charles

On Wed, Dec 1, 2010 at 12:41 PM, Janet P Gunn <[email-masked]> wrote:
> But there needs to be a discussion, both in the document and on the list, of
> which parts of 5390 this solution does/does not address, and why/why not.
>
> 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.
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>

---

From: <[email-masked]>
Date: Thu, 2 Dec 2010 17:18:26 +0100

Hi Charles,

I have two comments about clause 4.3 of draft-shen-soc-load-control-event-package-01
 
   "To begin load filter distribution on a network when the appropriate
   subscriptions among the SIP entities are ready, the initial filter
   contents are introduced to a SIP proxy server which acts as the
   network entry point for load filtering control.  The filter is then
   propagated to other SIP entities throughout the network.  We show two
   examples below."

==>BC: The initial filter contents may also be introduced to another type of SIP entity, e.g. on an operator-managed Application Server hosting the 800 number that creates the overload condition. This Application Server may itself be a SIP proxy or may be actcing as a SIP B2BUA. In this case the network entry point for load filtering control is the overloaded node rather than the edge proxy it is connected to.

"Case II: an earthquake affects the region covered by CPb2, EPb3 and
   EPb4.  All the three servers are overloaded.  The rescue team
   determines that outbound calls are more valuable than inbound calls
   in this specific situation.  Therefore, CPb2, EPb3 and EPb4 are
   configured with filters to accept more outbound calls than inbound
   calls.  Depending on the filter computation algorithm, CPb2 may also
   send out notifications to its outside neighbors, namely CPb1 and
   CPa2, specifying a limit on the acceptable rate of inbound calls to
   CPb2's responsible domain.  CPb1 and CPa2 may subsequently notify
   their neighbors about limiting the calls to CPb2's area.  The same
   process could continue until all edge proxy servers are notified and
   have filters configured."

==>BC: I'm not sure to understand why CPb2 has to be configured. Only EPb3 and EPb4 needs to be configured. CPb2 does not need to be configured as it can receive notifications with filters from EPb3/EPb4.

Regards,
Bruno

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Charles Shen
> Envoyé : mercredi 1 décembre 2010 22:53
> À : Janet P Gunn
> Cc : [email-masked]
> Objet : Re: [sip-overload] Load Control Event Package Re: 
> December 1st Virtual Meeting
> 
> Thanks Janet,
> 
> is expiring in a few days, I've re-submitted it as a 01 
> version. The comments below and any other further discussions 
> can be documented in the next version.
> 
> Thanks
> 
> Charles
> 
> 
> 
> 
> > That is OK, since this is not intended to be a complete 
> solution.  It 
> > is rather intended to enhance a more comprehensive solution, adding 
> > specific functionality when there is a known pattern/source 
> of congestion (e.g.
> > But there needs to be a discussion, both in the document and on the 
> > list, of which parts of 5390 this solution does/does not 
> address, and why/why not.
> >
> > 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]>
Date: Fri, 3 Dec 2010 00:42:53 -0500

Hi Bruno, thanks for the comments, please see inline.

> ==>BC: The initial filter contents may also be introduced to another type of SIP entity, e.g. on an operator-managed Application Server hosting the 800 number that creates the overload condition. T…

[CS] OK. So what do you think about rephrasing "SIP proxy server" in
the sentence to be "SIP entity"?

> ==>BC: I'm not sure to understand why CPb2 has to be configured. Only EPb3 and EPb4 needs to be configured. CPb2 does not need to be configured as it can receive notifications with filters from EPb…

[CS] This is an interesting point. In many cases, like what you
mentioned, CPb2 may just need to receive filters from all the
neighbors at the lower hierarchy, in this case EPb3/EPb4. I think the
original reason that I included CPb2 in the configuration list is
that, since it is the entry/exit point to/out of the CPb2/EPb3/EPb4
region, it might want to install some local filter policies (e.g.,
favoring outbound calls over inbound calls) for the whole region. This
does not preclude its receiving filter policies from its neighbors. Do
you think this could be a plausible scenario?

Thanks

Charles

---

From: Charles Shen <[email-masked]>
Date: Fri, 3 Dec 2010 16:46:06 -0500

Hi Janet, thanks for the comment. Here is a first pass on the event
package draft vs. the requirement RFC5390. As discussed during the
interim, not all the requirements are applicable. I tried to
categorize the assessment as Yes (meet), No (does not meet), N/A (Not
applicable), Partially (partially applicable, depends)

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.

Yes. The goal of the filter-based algorithms is to prevent overload
and mantain overall goodput, especially when the overload context is
known in advance.

   REQ 2:  When a single network element fails, goes into overload, or
      suffers from reduced processing capacity, the mechanism should
      strive to limit the impact of this on other elements in the
      network.  This helps to prevent a small-scale failure from
      becoming a widespread outage.

Partially. N/A if filter values are installed in advance and do not
change during the potential overload period. If filter values are
dynamically adjusted due to the specific filter computation algorithm,
that algorithm needs to take care of this requirement. The filter
computation algorithm is outside the scope of this document.

   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.

Partially. Since the main purpose of the filter-based approach is to
provision the appropriate capacity with advanced knowledge,
configuration cannot be entirely avoided, although minimizing
configuration is still desired.

   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.

Yes. Servers does not support the event package will not be able to
have the specific filters installed.

   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.

Yes. Servers need to take counter-measures for non-conforming elements
(may put a reference to Sec.5.2 of draft-ietf-soc-overload-control)

   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.

Yes. The defined event package is specifically for filter-based overload control

   REQ 7:  The mechanism shall provide a way for an element to throttle
      the amount of traffic it receives from an upstream element.  This
      throttling shall be graded so that it is not all-or-nothing as
      with the current 503 mechanism.  This recognizes the fact that
      "overload" is not a binary state and that there are degrees of
      overload.

Yes. The event package allows rate/loss/windows-based options.

   REQ 8:  The mechanism shall ensure that, when a request was not
      processed successfully due to overload (or failure) of a
      downstream element, the request will not be retried on another
      element that is also overloaded or whose status is unknown.  This
      requirement derives from REQ 1.

N/A to the event package itself.

   REQ 9:  That a request has been rejected from an overloaded element
      shall not unduly restrict the ability of that request to be
      submitted to and processed by an element that is not overloaded.
      This requirement derives from REQ 1.

Yes, e.g., the filter format allows the inclusion of alternative
forwarding destinations for rejected requests.

   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.

Partially: the filter-based approach is mainly for cases with advanced
overload contexts and for scnearios 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 can be expected that the mechanism may be more
difficult to apply.

   REQ 11:  The mechanism should support servers that receive requests
      from a finite set of upstream elements, where the set of upstream
      elements is enumerable.

Yes. (see also answer to REQ 10)

   REQ 12:  The mechanism should work between servers in different
      domains.

Yes. The event package is not limited by domains.

   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.

Yes. Local policies such as honoring RPH is documented.

   REQ 14:  The mechanism should provide unambiguous directions to
      clients on when they should retry a request and when they should
      not.  This especially applies to TCP connection establishment and
      SIP registrations, in order to mitigate against avalanche restart.

N/A to the event-package itself.

   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.

Yes. When the filter is provisioned in advance, it does not rely on
explicit overload feedback indication.

   REQ 16:  The mechanism should attempt to minimize the overhead of the
      overload control messaging.

Yes. The standardized event package mechanism is used.

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

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

   REQ 18:  The overload mechanism should be unambiguous about whether a
      load indication applies to a specific IP address, host, or URI, so
      that an upstream element can determine the load of the entity to
      which a request is to be sent.

Yes. The identity of load indication is covered in the filter format definition.

   REQ 19:  The specification for the overload mechanism should give
      guidance on which message types might be desirable to process over
      others during times of overload, based on SIP-specific
      considerations.  For example, it may be more beneficial to process
      a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh
      with a non-zero expiration (since the former reduces the overall
      amount of load on the element), or to process re-INVITEs over new
      INVITEs.

N/A to the event package itself.

   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.

Yes. May put similar reference to Sec.5.2 of
draft-ietf-soc-overload-control, See also answer to REQ 5.

   REQ 21:  The overload mechanism should ensure that the system remains
      stable.  When the offered load drops from above the overall
      capacity of the network to below the overall capacity, the
      throughput should stabilize and become equal to the offered load.

N/A to the event package itself

   REQ 22:  It must be possible to disable the reporting of load
      information towards upstream targets based on the identity of
      those targets.  This allows a domain administrator who considers
      the load of their elements to be sensitive information, to
      restrict access to that information.  Of course, in such cases,
      there is no expectation that the overload mechanism itself will
      help prevent overload from that upstream target.

N/A to the event package itself

   REQ 23:  It must be possible for the overload mechanism to work in
      cases where there is a load balancer in front of a farm of
      proxies.

Yes, the event package does not preclude its use in a scenario with
server farms.

Thanks

Charles

---

From: <[email-masked]>
Date: Mon, 6 Dec 2010 18:37:58 +0100

Hi Charles,

See below 

> De : [email-masked] 
> [mailto:[email-masked]] De la part de Charles Shen
> Envoyé : vendredi 3 décembre 2010 06:43
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> Objet : Re: [sip-overload] Load Control Event Package - 
> Filter distribution
> 
> On Thu, Dec 2, 2010 at 11:18 AM,  
> <[email-masked]> wrote:
> > Hi Charles,
> >
> > I have two comments about clause 4.3 of 
> > draft-shen-soc-load-control-event-package-01
> >
> > ==>BC: The initial filter contents may also be introduced 
> to another type of SIP entity, e.g. on an operator-managed 
> Application Server hosting the 800 number that creates the 
> overload condition. This Application Server may itself be a 
> SIP proxy or may be actcing as a SIP B2BUA. In this case the 
> network entry point for load filtering control is the 
> overloaded node rather than the edge proxy it is connected to.
> >
> 
> [CS] OK. So what do you think about rephrasing "SIP proxy 
> server" in the sentence to be "SIP entity"?

==>BC: I think this change is required indeed. Furthermore, it would be worth to state explictly that "the network entry point might be the entity to be protected or another SIP entity it is connected to. A case III could be added as well with the example of an Application Server hosting an 800-number translation service and requesting filtering of calls to a specific 800 number.

> > ==>BC: I'm not sure to understand why CPb2 has to be 
> configured. Only EPb3 and EPb4 needs to be configured. CPb2 
> does not need to be configured as it can receive 
> notifications with filters from EPb3/EPb4.
> 
> [CS] This is an interesting point. In many cases, like what 
> you mentioned, CPb2 may just need to receive filters from all 
> the neighbors at the lower hierarchy, in this case EPb3/EPb4. 
> I think the original reason that I included CPb2 in the 
> configuration list is that, since it is the entry/exit point 
> to/out of the CPb2/EPb3/EPb4 region, it might want to install 
> some local filter policies (e.g., favoring outbound calls 
> over inbound calls) for the whole region. This does not 
> preclude its receiving filter policies from its neighbors. Do 

==>BC: I think we should describe both cases. What about replacing 

"Therefore, CPb2, EPb3 and EPb4 are configured with filters to accept more outbound calls than inbound
calls."

with

"Therefore, EPb3 and EPb4 are configured with filters to accept more outbound calls than inbound
calls. CPb2 may be configured the same way or receive dynamic filters from EPb3 and EPb4."

> >> Envoyé : mercredi 1 décembre 2010 22:53 À : Janet P Gunn Cc : 
> >> [email-masked] Objet : Re: [sip-overload] Load 
> Control Event 
> >> Package Re:
> version. The

---

From: Charles Shen <[email-masked]>
Date: Wed, 15 Dec 2010 09:59:49 -0500

Hi Bruno, your comments below will be incorporated into the next revision.

Thanks

Charles