From internet-drafts@ietf.org Fri Jul 8 19:04:04 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A618B9E802E; Fri, 8 Jul 2011 19:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UGEWFhjTpeR; Fri, 8 Jul 2011 19:04:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7A9E802C; Fri, 8 Jul 2011 19:04:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709020403.10099.68239.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 19:04:03 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-design-07.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:04:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of= the IETF. Title : Design Considerations for Session Initiation Protocol (S= IP) Overload Control Author(s) : Volker Hilt Eric Noel Charles Shen Ahmed Abdelal Filename : draft-ietf-soc-overload-design-07.txt Pages : 25 Date : 2011-07-08 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 discusses models and design considerations for a SIP overload control mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-design-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-soc-overload-design-07.txt From shida@ntt-at.com Sun Jul 10 00:09:20 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F34021F8ACC for ; Sun, 10 Jul 2011 00:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go9YFf9xKzAK for ; Sun, 10 Jul 2011 00:09:19 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 592BD21F89E1 for ; Sun, 10 Jul 2011 00:09:19 -0700 (PDT) Received: from flh1ade252.tky.mesh.ad.jp ([220.102.214.252]:49693 helo=[192.168.11.10]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qfo8j-00042p-MZ; Sun, 10 Jul 2011 02:09:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4E0CEEAB.1070308@alcatel-lucent.com> Date: Sun, 10 Jul 2011 16:09:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7A56D7C0-70D2-4BF4-BE85-C20A401F4B3A@ntt-at.com> References: <4E08FA57.7040807@bell-labs.com> <4E0CEEAB.1070308@alcatel-lucent.com> To: Volker Hilt X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1ade252.tky.mesh.ad.jp ([192.168.11.10]) [220.102.214.252]:49693 X-Source-Auth: shida@agnada.com X-Email-Count: 17 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sip-overload@ietf.org Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 07:09:20 -0000 I support the path forward. I am glad to see that (2) will be progressed along with=20 (3).=20 Regards Shida=20 On Jul 1, 2011, at 6:46 AM, Volker Hilt wrote: > [as an individual] > I think this path forward make sense and is a good way forward. >=20 > [as a chair] > The two proposed drafts (2) and (3) will both address our charter item = 2. A specification for an SIP overload control mechanism based on = implicit/explicit feedback and should both be covered under this item. = If there are no concerns from the AD, I believe that we do not need to = re-charter if we add the draft proposed for (2). >=20 > Thanks, >=20 > Volker >=20 >=20 > On 6/27/2011 5:47 PM, Vijay K. Gurbani wrote: >> Folks: I am trying to close the conversation on SIP overload >> control algorithms. >>=20 >> To recap, we had a decision on making loss-based as the default >> mandatory-to-implement algorithm and had agreed to allow the >> choice of rate- and windows-based algorithms. >>=20 >> This is what's currently reflected in the protocol draft [1]. >>=20 >> During the Prague IETF, it was suggested that we revisit this >> decision and use only one algorithm. This suggestion lead to >> a subsequent thread [2] about which algorithm should be >> chosen --- loss-, rate- or windows-based one. >>=20 >> I think we have to be realistic here in recognizing that >> the relative performance of all the algorithms is about the same. >> So therefore, if the relative performance is the same then there >> may be certain network deployments where the choice of one algorithm >> seems better than the other. >>=20 >> Rate-based one will work well in managed networks where the set of >> upstream clients sending requests is bounded and rather static; this >> also makes it easier to apply capacity guarantees. Loss-based one >> works well where the set of upstream clients sending traffic is >> unbounded and frequently changing. >>=20 >> The loss-based algorithm is less complex than the rate-based one >> or the windows-based one. >>=20 >> Phil Williams has put out a proposal [3] to support all three >> algorithms simultaneously, thereby eliminating the need for protocol >> machinations to choose one. However, issues still remain: first, >> this will force implementations to implement all of the algorithms, >> and this I believe is a heavy burden. >>=20 >> Second, it does not eliminate the need or the desire to change >> algorithms mid stream, and finally, this decision forces an = overloaded >> server to maintain considerable state as to which particular >> algorithm has been chosen with the paired upstream client. >>=20 >> It seems that we are at an impasse. >>=20 >> So, let me suggest another concrete proposal, which will help move >> the work forward expeditiously if all agree. >>=20 >> I propose that draft-ietf-soc-overload-control continue as it >> is now with the following exception: >>=20 >> 1) Take window class out of the mix, leaving rate and >> loss. No one is explicitly championing the windows-based >> one; it could be added later if desired. >>=20 >> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >> working on a rate-based draft that uses the agreement >> mechanisms defined in draft-ietf-soc-overload-control >> and fleshes out how rate-based mechanism will function. >>=20 >> 3) Move draft-ietf-soc-overload-control and the new draft >> in (2) as a bundle so that no one algorithm gets an >> undue advantage of being specified first. >>=20 >> Note that (2) and (3) effectively mitigate Phil's concern that >> "proceeding with a single mandated algorithm would result in >> non-adoption of the other algorithms by suppliers and in effect the >> alternatives would become redundant." >>=20 >> Personally I do not think that the market will favour a sub-optimal >> algorithm and if loss-based does not work I am sure it will >> be replaced in short order. But I do empathize with the perceived >> advantage that loss-based one seems to benefit from if it is made the >> only mandatory-to-implement algorithm in [1]. Therefore, (2) and >> (3) above should mitigate this particular concern. >>=20 >> I suspect what will end up happening is that implementations geared >> to managed network providers will end up supporting both loss- >> and rate-based algorithms while other implementations can support >> only the loss-based one. >>=20 >> Do folks think that this is an agreeable compromise? It is no >> worse off than what we had agreed to before, and in fact it is >> much better since we have eliminated windows-based one and are >> moving loss-based and rate-based ahead at the same time. >>=20 >> I do note that the chairs may have to re-negotiate the charter >> deliverables with the ADs, but modifying the charter or deciding >> to make the rate-based draft as an extension to the second >> deliverable ("2. A specification for an SIP overload control >> mechanism based on implicit/explicit feedback.") is a minor >> detail once everyone agrees to this proposal. >>=20 >> Please comment. Thank you. >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 >> [2] = http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html >> [3] = http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.html >>=20 >> - vijay >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From salvatore.loreto@ericsson.com Mon Jul 11 04:14:13 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB821F8AF6 for ; Mon, 11 Jul 2011 04:14:13 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9233c+jzGfX for ; Mon, 11 Jul 2011 04:14:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8306A21F8A7E for ; Mon, 11 Jul 2011 04:14:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-43-4e1adb020088 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DB.80.20773.20BDA1E4; Mon, 11 Jul 2011 13:14:10 +0200 (CEST) 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.3.137.0; Mon, 11 Jul 2011 13:14:10 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1CB0A245F for ; Mon, 11 Jul 2011 14:14:10 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CCA2F5118D for ; Mon, 11 Jul 2011 14:14:09 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 753E851105 for ; Mon, 11 Jul 2011 14:14:09 +0300 (EEST) Message-ID: <4E1ADB01.1090205@ericsson.com> Date: Mon, 11 Jul 2011 14:14:09 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4E08FA57.7040807@bell-labs.com> <4E0CEEAB.1070308@alcatel-lucent.com> In-Reply-To: <4E0CEEAB.1070308@alcatel-lucent.com> 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: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 11:14:13 -0000 On 7/1/11 12:46 AM, Volker Hilt wrote: > [as an individual] > I think this path forward make sense and is a good way forward. +1 > [as a chair] > The two proposed drafts (2) and (3) will both address our charter item > 2. A specification for an SIP overload control mechanism based on > implicit/explicit feedback and should both be covered under this item. > If there are no concerns from the AD, I believe that we do not need to > re-charter if we add the draft proposed for (2). I concur, however we have at least change the Milestone for the deliverable 2 from the already passed May to what we think it will be a realistic one cheers /Sal -- Salvatore Loreto www.sloreto.com > Thanks, > > Volker > > > On 6/27/2011 5:47 PM, Vijay K. Gurbani wrote: >> Folks: I am trying to close the conversation on SIP overload >> control algorithms. >> >> To recap, we had a decision on making loss-based as the default >> mandatory-to-implement algorithm and had agreed to allow the >> choice of rate- and windows-based algorithms. >> >> This is what's currently reflected in the protocol draft [1]. >> >> During the Prague IETF, it was suggested that we revisit this >> decision and use only one algorithm. This suggestion lead to >> a subsequent thread [2] about which algorithm should be >> chosen --- loss-, rate- or windows-based one. >> >> I think we have to be realistic here in recognizing that >> the relative performance of all the algorithms is about the same. >> So therefore, if the relative performance is the same then there >> may be certain network deployments where the choice of one algorithm >> seems better than the other. >> >> Rate-based one will work well in managed networks where the set of >> upstream clients sending requests is bounded and rather static; this >> also makes it easier to apply capacity guarantees. Loss-based one >> works well where the set of upstream clients sending traffic is >> unbounded and frequently changing. >> >> The loss-based algorithm is less complex than the rate-based one >> or the windows-based one. >> >> Phil Williams has put out a proposal [3] to support all three >> algorithms simultaneously, thereby eliminating the need for protocol >> machinations to choose one. However, issues still remain: first, >> this will force implementations to implement all of the algorithms, >> and this I believe is a heavy burden. >> >> Second, it does not eliminate the need or the desire to change >> algorithms mid stream, and finally, this decision forces an overloaded >> server to maintain considerable state as to which particular >> algorithm has been chosen with the paired upstream client. >> >> It seems that we are at an impasse. >> >> So, let me suggest another concrete proposal, which will help move >> the work forward expeditiously if all agree. >> >> I propose that draft-ietf-soc-overload-control continue as it >> is now with the following exception: >> >> 1) Take window class out of the mix, leaving rate and >> loss. No one is explicitly championing the windows-based >> one; it could be added later if desired. >> >> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >> working on a rate-based draft that uses the agreement >> mechanisms defined in draft-ietf-soc-overload-control >> and fleshes out how rate-based mechanism will function. >> >> 3) Move draft-ietf-soc-overload-control and the new draft >> in (2) as a bundle so that no one algorithm gets an >> undue advantage of being specified first. >> >> Note that (2) and (3) effectively mitigate Phil's concern that >> "proceeding with a single mandated algorithm would result in >> non-adoption of the other algorithms by suppliers and in effect the >> alternatives would become redundant." >> >> Personally I do not think that the market will favour a sub-optimal >> algorithm and if loss-based does not work I am sure it will >> be replaced in short order. But I do empathize with the perceived >> advantage that loss-based one seems to benefit from if it is made the >> only mandatory-to-implement algorithm in [1]. Therefore, (2) and >> (3) above should mitigate this particular concern. >> >> I suspect what will end up happening is that implementations geared >> to managed network providers will end up supporting both loss- >> and rate-based algorithms while other implementations can support >> only the loss-based one. >> >> Do folks think that this is an agreeable compromise? It is no >> worse off than what we had agreed to before, and in fact it is >> much better since we have eliminated windows-based one and are >> moving loss-based and rate-based ahead at the same time. >> >> I do note that the chairs may have to re-negotiate the charter >> deliverables with the ADs, but modifying the charter or deciding >> to make the rate-based draft as an extension to the second >> deliverable ("2. A specification for an SIP overload control >> mechanism based on implicit/explicit feedback.") is a minor >> detail once everyone agrees to this proposal. >> >> Please comment. Thank you. >> >> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 >> [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html >> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.html >> >> - vijay > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From internet-drafts@ietf.org Mon Jul 11 09:27:44 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6411E80B6; Mon, 11 Jul 2011 09:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXCo++aWcmFq; Mon, 11 Jul 2011 09:27:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F09321F84CD; Mon, 11 Jul 2011 09:26:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711162650.17153.76637.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 09:26:50 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-design-08.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:27:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of= the IETF. Title : Design Considerations for Session Initiation Protocol (S= IP) Overload Control Author(s) : Volker Hilt Eric Noel Charles Shen Ahmed Abdelal Filename : draft-ietf-soc-overload-design-08.txt Pages : 25 Date : 2011-07-11 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 discusses models and design considerations for a SIP overload control mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-design-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-soc-overload-design-08.txt From internet-drafts@ietf.org Mon Jul 11 14:09:02 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A676211E8264; Mon, 11 Jul 2011 14:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYRGjNn9ctec; Mon, 11 Jul 2011 14:09:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CF211E8209; Mon, 11 Jul 2011 14:09:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711210902.28338.23788.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 14:09:02 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-01.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 21:09:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of= the IETF. Title : A Session Initiation Protocol (SIP) Load Control Event P= ackage Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-01.txt Pages : 32 Date : 2011-07-11 This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to other SIP servers in the network. The load control can throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-load-control-event-packa= ge-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-soc-load-control-event-packag= e-01.txt From HKaplan@acmepacket.com Tue Jul 12 06:10:15 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32A21F90C7 for ; Tue, 12 Jul 2011 06:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jezPJMMaeoBw for ; Tue, 12 Jul 2011 06:09:53 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id ADBE221F90C4 for ; Tue, 12 Jul 2011 06:09:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 12 Jul 2011 09:09:50 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 12 Jul 2011 09:09:50 -0400 From: Hadriel Kaplan To: "Vijay K. Gurbani" Date: Tue, 12 Jul 2011 09:09:48 -0400 Thread-Topic: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control Thread-Index: AcxAlPtrQYt71PFHR1q6zrs/Dh3+WA== Message-ID: <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> References: <4E08FA57.7040807@bell-labs.com> In-Reply-To: <4E08FA57.7040807@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 13:10:15 -0000 So in summary you're proposing to resolve the issue that having two mechani= sms is a bad idea, by specifying the two mechanisms in two separate docs??= =20 OK, well if we have to have two ways of doing the same thing, then I sugges= t we MANDATE BOTH, by putting them in the same document and a "MUST impleme= nt both" written right in it.=20 Otherwise, if you have RFC A and RFC B, then some devices will do A and oth= ers B and there won't be interop. -hadriel On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: > Folks: I am trying to close the conversation on SIP overload > control algorithms. >=20 > To recap, we had a decision on making loss-based as the default > mandatory-to-implement algorithm and had agreed to allow the > choice of rate- and windows-based algorithms. >=20 > This is what's currently reflected in the protocol draft [1]. >=20 > During the Prague IETF, it was suggested that we revisit this > decision and use only one algorithm. This suggestion lead to > a subsequent thread [2] about which algorithm should be > chosen --- loss-, rate- or windows-based one. >=20 > I think we have to be realistic here in recognizing that > the relative performance of all the algorithms is about the same. > So therefore, if the relative performance is the same then there > may be certain network deployments where the choice of one algorithm > seems better than the other. >=20 > Rate-based one will work well in managed networks where the set of > upstream clients sending requests is bounded and rather static; this > also makes it easier to apply capacity guarantees. Loss-based one > works well where the set of upstream clients sending traffic is > unbounded and frequently changing. >=20 > The loss-based algorithm is less complex than the rate-based one > or the windows-based one. >=20 > Phil Williams has put out a proposal [3] to support all three > algorithms simultaneously, thereby eliminating the need for protocol > machinations to choose one. However, issues still remain: first, > this will force implementations to implement all of the algorithms, > and this I believe is a heavy burden. >=20 > Second, it does not eliminate the need or the desire to change > algorithms mid stream, and finally, this decision forces an overloaded > server to maintain considerable state as to which particular > algorithm has been chosen with the paired upstream client. >=20 > It seems that we are at an impasse. >=20 > So, let me suggest another concrete proposal, which will help move > the work forward expeditiously if all agree. >=20 > I propose that draft-ietf-soc-overload-control continue as it > is now with the following exception: >=20 > 1) Take window class out of the mix, leaving rate and > loss. No one is explicitly championing the windows-based > one; it could be added later if desired. >=20 > 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start > working on a rate-based draft that uses the agreement > mechanisms defined in draft-ietf-soc-overload-control > and fleshes out how rate-based mechanism will function. >=20 > 3) Move draft-ietf-soc-overload-control and the new draft > in (2) as a bundle so that no one algorithm gets an > undue advantage of being specified first. >=20 > Note that (2) and (3) effectively mitigate Phil's concern that > "proceeding with a single mandated algorithm would result in > non-adoption of the other algorithms by suppliers and in effect the > alternatives would become redundant." >=20 > Personally I do not think that the market will favour a sub-optimal > algorithm and if loss-based does not work I am sure it will > be replaced in short order. But I do empathize with the perceived > advantage that loss-based one seems to benefit from if it is made the > only mandatory-to-implement algorithm in [1]. Therefore, (2) and > (3) above should mitigate this particular concern. >=20 > I suspect what will end up happening is that implementations geared > to managed network providers will end up supporting both loss- > and rate-based algorithms while other implementations can support > only the loss-based one. >=20 > Do folks think that this is an agreeable compromise? It is no > worse off than what we had agreed to before, and in fact it is > much better since we have eliminated windows-based one and are > moving loss-based and rate-based ahead at the same time. >=20 > I do note that the chairs may have to re-negotiate the charter > deliverables with the ADs, but modifying the charter or deciding > to make the rate-based draft as an extension to the second > deliverable ("2. A specification for an SIP overload control > mechanism based on implicit/explicit feedback.") is a minor > detail once everyone agrees to this proposal. >=20 > Please comment. Thank you. >=20 > [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 > [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.ht= ml > [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.ht= ml >=20 > - vijay > --=20 > 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 volker.hilt@alcatel-lucent.com Tue Jul 12 07:00:10 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612AF21F915E for ; Tue, 12 Jul 2011 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIDaTZxL0VLP for ; Tue, 12 Jul 2011 07:00:09 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5927221F915A for ; Tue, 12 Jul 2011 07:00:09 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6CE08Ju018005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Jul 2011 09:00:08 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6CE08hJ026443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Jul 2011 09:00:08 -0500 Received: from [135.244.40.52] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 12 Jul 2011 09:00:08 -0500 Message-ID: <4E1C5366.6070306@alcatel-lucent.com> Date: Tue, 12 Jul 2011 10:00:06 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> In-Reply-To: <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 14:00:10 -0000 Hadriel, the idea is to have a mandatory algorithm in the base draft and, at the same time, to leave the draft open for extensions to other algorithms. The second draft will then specify such an algorithm. That way RFC A is the common denominator supported by all devices and advanced devices can implement RFC A and B. Thanks, Volker (as individual) On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: > > So in summary you're proposing to resolve the issue that having two mechanisms is a bad idea, by specifying the two mechanisms in two separate docs?? > > OK, well if we have to have two ways of doing the same thing, then I suggest we MANDATE BOTH, by putting them in the same document and a "MUST implement both" written right in it. > Otherwise, if you have RFC A and RFC B, then some devices will do A and others B and there won't be interop. > > -hadriel > > > On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: > >> Folks: I am trying to close the conversation on SIP overload >> control algorithms. >> >> To recap, we had a decision on making loss-based as the default >> mandatory-to-implement algorithm and had agreed to allow the >> choice of rate- and windows-based algorithms. >> >> This is what's currently reflected in the protocol draft [1]. >> >> During the Prague IETF, it was suggested that we revisit this >> decision and use only one algorithm. This suggestion lead to >> a subsequent thread [2] about which algorithm should be >> chosen --- loss-, rate- or windows-based one. >> >> I think we have to be realistic here in recognizing that >> the relative performance of all the algorithms is about the same. >> So therefore, if the relative performance is the same then there >> may be certain network deployments where the choice of one algorithm >> seems better than the other. >> >> Rate-based one will work well in managed networks where the set of >> upstream clients sending requests is bounded and rather static; this >> also makes it easier to apply capacity guarantees. Loss-based one >> works well where the set of upstream clients sending traffic is >> unbounded and frequently changing. >> >> The loss-based algorithm is less complex than the rate-based one >> or the windows-based one. >> >> Phil Williams has put out a proposal [3] to support all three >> algorithms simultaneously, thereby eliminating the need for protocol >> machinations to choose one. However, issues still remain: first, >> this will force implementations to implement all of the algorithms, >> and this I believe is a heavy burden. >> >> Second, it does not eliminate the need or the desire to change >> algorithms mid stream, and finally, this decision forces an overloaded >> server to maintain considerable state as to which particular >> algorithm has been chosen with the paired upstream client. >> >> It seems that we are at an impasse. >> >> So, let me suggest another concrete proposal, which will help move >> the work forward expeditiously if all agree. >> >> I propose that draft-ietf-soc-overload-control continue as it >> is now with the following exception: >> >> 1) Take window class out of the mix, leaving rate and >> loss. No one is explicitly championing the windows-based >> one; it could be added later if desired. >> >> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >> working on a rate-based draft that uses the agreement >> mechanisms defined in draft-ietf-soc-overload-control >> and fleshes out how rate-based mechanism will function. >> >> 3) Move draft-ietf-soc-overload-control and the new draft >> in (2) as a bundle so that no one algorithm gets an >> undue advantage of being specified first. >> >> Note that (2) and (3) effectively mitigate Phil's concern that >> "proceeding with a single mandated algorithm would result in >> non-adoption of the other algorithms by suppliers and in effect the >> alternatives would become redundant." >> >> Personally I do not think that the market will favour a sub-optimal >> algorithm and if loss-based does not work I am sure it will >> be replaced in short order. But I do empathize with the perceived >> advantage that loss-based one seems to benefit from if it is made the >> only mandatory-to-implement algorithm in [1]. Therefore, (2) and >> (3) above should mitigate this particular concern. >> >> I suspect what will end up happening is that implementations geared >> to managed network providers will end up supporting both loss- >> and rate-based algorithms while other implementations can support >> only the loss-based one. >> >> Do folks think that this is an agreeable compromise? It is no >> worse off than what we had agreed to before, and in fact it is >> much better since we have eliminated windows-based one and are >> moving loss-based and rate-based ahead at the same time. >> >> I do note that the chairs may have to re-negotiate the charter >> deliverables with the ADs, but modifying the charter or deciding >> to make the rate-based draft as an extension to the second >> deliverable ("2. A specification for an SIP overload control >> mechanism based on implicit/explicit feedback.") is a minor >> detail once everyone agrees to this proposal. >> >> Please comment. Thank you. >> >> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 >> [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html >> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.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/ >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From phil.m.williams@bt.com Tue Jul 12 08:59:50 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBCA21F8F18 for ; Tue, 12 Jul 2011 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJMQHkuVRgnX for ; Tue, 12 Jul 2011 08:59:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D121F8F15 for ; Tue, 12 Jul 2011 08:59:49 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 12 Jul 2011 16:59:47 +0100 Received: from E07HT01-UKBR.domain1.systemhost.net (193.113.197.94) by EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 12 Jul 2011 16:59:47 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.2.170]) by E07HT01-UKBR.domain1.systemhost.net ([193.113.197.94]) with mapi; Tue, 12 Jul 2011 16:59:46 +0100 From: To: , Date: Tue, 12 Jul 2011 16:59:37 +0100 Thread-Topic: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control Thread-Index: AcxAnAsWHczBYdXQRc+PJmswqCmvnAAB9NSw Message-ID: References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> <4E1C5366.6070306@alcatel-lucent.com> In-Reply-To: <4E1C5366.6070306@alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 15:59:50 -0000 Volker, I concur with Hadriel. It wasn't clear to me what was being proposed, but I= don't see how what you are suggesting is workable. I pointed out in [1] that the server needs to determine the algorithm to be= used, otherwise it has to use an overload control method that will support= a mix of restriction algorithms on the client, which would be significantl= y more complex for the server than the client having to support two restric= tion algorithms (which I view as relatively straightforward to specify and = implement). Because the draft spec does not specify the server algorithm, i= t gives the illusion that most complexity is in the client, whereas in real= ity it is most likely to be on the server. In [2] I gave an example modification of the draft whereby the client algor= ithms are mandatory, which removes the complexity of the negotiation as wel= l. Regards, Phil [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00632.html [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.html -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Volker Hilt Sent: 12 July 2011 15:00 To: sip-overload@ietf.org Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorit= hms for overload control Hadriel, the idea is to have a mandatory algorithm in the base draft and, at the=20 same time, to leave the draft open for extensions to other algorithms.=20 The second draft will then specify such an algorithm. That way RFC A is the common denominator supported by all devices and=20 advanced devices can implement RFC A and B. Thanks, Volker (as individual) On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: > > So in summary you're proposing to resolve the issue that having two mecha= nisms is a bad idea, by specifying the two mechanisms in two separate docs?= ? > > OK, well if we have to have two ways of doing the same thing, then I sugg= est we MANDATE BOTH, by putting them in the same document and a "MUST imple= ment both" written right in it. > Otherwise, if you have RFC A and RFC B, then some devices will do A and o= thers B and there won't be interop. > > -hadriel > > > On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: > >> Folks: I am trying to close the conversation on SIP overload >> control algorithms. >> >> To recap, we had a decision on making loss-based as the default >> mandatory-to-implement algorithm and had agreed to allow the >> choice of rate- and windows-based algorithms. >> >> This is what's currently reflected in the protocol draft [1]. >> >> During the Prague IETF, it was suggested that we revisit this >> decision and use only one algorithm. This suggestion lead to >> a subsequent thread [2] about which algorithm should be >> chosen --- loss-, rate- or windows-based one. >> >> I think we have to be realistic here in recognizing that >> the relative performance of all the algorithms is about the same. >> So therefore, if the relative performance is the same then there >> may be certain network deployments where the choice of one algorithm >> seems better than the other. >> >> Rate-based one will work well in managed networks where the set of >> upstream clients sending requests is bounded and rather static; this >> also makes it easier to apply capacity guarantees. Loss-based one >> works well where the set of upstream clients sending traffic is >> unbounded and frequently changing. >> >> The loss-based algorithm is less complex than the rate-based one >> or the windows-based one. >> >> Phil Williams has put out a proposal [3] to support all three >> algorithms simultaneously, thereby eliminating the need for protocol >> machinations to choose one. However, issues still remain: first, >> this will force implementations to implement all of the algorithms, >> and this I believe is a heavy burden. >> >> Second, it does not eliminate the need or the desire to change >> algorithms mid stream, and finally, this decision forces an overloaded >> server to maintain considerable state as to which particular >> algorithm has been chosen with the paired upstream client. >> >> It seems that we are at an impasse. >> >> So, let me suggest another concrete proposal, which will help move >> the work forward expeditiously if all agree. >> >> I propose that draft-ietf-soc-overload-control continue as it >> is now with the following exception: >> >> 1) Take window class out of the mix, leaving rate and >> loss. No one is explicitly championing the windows-based >> one; it could be added later if desired. >> >> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >> working on a rate-based draft that uses the agreement >> mechanisms defined in draft-ietf-soc-overload-control >> and fleshes out how rate-based mechanism will function. >> >> 3) Move draft-ietf-soc-overload-control and the new draft >> in (2) as a bundle so that no one algorithm gets an >> undue advantage of being specified first. >> >> Note that (2) and (3) effectively mitigate Phil's concern that >> "proceeding with a single mandated algorithm would result in >> non-adoption of the other algorithms by suppliers and in effect the >> alternatives would become redundant." >> >> Personally I do not think that the market will favour a sub-optimal >> algorithm and if loss-based does not work I am sure it will >> be replaced in short order. But I do empathize with the perceived >> advantage that loss-based one seems to benefit from if it is made the >> only mandatory-to-implement algorithm in [1]. Therefore, (2) and >> (3) above should mitigate this particular concern. >> >> I suspect what will end up happening is that implementations geared >> to managed network providers will end up supporting both loss- >> and rate-based algorithms while other implementations can support >> only the loss-based one. >> >> Do folks think that this is an agreeable compromise? It is no >> worse off than what we had agreed to before, and in fact it is >> much better since we have eliminated windows-based one and are >> moving loss-based and rate-based ahead at the same time. >> >> I do note that the chairs may have to re-negotiate the charter >> deliverables with the ADs, but modifying the charter or deciding >> to make the rate-based draft as an extension to the second >> deliverable ("2. A specification for an SIP overload control >> mechanism based on implicit/explicit feedback.") is a minor >> detail once everyone agrees to this proposal. >> >> Please comment. Thank you. >> >> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 >> [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.h= tml >> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.h= tml >> >> - 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 > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From ecnoel@research.att.com Tue Jul 12 14:37:53 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D319E8033 for ; Tue, 12 Jul 2011 14:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEOaHCHo0rfY for ; Tue, 12 Jul 2011 14:37:49 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE69E8030 for ; Tue, 12 Jul 2011 14:37:49 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id F34FF1200BD; Tue, 12 Jul 2011 17:37:48 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id DD706854B; Tue, 12 Jul 2011 17:37:48 -0400 (EDT) Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Tue, 12 Jul 2011 17:37:21 -0400 From: "NOEL, ERIC C (ERIC C)" To: Volker Hilt , "sip-overload@ietf.org" Date: Tue, 12 Jul 2011 17:41:22 -0400 Thread-Topic: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control Thread-Index: AcxAnEmnACIGDP8eS2u1aSaxbMDcTwANFGdA Message-ID: <2F8FB48C17221643AD77FA295756D2A71E23BA1BE5@njfpsrvexg6.research.att.com> References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> <4E1C5366.6070306@alcatel-lucent.com> In-Reply-To: <4E1C5366.6070306@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:37:54 -0000 Volker, Vijay, I understand the need to have a simple default algorithm in this RFC and I = also agree it should not preclude extension to other algorithms. However, my interpretation of draft-ietf-soc-overload-control-02 is that on= one hand it allows for different class of algorithms to be used through th= e oc-algo parameter, and on the other hand it excludes other algorithms by = limiting the oc parameter value to a loss rate percentage (MUST be a number= between 0 and 100) irrespective of the selected oc-algo parameter.=20 Provided my interpretation is correct, could draft-ietf-soc-overload-contro= l-02 be modified so that the oc parameter is a loss rate percentage only wh= en used with the default algorithm? If there is a push for multiple simultaneous RFCs, then should not draft-ie= tf-soc-overload-control-02 require oc-algo to be set to the value "loss-con= trol" with no mentioning of other controls?=20 Thanks, Eric Noel=20 LMTS AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Volker Hilt Sent: Tuesday, July 12, 2011 10:00 AM To: sip-overload@ietf.org Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorit= hms for overload control Hadriel, the idea is to have a mandatory algorithm in the base draft and, at the=20 same time, to leave the draft open for extensions to other algorithms.=20 The second draft will then specify such an algorithm. That way RFC A is the common denominator supported by all devices and=20 advanced devices can implement RFC A and B. Thanks, Volker (as individual) On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: > > So in summary you're proposing to resolve the issue that having two mecha= nisms is a bad idea, by specifying the two mechanisms in two separate docs?= ? > > OK, well if we have to have two ways of doing the same thing, then I sugg= est we MANDATE BOTH, by putting them in the same document and a "MUST imple= ment both" written right in it. > Otherwise, if you have RFC A and RFC B, then some devices will do A and o= thers B and there won't be interop. > > -hadriel > > > On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: > >> Folks: I am trying to close the conversation on SIP overload >> control algorithms. >> >> To recap, we had a decision on making loss-based as the default >> mandatory-to-implement algorithm and had agreed to allow the >> choice of rate- and windows-based algorithms. >> >> This is what's currently reflected in the protocol draft [1]. >> >> During the Prague IETF, it was suggested that we revisit this >> decision and use only one algorithm. This suggestion lead to >> a subsequent thread [2] about which algorithm should be >> chosen --- loss-, rate- or windows-based one. >> >> I think we have to be realistic here in recognizing that >> the relative performance of all the algorithms is about the same. >> So therefore, if the relative performance is the same then there >> may be certain network deployments where the choice of one algorithm >> seems better than the other. >> >> Rate-based one will work well in managed networks where the set of >> upstream clients sending requests is bounded and rather static; this >> also makes it easier to apply capacity guarantees. Loss-based one >> works well where the set of upstream clients sending traffic is >> unbounded and frequently changing. >> >> The loss-based algorithm is less complex than the rate-based one >> or the windows-based one. >> >> Phil Williams has put out a proposal [3] to support all three >> algorithms simultaneously, thereby eliminating the need for protocol >> machinations to choose one. However, issues still remain: first, >> this will force implementations to implement all of the algorithms, >> and this I believe is a heavy burden. >> >> Second, it does not eliminate the need or the desire to change >> algorithms mid stream, and finally, this decision forces an overloaded >> server to maintain considerable state as to which particular >> algorithm has been chosen with the paired upstream client. >> >> It seems that we are at an impasse. >> >> So, let me suggest another concrete proposal, which will help move >> the work forward expeditiously if all agree. >> >> I propose that draft-ietf-soc-overload-control continue as it >> is now with the following exception: >> >> 1) Take window class out of the mix, leaving rate and >> loss. No one is explicitly championing the windows-based >> one; it could be added later if desired. >> >> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >> working on a rate-based draft that uses the agreement >> mechanisms defined in draft-ietf-soc-overload-control >> and fleshes out how rate-based mechanism will function. >> >> 3) Move draft-ietf-soc-overload-control and the new draft >> in (2) as a bundle so that no one algorithm gets an >> undue advantage of being specified first. >> >> Note that (2) and (3) effectively mitigate Phil's concern that >> "proceeding with a single mandated algorithm would result in >> non-adoption of the other algorithms by suppliers and in effect the >> alternatives would become redundant." >> >> Personally I do not think that the market will favour a sub-optimal >> algorithm and if loss-based does not work I am sure it will >> be replaced in short order. But I do empathize with the perceived >> advantage that loss-based one seems to benefit from if it is made the >> only mandatory-to-implement algorithm in [1]. Therefore, (2) and >> (3) above should mitigate this particular concern. >> >> I suspect what will end up happening is that implementations geared >> to managed network providers will end up supporting both loss- >> and rate-based algorithms while other implementations can support >> only the loss-based one. >> >> Do folks think that this is an agreeable compromise? It is no >> worse off than what we had agreed to before, and in fact it is >> much better since we have eliminated windows-based one and are >> moving loss-based and rate-based ahead at the same time. >> >> I do note that the chairs may have to re-negotiate the charter >> deliverables with the ADs, but modifying the charter or deciding >> to make the rate-based draft as an extension to the second >> deliverable ("2. A specification for an SIP overload control >> mechanism based on implicit/explicit feedback.") is a minor >> detail once everyone agrees to this proposal. >> >> Please comment. Thank you. >> >> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 >> [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.h= tml >> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.h= tml >> >> - 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 > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From volker.hilt@alcatel-lucent.com Tue Jul 12 16:59:31 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABDF11E8094 for ; Tue, 12 Jul 2011 16:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qK9rY5R5Mba for ; Tue, 12 Jul 2011 16:59:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id DDE7E11E8078 for ; Tue, 12 Jul 2011 16:59:26 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6CNxPCB023046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2011 18:59:25 -0500 (CDT) 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 p6CNxPrF018175 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Jul 2011 18:59:25 -0500 Received: from [135.244.35.137] (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, 12 Jul 2011 18:59:24 -0500 Message-ID: <4E1CDFDB.10704@alcatel-lucent.com> Date: Tue, 12 Jul 2011 19:59:23 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "NOEL, ERIC C (ERIC C)" References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> <4E1C5366.6070306@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A71E23BA1BE5@njfpsrvexg6.research.att.com> In-Reply-To: <2F8FB48C17221643AD77FA295756D2A71E23BA1BE5@njfpsrvexg6.research.att.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 23:59:31 -0000 Eric, > > I understand the need to have a simple default algorithm in this RFC > and I also agree it should not preclude extension to other > algorithms. > > However, my interpretation of draft-ietf-soc-overload-control-02 is > that on one hand it allows for different class of algorithms to be > used through the oc-algo parameter, and on the other hand it excludes > other algorithms by limiting the oc parameter value to a loss rate > percentage (MUST be a number between 0 and 100) irrespective of the > selected oc-algo parameter. > > Provided my interpretation is correct, could > draft-ietf-soc-overload-control-02 be modified so that the oc > parameter is a loss rate percentage only when used with the default > algorithm? > Yes! If, for example, a rate-based is used then the feedback needs to be a rate. There is no need to transmit loss value in this case. > If there is a push for multiple simultaneous RFCs, then should not > draft-ietf-soc-overload-control-02 require oc-algo to be set to the > value "loss-control" with no mentioning of other controls? > Yes, that would make sense. A separate draft can then define other values and the corresponding feedback transmission. Thanks, Volker (as individual) > > > -----Original Message----- From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent: > Tuesday, July 12, 2011 10:00 AM To: sip-overload@ietf.org Subject: > Re: [sip-overload] A modest (and new) proposal on multiple algorithms > for overload control > > Hadriel, > > the idea is to have a mandatory algorithm in the base draft and, at > the same time, to leave the draft open for extensions to other > algorithms. The second draft will then specify such an algorithm. > > That way RFC A is the common denominator supported by all devices > and advanced devices can implement RFC A and B. > > Thanks, > > Volker (as individual) > > > > > > On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: >> >> So in summary you're proposing to resolve the issue that having two >> mechanisms is a bad idea, by specifying the two mechanisms in two >> separate docs?? >> >> OK, well if we have to have two ways of doing the same thing, then >> I suggest we MANDATE BOTH, by putting them in the same document and >> a "MUST implement both" written right in it. Otherwise, if you have >> RFC A and RFC B, then some devices will do A and others B and there >> won't be interop. >> >> -hadriel >> >> >> On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: >> >>> Folks: I am trying to close the conversation on SIP overload >>> control algorithms. >>> >>> To recap, we had a decision on making loss-based as the default >>> mandatory-to-implement algorithm and had agreed to allow the >>> choice of rate- and windows-based algorithms. >>> >>> This is what's currently reflected in the protocol draft [1]. >>> >>> During the Prague IETF, it was suggested that we revisit this >>> decision and use only one algorithm. This suggestion lead to a >>> subsequent thread [2] about which algorithm should be chosen --- >>> loss-, rate- or windows-based one. >>> >>> I think we have to be realistic here in recognizing that the >>> relative performance of all the algorithms is about the same. So >>> therefore, if the relative performance is the same then there may >>> be certain network deployments where the choice of one algorithm >>> seems better than the other. >>> >>> Rate-based one will work well in managed networks where the set >>> of upstream clients sending requests is bounded and rather >>> static; this also makes it easier to apply capacity guarantees. >>> Loss-based one works well where the set of upstream clients >>> sending traffic is unbounded and frequently changing. >>> >>> The loss-based algorithm is less complex than the rate-based one >>> or the windows-based one. >>> >>> Phil Williams has put out a proposal [3] to support all three >>> algorithms simultaneously, thereby eliminating the need for >>> protocol machinations to choose one. However, issues still >>> remain: first, this will force implementations to implement all >>> of the algorithms, and this I believe is a heavy burden. >>> >>> Second, it does not eliminate the need or the desire to change >>> algorithms mid stream, and finally, this decision forces an >>> overloaded server to maintain considerable state as to which >>> particular algorithm has been chosen with the paired upstream >>> client. >>> >>> It seems that we are at an impasse. >>> >>> So, let me suggest another concrete proposal, which will help >>> move the work forward expeditiously if all agree. >>> >>> I propose that draft-ietf-soc-overload-control continue as it is >>> now with the following exception: >>> >>> 1) Take window class out of the mix, leaving rate and loss. No >>> one is explicitly championing the windows-based one; it could be >>> added later if desired. >>> >>> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >>> working on a rate-based draft that uses the agreement mechanisms >>> defined in draft-ietf-soc-overload-control and fleshes out how >>> rate-based mechanism will function. >>> >>> 3) Move draft-ietf-soc-overload-control and the new draft in (2) >>> as a bundle so that no one algorithm gets an undue advantage of >>> being specified first. >>> >>> Note that (2) and (3) effectively mitigate Phil's concern that >>> "proceeding with a single mandated algorithm would result in >>> non-adoption of the other algorithms by suppliers and in effect >>> the alternatives would become redundant." >>> >>> Personally I do not think that the market will favour a >>> sub-optimal algorithm and if loss-based does not work I am sure >>> it will be replaced in short order. But I do empathize with the >>> perceived advantage that loss-based one seems to benefit from if >>> it is made the only mandatory-to-implement algorithm in [1]. >>> Therefore, (2) and (3) above should mitigate this particular >>> concern. >>> >>> I suspect what will end up happening is that implementations >>> geared to managed network providers will end up supporting both >>> loss- and rate-based algorithms while other implementations can >>> support only the loss-based one. >>> >>> Do folks think that this is an agreeable compromise? It is no >>> worse off than what we had agreed to before, and in fact it is >>> much better since we have eliminated windows-based one and are >>> moving loss-based and rate-based ahead at the same time. >>> >>> I do note that the chairs may have to re-negotiate the charter >>> deliverables with the ADs, but modifying the charter or deciding >>> to make the rate-based draft as an extension to the second >>> deliverable ("2. A specification for an SIP overload control >>> mechanism based on implicit/explicit feedback.") is a minor >>> detail once everyone agrees to this proposal. >>> >>> Please comment. Thank you. >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 [2] >>> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html >>> >>> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.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/ >>> _______________________________________________ sip-overload >>> mailing list sip-overload@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-overload >> >> _______________________________________________ sip-overload >> mailing list sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ sip-overload mailing > list sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From volker.hilt@alcatel-lucent.com Tue Jul 12 17:14:57 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9416B21F8B75 for ; Tue, 12 Jul 2011 17:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeLFBES5yWrY for ; Tue, 12 Jul 2011 17:14:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0068621F8B73 for ; Tue, 12 Jul 2011 17:14:52 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p6D0EoS5028595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2011 19:14:50 -0500 (CDT) 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 p6D0Eo7C021163 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Jul 2011 19:14:50 -0500 Received: from [135.244.35.137] (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, 12 Jul 2011 19:14:50 -0500 Message-ID: <4E1CE376.4090204@alcatel-lucent.com> Date: Tue, 12 Jul 2011 20:14:46 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "phil.m.williams@bt.com" References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> <4E1C5366.6070306@alcatel-lucent.com> In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:14:57 -0000 Phil, > > I pointed out in [1] that the server needs to determine the algorithm > to be used, otherwise it has to use an overload control method that > will support a mix of restriction algorithms on the client, which > would be significantly more complex for the server than the client > having to support two restriction algorithms (which I view as > relatively straightforward to specify and implement). For a server it is fairly easy to convert a loss value into a rate (or vice versa) if it has the data available that is needed for rate-based controls (current call rate, number of upstream neighbors,...). > Because the > draft spec does not specify the server algorithm, it gives the > illusion that most complexity is in the client, whereas in reality it > is most likely to be on the server. > With the current proposal it is possible to build a simple client and server with effective overload control and to go for a more complex mechanism depending on the targeted scenario and use case. > In [2] I gave an example modification of the draft whereby the client > algorithms are mandatory, which removes the complexity of the > negotiation as well. > I believe it is fairly simple for client and server to agree. There are four cases: - Client and Server support A and B. * Client sends AB to server. * Server responds with A or with B (e.g., depending on configuration). - Client supports A and B. Server supports A. * Client sends AB to server * Server responds with A. - Client supports A. Server supports A and B * Client sends A to server. * Server responds with A. - Client supports A. Server supports A * same as above. Thanks, Volker (as individual) > -----Original Message----- From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent: > 12 July 2011 15:00 To: sip-overload@ietf.org Subject: Re: > [sip-overload] A modest (and new) proposal on multiple algorithms for > overload control > > Hadriel, > > the idea is to have a mandatory algorithm in the base draft and, at > the same time, to leave the draft open for extensions to other > algorithms. The second draft will then specify such an algorithm. > > That way RFC A is the common denominator supported by all devices > and advanced devices can implement RFC A and B. > > Thanks, > > Volker (as individual) > > > > > > On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: >> >> So in summary you're proposing to resolve the issue that having two >> mechanisms is a bad idea, by specifying the two mechanisms in two >> separate docs?? >> >> OK, well if we have to have two ways of doing the same thing, then >> I suggest we MANDATE BOTH, by putting them in the same document and >> a "MUST implement both" written right in it. Otherwise, if you have >> RFC A and RFC B, then some devices will do A and others B and there >> won't be interop. >> >> -hadriel >> >> >> On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: >> >>> Folks: I am trying to close the conversation on SIP overload >>> control algorithms. >>> >>> To recap, we had a decision on making loss-based as the default >>> mandatory-to-implement algorithm and had agreed to allow the >>> choice of rate- and windows-based algorithms. >>> >>> This is what's currently reflected in the protocol draft [1]. >>> >>> During the Prague IETF, it was suggested that we revisit this >>> decision and use only one algorithm. This suggestion lead to a >>> subsequent thread [2] about which algorithm should be chosen --- >>> loss-, rate- or windows-based one. >>> >>> I think we have to be realistic here in recognizing that the >>> relative performance of all the algorithms is about the same. So >>> therefore, if the relative performance is the same then there may >>> be certain network deployments where the choice of one algorithm >>> seems better than the other. >>> >>> Rate-based one will work well in managed networks where the set >>> of upstream clients sending requests is bounded and rather >>> static; this also makes it easier to apply capacity guarantees. >>> Loss-based one works well where the set of upstream clients >>> sending traffic is unbounded and frequently changing. >>> >>> The loss-based algorithm is less complex than the rate-based one >>> or the windows-based one. >>> >>> Phil Williams has put out a proposal [3] to support all three >>> algorithms simultaneously, thereby eliminating the need for >>> protocol machinations to choose one. However, issues still >>> remain: first, this will force implementations to implement all >>> of the algorithms, and this I believe is a heavy burden. >>> >>> Second, it does not eliminate the need or the desire to change >>> algorithms mid stream, and finally, this decision forces an >>> overloaded server to maintain considerable state as to which >>> particular algorithm has been chosen with the paired upstream >>> client. >>> >>> It seems that we are at an impasse. >>> >>> So, let me suggest another concrete proposal, which will help >>> move the work forward expeditiously if all agree. >>> >>> I propose that draft-ietf-soc-overload-control continue as it is >>> now with the following exception: >>> >>> 1) Take window class out of the mix, leaving rate and loss. No >>> one is explicitly championing the windows-based one; it could be >>> added later if desired. >>> >>> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >>> working on a rate-based draft that uses the agreement mechanisms >>> defined in draft-ietf-soc-overload-control and fleshes out how >>> rate-based mechanism will function. >>> >>> 3) Move draft-ietf-soc-overload-control and the new draft in (2) >>> as a bundle so that no one algorithm gets an undue advantage of >>> being specified first. >>> >>> Note that (2) and (3) effectively mitigate Phil's concern that >>> "proceeding with a single mandated algorithm would result in >>> non-adoption of the other algorithms by suppliers and in effect >>> the alternatives would become redundant." >>> >>> Personally I do not think that the market will favour a >>> sub-optimal algorithm and if loss-based does not work I am sure >>> it will be replaced in short order. But I do empathize with the >>> perceived advantage that loss-based one seems to benefit from if >>> it is made the only mandatory-to-implement algorithm in [1]. >>> Therefore, (2) and (3) above should mitigate this particular >>> concern. >>> >>> I suspect what will end up happening is that implementations >>> geared to managed network providers will end up supporting both >>> loss- and rate-based algorithms while other implementations can >>> support only the loss-based one. >>> >>> Do folks think that this is an agreeable compromise? It is no >>> worse off than what we had agreed to before, and in fact it is >>> much better since we have eliminated windows-based one and are >>> moving loss-based and rate-based ahead at the same time. >>> >>> I do note that the chairs may have to re-negotiate the charter >>> deliverables with the ADs, but modifying the charter or deciding >>> to make the rate-based draft as an extension to the second >>> deliverable ("2. A specification for an SIP overload control >>> mechanism based on implicit/explicit feedback.") is a minor >>> detail once everyone agrees to this proposal. >>> >>> Please comment. Thank you. >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 [2] >>> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html >>> >>> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.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/ >>> _______________________________________________ sip-overload >>> mailing list sip-overload@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-overload >> >> _______________________________________________ sip-overload >> mailing list sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ sip-overload mailing > list sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From ecnoel@research.att.com Wed Jul 13 06:52:41 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44BA21F86C1 for ; Wed, 13 Jul 2011 06:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHw1sLH9LIAw for ; Wed, 13 Jul 2011 06:52:37 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 587D421F86BD for ; Wed, 13 Jul 2011 06:52:23 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id D58FB120376 for ; Wed, 13 Jul 2011 09:52:22 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id C69E18533 for ; Wed, 13 Jul 2011 09:52:22 -0400 (EDT) Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 13 Jul 2011 09:51:58 -0400 From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: Wed, 13 Jul 2011 09:56:01 -0400 Thread-Topic: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control Thread-Index: AcxA7/DbmDQ4or4bR6uU5WVmiC207QAbtAwA Message-ID: <2F8FB48C17221643AD77FA295756D2A71E23BA1C4B@njfpsrvexg6.research.att.com> References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> <4E1C5366.6070306@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A71E23BA1BE5@njfpsrvexg6.research.att.com> <4E1CDFDB.10704@alcatel-lucent.com> In-Reply-To: <4E1CDFDB.10704@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:52:42 -0000 Volker, Vijay, It seems that a compromise would be to maintain the original objective, nam= ely have draft-ietf-soc-overload-control-02 specify: (1) the signaling mechanism by which servers and clients exchange overload = control messages, (2) a default overload control algorithm that uses the proposed signaling m= echanism. That means draft-ietf-soc-overload-control-02 needs to be adjusted so as to= make it clear that the main goal for that document is to define a signalin= g mechanism to support overload control for SIP. (In my opinion, the curre= nt version of draft-ietf-soc-overload-control-02 is too loss rate control c= entric.) In particular, draft-ietf-soc-overload-control-02 needs to have one section= to define the signaling mechanism, independently of any overload control a= lgorithms. And another section to define a default control algorithm that u= tilizes the proposed signaling mechanism. =20 Finally, separate specifications that define other overload control algorit= hms based on the signaling mechanism defined in draft-ietf-soc-overload-con= trol-02 could be proposed. For instance, a rate control algorithm co-author= ed by Phil Williams, Eric Noel, and Janet Gunn (and/or others). Thanks, Eric Noel=20 LMTS AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: Volker Hilt [mailto:volker.hilt@alcatel-lucent.com]=20 Sent: Tuesday, July 12, 2011 7:59 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorit= hms for overload control Eric, > > I understand the need to have a simple default algorithm in this RFC > and I also agree it should not preclude extension to other > algorithms. > > However, my interpretation of draft-ietf-soc-overload-control-02 is > that on one hand it allows for different class of algorithms to be > used through the oc-algo parameter, and on the other hand it excludes > other algorithms by limiting the oc parameter value to a loss rate > percentage (MUST be a number between 0 and 100) irrespective of the > selected oc-algo parameter. > > Provided my interpretation is correct, could > draft-ietf-soc-overload-control-02 be modified so that the oc > parameter is a loss rate percentage only when used with the default > algorithm? > Yes! If, for example, a rate-based is used then the feedback needs to be=20 a rate. There is no need to transmit loss value in this case. > If there is a push for multiple simultaneous RFCs, then should not > draft-ietf-soc-overload-control-02 require oc-algo to be set to the > value "loss-control" with no mentioning of other controls? > Yes, that would make sense. A separate draft can then define other=20 values and the corresponding feedback transmission. Thanks, Volker (as individual) > > > -----Original Message----- From: sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent: > Tuesday, July 12, 2011 10:00 AM To: sip-overload@ietf.org Subject: > Re: [sip-overload] A modest (and new) proposal on multiple algorithms > for overload control > > Hadriel, > > the idea is to have a mandatory algorithm in the base draft and, at > the same time, to leave the draft open for extensions to other > algorithms. The second draft will then specify such an algorithm. > > That way RFC A is the common denominator supported by all devices > and advanced devices can implement RFC A and B. > > Thanks, > > Volker (as individual) > > > > > > On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: >> >> So in summary you're proposing to resolve the issue that having two >> mechanisms is a bad idea, by specifying the two mechanisms in two >> separate docs?? >> >> OK, well if we have to have two ways of doing the same thing, then >> I suggest we MANDATE BOTH, by putting them in the same document and >> a "MUST implement both" written right in it. Otherwise, if you have >> RFC A and RFC B, then some devices will do A and others B and there >> won't be interop. >> >> -hadriel >> >> >> On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: >> >>> Folks: I am trying to close the conversation on SIP overload >>> control algorithms. >>> >>> To recap, we had a decision on making loss-based as the default >>> mandatory-to-implement algorithm and had agreed to allow the >>> choice of rate- and windows-based algorithms. >>> >>> This is what's currently reflected in the protocol draft [1]. >>> >>> During the Prague IETF, it was suggested that we revisit this >>> decision and use only one algorithm. This suggestion lead to a >>> subsequent thread [2] about which algorithm should be chosen --- >>> loss-, rate- or windows-based one. >>> >>> I think we have to be realistic here in recognizing that the >>> relative performance of all the algorithms is about the same. So >>> therefore, if the relative performance is the same then there may >>> be certain network deployments where the choice of one algorithm >>> seems better than the other. >>> >>> Rate-based one will work well in managed networks where the set >>> of upstream clients sending requests is bounded and rather >>> static; this also makes it easier to apply capacity guarantees. >>> Loss-based one works well where the set of upstream clients >>> sending traffic is unbounded and frequently changing. >>> >>> The loss-based algorithm is less complex than the rate-based one >>> or the windows-based one. >>> >>> Phil Williams has put out a proposal [3] to support all three >>> algorithms simultaneously, thereby eliminating the need for >>> protocol machinations to choose one. However, issues still >>> remain: first, this will force implementations to implement all >>> of the algorithms, and this I believe is a heavy burden. >>> >>> Second, it does not eliminate the need or the desire to change >>> algorithms mid stream, and finally, this decision forces an >>> overloaded server to maintain considerable state as to which >>> particular algorithm has been chosen with the paired upstream >>> client. >>> >>> It seems that we are at an impasse. >>> >>> So, let me suggest another concrete proposal, which will help >>> move the work forward expeditiously if all agree. >>> >>> I propose that draft-ietf-soc-overload-control continue as it is >>> now with the following exception: >>> >>> 1) Take window class out of the mix, leaving rate and loss. No >>> one is explicitly championing the windows-based one; it could be >>> added later if desired. >>> >>> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start >>> working on a rate-based draft that uses the agreement mechanisms >>> defined in draft-ietf-soc-overload-control and fleshes out how >>> rate-based mechanism will function. >>> >>> 3) Move draft-ietf-soc-overload-control and the new draft in (2) >>> as a bundle so that no one algorithm gets an undue advantage of >>> being specified first. >>> >>> Note that (2) and (3) effectively mitigate Phil's concern that >>> "proceeding with a single mandated algorithm would result in >>> non-adoption of the other algorithms by suppliers and in effect >>> the alternatives would become redundant." >>> >>> Personally I do not think that the market will favour a >>> sub-optimal algorithm and if loss-based does not work I am sure >>> it will be replaced in short order. But I do empathize with the >>> perceived advantage that loss-based one seems to benefit from if >>> it is made the only mandatory-to-implement algorithm in [1]. >>> Therefore, (2) and (3) above should mitigate this particular >>> concern. >>> >>> I suspect what will end up happening is that implementations >>> geared to managed network providers will end up supporting both >>> loss- and rate-based algorithms while other implementations can >>> support only the loss-based one. >>> >>> Do folks think that this is an agreeable compromise? It is no >>> worse off than what we had agreed to before, and in fact it is >>> much better since we have eliminated windows-based one and are >>> moving loss-based and rate-based ahead at the same time. >>> >>> I do note that the chairs may have to re-negotiate the charter >>> deliverables with the ADs, but modifying the charter or deciding >>> to make the rate-based draft as an extension to the second >>> deliverable ("2. A specification for an SIP overload control >>> mechanism based on implicit/explicit feedback.") is a minor >>> detail once everyone agrees to this proposal. >>> >>> Please comment. Thank you. >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 [2] >>> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html >>> >>> [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.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/ >>> _______________________________________________ sip-overload >>> mailing list sip-overload@ietf.org >>> https://www.ietf.org/mailman/listinfo/sip-overload >> >> _______________________________________________ sip-overload >> mailing list sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > _______________________________________________ sip-overload mailing > list sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From iesg-secretary@ietf.org Wed Jul 13 13:05:48 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385B721F8532; Wed, 13 Jul 2011 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN4+bLn23-MY; Wed, 13 Jul 2011 13:05:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACE621F853D; Wed, 13 Jul 2011 13:05:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110713200547.26576.32049.idtracker@ietfa.amsl.com> Date: Wed, 13 Jul 2011 13:05:47 -0700 Cc: soc chair , soc mailing list , RFC Editor Subject: [sip-overload] Document Action: 'Design Considerations for Session Initiation Protocol (SIP) Overload Control' to Informational RFC (draft-ietf-soc-overload-design-08.txt) X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:05:48 -0000 The IESG has approved the following document: - 'Design Considerations for Session Initiation Protocol (SIP) Overload Control' (draft-ietf-soc-overload-design-08.txt) as an Informational RFC This document is the product of the SIP Overload Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/ Technical Summary 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 discusses models and design considerations for a SIP overload control mechanism. Working Group Summary This document was originally started by an ad-hoc Design Team within the SIPPING wg. The document was then adopted by the SIP Overload Control WG once it has been created. Document Quality The draft is a design considerations document and therefore there are no implementations. There are implementations of drafts that are based on the design considerations draft. The document was reviewed in an early stage by the transport area. Version 04 of the draft has also received a second review by Pasi Lassila, an expert on control theory at Aalto university (in Finland) identified by Lars Eggert. Personnel Salvatore Loreto is the Document Shepherd Robert Sparks is the Responsible RAI AD From charles.newyork@gmail.com Mon Jul 18 08:43:16 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7621F8C69 for ; Mon, 18 Jul 2011 08:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fFBlHymcBwE for ; Mon, 18 Jul 2011 08:43:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2EBA21F8BDC for ; Mon, 18 Jul 2011 08:43:11 -0700 (PDT) Received: by iwn39 with SMTP id 39so3452474iwn.31 for ; Mon, 18 Jul 2011 08:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=4L8N48TxdXaY7vvmp4hKOKdcUff5NgOLzE7DsgGXJc4=; b=wY2UaKoTTKYrQeTu+ZPofmtkz9DezBrkAxzlTLHgHxeYe/6p3LlQq/OU3sVyEWysFP mMgQhj9oH1KvLP92ezNnjB/LYcfqWwWsJ25hPF7Jo+nrCBLeueyaTDfHc5MH+9HzdK5g UXPK0U3hK6cQyoLHcs0/kpEHHliK3q0/06RmU= Received: by 10.42.28.10 with SMTP id l10mr7911335icc.299.1311003790177; Mon, 18 Jul 2011 08:43:10 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.42.179.201 with HTTP; Mon, 18 Jul 2011 08:42:50 -0700 (PDT) From: Charles Shen Date: Mon, 18 Jul 2011 11:42:50 -0400 X-Google-Sender-Auth: vwsNxtLqn8zupaMBjBwdZskadCA Message-ID: To: sip-overload@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Volker Hilt , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] draft-ietf-soc-load-control-event-package-01.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:43:16 -0000 Hi all I am re-sending a request for comments on the load control event package draft: http://www.ietf.org/internet-drafts/draft-ietf-soc-load-cont= rol-event-package-01.txt Minutes from the last IETF indicates "the need to refine the texts in section 9 (RFC5390requirements).", we would appreciate people posting more details about their thoughts so we can make necessary adjustments and move forward. Thanks Charles On Thu, Apr 28, 2011 at 1:54 PM, Salvatore Loreto wrote: > Hi there, > > below the notes from the SoC session during the IETF80 meeting in Prague. > (I have already uploaded this initial version to ietf proceeding site) > > Please review them and submit any correction to the chairs by May 11. > The chairs have to send the notes toproceedings at ietf.org =C3=82by May1= 8th. > > (many thanks to Partha for taking notes during the meeting) > > cheers > /Sal > > -- > Salvatore Loreto > www.sloreto.com > > snipped > Load control Event package (Presenter: Arate Koike) > ------------------------- > Some people expressed the need to refine the texts in > section 9 (RFC5390 requirements). > > > snipped From phil.m.williams@bt.com Fri Jul 22 03:44:20 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3B21F869E for ; Fri, 22 Jul 2011 03:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ry40rF9ZsdS for ; Fri, 22 Jul 2011 03:44:19 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF0D21F85CA for ; Fri, 22 Jul 2011 03:44:19 -0700 (PDT) Received: from EVHUB70-UKRD.domain1.systemhost.net (10.36.3.153) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 22 Jul 2011 11:44:18 +0100 Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVHUB70-UKRD.domain1.systemhost.net (10.36.3.153) with Microsoft SMTP Server (TLS) id 14.1.323.0; Fri, 22 Jul 2011 11:44:18 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.2.170]) by EVMHT01-UKBR.domain1.systemhost.net ([193.113.108.42]) with mapi; Fri, 22 Jul 2011 11:44:16 +0100 From: To: Date: Fri, 22 Jul 2011 11:44:03 +0100 Thread-Topic: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control Thread-Index: AcxA8eXEigFNFdZDRXy77kULRIEu9gHZfQkQ Message-ID: References: <4E08FA57.7040807@bell-labs.com> <98176208-B87E-4D73-A84B-0E625132F4C9@acmepacket.com> <4E1C5366.6070306@alcatel-lucent.com> <4E1CE376.4090204@alcatel-lucent.com> In-Reply-To: <4E1CE376.4090204@alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 10:44:21 -0000 Thanks Volker, Comment below. I aim to try and attend the Quebec meeting remotely, Regards, Phil=20 > -----Original Message----- > From: Volker Hilt [mailto:volker.hilt@alcatel-lucent.com] > Sent: 13 July 2011 01:15 > To: Williams,PM,Phil,DEV6 R > Cc: sip-overload@ietf.org > Subject: Re: [sip-overload] A modest (and new) proposal on multiple > algorithms for overload control >=20 > Phil, > > > > I pointed out in [1] that the server needs to determine the algorithm > > to be used, otherwise it has to use an overload control method that > > will support a mix of restriction algorithms on the client, which > > would be significantly more complex for the server than the client > > having to support two restriction algorithms (which I view as > > relatively straightforward to specify and implement). >=20 > For a server it is fairly easy to convert a loss value into a rate (or > vice versa) if it has the data available that is needed for rate-based > controls (current call rate, number of upstream neighbors,...). [PhilW] Whilst it is possible to map between loss based and rate-based per = client-server stream by measuring the applied parameter and the arrival rat= e at the server, this requires measuring the arrival rate from each client = individually, and there will be implications for update frequency and contr= ol stability because some of these traffic streams will be relatively small= , particularly if the number of upstream neighbours is large. With a pure l= oss-based or pure rate-based schemes it is possible to design the server al= gorithm to have some nice/useful properties whilst only measuring the total= arrival rate and not that from each upstream client. For example with loss= -based method one can use the same loss proportion for every source, which = makes both adaptation simple and will satisfy one interpretation of fairnes= s. On the other hand for rate-based restriction one can get some nice behav= iours (and satisfying another interpretation of fairness) with clients deri= ved from minimum guarantees plus use of unused rate in a precise way, again= by only measuring the total arrival rate (some clients may send at below t= he max control rate received). To re-iterate my concern: if the two restriction algorithms are not made ma= ndatory for the clients, my suggestion is that it puts a greater burden on = the design of the server algorithm than that of the clients. >=20 > > Because the > > draft spec does not specify the server algorithm, it gives the > > illusion that most complexity is in the client, whereas in reality it > > is most likely to be on the server. > > > With the current proposal it is possible to build a simple client and > server with effective overload control and to go for a more complex > mechanism depending on the targeted scenario and use case. >=20 > > In [2] I gave an example modification of the draft whereby the client > > algorithms are mandatory, which removes the complexity of the > > negotiation as well. > > > I believe it is fairly simple for client and server to agree. There are > four cases: > - Client and Server support A and B. > * Client sends AB to server. > * Server responds with A or with B (e.g., depending on > configuration). > - Client supports A and B. Server supports A. > * Client sends AB to server > * Server responds with A. > - Client supports A. Server supports A and B > * Client sends A to server. > * Server responds with A. > - Client supports A. Server supports A > * same as above. [PhilW] OK, but not if the server wants B but the client only supports A! >=20 > Thanks, >=20 > Volker (as individual) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- From: sip-overload-bounces@ietf.org > > [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent: > > 12 July 2011 15:00 To: sip-overload@ietf.org Subject: Re: > > [sip-overload] A modest (and new) proposal on multiple algorithms for > > overload control > > > > Hadriel, > > > > the idea is to have a mandatory algorithm in the base draft and, at > > the same time, to leave the draft open for extensions to other > > algorithms. The second draft will then specify such an algorithm. > > > > That way RFC A is the common denominator supported by all devices > > and advanced devices can implement RFC A and B. > > > > Thanks, > > > > Volker (as individual) > > > > > > > > > > > > On 7/12/2011 9:09 AM, Hadriel Kaplan wrote: > >> > >> So in summary you're proposing to resolve the issue that having two > >> mechanisms is a bad idea, by specifying the two mechanisms in two > >> separate docs?? > >> > >> OK, well if we have to have two ways of doing the same thing, then > >> I suggest we MANDATE BOTH, by putting them in the same document and > >> a "MUST implement both" written right in it. Otherwise, if you have > >> RFC A and RFC B, then some devices will do A and others B and there > >> won't be interop. > >> > >> -hadriel > >> > >> > >> On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote: > >> > >>> Folks: I am trying to close the conversation on SIP overload > >>> control algorithms. > >>> > >>> To recap, we had a decision on making loss-based as the default > >>> mandatory-to-implement algorithm and had agreed to allow the > >>> choice of rate- and windows-based algorithms. > >>> > >>> This is what's currently reflected in the protocol draft [1]. > >>> > >>> During the Prague IETF, it was suggested that we revisit this > >>> decision and use only one algorithm. This suggestion lead to a > >>> subsequent thread [2] about which algorithm should be chosen --- > >>> loss-, rate- or windows-based one. > >>> > >>> I think we have to be realistic here in recognizing that the > >>> relative performance of all the algorithms is about the same. So > >>> therefore, if the relative performance is the same then there may > >>> be certain network deployments where the choice of one algorithm > >>> seems better than the other. > >>> > >>> Rate-based one will work well in managed networks where the set > >>> of upstream clients sending requests is bounded and rather > >>> static; this also makes it easier to apply capacity guarantees. > >>> Loss-based one works well where the set of upstream clients > >>> sending traffic is unbounded and frequently changing. > >>> > >>> The loss-based algorithm is less complex than the rate-based one > >>> or the windows-based one. > >>> > >>> Phil Williams has put out a proposal [3] to support all three > >>> algorithms simultaneously, thereby eliminating the need for > >>> protocol machinations to choose one. However, issues still > >>> remain: first, this will force implementations to implement all > >>> of the algorithms, and this I believe is a heavy burden. > >>> > >>> Second, it does not eliminate the need or the desire to change > >>> algorithms mid stream, and finally, this decision forces an > >>> overloaded server to maintain considerable state as to which > >>> particular algorithm has been chosen with the paired upstream > >>> client. > >>> > >>> It seems that we are at an impasse. > >>> > >>> So, let me suggest another concrete proposal, which will help > >>> move the work forward expeditiously if all agree. > >>> > >>> I propose that draft-ietf-soc-overload-control continue as it is > >>> now with the following exception: > >>> > >>> 1) Take window class out of the mix, leaving rate and loss. No > >>> one is explicitly championing the windows-based one; it could be > >>> added later if desired. > >>> > >>> 2) Invite Phil Williams, Eric Noel, or Janet Gunn to start > >>> working on a rate-based draft that uses the agreement mechanisms > >>> defined in draft-ietf-soc-overload-control and fleshes out how > >>> rate-based mechanism will function. > >>> > >>> 3) Move draft-ietf-soc-overload-control and the new draft in (2) > >>> as a bundle so that no one algorithm gets an undue advantage of > >>> being specified first. > >>> > >>> Note that (2) and (3) effectively mitigate Phil's concern that > >>> "proceeding with a single mandated algorithm would result in > >>> non-adoption of the other algorithms by suppliers and in effect > >>> the alternatives would become redundant." > >>> > >>> Personally I do not think that the market will favour a > >>> sub-optimal algorithm and if loss-based does not work I am sure > >>> it will be replaced in short order. But I do empathize with the > >>> perceived advantage that loss-based one seems to benefit from if > >>> it is made the only mandatory-to-implement algorithm in [1]. > >>> Therefore, (2) and (3) above should mitigate this particular > >>> concern. > >>> > >>> I suspect what will end up happening is that implementations > >>> geared to managed network providers will end up supporting both > >>> loss- and rate-based algorithms while other implementations can > >>> support only the loss-based one. > >>> > >>> Do folks think that this is an agreeable compromise? It is no > >>> worse off than what we had agreed to before, and in fact it is > >>> much better since we have eliminated windows-based one and are > >>> moving loss-based and rate-based ahead at the same time. > >>> > >>> I do note that the chairs may have to re-negotiate the charter > >>> deliverables with the ADs, but modifying the charter or deciding > >>> to make the rate-based draft as an extension to the second > >>> deliverable ("2. A specification for an SIP overload control > >>> mechanism based on implicit/explicit feedback.") is a minor > >>> detail once everyone agrees to this proposal. > >>> > >>> Please comment. Thank you. > >>> > >>> [1] > >>> http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 [2] > >>> http://www.ietf.org/mail-archive/web/sip- > overload/current/msg00616.html > >>> > >>> > [3] http://www.ietf.org/mail-archive/web/sip- > overload/current/msg00629.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/ > >>> _______________________________________________ sip-overload > >>> mailing list sip-overload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sip-overload > >> > >> _______________________________________________ sip-overload > >> mailing list sip-overload@ietf.org > >> https://www.ietf.org/mailman/listinfo/sip-overload > > _______________________________________________ sip-overload mailing > > list sip-overload@ietf.org > > https://www.ietf.org/mailman/listinfo/sip-overload From vkg@bell-labs.com Fri Jul 22 13:24:33 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C11C21F8AFD for ; Fri, 22 Jul 2011 13:24:33 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwtdTsXC7gla for ; Fri, 22 Jul 2011 13:24:32 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B91AF21F88A6 for ; Fri, 22 Jul 2011 13:24:32 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p6MKOUEq008963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Jul 2011 15:24:30 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6MKOTgY022921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 22 Jul 2011 15:24:30 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p6MKOTar002188 for ; Fri, 22 Jul 2011 15:24:29 -0500 (CDT) Message-ID: <4E29DCCE.5020208@bell-labs.com> Date: Fri, 22 Jul 2011 15:25:50 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b2 Thunderbird/3.1.11 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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [sip-overload] So, where are we on multiple algorithms...? X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 20:24:33 -0000 Folks: Sorry for the silence. I was on vacation, blissfully unaware of all things SOC ;-) I have caught up on the mailing list on the thread I opened [1] before I left for vacation. By and large, I note that most people think that this is a reasonable way to proceed. I think that Eric's follow-up email [2] in the thread nicely summarizes next steps. I am fine with this approach. This, then leaves us with Phil's objection outlined in [3], and summarized in the following sentence from his email: I believe that it would add considerable complexity to design an algorithm on the (overloaded) server that gives acceptable/desirable results when clients are operating a mix of algorithms. It would be nice if we could run simulations showing the effect on the overloaded server when the clients are running a mix of algorithms, but maybe the effects are not too onerous ...? After all, we have jettisoned windows-based one so we are now talking about clients supporting at most two algorithms. In the end, I go back to my contention that we have to be realistic here in recognizing that the relative performance of all the algorithms is about the same. So therefore, if the relative performance is the same then there may be certain network deployments where the choice of one algorithm seems better than the other. Rate-based one will work well in managed networks where the set of upstream clients sending requests is bounded and rather static; this also makes it easier to apply capacity guarantees. Loss-based one works well where the set of upstream clients sending traffic is unbounded and frequently changing. Are there deployments where a SIP server is running in a managed network and serving N upstream clients, N/2 of which are in managed networks and N/2 in unmanaged networks? If not, maybe we should proceed as outlined in [1] and finish this work. Thoughts? Can we proceed as outlined in [1, 2]? Thanks, [1] http://www.ietf.org/mail-archive/web/sip-overload/current/threads.html#00631 [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00646.html [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00632.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/ From phil.m.williams@bt.com Tue Jul 26 03:40:32 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D421F86EE for ; Tue, 26 Jul 2011 03:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bho2GsVSCn0P for ; Tue, 26 Jul 2011 03:40:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36421F86C4 for ; Tue, 26 Jul 2011 03:40:28 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 11:40:27 +0100 Received: from E07HT01-UKBR.domain1.systemhost.net (193.113.197.94) by EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 26 Jul 2011 11:40:26 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.2.170]) by E07HT01-UKBR.domain1.systemhost.net ([193.113.197.94]) with mapi; Tue, 26 Jul 2011 11:40:25 +0100 From: To: , Date: Tue, 26 Jul 2011 11:40:14 +0100 Thread-Topic: [sip-overload] So, where are we on multiple algorithms...? Thread-Index: AcxIrWCx2x3RiGbNSq2I0FGQ/E59hgCwSYNw Message-ID: References: <4E29DCCE.5020208@bell-labs.com> In-Reply-To: <4E29DCCE.5020208@bell-labs.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sip-overload] So, where are we on multiple algorithms...? X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 10:40:32 -0000 Vijay, Conscious that I may be seen as a spanner in the works... I like Eric's suggestion to separate the protocol support from the specific= restriction algorithm. But I still have reservations about the idea of a default algorithm. My gue= ss is that is that the likely consequences of this are some combination of: * Being difficult to deploy a non-default algorithm; * Force latent complexity on the server, which isn't within scope of the RF= C; * Suppliers having to give support two restriction algorithms on the client= anyway in order to interwork with different deployments, one where the def= ault is used, and another where it isn't (obviating the need for the algori= thm negotiation part of the protocol). I would like to see the server as master over the clients, i.e. it would be= up to the server to dictate which restriction algorithm to use, or indeed = to use more than one for some network architectures (see some further rambl= ings below). Some further responses below. Regards, Phil Dr Philip M Williams=20 Performance Analyst BT Innovate & Design=20 Floor 3, Orion Building (B62-MH)=20 Adastral Park=20 Martlesham Heath=20 IPSWICH=20 IP5 3RE=20 Phone:=A0 +44 1473 651709 (office: recorded answering facility)=20 =A0=A0=A0=A0=A0=A0=A0 +44 1473 250133 (home: no recorded answering facility= )=20 Email:=A0 phil.m.williams@bt.com=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: 22 July 2011 21:26 > To: sip-overload@ietf.org > Subject: [sip-overload] So, where are we on multiple algorithms...? >=20 > Folks: Sorry for the silence. I was on vacation, blissfully > unaware of all things SOC ;-) >=20 > I have caught up on the mailing list on the thread I opened [1] > before I left for vacation. >=20 > By and large, I note that most people think that this is a > reasonable way to proceed. I think that Eric's follow-up > email [2] in the thread nicely summarizes next steps. I am > fine with this approach. >=20 > This, then leaves us with Phil's objection outlined in > [3], and summarized in the following sentence from his > email: >=20 > I believe that it would add considerable > complexity to design an algorithm on the (overloaded) > server that gives acceptable/desirable results when > clients are operating a mix of algorithms. >=20 > It would be nice if we could run simulations showing the > effect on the overloaded server when the clients are running > a mix of algorithms, but maybe the effects are not too > onerous ...? After all, we have jettisoned windows-based > one so we are now talking about clients supporting at most > two algorithms. [PhilW] It depends on what you mean by onerous. In terms of processing load= , it may be more, but I don't see this as the main issue. It is the additio= nal complexity of designing the server control, and subtleties concerning m= onitoring traffic from each client. Whilst a simulation may be useful for t= rickier aspects of transient and stochastic effects, results about converge= nce and steady-state are usually not difficult to prove assuming simple pro= perties of a known adaptation algorithm at the server. A basic requirement= of any server algorithm is that it converges to a unique solution for a co= nstant offered traffic load. But you also want to know how the server's cap= acity is distributed amongst the clients, and that's where you get into que= stions about fairness and guarantees. There is an architecture I can envisa= ge where a mix of restriction algorithms could be deployed, which I raise b= elow... >=20 > In the end, I go back to my contention that we have to > be realistic here in recognizing that the relative performance > of all the algorithms is about the same. So therefore, if the > relative performance is the same then there may be certain network > deployments where the choice of one algorithm seems better than > the other. >=20 > Rate-based one will work well in managed networks where the set of > upstream clients sending requests is bounded and rather static; this > also makes it easier to apply capacity guarantees. Loss-based one > works well where the set of upstream clients sending traffic is > unbounded and frequently changing. >=20 > Are there deployments where a SIP server is running in a managed > network and serving N upstream clients, N/2 of which are in managed > networks and N/2 in unmanaged networks? If not, maybe we should > proceed as outlined in [1] and finish this work. [PhilW] A factor here is that we are in relatively early days with respect = to the deployment of SIP. However I can envisage an architecture where one = want to use a mix of restriction algorithms (N may not be partitioned into = two equal sizes, but rather as N+M). E.g. one might have a server at networ= k (operator) boundary using guarantees where one wants to use rate-based re= striction (N clients), and a fully meshed internal architecture (M clients)= where one might use loss-based (and perhaps M >> N?). Partitioning the inc= oming load on the server between the two network sides may be easier in thi= s case, where the interior load can be treated as one rate and then mapped = to proportional (loss-based) for interior control. >=20 > Thoughts? Can we proceed as outlined in [1, 2]? >=20 > Thanks, >=20 > [1] > http://www.ietf.org/mail-archive/web/sip- > overload/current/threads.html#00631 > [2] http://www.ietf.org/mail-archive/web/sip- > overload/current/msg00646.html > [3] http://www.ietf.org/mail-archive/web/sip- > overload/current/msg00632.html >=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 salvatore.loreto@ericsson.com Tue Jul 26 04:59:46 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79CE21F8C99 for ; Tue, 26 Jul 2011 04:59:46 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIimQaqbvjw5 for ; Tue, 26 Jul 2011 04:59:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id ED69221F8C8B for ; Tue, 26 Jul 2011 04:59:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d4-4e2eac30a2f5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.B8.20773.03CAE2E4; Tue, 26 Jul 2011 13:59:45 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 26 Jul 2011 13:59:44 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A9DFD2461 for ; Tue, 26 Jul 2011 14:59:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 688235119D for ; Tue, 26 Jul 2011 14:59:44 +0300 (EEST) Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E4FBA510EC for ; Tue, 26 Jul 2011 14:59:43 +0300 (EEST) Message-ID: <4E2EAC2F.8070602@ericsson.com> Date: Tue, 26 Jul 2011 07:59:43 -0400 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 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] remote participation today meeting X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:59:47 -0000 Hi there, if you are not in Quebec City, but you are interested to follow the today SoC discussion, this time we will have also the Meetecho tool for this aim, with Meetecho you have audio synchronized with slides and the jabber room. Check more information: http://www.ietf.org/meeting/81/remote-participation.html#Meetecho or you can alternative use, as usual, the audio stream: http://ietf81streaming.dnsalias.net/ietf/ietf802.m3u and the jabber room: soc@jabber.ietf.org all the information about the remote participation are available here: http://www.ietf.org/meeting/81/remote-participation.html cheers /Sal -- Salvatore Loreto www.sloreto.com From ietf@meetecho.com Tue Jul 26 09:13:30 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E535121F8B68 for ; Tue, 26 Jul 2011 09:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d2tO+Pfgi9a for ; Tue, 26 Jul 2011 09:13:30 -0700 (PDT) Received: from smtplqs01.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id D6EE521F8B43 for ; Tue, 26 Jul 2011 09:13:29 -0700 (PDT) Received: (qmail 18810 invoked by uid 89); 26 Jul 2011 16:13:28 -0000 Received: from unknown (HELO smtpw1.aruba.it) (62.149.128.188) by smtplqs01.aruba.it with SMTP; 26 Jul 2011 16:13:28 -0000 Received: (qmail 32550 invoked by uid 89); 26 Jul 2011 16:13:28 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 26 Jul 2011 16:13:28 -0000 Date: Tue, 26 Jul 2011 18:13:28 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: sip-overload@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs01.aruba.it 1.6.2 0/1000/N Subject: [sip-overload] Meetecho support for SOC WG meeting session X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 16:13:31 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system. =0A= =0AAccess to the on-line session (including audio and video streams) will= be available from 15:10 at:=0Ahttp://www.meetecho.com/ietf81/soc=0A=0ATh= e Meetecho session automatically logs you into the standard IETF jabber r= oom. So, from there, you can have an integrated experience involving all = media and allowing you to interact with the room.=0A=0AA tutorial of inte= ractivity features of the tool can be found at:=0Ahttp://www.meetecho.com= /ietf81/tutorials=0A=0AFor further information you can contact us at ietf= -support@meetecho.com.=0A=0ACheers,=0Athe Meetecho Team From ietf@meetecho.com Tue Jul 26 16:08:46 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1443111E80BE for ; Tue, 26 Jul 2011 16:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ued5DeVLMIB for ; Tue, 26 Jul 2011 16:08:45 -0700 (PDT) Received: from smtplqs01.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id F3EF011E809E for ; Tue, 26 Jul 2011 16:08:44 -0700 (PDT) Received: (qmail 31453 invoked by uid 89); 26 Jul 2011 23:08:42 -0000 Received: from unknown (HELO smtpw1.aruba.it) (62.149.128.188) by smtplqs01.aruba.it with SMTP; 26 Jul 2011 23:08:42 -0000 Received: (qmail 20049 invoked by uid 89); 26 Jul 2011 23:08:42 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 26 Jul 2011 23:08:42 -0000 Date: Wed, 27 Jul 2011 01:08:42 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: sip-overload@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs01.aruba.it 1.6.2 0/1000/N Subject: [sip-overload] SOC recording available X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:08:46 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room) =0Aof today's SOC session is available at the following URL:= =0A=0Ahttp://www.meetecho.com/ietf81/recordings=0A=0AFor the chair(s): pl= ease feel free to put the link to the recording in the minutes, if you th= ink this might be useful.=0A=0AIn case of problems with the playout, just= drop an e-mail to =0Aietf-support@meetecho.com.=0A=0ACheers,=0Athe Meete= cho Team