Subject: [sip-overload] FW: New Version Notification for draft-partha-soc-overload-resource-availability-00

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 3 Jun 2010 16:41:14 +0530

Hi all,

The below draft was submitted in SIPPING WG earlier. Now, we are
re-submitting in SoC WG. The draft is available at
https://datatracker.ietf.org/doc/draft-partha-soc-overload-resource-avai
lability/

The proposed explicit SIP SUBSCRIBE/NOTIFY draft will be useful for
resource monitoring and SIP overload control in the SIP network. The
proposal aims at meeting Requirements for Management of Overload in the
Session Initiation Protocol (RFC 5390) requirements. The base concept of
this resource availability draft is taken from H.323 Resource
availability indication (RAI) mechanism and enhanced to meet the SIP
requirements. H.323 RAI mechanism is already deployed by lot of H.323
products and is working well in Enterprise and service provider network.

The proposed SIP mechanism is working fine in the Lab. Could you please
review this draft and provide your expert comments.

Thanks
Partha/Shesh

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, June 03, 2010 4:28 PM
To: Parthasarathi R (partr)
Cc: Sheshadri Shalya (svshesha)
Subject: New Version Notification for
draft-partha-soc-overload-resource-availability-00 

A new version of I-D,
draft-partha-soc-overload-resource-availability-00.txt has been
successfully submitted by Parthasarathi R and posted to the IETF
repository.

Filename:	 draft-partha-soc-overload-resource-availability
Revision:	 00
Title:		 Session Initiation Protocol (SIP) Resource availability
Event package
Creation_date:	 2010-06-03
WG ID:		 Independent Submission
Number_of_pages: 18

Abstract:
Overload occurs in Session Initiation Protocol (SIP) networks when
B2BUA, proxies, and user agents have insufficient resources like CPU,
memory, DSP, DS0, disk resources or available bandwidth to complete the
processing of a request.  SIP provides limited support for overload
handling through its 503 response code, which tells an upstream element
that it is overloaded.  This document defines explicit SIP based
resource monitoring and overload avoidance mechanism based on the
resource availability of the entity.

The IETF Secretariat.

---

From: <[email-masked]>
Date: Thu, 3 Jun 2010 14:07:27 +0200

Hi,

Is there any fundamental difference compared to (a part from the XML schema)?

http://tools.ietf.org/html/draft-shen-sipping-load-control-event-package-04

Is intended as an alternative?

BC

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> Parthasarathi R (partr)
> Envoyé : jeudi 3 juin 2010 13:11
> À : [email-masked]
> Objet : [sip-overload] FW: New Version Notification 
> fordraft-partha-soc-overload-resource-availability-00
> 
> Hi all,
> 
> The below draft was submitted in SIPPING WG earlier. Now, we 
> are re-submitting in SoC WG. The draft is available at 
> The proposed explicit SIP SUBSCRIBE/NOTIFY draft will be 
> useful for resource monitoring and SIP overload control in 
> the SIP network. The proposal aims at meeting Requirements 
> for Management of Overload in the Session Initiation Protocol 
> (RFC 5390) requirements. The base concept of this resource 
> availability draft is taken from H.323 Resource availability 
> indication (RAI) mechanism and enhanced to meet the SIP 
> requirements. H.323 RAI mechanism is already deployed by lot 
> of H.323 products and is working well in Enterprise and 
> service provider network.
> 
> The proposed SIP mechanism is working fine in the Lab. Could 
> you please review this draft and provide your expert comments.
> 
> Thanks
> Partha/Shesh
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 3 Jun 2010 15:50:04 +0200

In fact I'm not convinced we need a SUBSCRIBE/NOTIFY mechanism for
this. Is draft-hilt-sipping-overload planned to be moved to the SOC
WG?

Thanks,
-Victor

-- 
Victor Pascual Ávila

---

From: Volker Hilt <[email-masked]>
Date: Thu, 3 Jun 2010 15:23:36 -0400

Victor,

yes, there will be a new version of draft-hilt-sipping-overload 
submitted to soc. The new editor of this draft will be Vijay.

Thanks,

Volker

On 6/3/2010 9:50 AM, Victor Pascual Avila wrote:
> On Thu, Jun 3, 2010 at 2:07 PM,<[email-masked]>  wrote:
>> Hi,
>>

---

From: "Sheshadri Shalya (svshesha)" <[email-masked]>
Date: Fri, 4 Jun 2010 08:46:22 +0530

Victor,
We selected Subscribe/notify mechanism to keep the overload indication and conveying the resource usage information out of the session establishment method. This way, even before the session creation, SIP upstream entity will be aware of the resource utilization scenario on the down stream entity and use this information for routing purpose and avoid overloading of downstream SIP entities.

Bruno,
The xml schema that we have defined in this draft provides more granular information on the usage of different resources like cpu, memory etc and this does not specify what action to be taken based on the information. It is left to the upstream SIP server to take an appropriate decision and action to avoid overload condition.

Thanks,
Sheshadri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
Sent: Thursday, June 03, 2010 7:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sip-overload] FW: New Version Notificationfordraft-partha-soc-overload-resource-availability-00

Thanks,
-Victor

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 4 Jun 2010 11:00:27 +0530

Hi Bruno,

Thanks for looking at our draft. The fundamental difference between shen and our draft is that Shen draft addresses the SoC requirements of " A specification for a SIP load filtering mechanism." whereas our draft falls into "A specification for an SIP overload control mechanism based on implicit/explicit feedback." and particularly based on explicit feedback mechanism. Could you please look from this perspective and provide your valuable comments.

Thanks
Partha/Shesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 03, 2010 5:37 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [sip-overload] FW: New Version Notification fordraft-partha-soc-overload-resource-availability-00

Hi,

BC

> [mailto:[email-masked]] De la part de Parthasarathi R 
> (partr) Envoyé : jeudi 3 juin 2010 13:11 À : [email-masked] 
> proposal aims at meeting Requirements for Management of Overload in 
> the Session Initiation Protocol (RFC 5390) requirements. The base 
> concept of this resource availability draft is taken from H.323 
> Resource availability indication (RAI) mechanism and enhanced to meet 
> the SIP requirements. H.323 RAI mechanism is already deployed by lot 
> of H.323 products and is working well in Enterprise and service 
> provider network.
> 
> The proposed SIP mechanism is working fine in the Lab. Could you 
> please review this draft and provide your expert comments.
> 
> Thanks
> Partha/Shesh
> 
> memory, DSP, DS0, disk resources or available bandwidth to complete 
> the processing of a request.  SIP provides limited support for 
> overload handling through its 503 response code, which tells an 
> upstream element that it is overloaded.  This document defines 
> explicit SIP based resource monitoring and overload avoidance 
> mechanism based on the resource availability of the entity.
>  
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 4 Jun 2010 07:37:02 +0200

Hi Sheshadri,

Thanks for your message. Please see below.

> We selected Subscribe/notify mechanism to keep the overload indication and conveying the resource usage information out of the session establishment method. This way, even before the session creati…

Sending SIP ping messages, say out-of-dialog SIP OPTIONS, is widely
used today to determine operational status of a neighboring entity.
That could be used to convey overload control information.

Thanks,
-Victor

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 4 Jun 2010 11:31:24 +0530

Hi Victor,

