[sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: draft minutes IETF83]

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Thu, 07 June 2012 09:23 UTC

From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
Thread-Topic: Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: [sip-overload] draft minutes IETF83]
Thread-Index: AQHNRI86dm1Q0tcgiE28amjvCK4nLg==
Date: Thu, 07 Jun 2012 09:23:42 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.com>
References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com> <4F957A0C.4050606@bell-labs.com> <4F957A50.7040402@bell-labs.com> <4F95845B.2040508@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@inba-mail01.sonusnet.com> <4F97191A.5020501@bell-labs.com>
In-Reply-To: <4F97191A.5020501@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>, Volker Hilt <volker.hilt@bell-labs.com>
Subject: [sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: draft minutes IETF83]
Precedence: list

Vijay,

Sorry for the delay reply. My comments are as follows:

In Sec 9.1.2 (SIP Event package) of draft-ietf-soc-overload-control-08:

Bullet 2:  "However, these notifications do generate additional traffic, which adds to the overall load."

In case of "oc" parameter, "oc" parameter is passed across in each message whereas NOTITY is one per device and number of NOTIFY depends upon the upstream server. As each server is capable of handling at least few thousand of messages at the time and only few upstream servers compare to number of messages. The number of bytes consumed by "oc" parameter per server in terms of traffic is higher than NOTIFY message in general.

Bullet 3: "However, this would require additional protection to avoid the avalanche restart problem for overload control."

This subscription will not cause avalanche restart normally as subscription is done per server whereas the servers are capable of handling register avalanche which occurs per user.

Bullet 4: "A receiver needs to send NOTIFY messages to all subscribed
      upstream neighbors in a timely manner when the control algorithm
      requires a change in the control variable "

Comment is same as bullet 2.

Bullet 5: "As overload feedback is sent to all senders in separate messages,
      this mechanism is not suitable when frequent overload control
      feedback is needed."

In case frequent overload control is required then the algorithm for overload control really does not work well and oscillation kind of behavior is observed. Even if those scenarios occurs, the main argument is that number of "oc" parameter bytes in the message to the NOTIFY message to the few set of servers. IMO, it is purely deployment and most of the deployment, NOTIFY will have advantages as number of upstream server to the corresponding message is low.

Thanks
Partha

>-----Original Message-----
>From: Vijay K. Gurbani [mailto:vkg@bell-labs.com]
>Sent: Wednesday, April 25, 2012 2:50 AM
>To: Ravindran, Parthasarathi
>Cc: Volker Hilt; sip-overload@ietf.org
>Subject: Re: [sip-overload] draft minutes IETF83
>
>On 04/23/2012 08:24 PM, Ravindran, Parthasarathi wrote:
>> Vijay/Volker,
>>
>> I'm reading this mail after replied to your initial proposal as this
>> mail is not in my "To me" folder :-)
>>
>> I have difference of opinion about the content of sub/not in Sec 9 as
>> it is not fully analyzed after deep-dive into "OC" parameters in "via"
>> header based mechanism. My opinion comes from the Session Initiation
>> Protocol (SIP) Resource availability Event package draft
>> (http://tools.ietf.org/html/draft-partha-soc-overload-resource-
>availability-00).
>> I personally feel that it is not worthy to discuss about SUB/NOT
>> mechanism's merits/demerits within this draft at this moment. In case
>> you wish to discuss, I'll continue the merit/demerit as part of this
>> mail thread.
>
>Initially, I was of the opinion that removing S9 may be the expedient
>way forward, as my earlier email [1] indicated.  However, Volker has
>made a case that we should maintain S9 as background information to
>demonstrate the discussions that lead to the choice of the current
>solution.
>
>Having been through a rather brutal IESG review of sipclf where similar
>justification was asked for, I am sympathetic to providing background
>information precisely for the purpose of completeness.
>
>I gather that you would rather see S9 excised completely.
>
>We have to converge at a middle point somewhere.
>
>If you are not comfortable with the suggested text of [2], then can I
>kindly ask you to read S9.1.2 and send me some suggested text that gets
>your point across?  I will be more than happy to put that into the draft
>and move forward.
>
>Please send me the text at your earliest convenience (or post on the
>list) and we can iterate through it to include it in the next revision.
>
>[1] http://www.ietf.org/mail-archive/web/sip-
>overload/current/msg00773.html
>[2] http://www.ietf.org/mail-archive/web/sip-
>overload/current/msg00778.html
>
>Thanks,
>
>- vijay
>--
>Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
>Web:   http://ect.bell-labs.com/who/vkg/

[sip-overload] draft minutes IETF83 Salvatore Loreto
Re: [sip-overload] draft minutes IETF83 Ravindran, Parthasarathi
Re: [sip-overload] draft minutes IETF83 Salvatore Loreto
Re: [sip-overload] draft minutes IETF83 Vijay K. Gurbani
Re: [sip-overload] draft minutes IETF83 bruno.chatras
Re: [sip-overload] draft minutes IETF83 Volker Hilt
Re: [sip-overload] draft minutes IETF83 Vijay K. Gurbani
Re: [sip-overload] draft minutes IETF83 Volker Hilt
Re: [sip-overload] draft minutes IETF83 Vijay K. Gurbani
Re: [sip-overload] draft minutes IETF83 Ravindran, Parthasarathi
Re: [sip-overload] draft minutes IETF83 Ravindran, Parthasarathi
Re: [sip-overload] draft minutes IETF83 Vijay K. Gurbani
[sip-overload] Comment on draft-ietf-soc-overload… Ravindran, Parthasarathi
Re: [sip-overload] Comment on draft-ietf-soc-over… Vijay K. Gurbani
Re: [sip-overload] Comment on draft-ietf-soc-over… Ravindran, Parthasarathi
Re: [sip-overload] Comment on draft-ietf-soc-over… Vijay K. Gurbani