RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery
Albrecht.Schwarz@alcatel.de Fri, 17 November 2006 07:51 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkyV8-0001WB-Mi; Fri, 17 Nov 2006 02:51:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkyV7-0001Vm-8g for sipping@ietf.org; Fri, 17 Nov 2006 02:51:05 -0500
Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkyV5-0000pk-GD for sipping@ietf.org; Fri, 17 Nov 2006 02:51:05 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005) with ESMTP id kAH7orPg002451; Fri, 17 Nov 2006 08:50:53 +0100
In-Reply-To: <9F1D84BDF02A2B41B030921EB09086188542CE@ILEXC1U01.ndc.lucent.com>
Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery
To: "Widjaja, Indra (Indra)" <iwidjaja@research.bell-labs.com>
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF07EC7727.1AB6FF52-ONC1257229.002A12FC-C1257229.002B19DB@netfr.alcatel.fr>
From: Albrecht.Schwarz@alcatel.de
Date: Fri, 17 Nov 2006 08:50:47 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 11/17/2006 08:50:53
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801
Cc: Cullen Jennings <fluffy@cisco.com>, "Dolly, Martin C, ALABS" <mdolly@att.com>, sipping <sipping@ietf.org>, Volker Hilt <volkerh@bell-labs.com>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
I could be such a function, but it must not be IMHO. I'm not sure whether you can pose a requirement itself on specific functions or algorithms. [The network model in clause 6.1 reminds me a little bit to overload control mechanisms designed for intelligent networks. The "home proxy" relates to the IN SCP, the "edge proxy" to the SSPs, etc. The problem is very similar in many aspects. But I can't remember a requirement itself for the convergence/adapation/stability/... functional behaviour (arround TCAP, INAP, served user instances of INAP; or SSP/SCP internal behaviour).] - Albrecht "Widjaja, Indra \(Indra\)" To: "Dolly, Martin C, ALABS" <mdolly@att.com>, Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <iwidjaja@research.bel "Volker Hilt" <volkerh@bell-labs.com> l-labs.com> cc: Cullen Jennings <fluffy@cisco.com>, sipping <sipping@ietf.org> Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery 16.11.2006 17:31 My understanding is that #22 in "drops from above the overall capacity of the network to below the overall capacity" can take a step function. Requirement #22 also implies that the system is asymptotically stable. One question is whether a stronger or more specific requirement in #22 is needed such as by how much oscillation (if it occurs) should decay after a certain period, or what is the speed of convergence. Maybe, this is too much? Indra -----Original Message----- From: Dolly, Martin C, ALABS [mailto:mdolly@att.com] Sent: Thursday, November 16, 2006 6:42 AM To: Albrecht.Schwarz@alcatel.de; Volker Hilt Cc: Cullen Jennings; sipping Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Is requirement #22 a step function, or does it support a gradual recovery? -----Original Message----- From: Albrecht.Schwarz@alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] Sent: Thursday, November 16, 2006 2:50 AM To: Volker Hilt Cc: Cullen Jennings; sipping Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery Agree to make an explicit requirement, but the current proposal is now containing two requirements in my understanding. One related to the stability criteria, and one related to performance (-> throughput) under overload. The 2nd one is so far only considering throughput ("maximize throughput, = equal to offered load"), but not the requirement of bounding response times of (SIP) messages. A successfully processed SIP message and the correspondent response time are tightly coupled. A successfully processed message, but with too much delay, is typically meaningless. (The maximum response time is typically given by SIP protocol timers, or timers of the SIP served application, or behaviour of human beings behind a UA, or ...) Like to split them therefore into two: <t hangText="REQ 21:"> The overload mechanism should ensure that the system remains stable independent of the offered load (i.e., in the entire load range). </t> <t hangText="REQ 22:"> 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 (under steady-state conditions). Response times (or system times; given by service time and all waiting times within the SIP entity) should be below a maximum value under all load conditions. </t> - Albrecht Volker Hilt <volkerh@bell-la To: Jonathan Rosenberg <jdrosen@cisco.com> bs.com> cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings <fluffy@cisco.com>, sipping <sipping@ietf.org> 15.11.2006 23:34 Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery I think the requirement looks good. Volker Jonathan Rosenberg wrote: > I think its reasonable to make it an explicit requirement. How about: > > <t hangText="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. > </t> > > > -Jonathan R. > > Albrecht.Schwarz@alcatel.de wrote: > >> Stability is an implicit requirement of every load control and overload >> protection mechanism (for network elements and networks targeting high >> system and/or service availability). >> >> The rational behind is the fact that any overload control may be >> modeled (& >> realized) as open or closed control loop. Any control arround signalling >> protocols is typically realized as closed loop (e.g. due to realtime >> background). >> A well designed closed control requires a proof of stability for the >> intended range of operation; stability is an implicit requirement from >> control theory, particularly for load control with stochastic >> components as >> in our case here. >> >> - Albrecht >> >> >> >> >> Volker >> Hilt >> <volkerh@bell-la To: Cullen >> Jennings >> <fluffy@cisco.com> >> bs.com> cc: sipping >> <sipping@ietf.org> >> Subject: Re: [Sipping] >> Re: draft-rosenberg-sipping-overload-reqs recovery >> 08.11.2006 >> 17:18 >> >> >> >> >> >> I think that stability of overload control is an important requirement. >> We certainly want to avoid building something that starts to oscillate >> once it reaches overload state. It may be somehow implicit to REQ 1 >> since an unstable system will hardly be able to maintain the overall >> useful throughput at a high level. >> >> Volker >> >> >> >> Cullen Jennings wrote: >> >>> Clearly this was a long way from the text for a requirement but, yes, I >>> was proposing that this be added as one of the requirements. I don't >>> feel strongly about this and if we can't figure out how to express this >>> as a requirement that is useful, I can certainly live with not adding >>> it. >>> >>> The reason I think it is a requirement is I can easily imagine that the >>> mechanism for doing overload push-back causes the systems to fail in the >>> way I described below (i.e. never recover back to steady state). >>> >>> >>> On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote: >>> >>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> A possible additional requirement.... >>>>> Imagine a system (perhaps a single proxy) that could do 100cps. It >>>>> is in steady state doing 80cps with very few retransmission. Then >>>>> for 5 minutes the incoming requests goes to 500cps then drops back >>>>> to an incoming call rate of 80cps. The question is, how long before >>>>> the system gets back to the state where it if is successfully >>>>> processing all the 80cps? >>>> >>>> As soon as it can. Are you suggesting a requirement here? Seems like >>>> this is an implementation thing and wouldn't impact any protocol >>>> mechanisms. >>>> >>>> >>>>> I have seen systems that never recover - that is bad. I think one of >>>>> the design goals is that it is at least possible to build to systems >>>>> that recover back to steady state relatively quickly after an >>>>> overload impulse. >>>> >>>> Sure; but I'm not sure I see the protocol requirement. >>>> >>>> -Jonathan R. >>>> >>>> >>>> >>>> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>>> Cisco Fellow Parsippany, NJ >>>> 07054-2711 >>>> Cisco Systems >>>> jdrosen@cisco.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.cisco.com >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> >> >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] draft-rosenberg-sipping-overload-reqs r… Cullen Jennings
- RE: [Sipping] draft-rosenberg-sipping-overload-re… Poretsky, Scott
- [Sipping] Re: draft-rosenberg-sipping-overload-re… Jonathan Rosenberg
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Spencer Dawkins
- [Sipping] Re: draft-rosenberg-sipping-overload-re… Cullen Jennings
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Volker Hilt
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Jean-Francois Mule
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Janet P Gunn
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Michael Hammer (mhammer)
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Michael Hammer (mhammer)
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Albrecht.Schwarz
- [Sipping] SIP Malformed messages SUNIL J. KUMAR
- RE: [Sipping] SIP Malformed messages Geneiatakis Dimitris
- RE: [Sipping] SIP Malformed messages Gaurav Kheterpal
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Jonathan Rosenberg
- [Sipping] proxy in DMZ while B2BUA as an ALG SUNIL J. KUMAR
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Volker Hilt
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Albrecht.Schwarz
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Dolly, Martin C, ALABS
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Widjaja, Indra (Indra)
- RE: [Sipping] Re: draft-rosenberg-sipping-overloa… Albrecht.Schwarz
- Re: [Sipping] Re: draft-rosenberg-sipping-overloa… Cullen Jennings