Adding to Shesh mail, I'm not getting your point as  Sec 6.1.2 of draft-hilt-sipping-overload-07 highlights the mechanism for event package.

For load balancing scenario, the load balancer acts as a subscriber and other entities acts as Notifier. Notifier notifies the resource availability to subscriber and subscriber balances the load based on the Notifier information. The advantage with SUBSCRIBE/NOTIFY mechanism is that

1) Notifier shall indicate the recovery of overload condition immediately so that load balancer better use the resources.  
2) Notifier shall indicate the resource availability of different resource (DSP, DS0, CPU, Memory) using the proposed mechanism.
3) During the overload scenario, there is no need of polling the Notifier using normal SIP message till Notifier indicates the availability. In case of using new dialog creation like INVITE as a polling message may leads to setup delay as INVITE has to be forwarded to other rotifer after getting the failure.
4) There is no need to inform the load condition in each SIP message. In each device, There is a separate dialog just to handle the overload mechanism.

Could you please elaborate your reasons for not convinced with the SUBSCRIBE/NOTIFY mechanism for overload indication.

Regards
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sheshadri Shalya (svshesha)
Sent: Friday, June 04, 2010 8:46 AM
To: Victor Pascual Avila; [email-masked]
Cc: [email-masked]
Subject: Re: [sip-overload] FW: New VersionNotificationfordraft-partha-soc-overload-resource-availability-00

Victor,

Bruno,

Thanks,
Sheshadri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
Sent: Thursday, June 03, 2010 7:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sip-overload] FW: New Version Notificationfordraft-partha-soc-overload-resource-availability-00

In fact I'm not convinced we need a SUBSCRIBE/NOTIFY mechanism for this. Is draft-hilt-sipping-overload planned to be moved to the SOC WG?

Thanks,
-Victor

On Thu, Jun 3, 2010 at 2:07 PM,  <[email-masked]> wrote:
>> Title:                 Session Initiation Protocol (SIP) Resource 
>> availability Event package

---

From: "Sheshadri Shalya (svshesha)" <[email-masked]>
Date: Fri, 4 Jun 2010 11:54:22 +0530

Hi Victor,
OPTIONS are generally used for queries/keep alive only, but not to
notify the information voluntarily. With the use of OPTIONS for passing
resource availability information, the load balancing entity will not
have any control over the notifier. In case load balancing entity wants
to reduce or increase the notification frequency or do not want to get
these resource availability notifications, it is not possible with
OPTIONS.

Hope this clarifies your question. Let us know if you have any further
comments on this draft.

Thanks,
Shesh

-----Original Message-----
From: Victor Pascual Avila [mailto:[email-masked]] 
Sent: Friday, June 04, 2010 11:07 AM
To: Sheshadri Shalya (svshesha)
Cc: [email-masked]; [email-masked]
Subject: Re: [sip-overload] FW: New Version
Notificationfordraft-partha-soc-overload-resource-availability-00

Hi Sheshadri,

On Fri, Jun 4, 2010 at 5:16 AM, Sheshadri Shalya (svshesha)
<[email-masked]> wrote:
> We selected Subscribe/notify mechanism to keep the overload indication
and conveying the resource usage information out of the session
establishment method. This way, even before the session creation, SIP
upstream entity will be aware of the resource utilization scenario on
the down stream entity and use this information for routing purpose and
avoid overloading of downstream SIP entities.

Thanks,
-Victor

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 4 Jun 2010 09:48:19 -0400

Victor, et al,

Speaking of SIP OPTIONS, we have a draft prepared that tries to improve on
the interworking issues we've seen where folks are using OPTIONS to get
device status, but do so with a bit of inconsistency.  (Victor, I know
you're aware of this draft, but I mention it for the benefit of others on
the list who are not.)

We've received a few comments to improve the text, but we've not submitted a
revised text in a month as what we had proposed to the sip-core WG was not
getting much traction.  Nonetheless, we are still of the mind that it should
move forward, since as you say, it's widely implemented.

If you've not seen the draft, please see:
http://tools.ietf.org/html/draft-jones-sip-options-ping

We had not intended this to be positioned as an overload mechanism, but
rather as a means of determining device status in line with RFC 3261.  That
said, some have suggested that the overload WG might be the better home.

We'd certainly welcome comments.

Paul

> From: [email-masked] [mailto:sip-overload-
> [email-masked]] On Behalf Of Victor Pascual Avila
> Sent: Friday, June 04, 2010 1:37 AM
> Subject: Re: [sip-overload] FW: New Version Notificationfordraft-
> partha-soc-overload-resource-availability-00
> 
> Hi Sheshadri,
> 
> > We selected Subscribe/notify mechanism to keep the overload
> indication and conveying the resource usage information out of the
> session establishment method. This way, even before the session
> creation, SIP upstream entity will be aware of the resource utilization
> scenario on the down stream entity and use this information for routing
> purpose and avoid overloading of downstream SIP entities.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Jun 2010 10:29:46 -0400

Adding to what Partha said:

IIUC the two drafts are distributing information that feeds different 
control mechanisms. But interestingly the subscriptions are between 
exactly the same entities. Its conceivable that these two mechanisms 
could be harmonized, with a single subscription conveying both sorts of 
information.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 4 Jun 2010 10:49:00 -0400

Paul,

Yes, they could.  However, a pub/sub mechanism introduces more complexity
for devices to implement.  That might be fine for a GW or large SBC peering
devices, but it may not desirable for an IP phone or some low-end B2BUA
devices.  A reply to OPTIONS is a trivial reactive function.  Further, a
peer that wishes to send a "ping" may only do so when there is no other
activity.

More importantly, these drafts serve different purposes.  A management
device might send an OPTIONS "ping" to a network device, but perhaps has no
interest in knowing what capacity is available.  This might be done from
time to time by a service provider to monitor to status of its managed
enterprise SBC devices or perhaps "on demand" when one wishes to probe a
particular device.

In any case, the OPTIONS method already exists and is widely implemented.
The procedures just need a little more clarity, since implementations all
over are inconsistent in behavior.

The overload work, I assume, will address situations where it's important to
monitor devices very closely in order to ensure that traffic is directed to
a device with available capacity.

So, while these could be merged in some way, OPTIONS already exists and does
serve a different purpose than what I've seen with the overload work.

Paul

