From salvatore.loreto@ericsson.com Fri Feb 4 04:10:47 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA4D3A6914 for ; Fri, 4 Feb 2011 04:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrJsfNCfAmuK for ; Fri, 4 Feb 2011 04:10:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CF6BC3A6907 for ; Fri, 4 Feb 2011 04:10:44 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-4d-4d4bed90fda4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E7.17.13987.09DEB4D4; Fri, 4 Feb 2011 13:14:08 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 4 Feb 2011 13:14:08 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 534142A53 for ; Fri, 4 Feb 2011 14:14:08 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0F9FF506FF for ; Fri, 4 Feb 2011 14:14:08 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 99F004F1B5 for ; Fri, 4 Feb 2011 14:14:07 +0200 (EET) Message-ID: <4D4BED8F.2070408@ericsson.com> Date: Fri, 4 Feb 2011 13:14:07 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [sip-overload] publication request ietf-soc-overload-design X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 12:10:48 -0000 Hi there, I have sent to IESG a publication request for "Design Considerations for Session Initiation Protocol (SIP) Overload Control" https://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/ cheers /Sal -- Salvatore Loreto www.sloreto.com From bruno.chatras@orange-ftgroup.com Mon Feb 7 07:55:53 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BEC3A6E0F for ; Mon, 7 Feb 2011 07:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnUi5O2WkDYt for ; Mon, 7 Feb 2011 07:55:52 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2EDB03A6D83 for ; Mon, 7 Feb 2011 07:55:52 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B9A046C0008; Mon, 7 Feb 2011 16:56:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id AFAD56C0007; Mon, 7 Feb 2011 16:56:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Feb 2011 16:55:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 16:55:54 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D3876BF.9050009@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-01 submitted Thread-Index: Acu4ysBcmebGVW6bTUaipsTGKqx8awOEcY9w References: <4D3876BF.9050009@bell-labs.com> From: To: , X-OriginalArrivalTime: 07 Feb 2011 15:55:55.0419 (UTC) FILETIME=[80FBE6B0:01CBC6DF] Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 15:55:53 -0000 Two comments: 1) I think we need to say something about the interactions between this = mechanism and B2BUAs. The configuration I have in mind is the following: = INVITE requests from multiple end user devices are received by a proxy = server which forwards them to a first Application Server (AS-A) acting = as a B2BUA which in turn forwards it to another Application Server = (AS-B). In case AS-B is overloaded, it makes sense to expect the proxy = server to drop a percentage of new incoming requests based on the oc = value rather than to rely on AS-A to do that. However, this requires = AS-A to copy this parameter from one B2BUA side to the other.=20 2) On new appendix B: I think Req23 should be changed from Yes to = Partially. My understanding of the discussion we had on the list is that = there are configurations where the requirement is hard to meet if the = load balancer is not SIP-aware. Bruno > -----Message d'origine----- > De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] De la part de Vijay K. Gurbani > Envoy=E9=A0: jeudi 20 janvier 2011 18:54 > =C0=A0: sip-overload@ietf.org > Objet=A0: [sip-overload] draft-ietf-soc-overload-control-01 submitted >=20 > Folks: Pursuant to our virtual meeting in December-1-2010 [1], > an update to draft-ietf-soc-overload-control has been submitted > [2]. >=20 > There are some substantive changes that have been discussed on > the mailing list. These are: >=20 > 1) The need to support algorithm agility (i.e., negotiate different > overload control algorithms). This discussion resulted in the > addition of the "oc-algo" parameter and is discussed in Sections 4.2 > and 5 of the -01 draft. [2] >=20 > 2) The caveats of sending overload control parameters in a 100- > Trying. This discussion is captured in Section 12 of [2]. >=20 > 3) The relationship of SIP overload control mechanism with other > overload control mechanisms. This discussion is captured in > Section 13. >=20 > 4) A new appendix (Appendix B) has been added that tracks the > requirements of RFC5390 and how they apply to this draft. >=20 > 5) Miscellaneous changes to aid in readability. >=20 > The diff between -00 and -01 is available in [3]. >=20 > Please take a look at the new revision and provide comments on > the mailing list. >=20 > [1] http://www.ietf.org/mail-archive/web/sip- > overload/current/msg00498.html > [2] > http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control- > 01.txt > [3] > = http://tools.ietf.org/rfcdiff?url1=3Dhttp://www.ietf.org/id/draft-ietf- > = soc-overload-control-00.txt&url2=3Dhttp://www.ietf.org/id/draft-ietf-soc-= > overload-control-01.txt >=20 > Thank you, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From vkg@bell-labs.com Mon Feb 7 11:28:07 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93CD3A6E81 for ; Mon, 7 Feb 2011 11:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frfDBD0dBJ3k for ; Mon, 7 Feb 2011 11:28:06 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 4A9E43A6E5E for ; Mon, 7 Feb 2011 11:28:06 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p17JSA68021911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 13:28:10 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p17JSARx016180; Mon, 7 Feb 2011 13:28:10 -0600 (CST) Message-ID: <4D503A57.6070206@bell-labs.com> Date: Mon, 07 Feb 2011 12:30:47 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:28:07 -0000 On 02/07/2011 09:55 AM, bruno.chatras@orange-ftgroup.com wrote: > Two comments: Bruno: Thank you for a close read. More inline. > 1) I think we need to say something about the interactions between > this mechanism and B2BUAs. The configuration I have in mind is the > following: INVITE requests from multiple end user devices are > received by a proxy server which forwards them to a first Application > Server (AS-A) acting as a B2BUA which in turn forwards it to another > Application Server (AS-B). In case AS-B is overloaded, it makes sense > to expect the proxy server to drop a percentage of new incoming > requests based on the oc value rather than to rely on AS-A to do > that. However, this requires AS-A to copy this parameter from one > B2BUA side to the other. This is an interesting case, but I remain unsure on the need to specify the behaviour of a B2BUA in the draft with respect to overload control. Clearly, if AS-B is overloaded, then its direct upstream neighbour (AS-A) should perform overload control for request destined to AS-B. With the suggested model of AS-A copying the overload control parameters from AS-B, the proxy is performing overload control for AS-B by reducing all messages going to AS-A, even those messages that AS-A will not send to AS-B! For this reason, I think it is best that AS-A assume the role of dampening messages towards AS-B. > 2) On new appendix B: I think Req23 should be changed from Yes to > Partially. My understanding of the discussion we had on the list is > that there are configurations where the requirement is hard to meet > if the load balancer is not SIP-aware. I am happy to change REQ-23 from "Yes" to "Partial", but I'd like to have some discussion on this. Those load balancers that are not SIP-aware will do load balancing based on (say) destination IP address and destination port number. They may also remember the source IP address and source port number and create a tuple {src-ip, src-port, dest-ip, dest-port} when the first message from src-ip:src-port goes to dest-ip:dest-port and use the tuple for subsequent messages from src-ip:src-port. Now, such a SIP-unaware load balancer may operate on feedback from its downstream server or it may operate without any feedback. If such a SIP-unaware load balancer receives some feedback from its downstream server, it may load a policy that reduces traffic going to that down- stream server. So it seems that a SIP-unaware load balancer that receives feedback from its downstream server may work as per REQ-23. However, if the SIP server downstream from the load balancer supports overload control, then it may get two treatments of reduced traffic: one from the load balancer and one from the upstream SIP server (up- stream of the load balancer as well). A SIP-unware load balancer that does not receive any feedback at all from its downstream SIP server will not reduce traffic and it will continue to send traffic to the downstream server that matches the tuple (and it will create a new tuple when a new src-ip:src-port presents itself). However, the SIP server upstream of the load balancer will still dampen requests going downstream, so maybe all is well. Furthermore, to quote from [1], "...If the load balancer is not a SIP entity, servers D, E, and F can report the overall load of the server farm (i.e., the load of the virtual server) in their messages. As an alternative, one of the servers (e.g., server E) can report overload on behalf of the server farm. In this case, not all messages contain overload control information and it needs to be ensured that all upstream neighbors are periodically served by server E to received updated information." To be frank, there is so much latitude in how a SIP server can operate when the load balancer is not a SIP-aware entity that I confess in being unable to articulate a coherent architecture on how to meet this requirement. It seems to me that under certain assumptions REQ-23 can be met even when the load balancer is not SIP- aware. Thank you much for continuing to explore the issues around load balancing. Thoughts? - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From bruno.chatras@orange-ftgroup.com Tue Feb 8 05:55:49 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBA73A6DDF for ; Tue, 8 Feb 2011 05:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc3Yks5MRYgN for ; Tue, 8 Feb 2011 05:55:48 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 129D63A6924 for ; Tue, 8 Feb 2011 05:55:48 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 29DBE6C0007; Tue, 8 Feb 2011 14:56:24 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1E3566C0002; Tue, 8 Feb 2011 14:56:24 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 14:55:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 14:55:52 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D503A57.6070206@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-01 submitted Thread-Index: AcvG/TvBwst80aa4SdKFLSjbG1nVwQAko6WQ References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> From: To: X-OriginalArrivalTime: 08 Feb 2011 13:55:54.0147 (UTC) FILETIME=[E71ABF30:01CBC797] Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 13:55:49 -0000 Hi Vijay, See below > -----Message d'origine----- > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Envoy=E9=A0: lundi 7 f=E9vrier 2011 19:31 > =C0=A0: CHATRAS Bruno RD-CORE-ISS > Cc=A0: sip-overload@ietf.org > Objet=A0: Re: [sip-overload] draft-ietf-soc-overload-control-01 = submitted >=20 > On 02/07/2011 09:55 AM, bruno.chatras@orange-ftgroup.com wrote: > > Two comments: >=20 > Bruno: Thank you for a close read. More inline. >=20 > > 1) I think we need to say something about the interactions between > > this mechanism and B2BUAs. The configuration I have in mind is the > > following: INVITE requests from multiple end user devices are > > received by a proxy server which forwards them to a first = Application > > Server (AS-A) acting as a B2BUA which in turn forwards it to another > > Application Server (AS-B). In case AS-B is overloaded, it makes = sense > > to expect the proxy server to drop a percentage of new incoming > > requests based on the oc value rather than to rely on AS-A to do > > that. However, this requires AS-A to copy this parameter from one > > B2BUA side to the other. >=20 > This is an interesting case, but I remain unsure on the need to > specify the behaviour of a B2BUA in the draft with respect to > overload control. Clearly, if AS-B is overloaded, then its > direct upstream neighbour (AS-A) should perform overload control > for request destined to AS-B. >=20 > With the suggested model of AS-A copying the overload control > parameters from AS-B, the proxy is performing overload control > for AS-B by reducing all messages going to AS-A, even those > messages that AS-A will not send to AS-B! For this reason, I think > it is best that AS-A assume the role of dampening messages towards > AS-B. [BC] I was trying to find a solution for the case where the proxy has = been upgraded to support filtering of messages but not AS-A. I believe = this will frequently happen in real networks (e.g. AS-A is an old system = hosting basic telephony applications for user A while AS-B is a new = system hosting a new overload control sensitive application, the core = network proxies are upgraded).=20 >=20 > > 2) On new appendix B: I think Req23 should be changed from Yes to > > Partially. My understanding of the discussion we had on the list is > > that there are configurations where the requirement is hard to meet > > if the load balancer is not SIP-aware. >=20 > I am happy to change REQ-23 from "Yes" to "Partial", but I'd like to > have some discussion on this. >=20 > Those load balancers that are not SIP-aware will do load > balancing based on (say) destination IP address and destination > port number. They may also remember the source IP address and > source port number and create a tuple > {src-ip, src-port, dest-ip, dest-port} when the first message from > src-ip:src-port goes to dest-ip:dest-port and use the tuple for > subsequent messages from src-ip:src-port. >=20 > Now, such a SIP-unaware load balancer may operate on feedback from > its downstream server or it may operate without any feedback. If such > a SIP-unaware load balancer receives some feedback from its downstream > server, it may load a policy that reduces traffic going to that down- > stream server. So it seems that a SIP-unaware load balancer that > receives feedback from its downstream server may work as per REQ-23. > However, if the SIP server downstream from the load balancer supports > overload control, then it may get two treatments of reduced traffic: > one from the load balancer and one from the upstream SIP server (up- > stream of the load balancer as well). >=20 > A SIP-unware load balancer that does not receive any feedback at all > from its downstream SIP server will not reduce traffic and it will > continue to send traffic to the downstream server that matches the > tuple (and it will create a new tuple when a new src-ip:src-port > presents itself). However, the SIP server upstream of the load > balancer will still dampen requests going downstream, so maybe all > is well. >=20 > Furthermore, to quote from [1], "...If the load balancer is not a > SIP entity, servers D, E, and F can report the overall load of the > server farm (i.e., the load of the virtual server) in their messages. [BC] They can do it if they have access to this information. However, in = some cases they will be aware of their own load rather than the load of = the virtual server. > As an alternative, one of the servers (e.g., server E) can report > overload on behalf of the server farm. In this case, not all messages > contain overload control information and it needs to be ensured that > all upstream neighbors are periodically served by server E to received > updated information." [BC] I agree. However this indeed requires that load distribution be = configured in such a way that all upstream neighbors are periodically = served by server E >=20 > To be frank, there is so much latitude in how a SIP server can > operate when the load balancer is not a SIP-aware entity that I > confess in being unable to articulate a coherent architecture on how > to meet this requirement. It seems to me that under certain > assumptions REQ-23 can be met even when the load balancer is not SIP- > aware. [BC] I agree under certain assumptions REQ-23 can be met. That's why I = think that "partial" is more suitable than "Yes". "Yes under certain = assumptions" would be fine as well. >=20 > Thank you much for continuing to explore the issues around load > balancing. >=20 > Thoughts? >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Tue Feb 8 06:52:56 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B219A3A67A8 for ; Tue, 8 Feb 2011 06:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV5dv0r-w9bT for ; Tue, 8 Feb 2011 06:52:55 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 7DB6E3A659A for ; Tue, 8 Feb 2011 06:52:55 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p18Er2XU016154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 08:53:02 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p18Er1k2021184; Tue, 8 Feb 2011 08:53:02 -0600 (CST) Message-ID: <4D514B5B.6030503@bell-labs.com> Date: Tue, 08 Feb 2011 07:55:39 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:52:56 -0000 On 02/08/2011 07:55 AM, bruno.chatras@orange-ftgroup.com wrote: > [BC] I was trying to find a solution for the case where the proxy has > been upgraded to support filtering of messages but not AS-A. I > believe this will frequently happen in real networks (e.g. AS-A is an > old system hosting basic telephony applications for user A while AS-B > is a new system hosting a new overload control sensitive application, > the core network proxies are upgraded). Bruno: I see. The thing that bothers me about this approach --- and I readily subscribe to your assertion that this may happen in real networks --- is that (a) we are essentially performing overload control for AS-B two hops away, and (b) we are attempting to codify B2BUA behaviour in the context of overload. Even then, the proxy must have a filter so only those messages that AS-A will send to AS-B will be quenched. What is the nature of this filter? Is it prescribed anywhere? Is loading this filter an administrative task or will AS-A automatically send it to the proxy? And if so, how? These are all questions that arise in the context of your scenario. To what extent do we need to flesh these out if we go this route? > [BC] I agree under certain assumptions REQ-23 can be met. That's why > I think that "partial" is more suitable than "Yes". "Yes under > certain assumptions" would be fine as well. I agree; that is probably the best we can do. Unless someone else has any objections, I will update REQ-23 to read "Partial". Thank you, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From bruno.chatras@orange-ftgroup.com Tue Feb 8 08:37:44 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094223A680A for ; Tue, 8 Feb 2011 08:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY1R4cx39NW2 for ; Tue, 8 Feb 2011 08:37:42 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A163B3A67E3 for ; Tue, 8 Feb 2011 08:37:35 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 145C6760004; Tue, 8 Feb 2011 17:42:49 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0CFE9760003; Tue, 8 Feb 2011 17:42:49 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 17:37:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2011 17:37:40 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102810E50@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D514B5B.6030503@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-01 submitted Thread-Index: AcvHn/ZyKKkq3MnqRMu+WxF4PrqVFAADgI+Q References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> <4D514B5B.6030503@bell-labs.com> From: To: X-OriginalArrivalTime: 08 Feb 2011 16:37:42.0604 (UTC) FILETIME=[81CBB8C0:01CBC7AE] Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 16:37:44 -0000 > -----Message d'origine----- > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Envoy=E9=A0: mardi 8 f=E9vrier 2011 14:56 > =C0=A0: CHATRAS Bruno RD-CORE-ISS > Cc=A0: sip-overload@ietf.org > Objet=A0: Re: [sip-overload] draft-ietf-soc-overload-control-01 = submitted >=20 > On 02/08/2011 07:55 AM, bruno.chatras@orange-ftgroup.com wrote: > > [BC] I was trying to find a solution for the case where the proxy = has > > been upgraded to support filtering of messages but not AS-A. I > > believe this will frequently happen in real networks (e.g. AS-A is = an > > old system hosting basic telephony applications for user A while = AS-B > > is a new system hosting a new overload control sensitive = application, > > the core network proxies are upgraded). >=20 > Bruno: I see. The thing that bothers me about this approach --- and I > readily subscribe to your assertion that this may happen in real > networks --- is that (a) we are essentially performing overload = control > for AS-B two hops away, and (b) we are attempting to codify B2BUA > behaviour in the context of overload. >=20 > Even then, the proxy must have a filter so only those messages that > AS-A will send to AS-B will be quenched. What is the nature of this > filter? Is it prescribed anywhere? Is loading this filter an > administrative task or will AS-A automatically send it to the proxy? > And if so, how? These are all questions that arise in the context of > your scenario. To what extent do we need to flesh these out if we go > this route? [BC] That's a bit tricky indeed. I think I understand you point as well. = May be we should just add a warning that filtering must be performed by = the adjacent nodes or is this stated somewhere already? >=20 > > [BC] I agree under certain assumptions REQ-23 can be met. That's why > > I think that "partial" is more suitable than "Yes". "Yes under > > certain assumptions" would be fine as well. >=20 > I agree; that is probably the best we can do. Unless someone else has > any objections, I will update REQ-23 to read "Partial". >=20 > Thank you, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ From volker.hilt@alcatel-lucent.com Tue Feb 8 14:09:39 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BFC93A68BD for ; Tue, 8 Feb 2011 14:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov5Wy8mWgTIw for ; Tue, 8 Feb 2011 14:09:38 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 0BF153A68B7 for ; Tue, 8 Feb 2011 14:09:37 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p18M9iiG012763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Feb 2011 16:09:44 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18M9iv9032542 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Feb 2011 16:09:44 -0600 Received: from [135.112.131.41] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 8 Feb 2011 16:09:44 -0600 Message-ID: <4D51BF4B.5070500@alcatel-lucent.com> Date: Tue, 8 Feb 2011 17:10:19 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:09:39 -0000 Bruno, Vijay, please see inline. >> -----Message d'origine----- >> De : Vijay K. Gurbani [mailto:vkg@bell-labs.com] >> Envoyé : lundi 7 février 2011 19:31 >> À : CHATRAS Bruno RD-CORE-ISS >> Cc : sip-overload@ietf.org >> Objet : Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted >> >> On 02/07/2011 09:55 AM, bruno.chatras@orange-ftgroup.com wrote: >>> Two comments: >> >> Bruno: Thank you for a close read. More inline. >> >>> 1) I think we need to say something about the interactions between >>> this mechanism and B2BUAs. The configuration I have in mind is the >>> following: INVITE requests from multiple end user devices are >>> received by a proxy server which forwards them to a first Application >>> Server (AS-A) acting as a B2BUA which in turn forwards it to another >>> Application Server (AS-B). In case AS-B is overloaded, it makes sense >>> to expect the proxy server to drop a percentage of new incoming >>> requests based on the oc value rather than to rely on AS-A to do >>> that. However, this requires AS-A to copy this parameter from one >>> B2BUA side to the other. >> >> This is an interesting case, but I remain unsure on the need to >> specify the behaviour of a B2BUA in the draft with respect to >> overload control. Clearly, if AS-B is overloaded, then its >> direct upstream neighbour (AS-A) should perform overload control >> for request destined to AS-B. >> >> With the suggested model of AS-A copying the overload control >> parameters from AS-B, the proxy is performing overload control >> for AS-B by reducing all messages going to AS-A, even those >> messages that AS-A will not send to AS-B! For this reason, I think >> it is best that AS-A assume the role of dampening messages towards >> AS-B. > There is already text in the draft that says that AS-A can forward overload control feedback considering AS-Bs status if it knows that AS-B is the only server it forwards traffic to. If AS-A forwards traffic to other destinations, generating overload feedback would be harmful as it would throttle traffic to these destinations as well as Vijay has pointed out. This will get us into the domain of multi-hop overload control, which is difficult. > [BC] I was trying to find a solution for the case where the proxy has been upgraded to support filtering of messages but not AS-A. I believe this will frequently happen in real networks (e.g. AS-A is an old system hosting basic telephony applications for user A while AS-B is a new system hosting a new overload control sensitive application, the core network proxies are upgraded). > If AS-A is not upgraded to support overload control, how would it forward the oc parameter? >> >>> 2) On new appendix B: I think Req23 should be changed from Yes to >>> Partially. My understanding of the discussion we had on the list is >>> that there are configurations where the requirement is hard to meet >>> if the load balancer is not SIP-aware. >> >> I am happy to change REQ-23 from "Yes" to "Partial", but I'd like to >> have some discussion on this. >> >> Those load balancers that are not SIP-aware will do load >> balancing based on (say) destination IP address and destination >> port number. They may also remember the source IP address and >> source port number and create a tuple >> {src-ip, src-port, dest-ip, dest-port} when the first message from >> src-ip:src-port goes to dest-ip:dest-port and use the tuple for >> subsequent messages from src-ip:src-port. >> >> Now, such a SIP-unaware load balancer may operate on feedback from >> its downstream server or it may operate without any feedback. If such >> a SIP-unaware load balancer receives some feedback from its downstream >> server, it may load a policy that reduces traffic going to that down- >> stream server. So it seems that a SIP-unaware load balancer that >> receives feedback from its downstream server may work as per REQ-23. >> However, if the SIP server downstream from the load balancer supports >> overload control, then it may get two treatments of reduced traffic: >> one from the load balancer and one from the upstream SIP server (up- >> stream of the load balancer as well). >> >> A SIP-unware load balancer that does not receive any feedback at all >> from its downstream SIP server will not reduce traffic and it will >> continue to send traffic to the downstream server that matches the >> tuple (and it will create a new tuple when a new src-ip:src-port >> presents itself). However, the SIP server upstream of the load >> balancer will still dampen requests going downstream, so maybe all >> is well. >> >> Furthermore, to quote from [1], "...If the load balancer is not a >> SIP entity, servers D, E, and F can report the overall load of the >> server farm (i.e., the load of the virtual server) in their messages. > > [BC] They can do it if they have access to this information. However, in some cases they will be aware of their own load rather than the load of the virtual server. > >> As an alternative, one of the servers (e.g., server E) can report >> overload on behalf of the server farm. In this case, not all messages >> contain overload control information and it needs to be ensured that >> all upstream neighbors are periodically served by server E to received >> updated information." > > [BC] I agree. However this indeed requires that load distribution be configured in such a way that all upstream neighbors are periodically served by server E >> >> To be frank, there is so much latitude in how a SIP server can >> operate when the load balancer is not a SIP-aware entity that I >> confess in being unable to articulate a coherent architecture on how >> to meet this requirement. It seems to me that under certain >> assumptions REQ-23 can be met even when the load balancer is not SIP- >> aware. > [BC] I agree under certain assumptions REQ-23 can be met. That's why I think that "partial" is more suitable than "Yes". "Yes under certain assumptions" would be fine as well. > Vijay, Bruno, following the discussion above - I believe that REQ-23 can in fact be met for load balancers that are not SIP aware. Of course, there is always a way to build a system that does not work. But the key point is that this requirement can be met with the correct design. My suggestion would be to document these approaches in the draft as this will be very relevant for implementers. I think with this documentation, a "Yes" to REQ-23 is appropriate. Thanks, Volker (as individual) From volker.hilt@alcatel-lucent.com Tue Feb 8 14:24:20 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A803A6855 for ; Tue, 8 Feb 2011 14:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiIZpC9NkoHz for ; Tue, 8 Feb 2011 14:24:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B4BB33A6835 for ; Tue, 8 Feb 2011 14:24:19 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p18MOQP2021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Feb 2011 16:24:26 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p18MOQeS002752 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Feb 2011 16:24:26 -0600 Received: from [135.112.131.41] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 8 Feb 2011 16:24:26 -0600 Message-ID: <4D51C2BD.1090206@alcatel-lucent.com> Date: Tue, 8 Feb 2011 17:25:01 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> <4D514B5B.6030503@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810E50@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102810E50@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:24:20 -0000 On 2/8/2011 11:37 AM, bruno.chatras@orange-ftgroup.com wrote: >> -----Message d'origine----- >> De : Vijay K. Gurbani [mailto:vkg@bell-labs.com] >> Envoyé : mardi 8 février 2011 14:56 >> À : CHATRAS Bruno RD-CORE-ISS >> Cc : sip-overload@ietf.org >> Objet : Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted >> >> On 02/08/2011 07:55 AM, bruno.chatras@orange-ftgroup.com wrote: >>> [BC] I was trying to find a solution for the case where the proxy has >>> been upgraded to support filtering of messages but not AS-A. I >>> believe this will frequently happen in real networks (e.g. AS-A is an >>> old system hosting basic telephony applications for user A while AS-B >>> is a new system hosting a new overload control sensitive application, >>> the core network proxies are upgraded). >> >> Bruno: I see. The thing that bothers me about this approach --- and I >> readily subscribe to your assertion that this may happen in real >> networks --- is that (a) we are essentially performing overload control >> for AS-B two hops away, and (b) we are attempting to codify B2BUA >> behaviour in the context of overload. >> >> Even then, the proxy must have a filter so only those messages that >> AS-A will send to AS-B will be quenched. What is the nature of this >> filter? Is it prescribed anywhere? Is loading this filter an >> administrative task or will AS-A automatically send it to the proxy? >> And if so, how? These are all questions that arise in the context of >> your scenario. To what extent do we need to flesh these out if we go >> this route? > > [BC] That's a bit tricky indeed. I think I understand you point as well. May be we should just add a warning that filtering must be performed by the adjacent nodes or is this stated somewhere already? > This is essentially going down the path of end-to-end overload control, which is discussed in the design considerations draft. If AS-A is not updated to support overload control, it will drop the feedback from AS-B, which is exactly what it needs to do. If AS-A would blindly copy the feedback from AS-B to the proxy, it will throttle all traffic to AS-A even if that would not hit AS-B at all. The proxy would have to be specifically updated to copy the oc parameter, which would be unwise to do. If an update is performed, it should be updated to support regular overload control. Volker (as individual) From vkg@bell-labs.com Wed Feb 9 08:08:38 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEDC3A67B4 for ; Wed, 9 Feb 2011 08:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj84KEloNL42 for ; Wed, 9 Feb 2011 08:08:36 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C170F3A67A7 for ; Wed, 9 Feb 2011 08:08:36 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p19G8kVI014862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Feb 2011 10:08:46 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p19G8j08028762 for ; Wed, 9 Feb 2011 10:08:46 -0600 (CST) Message-ID: <4D52AE9B.4070901@bell-labs.com> Date: Wed, 09 Feb 2011 09:11:23 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> <4D51BF4B.5070500@alcatel-lucent.com> In-Reply-To: <4D51BF4B.5070500@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:08:38 -0000 On 02/08/2011 04:10 PM, Volker Hilt wrote: > Vijay, Bruno, following the discussion above - I believe that REQ-23 can > in fact be met for load balancers that are not SIP aware. Of course, > there is always a way to build a system that does not work. But the key > point is that this requirement can be met with the correct design. > > My suggestion would be to document these approaches in the draft as this > will be very relevant for implementers. > > I think with this documentation, a "Yes" to REQ-23 is appropriate. OK, this is more work for me then simply changing a "Yes" to "Partial". But, I will go ahead and do so. If we need more discussion around this, we should hold it now before I update the draft and summarize the current discussion ... Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From salvatore.loreto@ericsson.com Sat Feb 26 11:57:13 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0773A67F5 for ; Sat, 26 Feb 2011 11:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnhllsP-pPCH for ; Sat, 26 Feb 2011 11:57:12 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1125F3A67EE for ; Sat, 26 Feb 2011 11:57:11 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-0e-4d695b4ed10b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 64.2F.09202.E4B596D4; Sat, 26 Feb 2011 20:58:06 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Sat, 26 Feb 2011 20:58:06 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 37E9625C4 for ; Sat, 26 Feb 2011 21:58:06 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E611E50915 for ; Sat, 26 Feb 2011 21:58:05 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 84DFD50914 for ; Sat, 26 Feb 2011 21:58:05 +0200 (EET) Message-ID: <4D695B4D.4040306@ericsson.com> Date: Sat, 26 Feb 2011 21:58:05 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: multipart/alternative; boundary="------------030707000109060300070100" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [sip-overload] Fwd: SOC - Requested session has been scheduled for IETF 80 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 19:57:13 -0000 --------------030707000109060300070100 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit The SoC meeting has been scheduled for Tuesday afternoon (1520-1700 CET), cheers /Sal -------- Original Message -------- Subject: SOC - Requested session has been scheduled for IETF 80 Date: Thu, 24 Feb 2011 23:48:22 +0100 From: IETF Secretariat To: Salvatore Loreto CC: volker.hilt@alcatel-lucent.com , Gonzalo Camarillo , rjsparks@nostrum.com , session-request@ietf.org Dear Salvatore Loreto, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. SOC Session 1 (1.5 hours) Tuesday, Afternoon Session II 1520-1700 Room Name: Grand Ballroom ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: soc Area Name: Real-time Applications and Infrastructure Area Session Requester: Salvatore Loreto Number of Sessions: 1 Length of Session(s): 1.5 hours Number of Attendees: 75 Conflicts to Avoid: First Priority: HyBi SIPCore dispatch httpbis sipclf alto p2psip core apparea appsawg Second Priority: websec httpbis Special Requests: --------------------------------------------------------- --------------030707000109060300070100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit The SoC meeting has been scheduled for Tuesday afternoon (1520-1700 CET),