> [email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, June 04, 2010 10:30 AM
> Subject: Re: [sip-overload] FW: New Version Notification fordraft-
> > Thanks for looking at our draft. The fundamental difference between
> shen and our draft is that Shen draft addresses the SoC requirements of
> " A specification for a SIP load filtering mechanism." whereas our
> draft falls into "A specification for an SIP overload control mechanism
> based on implicit/explicit feedback." and particularly based on
> explicit feedback mechanism. Could you please look from this
> perspective and provide your valuable comments.
> >
> > Thanks
> > Partha/Shesh
> >
> > Subject: RE: [sip-overload] FW: New Version Notification fordraft-

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Jun 2010 11:02:49 -0400

Paul J,

My comment was specifically about the two overload drafts that both use 
pub/sub. I see that others have commented that pub/sub may not be 
required, but I wasn't responding to that at this time.

I suspect that OPTIONS may have some role in the overall approch to 
overload. I just don't know yet what that is. It would be helpful if you 
can shed some light on that - positioning the use of OPTIONS relative to 
pub/sub mechanisms in an overall system for overload control.

	Thanks,
	Paul K

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 4 Jun 2010 17:28:59 +0200

Hi,

quick clarification: when I suggested that OPTIONS could be used to
convey overload control information, it was just for idle
destinations. "Real traffic" could also convey this information. As an
example please see draft-hilt-sipping-overload-07, Section 3.

Thanks,
-Victor

On Fri, Jun 4, 2010 at 5:02 PM, Paul Kyzivat <[email-masked]> wrote:
> pub/sub. I see that others have commented that pub/sub may not be required,
> but I wasn't responding to that at this time.
>
> overload. I just don't know yet what that is. It would be helpful if you can
> shed some light on that - positioning the use of OPTIONS relative to pub/sub
> mechanisms in an overall system for overload control.
>
>        Thanks,
>        Paul K
>
> Paul E. Jones wrote:
>>
>> Paul,
>>
>>>> From: [email-masked] [mailto:bruno.chatras@orange-
>>>
>>> ftgroup.com]
>>>>
>>>> Is there any fundamental difference compared to (a part from the XML
>>>
>>> schema)?
>>>>
>>>> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-
>>>
>>> package-04
>>>>
>>>>> https://datatracker.ietf.org/doc/draft-partha-soc-overload-res
>>>>
>>>> ource-avai
>>>>>
>>>>> lability/
>>>>>
>>>>> Resource availability indication (RAI) mechanism and enhanced to
>>>
>>> meet
>>>>>
>>>>> B2BUA, proxies, and user agents have insufficient resources like
>>>
>>> CPU,
>>>>>

-- 
Victor Pascual Ávila

---

From: Volker Hilt <[email-masked]>
Date: Sun, 6 Jun 2010 15:41:47 -0400

Paul, Paul,
> pub/sub mechanisms in an overall system for overload control.
Indeed. It would be helpful to understand how the use of OPTIONS relates 
to use of a header parameter for feedback.

Thanks,

Volker [as individual contributor]

---

From: Volker Hilt <[email-masked]>
Date: Sun, 6 Jun 2010 15:42:04 -0400

Partha,

there has been a long discussion on this topic on the SIPPING mailing 
list in the 04 - 05/2007 timeframe. Section 6.1.2 of 
draft-hilt-sipping-overload-08 tries to summarize what has been discussed.

> 1) Notifier shall indicate the recovery of overload condition immediately so that load balancer better use the resources.

An overload control mechanism should try to prevent complete overload in 
a downstream neighbor and avoid that a node is completely shut down. You 
typically want to maintain your ability to forward requests to an entity.

> 2) Notifier shall indicate the resource availability of different resource (DSP, DS0, CPU, Memory) using the proposed mechanism.

What would the subscriber use this information for? Eventually the 
subscriber has to decide how much load it is going to forward. What 
would the subscriber do with the information that memory is exhausted 
but CPU utilization is low?

> 3) During the overload scenario, there is no need of polling the Notifier using normal SIP message till Notifier indicates the availability. In case of using new dialog creation like INVITE as a po…

You probably want to avoid the complete shutdown of an entity.

Thanks,

---

From: <[email-masked]>
Date: Mon, 7 Jun 2010 13:49:56 +0200

One approach could consist in separating the event specification (in one RFC) from the control document specifications (in one or more RFCs and possibly other types of standards). This would also provide a solution to the issue I raised on Friday about the ETSI XML schema.
Bruno

> De : Paul Kyzivat [mailto:[email-masked]] 
> Envoyé : vendredi 4 juin 2010 16:30
> À : Parthasarathi R (partr)
> Cc : CHATRAS Bruno RD-CORE-ISS; [email-masked]
> Objet : Re: [sip-overload] FW: New Version Notification 
> IIUC the two drafts are distributing information that feeds 
> different control mechanisms. But interestingly the 
> subscriptions are between exactly the same entities. Its 
> conceivable that these two mechanisms could be harmonized, 
> with a single subscription conveying both sorts of information.
> 
> 	Thanks,
> 	Paul
> 
> > Thanks for looking at our draft. The fundamental difference 
> between shen and our draft is that Shen draft addresses the 
> SoC requirements of " A specification for a SIP load 
> filtering mechanism." whereas our draft falls into "A 
> specification for an SIP overload control mechanism based on 
> implicit/explicit feedback." and particularly based on 
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > Subject: RE: [sip-overload] FW: New Version Notification 
> Parthasarathi R
> useful for

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 7 Jun 2010 21:04:38 +0530

Hi Volker,

In case OPTION method alone (with header parameter) is used for getting the feedback, the polling of overload information using OPTIONS has to be done very frequently which may not be desired behavior.  In case the frequency is less, the overload may occur in the neighboring entity due to delay in getting the information. I think that it is better to provide the feedback immediately rather than using polling mechanism. Please let me know your opinion on this.

Thanks
Partha  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: Monday, June 07, 2010 1:12 AM
To: [email-masked]
Subject: Re: [sip-overload] FW:New Version Notification fordraft-partha-soc-overload-resource-availability-00

Paul, Paul,
>
> My comment was specifically about the two overload drafts that both 
> use pub/sub. I see that others have commented that pub/sub may not be 
> overload. I just don't know yet what that is. It would be helpful if 
> you can shed some light on that - positioning the use of OPTIONS 
> relative to pub/sub mechanisms in an overall system for overload control.
>
Indeed. It would be helpful to understand how the use of OPTIONS relates to use of a header parameter for feedback.

Thanks,

> Paul E. Jones wrote:
>> Paul,
>>
>> Yes, they could.  However, a pub/sub mechanism introduces more 
>> complexity for devices to implement.  That might be fine for a GW or 
>> large SBC peering devices, but it may not desirable for an IP phone 
>> or some low-end B2BUA devices.  A reply to OPTIONS is a trivial 
>> reactive function.  Further, a peer that wishes to send a "ping" may 
>> only do so when there is no other activity.
>>
>> More importantly, these drafts serve different purposes.  A 
>> management device might send an OPTIONS "ping" to a network device, 
>> but perhaps has no interest in knowing what capacity is available.  
>> This might be done from time to time by a service provider to monitor 
>> to status of its managed enterprise SBC devices or perhaps "on 
>> demand" when one wishes to probe a particular device.
>>
>> The procedures just need a little more clarity, since implementations 
>> all over are inconsistent in behavior.
>>
>> The overload work, I assume, will address situations where it's 
>> important to monitor devices very closely in order to ensure that 
>> traffic is directed to a device with available capacity.
>>
>> So, while these could be merged in some way, OPTIONS already exists 
>> and does serve a different purpose than what I've seen with the overload work.
>>
>> Paul
>>
>>> different control mechanisms. But interestingly the subscriptions 
>>> are between exactly the same entities. Its conceivable that these 
>>> two mechanisms could be harmonized, with a single subscription 
>>> conveying both sorts of information.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>> shen and our draft is that Shen draft addresses the SoC requirements 
>>> of " A specification for a SIP load filtering mechanism." whereas 
>>> our draft falls into "A specification for an SIP overload control 
>>> mechanism based on implicit/explicit feedback." and particularly 
>>> based on explicit feedback mechanism. Could you please look from 
>>> this perspective and provide your valuable comments.
>>>> Thanks
>>>> Partha/Shesh
>>>>
>>>>> The proposed explicit SIP SUBSCRIBE/NOTIFY draft will be useful 
>>>>> for resource monitoring and SIP overload control in the SIP 
>>>>> network. The proposal aims at meeting Requirements for Management 
>>>>> of Overload in the Session Initiation Protocol (RFC 5390) 
>>>>> requirements. The base concept of this resource availability draft 
>>>>> is taken from H.323 Resource availability indication (RAI) 
>>>>> mechanism and enhanced to
>>> meet
>>>>> the SIP requirements. H.323 RAI mechanism is already deployed by 
>>>>> lot of H.323 products and is working well in Enterprise and 
>>>>> memory, DSP, DS0, disk resources or available bandwidth to 
>>>>> complete the processing of a request.  SIP provides limited 
>>>>> support for overload handling through its 503 response code, which 
>>>>> tells an upstream element that it is overloaded.  This document 
>>>>> defines explicit SIP based resource monitoring and overload 
>>>>> avoidance mechanism based on the resource availability of the entity.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat.
>>>>>
>>>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 7 Jun 2010 15:19:02 -0400

Paul,

As I mentioned, it was not our intent to introduce the OPTIONS "ping" draft
as a means of preventing overload.  Managing overload in SIP is needed and
the insertion of the "oc" tags in messages is actually a good idea.  Handing
overload via a simple NOTIFY message that triggers once a "low water mark"
is reached will not work.  The systems need to report, with some regularity,
the load condition of a peer device.  That way, SBCs (or whatever) that is
selecting a peer SBC or GW device can do so with some level of assurance
that the peer will actually not have reached an overload state by the time
the INVITE is delivered.  This is what we did for H.323 in H.323v4.  I guess
SIP just hasn't seen the same level of deployment until some 10 years later.

Further, what gets reported for overload control is important.  For a PSTN
GW, DS0s make sense.  For other devices, something else is needed.  I have
an idea as to what should be reported and how, but I've not had time to
write it up.

Anyway, the OPTIONS "ping" was intended for situations that are quite
different to what I consider overload control.  A service provider wants to
know if the enterprise PBX or SBC is dead (and vice versa).  OPTIONS is good
for that.  It's good in helping to discover that a peer device has a problem
and can be used to notify network administrators; it's a good management
tool.  But, it was never intended to serve where an "overload" mechanism is
needed in a high-transaction network.

Paul

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, June 04, 2010 11:03 AM
> To: Paul E. Jones
> Cc: 'Parthasarathi R (partr)'; [email-masked]
> you
> complexity
> management
> > device might send an OPTIONS "ping" to a network device, but perhaps
> has
> no
> important to
> > monitor devices very closely in order to ensure that traffic is
> directed
> to
> and
> does
> different
> of
> for
> lot
> complete

---

From: Volker Hilt <[email-masked]>
Date: Mon, 7 Jun 2010 17:28:06 -0400

Partha,

is the OPTION method used if there is no other traffic between two 
entities that can be used to piggyback overload feedback? Or would 
OPTION be the only message that contains overload feedback?

I was hoping to get clarification on the use of OPTIONs.

Thanks,

Volker

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 8 Jun 2010 08:43:23 +0530

Volker,
 
Please read inline.
 
Thanks
Partha

________________________________

From: Volker Hilt [mailto:[email-masked]]
Sent: Tue 6/8/2010 2:58 AM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [sip-overload] FW:New Version Notification fordraft-partha-soc-overload-resource-availability-00

Partha,

is the OPTION method used if there is no other traffic between two
entities that can be used to piggyback overload feedback? 

<Partha> In this "no traffic" case, OPTION with piggyback overload feedback will work to an extent. In the normal scenario, the feedback helps to decide whether to forward the message or not. In case there is no response for OPTION indicates that neighboring entity is not reachable or overloaded. OPTION shall send in the periodic manner to check the overload condition of the neighbor. This mechanism's only caveat is that the system overloaded after sending the feedback will have no control. This caveat will be resolved with the use of "NOTIFY" from the receiver as the receiver knows when the overload occurs in the receiver itself.  </Partha>

Or would

<Partha>  This will not work during high traffic as mentioned earlier in this mail thread.  </Partha>

Thanks,

Volker

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 08 Jun 2010 10:31:43 +0300

Paul,

with the draft 
http://tools.ietf.org/id/draft-ietf-sipcore-event-rate-control-03.txt
it is possible to use the SIP event notification mechanism to receive 
regularly reports
about the load condition of a peer device, without wait a "low water mark",
also when there is no traffic between the two entities.

having said that, (as individual) I see some value  in the fact that 
OPTION "ping" with piggyback information
can be a good management tool that can be used to discover problems 
within the network.

cheers
Sal

On 6/7/10 10:19 PM, Paul E. Jones wrote:
>>> for devices to implement.  That might be fine for a GW or large SBC
>>>        
>> peering
>>      
>>> devices, but it may not desirable for an IP phone or some low-end
>>>        
>> B2BUA
>>      
>>> devices.  A reply to OPTIONS is a trivial reactive function.
>>>        
>> Further, a
>>      
>>> peer that wishes to send a "ping" may only do so when there is no
>>>        
>> other
>>      
>>> activity.
>>>
>>> interest in knowing what capacity is available.  This might be done
>>>        
>> from
>>      
>>> time to time by a service provider to monitor to status of its
>>>        
>> managed
>>      
>>> enterprise SBC devices or perhaps "on demand" when one wishes to
>>>        
>> probe a
>>      
>>> particular device.
>>>
>>> In any case, the OPTIONS method already exists and is widely
>>>        
>> implemented.
>>      
>> all
>>>> could be harmonized, with a single subscription conveying both sorts
>>>>          
>> of
>>      
>>>> information.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> draft falls into "A specification for an SIP overload control
>>>>          
>> mechanism
>>      
>> [mailto:bruno.chatras@orange-
>>      
>>>> ftgroup.com]
>>>>          
>>>>> Is there any fundamental difference compared to (a part from the
>>>>>            
>> XML
>>      
>>>> schema)?
>>>>          
>>>>>> [mailto:[email-masked]] De la part de Parthasarathi
>>>>>>              
>> R
>>      
>>>>>> resource monitoring and SIP overload control in the SIP network.
>>>>>>              
>> The
>>      
>>>>>> proposal aims at meeting Requirements for Management of Overload
>>>>>>              
>> in
>>      

-- 
Salvatore Loreto
www.sloreto.com

---

From: Volker Hilt <[email-masked]>
Date: Tue, 8 Jun 2010 18:27:32 -0400

Partha,
> <Partha> In this "no traffic" case, OPTION with piggyback overload
> feedback will work to an extent.

Yes. In many cases it might indeed be reasonable to send actual traffic 
at a low rate. Overload control should preserve the ability of a system 
to process messages (i.e., not shut it down completely).

> In the normal scenario, the feedback
> helps to decide whether to forward the message or not. In case there is
> no response for OPTION indicates that neighboring entity is not
> reachable or overloaded. OPTION shall send in the periodic manner to
> check the overload condition of the neighbor. This mechanism's only
> caveat is that the system overloaded after sending the feedback will
> have no control.