cheers
/Sal

-------- Original Message --------
Subject: SOC - Requested session has been scheduled for IETF 80
Date: Thu, 24 Feb 2011 23:48:22 +0100
From: IETF Secretariat <agenda@ietf.org>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
CC: volker.hilt@alcatel-lucent.com <volker.hilt@alcatel-lucent.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, rjsparks@nostrum.com <rjsparks@nostrum.com>, session-request@ietf.org <session-request@ietf.org> 


Dear Salvatore Loreto,

The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by 
the information of sessions that you have requested.

SOC Session 1 (1.5 hours)
Tuesday, Afternoon Session II 1520-1700
Room Name: Grand Ballroom
----------------------------------------------



Requested Information:


---------------------------------------------------------
Working Group Name: soc
Area Name: Real-time Applications and Infrastructure Area
Session Requester: Salvatore Loreto

Number of Sessions: 1
Length of Session(s):  1.5 hours
                       
                       
Number of Attendees: 75
Conflicts to Avoid:
  First Priority: HyBi SIPCore dispatch httpbis sipclf alto p2psip core apparea  appsawg
  Second Priority:  websec httpbis

Special Requests:
  
---------------------------------------------------------
--------------030707000109060300070100-- From volker.hilt@alcatel-lucent.com Mon Feb 28 06:56:06 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368583A6947 for ; Mon, 28 Feb 2011 06:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1xaTyqD3WZt for ; Mon, 28 Feb 2011 06:56:05 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 337CD3A6938 for ; Mon, 28 Feb 2011 06:56:04 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1SEuigX018675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Feb 2011 08:57:04 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1SEtoql010189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 28 Feb 2011 08:55:52 -0600 Received: from [135.244.23.226] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Feb 2011 08:55:52 -0600 Message-ID: <4D6BB775.5030409@alcatel-lucent.com> Date: Mon, 28 Feb 2011 09:55:49 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: <4D695B4D.4040306@ericsson.com> In-Reply-To: <4D695B4D.4040306@ericsson.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sip-overload] Fwd: SOC - Requested session has been scheduled for IETF 80 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 14:56:06 -0000 Folks, We will have a SoC session at the next IETF meeting (see below). To request a slot on the agenda please send the chairs an email with a short description of the topic, a reference to the draft (if applicable) and the desired time. The cutoff for agenda requests is Fri March 11, 2011. Thanks, Volker On 2/26/2011 2:58 PM, Salvatore Loreto wrote: > The SoC meeting has been scheduled for Tuesday afternoon (1520-1700 CET), > > > cheers > /Sal > > -------- Original Message -------- > Subject: SOC - Requested session has been scheduled for IETF 80 > Date: Thu, 24 Feb 2011 23:48:22 +0100 > From: IETF Secretariat > To: Salvatore Loreto > CC: volker.hilt@alcatel-lucent.com , > Gonzalo Camarillo , rjsparks@nostrum.com > , session-request@ietf.org > > > > Dear Salvatore Loreto, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > SOC Session 1 (1.5 hours) > Tuesday, Afternoon Session II 1520-1700 > Room Name: Grand Ballroom > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: soc > Area Name: Real-time Applications and Infrastructure Area > Session Requester: Salvatore Loreto > > Number of Sessions: 1 > Length of Session(s): 1.5 hours > > > Number of Attendees: 75 > Conflicts to Avoid: > First Priority: HyBi SIPCore dispatch httpbis sipclf alto p2psip core apparea appsawg > Second Priority: websec httpbis > > Special Requests: > > --------------------------------------------------------- > > > From Internet-Drafts@ietf.org Mon Feb 28 07:45:02 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FAE3A6C1C; Mon, 28 Feb 2011 07:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ofHRUWP-lzV; Mon, 28 Feb 2011 07:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8E33A6BEF; Mon, 28 Feb 2011 07:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110228154501.12963.32242.idtracker@localhost> Date: Mon, 28 Feb 2011 07:45:01 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action:draft-ietf-soc-overload-control-02.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Overload Control Working Group of the IETF. Title : Session Initiation Protocol (SIP) Overload Control Author(s) : V. Gurbani, et al. Filename : draft-ietf-soc-overload-control-02.txt Pages : 26 Date : 2011-02-28 Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines an overload control mechanism for SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-soc-overload-control-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-28073649.I-D@ietf.org> --NextPart-- From vkg@bell-labs.com Mon Feb 28 07:53:01 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDBD3A692E for ; Mon, 28 Feb 2011 07:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Eqlti9dkM+C for ; Mon, 28 Feb 2011 07:52:58 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id EC6013A6944 for ; Mon, 28 Feb 2011 07:52:57 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p1SFrvhs025854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Feb 2011 09:53:57 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p1SFrv5v007070 for ; Mon, 28 Feb 2011 09:53:57 -0600 (CST) Message-ID: <4D6BC570.6080504@bell-labs.com> Date: Mon, 28 Feb 2011 09:55:28 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [sip-overload] draft-ietf-soc-overload-control-02 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 15:53:01 -0000 Folks: I have submitted draft-ietf-soc-overload-control-02 [1]. Diffs between -01 and -02 are at [2]. This version incorporates the list discussion and private feedback I received on -01. I have also updated the IANA section. However, this is a minor update since most of the substantive changes to the overload control parameters went into -01 [3]. I believe we can benefit from a larger discussion on the changes that were incorporated into the -01 version [3]. Please do look at the parameters added for algorithm agility and the other changes that have been added in -01. Thank you. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02.txt [2] http://tools.ietf.org/rfcdiff?url2=draft-ietf-soc-overload-control-02.txt [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00526.html - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/