As mentioned, you probably want to avoid a situation in which a system 
stops all traffic. If overload control works, it will maintain a systems 
ability to process requests.

Thanks,

Volker [as an individual]

> This caveat will be resolved with the use of "NOTIFY"
> from the receiver as the receiver knows when the overload occurs in the
> receiver itself. </Partha>
>
> Or would
>  > In case OPTION method alone (with header parameter) is used for
> getting the feedback, the polling of overload information using OPTIONS
> has to be done very frequently which may not be desired behavior. In
> case the frequency is less, the overload may occur in the neighboring
> entity due to delay in getting the information. I think that it is
> better to provide the feedback immediately rather than using polling
> mechanism. Please let me know your opinion on this.
>  >
>  > Thanks
>  > Partha
>  >
>  > From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Volker Hilt
>  > Subject: Re: [sip-overload] FW:New Version Notification
>  > Indeed. It would be helpful to understand how the use of OPTIONS
> relates to use of a header parameter for feedback.
>  >
>  > Thanks,
>  >

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 9 Jun 2010 15:10:31 +0530

Hi Volker,

Please read inline.

Thanks
Partha/Shesh 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: Monday, June 07, 2010 1:12 AM
To: [email-masked]
Subject: Re: [sip-overload] FW:New VersionNotificationfordraft-partha-soc-overload-resource-availability-00

Partha,

there has been a long discussion on this topic on the SIPPING mailing list in the 04 - 05/2007 timeframe. Section 6.1.2 of
draft-hilt-sipping-overload-08 tries to summarize what has been discussed.

> For load balancing scenario, the load balancer acts as a subscriber 
> and other entities acts as Notifier. Notifier notifies the resource 
> availability to subscriber and subscriber balances the load based on 
> the Notifier information. The advantage with SUBSCRIBE/NOTIFY 
> mechanism is that
>

An overload control mechanism should try to prevent complete overload in a downstream neighbor and avoid that a node is completely shut down. You typically want to maintain your ability to forward requests to an entity.

<Partha> We mean the overload condition in which the system will be able to process only the specific messages like Emergency call, Re-INVITE, responses of the existing transaction and not able to handle further incoming message like New dialog creation message (INVITE, SUBSCRIBE). Just to elaborate more, let us say the system is capable of handling the traffic of 90% CPU and then 10% CPU will service the existing dialogs, emergency services and some housekeeping activities. As you mentioned, this will prevent from complete overload. Notifier has to notify the overload condition whenever CPU utilization reaches 90%. </Partha>

> 2) Notifier shall indicate the resource availability of different resource (DSP, DS0, CPU, Memory) using the proposed mechanism.

What would the subscriber use this information for? 
<Partha> The information helps subscriber to forward the new dialogs based on the resource availability. </Partha>
Eventually the subscriber has to decide how much load it is going to forward. What would the subscriber do with the information that memory is exhausted but CPU utilization is low? 
<Partha> As we mentioned in the sec 4.10, the resource shall be classified as critical and non-critical. CPU and Memory will come up critical resource and any one of the critical resource is reached the overload condition, the system will not be able to service further new dialogs. In SBC, DSP is required only for transcoding calls and if DSP is not available, the system will still be able to service  calls that does not need transcoder. This typically applies in the Enterprise SBC (Branch office) wherein the transcoding will be needed for the calls going towards Service provider (SP) cloud whereas transcoding service is not required for communicating with the Enterprise Headquarters  </Partha>

You probably want to avoid the complete shutdown of an entity.
<Partha> The complete shutdown will not happen as explained for point 1 above </Partha>

Thanks,

> [mailto:[email-masked]] On Behalf Of Sheshadri Shalya 
> (svshesha)
> Subject: Re: [sip-overload] FW: New 
> VersionNotificationfordraft-partha-soc-overload-resource-availability-
> 00
>
> Victor,
> [mailto:[email-masked]] On Behalf Of Victor Pascual 
> Avila
>> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-pack
>> a
>> ge-04
>>
>>> meet the SIP requirements. H.323 RAI mechanism is already deployed 
>>> by lot of H.323 products and is working well in Enterprise and 
>>> CPU, memory, DSP, DS0, disk resources or available bandwidth to 
>>> complete the processing of a request.  SIP provides limited support 
>>> for overload handling through its 503 response code, which tells an

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 9 Jun 2010 09:43:34 -0400

I don't think that's a real problem with the OPTIONS being used for sip-overload.

The proposal would be that an OPTIONS request is a message like any other, and thus can have the Via-header param indicate the OPTIONS *sender's* load in the request, and the receiver's load in the response.

So think of it in the context of the SUBSCRIBE/NOTIFY model.  In that model a subscriber creates a dialog for NOTIFY requests to be returned indicating the far end's load.  Effectively, the OPTIONS is simply replacing/in-lieu-of the NOTIFY, without needing the SUBSCRIBE to begin with.  However often you would have sent your NOTIFY, is how often you send the OPTIONS.  

It's better because it requires NO dialog: no dialog state, no dialog info lookup, no expiration timer, and no Subscription to begin with.  It's really simple.  Those are pretty good properties for an overload indicator, I would think.

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Parthasarathi R (partr)
> Sent: Monday, June 07, 2010 11:35 AM
> 
> Hi Volker,
> 
> In case OPTION method alone (with header parameter) is used for getting
> the feedback, the polling of overload information using OPTIONS has to be
> done very frequently which may not be desired behavior.  In case the
> frequency is less, the overload may occur in the neighboring entity due to
> delay in getting the information. I think that it is better to provide the
> feedback immediately rather than using polling mechanism. Please let me
> know your opinion on this.
> 
> Thanks
> Partha
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jun 2010 10:03:02 -0400

> It's better because it requires NO dialog: no dialog state, no dialog info lookup, no expiration timer, and no Subscription to begin with.  It's really simple.  Those are pretty good properties for…

IIUC, this approach requires that downstream nodes know who their 
upstream neighbors are so that they can send OPTIONS to them. That 
requires a lot of configuration and rules out some more dynamic cases.

An advantage of sub/not is that the process is initiated by the upstream 
node. Upstream nodes can discover who their downstream neighbors will be 
either by configuration when that is appropriate, or dynamically based 
on the requests they receive.

	Thanks,
	Paul

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 9 Jun 2010 16:29:01 +0200

Paul,

On Wed, Jun 9, 2010 at 4:03 PM, Paul Kyzivat <[email-masked]> wrote:
> IIUC, this approach requires that downstream nodes know who their upstream
> neighbors are so that they can send OPTIONS to them. That requires a lot of
> configuration and rules out some more dynamic cases.

IMO it would be something like:

UAC -----INVITE (w/ sender's load)----->UAS
       <----Response (w/ receiver's load)--

UAC -----OPTIONS (w/ sender's load)----->UAS
       <----Response (w/ receiver's load)--

Thanks,
-Victor

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 9 Jun 2010 20:56:11 +0530

Hi Hadriel,

Adding to Paul mail, I'm seeing your proposal as unsolicited overload
information passing. AFAIK, OPTIONS is used to query the information and
not to pass the information. In my opinion, OPTIONS with overload
information is equivalent to Unsolicited NOTIFY with overload
information. OPTIONS (Unsolicited NOTIFY) does not have the control in
the receiver side. There is no negotiation with the receiver and also,
Sender will not know whether the receiver supports the overload
mechanism or not. There is no timer negotiation in OPTIONS and it itself
may be overkill in few networks.

In case, Unsolicited NOTIFY with overload is an accepted solution in
IETF then OPTIONS with overload will also be an accepted solution.

Thanks 
Partha 

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Wednesday, June 09, 2010 7:33 PM
To: Hadriel Kaplan
Cc: Parthasarathi R (partr); Volker Hilt; [email-masked]
Subject: Re: [sip-overload] FW:New Version Notification

Hadriel Kaplan wrote:
> The proposal would be that an OPTIONS request is a message like any
other, and thus can have the Via-header param indicate the OPTIONS
*sender's* load in the request, and the receiver's load in the response.

> So think of it in the context of the SUBSCRIBE/NOTIFY model.  In that
model a subscriber creates a dialog for NOTIFY requests to be returned
indicating the far end's load.  Effectively, the OPTIONS is simply
replacing/in-lieu-of the NOTIFY, without needing the SUBSCRIBE to begin
with.  However often you would have sent your NOTIFY, is how often you
send the OPTIONS.  
> 
> It's better because it requires NO dialog: no dialog state, no dialog
info lookup, no expiration timer, and no Subscription to begin with.
It's really simple.  Those are pretty good properties for an overload
indicator, I would think.

	Thanks,
	Paul

>> [mailto:[email-masked]]
>> getting the feedback, the polling of overload information using 
>> OPTIONS has to be done very frequently which may not be desired 
>> behavior.  In case the frequency is less, the overload may occur in 
>> the neighboring entity due to delay in getting the information. I 
>> think that it is better to provide the feedback immediately rather 
>> than using polling mechanism. Please let me know your opinion on
this.

---

From: Volker Hilt <[email-masked]>
Date: Wed, 9 Jun 2010 20:25:41 -0400

I think I'd like to better understand the use case behind this 
discussion. Is this is for the exchange of overload control information 
between devices that do not exchange SIP traffic?

Thanks,

Volker [as individual]

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Jun 2010 22:00:30 -0400

Sal, et al,

I looked at the "rate-control" draft.  As I understand it, it's primary
purpose is to prevent a flood of NOTIFY messages.  This is particularly
important for such things as presence, should folks wish to use SIP for
that.

However, I didn't see anything in the draft that was specifically focused on
the general problem of "overload".  Did I overlook it?

I also looked at the draft "draft-hilt-sipping-overload".  I like where
that's going, but I had some reservations.  What I liked about that draft is
that it provides a means of providing real-time updates to peers.  As a new
session is established (or upon any exchange, for that matter), peer devices
are able to discover information about the load on the peer server.  What I
did not fully understand was how we prevent overflow.  It said that device
inserting the "oc" values in the Via headers would indicate (to whom?) "the
percentage by which the load forwarded to this SIP server should be
reduced".  This might make sense if there is a single peer device, but what
if there are 100 peers?  How much should any one of those peers reduce load
to the device?  This seemed a little confusing to me, even if there were
just two peers.  And in the case of a single peer, it seems to only work
with percentages.  So, if a device tells a peer to reduce by 100%, then
traffic stops.  If it says "reduce by 0%", then what would prompt traffic to
flow?  Anything times 0 is 0.  So, perhaps I didn't quite understand how
this mechanism works.  Nonetheless, I like the idea of providing
instantaneous feedback... so I did like where this is headed in that regard.

I also reviewed "draft-partha-soc-overload-resource-availability".  This
kind of approach can help to avoid some of the concerns I had with the
previous document I discussed, as it tells more concretely what the resource
situation looks like at a peer device.  However, this mechanism alone will
not work in all cases, as I mentioned before.  In deploying networks with a
high call or transaction volume, resource capacities can change so quickly
that by the time the "almost out of resources" indicator is received, the
device is already overloaded.  It's certainly better than a simple 503, but
only slightly better.

Perhaps the solution to overload is a combination of these approaches.

Paul

> [email-masked]] On Behalf Of Salvatore Loreto
> Sent: Tuesday, June 08, 2010 3:32 AM
> use
> >> can shed some light on that - positioning the use of OPTIONS
> relative
> >> to
> between
> fordraft-
> Parthasarathi

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 10 Jun 2010 08:09:53 +0530

Hi Volker,
 
IIUC, Using OPTIONS method instead of SUB/NOT mechanism for transporting overload information in the SIP network. Please correct me in case I misunderstand something.
 
Thanks
Partha  

From: Volker Hilt [mailto:[email-masked]]
Sent: Thu 6/10/2010 5:55 AM
To: Parthasarathi R (partr)
Cc: Paul Kyzivat (pkyzivat); Hadriel Kaplan; [email-masked]
Subject: Re: [sip-overload] FW:New Version Notification fordraft-partha-soc-overload-resource-availability-00

Thanks,

Volker [as individual]

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 10 Jun 2010 08:55:30 +0300

> the general problem of "overload".  Did I overlook it?
Hi Paul,

you are right, there in nothing in the draft specifically focused on the 
general problem of "overload".
I was pointed to the draft to let people know of the possibilities for 
the subscriber to ask to be notified
regularly (but adaptively ) even if nothing (that would normally trigger 
a notification) has changed in the notifier.
In my personal view that could make unnecessary the use of OPTIONS 
request when there is no traffic.
I mean, instead of send an OPTIONS request to discover the status of a 
server (in a sort of PING),
a network administrator can, thanks to rate-control mechanism, set 
sub/not to receive a sort of heartbeat from it.

/Sal

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 10 Jun 2010 09:36:50 +0200

Hi Sal,

On Thu, Jun 10, 2010 at 7:55 AM, Salvatore Loreto
<[email-masked]> wrote:
> In my personal view that could make unnecessary the use of OPTIONS request
> when there is no traffic.
> a network administrator can, thanks to rate-control mechanism, set sub/not
> to receive a sort of heartbeat from it.

While I believe the above could be a reasonable approach, SIP ping
messages are already deployed in different scenarios. I'm afraid we
would end up having two different mechanisms, one to determine the
operational status of a neighboring entity (binary status--
available/unavailable) and the other to determine the "amount of
traffic" a node should be sending to it.

What I'm proposing here is to reuse an existing (and deployed)
mechanism while refining the information it currently provides.

Regards,
-- 
Victor Pascual Ávila

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 10 Jun 2010 13:07:56 +0530

Hi Paul,

Thanks for reviewing our draft and providing the comments. Please read inline for our responses.  

Thanks
Partha/Shesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Thursday, June 10, 2010 7:31 AM
To: 'Salvatore Loreto'; [email-masked]
Subject: Re: [sip-overload]FW: New Version Notification fordraft-partha-soc-overload-resource-availability-00

Sal, et al,

I looked at the "rate-control" draft.  As I understand it, it's primary purpose is to prevent a flood of NOTIFY messages.  This is particularly important for such things as presence, should folks wish to use SIP for that.

However, I didn't see anything in the draft that was specifically focused on the general problem of "overload".  Did I overlook it?

I also looked at the draft "draft-hilt-sipping-overload".  I like where that's going, but I had some reservations.  What I liked about that draft is that it provides a means of providing real-time updates to peers.  As a new session is established (or upon any exchange, for that matter), peer devices are able to discover information about the load on the peer server.  What I did not fully understand was how we prevent overflow.  It said that device inserting the "oc" values in the Via headers would indicate (to whom?) "the percentage by which the load forwarded to this SIP server should be reduced".  This might make sense if there is a single peer device, but what if there are 100 peers?  How much should any one of those peers reduce load to the device?  This seemed a little confusing to me, even if there were just two peers.  And in the case of a single peer, it seems to only work with percentages.  So, if a device tells a peer to reduce by 100%, then traffic stops.  If it says "reduce by 0%", then what would prompt traffic to flow?  Anything times 0 is 0.  So, perhaps I didn't quite understand how this mechanism works.  Nonetheless, I like the idea of providing instantaneous feedback... so I did like where this is headed in that regard.

I also reviewed "draft-partha-soc-overload-resource-availability".  This kind of approach can help to avoid some of the concerns I had with the previous document I discussed, as it tells more concretely what the resource situation looks like at a peer device.  However, this mechanism alone will not work in all cases, as I mentioned before. 

<Partha> IIUC, the periodic reporting of NOTIFY can alleviate your concern. Sec 4.10 of our draft provides the mechanism to pass the NOTIFY in the periodic manner based on the local policy. By skimming through the "rate-control" draft mechanism, we feel that the rate of notification in our draft shall use the mentioned mechanism in "rate-control" draft for better control from the subscriber end. </Partha>

 In deploying networks with a high call or transaction volume, resource capacities can change so quickly that by the time the "almost out of resources" indicator is received, the device is already overloaded.  

<Partha> With the proper "almost out of resources" configuration and sending "NOTIFY" immediately after getting the threshold limit will reduce the chances of reaching the mentioned scenario. In case of High call volume scenario, Local Overload Control mentioned in Sec 5.3 of draft-hilt-soc-overload-design-00 has to be implemented. I assume that the co-existence of our proposed mechanism and Local overload control will solve the above mentioned issue. </Partha>

It's certainly better than a simple 503, but only slightly better.

Paul

> regularly reports about the load condition of a peer device, without 
> wait a "low water mark", also when there is no traffic between the two 
> entities.
> 
> OPTION "ping" with piggyback information can be a good management tool 
> that can be used to discover problems within the network.
> 
> cheers
> Sal
> 
> > that the peer will actually not have reached an overload state by 
> > the
> time
> > SIP just hasn't seen the same level of deployment until some 10 
> > years
> later.
> >
> > Further, what gets reported for overload control is important.  For 
> > a
> PSTN
> > GW, DS0s make sense.  For other devices, something else is needed.  
> > I
> have
> > Anyway, the OPTIONS "ping" was intended for situations that are 
> > quite different to what I consider overload control.  A service 
> > provider
> wants to
> >> overload. I just don't know yet what that is. It would be helpful 
> >> if you can shed some light on that - positioning the use of OPTIONS
> relative
> >> to
> >>>> Subject: Re: [sip-overload] FW: New Version Notification 
> >>>> fordraft- partha-soc-overload-resource-availability-00
> >>>>
> >>>> " A specification for a SIP load filtering mechanism." whereas 
> >>>>>> successfully submitted by Parthasarathi R and posted to the 
> >>>>>> IETF repository.
> >>>>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 10 Jun 2010 12:21:43 -0400

Sal,

> sub/not to receive a sort of heartbeat from it.

Perhaps, though I'll reiterate that I worked on the OPTIONS "ping" draft,
not as an overload avoidance mechanism, but just as a general-purpose
application-level "are you alive?" kind of issue.  Further, not because
we're creating a new mechanism, but because OPTIONS "ping" messages are
already widely used.  The problem of overload is very different than
checking device status.

If there is a regular exchange of traffic between two points and capacity
information is being exchanged in the process (e.g., in Via headers), then
neither OPTIONS nor NOTIFY are really necessary.  It's when traffic is not
flowing that one needs to explicitly check.  We could either use NOTIFY for
that (which only adds to load when there is already ongoing communication
exchanges) or OPTIONS (which could be used in the absence of such
exchanges).

I think the solution to overload ought to be a combination of the things
I've seen in these various drafts.  They each have their pros and cons, but
taken together I think the group has most of the issues covered.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 10 Jun 2010 12:55:08 -0400

Partha,

> I also reviewed "draft-partha-soc-overload-resource-availability".
> This kind of approach can help to avoid some of the concerns I had with
> the previous document I discussed, as it tells more concretely what the
> resource situation looks like at a peer device.  However, this
> mechanism alone will not work in all cases, as I mentioned before.
> 
> <Partha> IIUC, the periodic reporting of NOTIFY can alleviate your
> concern. Sec 4.10 of our draft provides the mechanism to pass the
> NOTIFY in the periodic manner based on the local policy. By skimming
> through the "rate-control" draft mechanism, we feel that the rate of
> notification in our draft shall use the mentioned mechanism in "rate-
> control" draft for better control from the subscriber end. </Partha>

This will certainly help.  My concern is that, unless the peer device
actually keeps an accumulator for the various capacity values being
reported, then it will still overload a device.

Let's consider the most concrete thing reported: available DS0s.  Suppose
there are 200 available DS0s on a GW and the peer is an SBC or proxy.  If
the call establishment rate is 20cps, then it maxes out in 10s.  Perhaps the
low water mark is set at 10 DS0s.  It would get maxed out in 500ms.  Likely,
a few calls will fail.

Is this horrible?  Perhaps not.  However, what I would prefer is that the
peer device is notified of the current conditions with every exchange.  This
avoids the need for the peer to keep statistics (which might be wrong since
there may be multiple devices feeding to the same GW) and avoids the "race
condition" we see when approaching a low watermark.
 
>  In deploying networks with a high call or transaction volume, resource
> capacities can change so quickly that by the time the "almost out of
> resources" indicator is received, the device is already overloaded.
> 
> <Partha> With the proper "almost out of resources" configuration and
> sending "NOTIFY" immediately after getting the threshold limit will
> reduce the chances of reaching the mentioned scenario. In case of High
> call volume scenario, Local Overload Control mentioned in Sec 5.3 of
> draft-hilt-soc-overload-design-00 has to be implemented. I assume that
> the co-existence of our proposed mechanism and Local overload control
> will solve the above mentioned issue. </Partha>

In real world deployments, we've seen this not work.  As I mentioned above,
if you actually have high call setup rates, it's all too easy to blow past
those low watermark messages.  That's what we originally had with H.323 and
when we deployed it in large scale in carrier networks, we discovered it did
not work.  That's why we introduced changed in H.323v4, and those changes
worked.

I agree with you, though, that there is value in reporting capacity
information.  Your draft has value.  Also, the draft-hilt-sipping-overload
draft seems to put everything in terms of percentages and that does not give
me a strong feeling that it will avoid resource exhaustion entirely, either.

Thus, my suggestion that we need a merger of ideas here.

Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 10 Jun 2010 23:11:53 +0530

I thought of summarizing and adding more point to this thread by which everybody will be in same page. The notion for using SUBSCRIBE/NOTIFY instead of OPTIONS for overload are as follows:
 
1) In SUB/NOT mechanism, the list of Subscription in the Notifier indicates the set of servers has to be notified. The servers are selected based on configuration in OPTIONS mechanism.   
2) In SUB/NOT, it is possible to control the rate of the notification from Subscriber (including start/stop) whereas it is not possible in OPTIONS.
3) NOTIFY method is designed to pass the information whereas OPTIONS is used query the information. Even in case of proposed OPTIONS ping, Sender queries whether receiver is reachable or not.
4) Sending OPTIONS in the periodic manner requires new timer which has to be maintained outside the transaction scope and purely configuration based. In case SUB/NOT, this information will be within the dialog scope. 
5) For Subscriber, SUB/NOT will provides the facility for providing the selecting the set of overload information interested from the Notifier or specific overload mechanism in case of multiple mechanism exists. It is not possible with OPTIONS 
6) In case of Mixed environment like few system supports the overload mechanism and not the other. Notifier will not understand whether subscriber understand the overload mechanism when OPTIONS is used.
7) OPTIONS with overload information will leads to security issues in case of untrusted network (No authentication)
 
Apart from this, SUB/NOT has the following advantage with other methods:
 
1) Overload mechanism is segregated from the normal signaling. NOTIFY with overload information will take care for the entire Notifier system overload condition. 
2) Subscriber has to process only NOTIFY with overload information rather than looking into all the message.
3) Subscriber knows the required resource is not available in the Notifier, there is no need to send any message till Notifier is available with resources.
4) SUB/NOT authentication/security mechanism shall be reused  
5) Even in case of inactive traffic from the subscriber, the Notifier informs the overload information.
 
Thanks
Partha

From: Parthasarathi R (partr)
Sent: Thu 6/10/2010 8:09 AM
To: Volker Hilt
Cc: Paul Kyzivat (pkyzivat); Hadriel Kaplan; [email-masked]
Subject: RE: [sip-overload] FW:New Version Notification fordraft-partha-soc-overload-resource-availability-00

Hi Volker,

Thanks
Partha  

Thanks,

Volker [as individual]

---

From: Volker Hilt <[email-masked]>
Date: Thu, 10 Jun 2010 21:43:37 -0400

Paul,

> to the device?

The nice thing about percentage numbers is that you can forward them to 
all neighbors (e.g., 20%) without counting them. Overall you will get a 
reduction of 20%. An alternative is to forward an absolute rate (say 
100cps). In this case, you need to split your overall capacity across 
all upstream neighbors (i.e, know how many neighbors there are).

> This seemed a little confusing to me, even if there were
> flow?

Not sure I understand your comment. Reduce by 0% would mean there is no 
reduction, i.e., the proxy can pass along messages.

> Anything times 0 is 0.  So, perhaps I didn't quite understand how
Thanks,

Volker [as individual]

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 11 Jun 2010 12:37:51 -0400

Volker,

In regards to "draft-hilt-sipping-overload" ...
> all upstream neighbors (i.e, know how many neighbors there are).

I have a third alternative that I'd like to write up, as it requires a bit
of explanation.

I still don't quite understand how the percentage-based messages will work.
If a device is sending no traffic, then it's a bit hard to reduce.  If it
sends 1 call and gets a response that says to reduce traffic by 90%, what
does that mean?  I understand what the behavior would be when there is an
established flow of messages, but it's the "edge cases" that I don't fully
understand how to handle.
 
> reduction, i.e., the proxy can pass along messages.

There are two points of confusion I have:
1) What happens when a device is told to reduce by 100%?  Does that stop all
messages?
2) When and how is it able to start message exchanges again?  If a device
was told to reduce by 100%, but then we tell it to reduce by 0%, would that
prompt traffic flow?  My point here was that if a device is sending 0
traffic and is told to reduce by 0 (i.e., increase by 100%), the 0 * 100% =
0.

Paul

---

From: Volker Hilt <[email-masked]>
Date: Fri, 11 Jun 2010 18:28:35 -0400

Paul,
> understand how to handle.
A simple way of thinking about this is that the percentage value is the 
probability for each message to be rejected. I.e., if a SIP proxy needs 
to reduce load by 10%, it can to use a random process that rejects each 
message with a 10% probability and forwards it with 90% probability. 
Overall, this will lead to the desired reduction.

This is described in more detail in Section 9.2. of 
draft-hilt-soc-overload-design-00.

> 1) What happens when a device is told to reduce by 100%?  Does that stop all

This is a good point that probably needs clarification in the draft. 
Applying the percentage to all messages has the advantage that it works 
independent of the transaction type. I.e., you don't need to know that 
an INVITE transaction actually corresponds to 5 messages whereas a 
MESSAGE only to two. If you use the percentage on all messages, a 
reduction percentage of 100% would be catastrophic and something you 
should not experience if the overload control algorithm works properly. 
For any reduction, it is useful to have priorities, e.g., target new 
INVITEs before messages of existing dialoges are targeted.

> traffic and is told to reduce by 0 (i.e., increase by 100%), the 0 * 100% =
There is a discussion of this issue in Section 9.2. of 
draft-hilt-soc-overload-design-00.

Thanks,

Volker

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 14 Jun 2010 15:47:44 +0200

Paul, Partha,

>       <----Response (w/ receiver's load)--

Could you please elaborate on why additional configuration is required?

Thank you,
-- 
Victor Pascual Ávila

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jun 2010 09:58:58 -0400

> Could you please elaborate on why additional configuration is required?

I thought what was being proposed was for the downstream node to send 
OPTIONS with load info upstream (hence "pushing" its status to its 
potential callers.) *That* would require it to somehow learn the 
addresses of its upstream neighbors.

What you showed is sending OPTIONS in the other direction, and so 
doesn't require that extra information.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Jun 2010 23:55:05 +0530

Paul,
 
 My concern is that, unless the peer device
actually keeps an accumulator for the various capacity values being
reported, then it will still overload a device.

Let's consider the most concrete thing reported: available DS0s.  Suppose
there are 200 available DS0s on a GW and the peer is an SBC or proxy.  If
the call establishment rate is 20cps, then it maxes out in 10s.  Perhaps the
low water mark is set at 10 DS0s. 
<Partha> Even in this worst case scenario,  NOTIFY triggered will reach next hop within 250 ms with the default RTT as 500 ms. As there is a separate overload control channel exists,the message shall be priortized and passed in reliable transport. Also in the proposed mechanism, total and available count is passed which shall help to reduce the load based on the availability of the system. </Partha>
 It would get maxed out in 500ms.  Likely,
a few calls will fail.
<Partha> Multiple source to the GW with peek load may lead to calls failure. The local  accumulator rejects the call in this scenario for few ms with the above example. I suppose that this caveat will be with any of the overload feedback mechanism. </Partha>

<Partha>  In case accumulator is not kept in the peer device, every message has to be processed  for these capacity values. IMO, the accumulator requires more memory in peer device vs every messge feedback requires more CPU in the peer device as every message is processed for overload. From the peer device perspective (load balancer), the accumulator has advantage as  the number of servers contacting will be very less compare to the number of message processing. </Partha>

<Partha>  I have not fully understand your proposal here. In resource availability proposal, the feedback is based on low watermark or rate of notification. Is your proposal similar to passing the feedback based on the change in the resource availability. Say send NOTIFY on each increase/decrease x% (5% or 10%) resource availability based on the resource and system capacity.  </partha>
Paul