From vkg@bell-labs.com Tue Aug 6 14:57:57 2013 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 4D25B21F9F96 for ; Tue, 6 Aug 2013 14:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gv39g-c772X for ; Tue, 6 Aug 2013 14:57:52 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6333921F9AA1 for ; Tue, 6 Aug 2013 14:57:52 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r76Lvfgm001049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2013 16:57:42 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r76LvfS9031888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 16:57:41 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r76LveFD003025; Tue, 6 Aug 2013 16:57:40 -0500 (CDT) Message-ID: <52017265.4070409@bell-labs.com> Date: Tue, 06 Aug 2013 17:02:13 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Yu, James" , Christer Holmberg References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080A4D90@STNTEXMB10.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C41581A@ESESSMB209.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080A51DC@STNTEXMB10.cis.neustar.com> In-Reply-To: <56FB15AFE08E1242B0736CBDCE6E8561080A51DC@STNTEXMB10.cis.neustar.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "volkerh@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 06 Aug 2013 21:57:57 -0000 On 07/31/2013 01:05 PM, Yu, James wrote: > I agree with the change. James, Christer: I went through the minor change you are suggesting to the ABNF. Essentially, you want to change two things: - s/algo-list/algo-value/ - change the variable repetition rule such that it applies to the production definition of other-algo In terms of actual change, this is: OLD: oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list = "loss" / *(other-algo) other-algo = %x41-5A / %x61-7A / %x30-39 NEW: oc-algo = "oc-algo" EQUAL DQUOTE algo-value *(COMMA algo-value) DQUOTE algo-value = "loss" / other-algo other-algo = 1*(%x41-5A / %x61-7A / %x30-39) Note that this change does perturb the intent of the old production rule (as far as I can see it, at least). Either of the above grammars produce the following valid token sequence: oc-algo="loss" oc-algo="loss,rate" oc-algo="loss,rate,window" However, if the new change appears to read better, I am happy to change it as suggested. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From christer.holmberg@ericsson.com Tue Aug 6 23:26:57 2013 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 9C47821E804B for ; Tue, 6 Aug 2013 23:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJhp-NmliVp6 for ; Tue, 6 Aug 2013 23:26:53 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7957321E80E6 for ; Tue, 6 Aug 2013 23:26:52 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-cb-5201e8ab52fb Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6E.9E.05990.BA8E1025; Wed, 7 Aug 2013 08:26:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 08:26:50 +0200 From: Christer Holmberg To: "Vijay K. Gurbani" , "Yu, James" Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-13 Thread-Index: AQHOhxU3F7sJun9uH0SBY0IRumtD5plw/7kAgACg/lCADRiOAIAAMJyggAAXfgCACbAlgIAArKGg Date: Wed, 7 Aug 2013 06:26:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41F7B2@ESESSMB209.ericsson.se> References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C00@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E856108096C3D@stntexmb12.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C3FC99D@ESESSMB209.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080A4D90@STNTEXMB10.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B1C41581A@ESESSMB209.ericsson.se> <56FB15AFE08E1242B0736CBDCE6E8561080A51DC@STNTEXMB10.cis.neustar.com> <52017265.4070409@bell-labs.com> In-Reply-To: <52017265.4070409@bell-labs.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvre7qF4xBBs9+i1lc6VvJZLFoWojF /qcJFg1r5Cw2Lb/F7sDq0XfZxePrrYNMHkuW/GTy2NHwnDmAJYrLJiU1J7MstUjfLoEr4/p+ mYJDYhXPv09namD8IdrFyMkhIWAi0Tp5FQuELSZx4d56NhBbSOAwo0TPV/kuRi4gezGjxK5j P4CKODjYBCwkuv9pg9SICPhJzFs9hQWkhllgMqPE2rZlrCAJYQE7iflPJzNCFNlLvGt+zQJh R0ms3PcBbAGLgIrExI+z2EFsXgFfiad7fjJCLPvAKnFm+hqwBk4BXYnPt98wgdiMQNd9P7UG zGYWEJf4cPA6M8TVAhJL9pyHskUlXj7+xwphK0k0LnnCCnI0s4CmxPpd+hCtihJTuh9C7RWU ODnzCcsERrFZSKbOQuiYhaRjFpKOBYwsqxjZcxMzc9LLjTYxAiPp4JbfqjsY75wTOcQozcGi JM67We9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGh5CFp5zu5znvDp7N+TRI99MBlmvX XFl9a08Kqq7yD7aZGG4063d5Q9el8x9NfDRlZ9ZURnqlLn387tFcebULUZGXot6+rTr7TY1l reqOnMh1bw5/v6KZUHhpddNW+1STDLlbCwvZ+kQ+ix3d6nT7dldIXMvST6eszshMNvgdO+Hb b4mcyzr8SizFGYmGWsxFxYkAc+jYf3ICAAA= Cc: "volkerh@bell-labs.com" , "sip-overload@ietf.org" , "hgs@cs.columbia.edu" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13 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, 07 Aug 2013 06:26:57 -0000 SGkgVmlqYXksDQoNCllvdXIgc3VnZ2VzdGlvbiAoTkVXKSBpcyB3aGF0IEkgaGFkIGluIG1pbmQg OikNCg0KSnVzdCBvbmUgbW9yZSB0aGluZywgYXMgeW91IGFyZSBnb2luZyB0byB1cGRhdGUgdGhl IEFCTkY6IHdoeSBub3QgYWxzbyBzaW1wbHkgZGVmaW5lIG90aGVyLWFsZ28gYXM6DQoNCglvdGhl ci1hbGdvID0gIDEqKEFMUEhBIC8gRElHSVQpDQoNCkkgdGhpbmsgaXQgd291bGQgbWFrZSB0aGUg c3ludGF4IGV2ZW4gbW9yZSBjbGVhci4gQW5kLCB5b3UgZG9uJ3QgbmVlZCB0byBkZWZpbmUgQUxQ SEEgYW5kIERJR0lULCBidXQgc2ltcGx5IHJlZmVyIHRvIHRoZSBBQk5GIGNvcmUgc3BlYyA6KQ0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KLS0tLS1BbGt1cGVyw6RpbmVuIHZp ZXN0aS0tLS0tDQpMw6RoZXR0w6Rqw6Q6IFZpamF5IEsuIEd1cmJhbmkgW21haWx0bzp2a2dAYmVs bC1sYWJzLmNvbV0gDQpMw6RoZXRldHR5OiA3LiBlbG9rdXV0YSAyMDEzIDE6MDINClZhc3RhYW5v dHRhamE6IFl1LCBKYW1lczsgQ2hyaXN0ZXIgSG9sbWJlcmcNCktvcGlvOiB2b2xrZXJoQGJlbGwt bGFicy5jb207IHNpcC1vdmVybG9hZEBpZXRmLm9yZzsgaGdzQGNzLmNvbHVtYmlhLmVkdQ0KQWlo ZTogUmU6IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTMN Cg0KT24gMDcvMzEvMjAxMyAwMTowNSBQTSwgWXUsIEphbWVzIHdyb3RlOg0KPiBJIGFncmVlIHdp dGggdGhlIGNoYW5nZS4NCg0KSmFtZXMsIENocmlzdGVyOiBJIHdlbnQgdGhyb3VnaCB0aGUgbWlu b3IgY2hhbmdlIHlvdSBhcmUgc3VnZ2VzdGluZyB0byB0aGUgQUJORi4gIEVzc2VudGlhbGx5LCB5 b3Ugd2FudCB0byBjaGFuZ2UgdHdvIHRoaW5nczoNCg0KICAgLSBzL2FsZ28tbGlzdC9hbGdvLXZh bHVlLw0KICAgLSBjaGFuZ2UgdGhlIHZhcmlhYmxlIHJlcGV0aXRpb24gcnVsZSBzdWNoIHRoYXQg aXQgYXBwbGllcyB0bw0KICAgICB0aGUgcHJvZHVjdGlvbiBkZWZpbml0aW9uIG9mIG90aGVyLWFs Z28NCg0KSW4gdGVybXMgb2YgYWN0dWFsIGNoYW5nZSwgdGhpcyBpczoNCg0KT0xEOg0KDQogICAg b2MtYWxnbyAgICAgPSAib2MtYWxnbyIgRVFVQUwgRFFVT1RFIGFsZ28tbGlzdCAqKENPTU1BIGFs Z28tbGlzdCkNCiAgICAgICAgICAgICAgICAgIERRVU9URQ0KICAgIGFsZ28tbGlzdCAgID0gImxv c3MiIC8gKihvdGhlci1hbGdvKQ0KICAgIG90aGVyLWFsZ28gID0gJXg0MS01QSAvICV4NjEtN0Eg LyAleDMwLTM5DQoNCk5FVzoNCg0KICAgIG9jLWFsZ28gICAgID0gIm9jLWFsZ28iIEVRVUFMIERR VU9URSBhbGdvLXZhbHVlICooQ09NTUEgYWxnby12YWx1ZSkNCiAgICAgICAgICAgICAgICAgIERR VU9URQ0KICAgIGFsZ28tdmFsdWUgID0gImxvc3MiIC8gb3RoZXItYWxnbw0KICAgIG90aGVyLWFs Z28gID0gMSooJXg0MS01QSAvICV4NjEtN0EgLyAleDMwLTM5KQ0KDQpOb3RlIHRoYXQgdGhpcyBj aGFuZ2UgZG9lcyBwZXJ0dXJiIHRoZSBpbnRlbnQgb2YgdGhlIG9sZCBwcm9kdWN0aW9uIHJ1bGUg KGFzIGZhciBhcyBJIGNhbiBzZWUgaXQsIGF0IGxlYXN0KS4gIEVpdGhlciBvZiB0aGUgYWJvdmUg Z3JhbW1hcnMgcHJvZHVjZSB0aGUgZm9sbG93aW5nIHZhbGlkIHRva2VuIHNlcXVlbmNlOg0KDQog ICBvYy1hbGdvPSJsb3NzIg0KICAgb2MtYWxnbz0ibG9zcyxyYXRlIg0KICAgb2MtYWxnbz0ibG9z cyxyYXRlLHdpbmRvdyINCg0KSG93ZXZlciwgaWYgdGhlIG5ldyBjaGFuZ2UgYXBwZWFycyB0byBy ZWFkIGJldHRlciwgSSBhbSBoYXBweSB0byBjaGFuZ2UgaXQgYXMgc3VnZ2VzdGVkLg0KDQpUaGFu a3MsDQoNCi0gdmlqYXkNCi0tDQpWaWpheSBLLiBHdXJiYW5pLCBCZWxsIExhYm9yYXRvcmllcywg QWxjYXRlbC1MdWNlbnQNCjE5NjAgTHVjZW50IExhbmUsIFJtLiA5Qy01MzMsIE5hcGVydmlsbGUs IElsbGlub2lzIDYwNTYzIChVU0EpDQpFbWFpbDogdmtnQHtiZWxsLWxhYnMuY29tLGFjbS5vcmd9 IC8gdmlqYXkuZ3VyYmFuaUBhbGNhdGVsLWx1Y2VudC5jb20NCldlYjogaHR0cDovL2VjdC5iZWxs LWxhYnMuY29tL3doby92a2cvICB8IENhbGVuZGFyOiBodHRwOi8vZ29vLmdsL3gzT2dxDQo= From vkg@bell-labs.com Fri Aug 9 14:55:59 2013 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 0A5261F0C55 for ; Fri, 9 Aug 2013 14:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.449 X-Spam-Level: X-Spam-Status: No, score=-109.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ5aGU0fRlne for ; Fri, 9 Aug 2013 14:55:54 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E34CB11E8107 for ; Fri, 9 Aug 2013 14:48:22 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r79LmKLk015513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Aug 2013 16:48:21 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r79LmKoR003383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Aug 2013 16:48:20 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r79LmJ6c012253; Fri, 9 Aug 2013 16:48:20 -0500 (CDT) Message-ID: <520564B6.7040304@bell-labs.com> Date: Fri, 09 Aug 2013 16:52:54 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Richard Barnes 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.10 Cc: "sip-overload@ietf.org" Subject: [sip-overload] AD review: draft-ietf-soc-overload-control-13 (MAJOR ISSUES) 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, 09 Aug 2013 21:55:59 -0000 Richard: Thank you for a close read of the draft as part of the AD review (c.f. [1]). I must offer my apologies for a delay in response, but I was on vacation when your email arrived and could not get to attend to it until now. I will break the response to your review in two parts. This email attends to the major issues. I will generate a separate email for the minor issues. So, taking a look at the major issues. > 1. The fourth paragraph of Section 4.4 does not allow clients to detect > when overflow has happened. It seems like there are two options: (1) > Define the timestamp so it cannot overflow (e.g., as a sufficiently long > timestap), or (2) define what an "appropriate base value" is so that a > client can recognize when the "oc-seq" has been reset there. It seems > like it would be simplest to imply say that "oc-seq" MUST be an N-bit > counter value or a timestamp. (Or better, choose one.) The client will detect overflow when it receives an "oc-seq" parameter whose value is less than the previously seen value (because successive "oc-seq" parameter values are defined to be in an increasing order). When this happens there are guidelines on what the client implementation can do (last indented paragraph of S4.4). Regarding choosing between a timestamp or a counter, the WG prefers to use a timestamp primarily because of re-entrancy issues in a multi- core/thread environment when using a common variable (the counter) [2]. However, we did not end up mandating a timestamp using rfc2119 language to allow flexibility to implementations who may want to use something else. The earliest we will overflow using a signed 32-bit representation of a timestamp will be January 2038; using a signed 64-bit representation gets us about 290 billion more years. I understand the need to design robust protocols, but I am not sure what to mandate here besides perhaps exhorting implementations to use an unsigned 32-bit integer or move to a 64-bit machine or use a time library that will handles large time values on a 32-bit architecture. > 2. "oc=0" seems like a bad way to signal that there's no overload going > on. "oc-validity=0" does that. And if there's no overload condition, > on algorithm is being applied, so no "oc" parameter value needs to be > supplied. So it seems like you should signal support with no overload > with "oc;oc-validity=0". The reason "oc=0" was chosen to denote a server was not under overload control was that we wanted to treat the "oc" parameter in the same manner as the SIP "rport" parameter in rfc3581. Like "rport", when a server filled a value for "oc" it indicated support for the overload extension. A value of "0" for the "oc" parameter indicated that the server supported overload control but it was not interested in using it right now. The problem that arised when using only "oc=0" to indicate support for overload control was that if the rate-based algorithm was chosen to perform overload, then the value "oc=0" was taken as indication not to send any requests to the server. Hence we added "oc-validity=0" as well. Ostensibly, as you state, a server could insert "oc;oc-validity=0" to indicate to a client that it supports overload control. But being more explicit by "oc=0;oc-validity=0" does not seem too onerous. Unless you feel strongly about this, I'd rather leave the current text as is. > 3. As written, it seems like Section 5.9 could be read to require a > behavior that would exacerbate overload conditions with liveness checks. > (For example, "periodically" with period 500ms.) Suggest that this > section recommend a back-off algorithm, possibly with some concrete > timing paramters. E.g., start at whatever interval you like, > exponential back-off to some floor (say 10sec). I believe this issue is a bit more complex than suggesting a exponential backoff algorithm. The intent is that a SIP client has a plurality of downstream servers to choose from, and that one of these servers is not currently responding. Therfore, request is sent to the other (N-1) servers in some fashion. It is not the case that the same request is continuously sent to the non-responding server. Instead of mandating any specific behaviour, the current text leaves this to implementations to determine how often they want to, and indeed, if they want to, contact the non-responding server. Should we mandate more? > 4. The Security Considerations do a good job of describing the threats > that this mechanism introduces, but less so the mitigations to these > threats. In particular, there is no mitigation provided for the > multi-hop attack, and the mitigation for a malicious client is not > clearly stated. Suggest: > -- Recommending that clients enforce a maximum validity period (e.g., > 3600s) in order to limit the scope of spoofing attacks (off-path or > multi-hop) > -- "Servers SHOULD monitor client behavior to determine whether they are > complying with overload control policies. If a client is not > conforming, then the server SHOULD treat it as a non-supporting client > (Section 5.10.2)." Thanks for the suggestions. I re-read the section and in light of your suggestions, I think the section may benefit from rewording it to enunciate the security threats better. The mitigation strategies you outline then become more apparent. Let me suggest the new wording of the section, including your mitigation strategies, that will completely replace the current S10. Let me know what you think. --- Begin new text 10. Security Considerations Overload control mechanisms can be used by an attacker to conduct a denial-of-service attack on a SIP entity if the attacker can pretend that the SIP entity is overloaded. When such a forged overload indication is received by an upstream SIP client, it will stop sending traffic to the victim. Thus, the victim is subject to a denial-of-service attack. To better understand the threat model, consider the following diagram: Pa ------- ------ Pb \ / : ------ +-------- P1 ------+------ : / L1 L2 \ : ------- ------ : -----> Downstream (requests) <----- Upstream (responses) Here, requests travel downstream from the left-hand side, through Proxy P1, towards the right-hand side, and responses travel upstream from the right-hand side, through P1, towards the left hand side. Proxies Pa, Pb and P1 support overload control. L1 and L2 are labels for the links connecting P1 to the upstream clients and downstream servers. If an attacker is able to modify traffic between Pa and P1 on link L1, it can cause denial of service attack on P1 by having Pa not send any traffic to P1. Such an attack can proceed by the attacker modifying the response from P1 to Pa such that Pa's Via header is changed to indicate that all requests destined towards P1 should be dropped. Conversely, the attacker can simply remove any "oc", "oc-validity" and "oc-seq" markings added by P1 in a response to Pa. In such a case, the attacker will force P1 into overload control by denying request quenching at Pa even though Pa is capable of performing overload control. Similarly, if an attacker is able to modify traffic between P1 and Pb on link L2, it can change P1's Via header in a response from Pb to P1 such that all subsequent requests destined towards Pb from P1 are dropped. A denial of service attack is thus mounted on Pb. Note that it is immaterial whether Pb supports overload control or not, the attack will succeed as long as the attacker is able to control L2. Conversely, an attacker can simply remove any "oc", "oc-validity" and "oc-seq" markings added by Pb in a response to P1. In such a case, the attacker will force P1 into sending requests to Pb even under overload conditions because P1 would not be aware aware that Pb supports overload control. P1 can prevent these types of attack by using TLS on links L1 and L2. Yet another type of attack could be mounted by a malicious proxy (say Pb in the above figure) changing Via headers not corresponding to their immediate neighbor such that the overload control parameters of these Via headers would cause the SIP client identified in the Via header not to send requests to its neighbour. Such a multi-hop attack can be prevented ensuring that a SIP client removes "oc", "oc-validity" and "oc-seq" parameters from all Via headers of a response received, except for the topmost Via header. This prevents overload control parameters that were accidentally or maliciously inserted into Via headers by a downstream SIP server from traveling upstream (Section 5.4). A malicious SIP entity could gain an advantage by pretending to support this specification but never reducing the amount of traffic it forwards to the downstream neighbor. If its downstream neighbor receives traffic from multiple sources which correctly implement overload control, the malicious SIP entity would benefit since all other sources to its downstream neighbor would reduce load. The solution to this problem depends on the overload control method. For rate-based and window-based overload control, it is very easy for a downstream entity to monitor if the upstream neighbor throttles traffic forwarded as directed. For percentage throttling this is not always obvious since the load forwarded depends on the load received by the upstream neighbor. To prevent such attacks, servers should monitor client behavior to determine whether they are complying with overload control policies. If a client is not conforming to such policies, then the server should treat it as a non-supporting client (Section 5.10.2). --- End new text Please let me know what you think on these issues and I will close any resolutions as expeditiously as possible. [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00988.html [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00307.html Thanks, Richard. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From vkg@bell-labs.com Mon Aug 12 14:51:31 2013 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 5F40721F9F5E for ; Mon, 12 Aug 2013 14:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.435 X-Spam-Level: X-Spam-Status: No, score=-110.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBX-hIOPBcLM for ; Mon, 12 Aug 2013 14:51:26 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A89F921F9E9F for ; Mon, 12 Aug 2013 14:51:26 -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 r7CLpC6F003085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Aug 2013 16:51:12 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r7CLpBvc023359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Aug 2013 16:51:11 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r7CLpAB8010972; Mon, 12 Aug 2013 16:51:11 -0500 (CDT) Message-ID: <520959E3.10909@bell-labs.com> Date: Mon, 12 Aug 2013 16:55:47 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Richard Barnes 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 Cc: "sip-overload@ietf.org" Subject: [sip-overload] AD review: draft-ietf-soc-overload-control-13 (MINOR ISSUES) 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, 12 Aug 2013 21:51:31 -0000 Dear Richard: Continuing from your review of the draft [0], here are the resolutions to the minor issues. > 1. The last paragraph of Section 2 is tautological. ("The normative > statements...this specification.") If an entity doesn't support this > specification, then of course the normative requirements don't apply! > Do you mean something different from that? I always liked the T-shirt that said, "Dept. of Redundancy Department" :-) But all kidding aside, this was something the WG grappled with to some extent. The issue is that before the introduction of that paragraph, the document was peppered with qualifying phrases such as "A SIP entity that supports this specification..." Ergo, to get rid of such qualifiers, we added a blanket statement that you point out. It appears that what we did does not quite convey the semantic we wanted to. I am happy to entertain other thoughts on how to not burden the draft with the qualifying phrase. > 2. In Section 4.2, it would help if you could say briefly why multiple > algorithms are needed. Are some algorithms better suited to different > overload conditions? Or could the group just not make up its mind? > (Maybe there's a reference for this?) The design team that preceded this work studied 3 different algorithms for throttling --- rate-based, loss-based and window-based (c.f. Section 9 of RFC6357 [1]). As the work progressed, there was strong interest in the working group to support at least loss-based and rate-based throttling algorithms. The general view was that rate-based algorithms were useful in managed networks while loss-based were productive in more heterogeneous environments. There was a community supporting both the rate-based and loss-based algorithms, which is reflected as a framework in the current draft to support multiple algorithms. I could put a reference to S9 of RFC6357 [1] in S4.2 to signify that multiple algorithms need to be supported. Would that work? > 3. Mandating that "loss" be included in the list of supported > algorithms seems duplicative. Clients are already required to > support "loss" and put supported algorithms in the list. It also > seems undesirable for servers to rely on "loss" being present, since > that could cause problems if for some reason we decide to deprecate > "loss" in the future (cf. [[ SDP codec change ]]) I think the important issue here is that "loss" and "rate" are not instances of particular algorithms, they are a general collection of algorithms; to stretch an analogy, in OO terms, they are abstract classes. An implementation can use any specific loss- or rate-based algorithm as long as the algorithm trims the amount of traffic it promises to. Consequently, the reference algorithm in S6.3 may be used by a simple implementation for a loss-based scheme, but any equivalent algorithm that reduces traffic in the same amount can be used by the client. The server simply expects that there will be a reduction in traffic in the amount it indicated. How the client accomplishes this is left to the client. As such, I am not too worried about the deprecation qualities of the tokens used in the "oc-algo" parameter. > 4. It's not clear why the "oc-seq" parameter needs a fractional > portion. Wouldn't it be simple just to make it an integer? In case the server issues multiple responses in the same second it helps to have a fractional portion. > 5. In Section 5.8, "frequent changes of overload control algorithm > MUST be avoided" -- This is not an RFC 2119 MUST. Got it, will downgrade. > 6. In Section 5.8, "the algorithm MUST remain in effect" -> "the > server SHOULD NOT change the algorithm for that client" It seems > like you wouldn't want to prevent the server from changing if it > really needed to. Sure, I will make that change. > 7. In Section 5.10.2, the recommendation at the end seems a little > light, and unclear how to implement. You might recommend a simple > algorithm to apply here, e.g., just drop everything from > non-supporting clients. I have a hard time personally sating that the SIP server simply drops all requests from non-supporting clients. What if a request from a non-supporting client had RPH markings? I am susceptible to the argument that searching for RPH markings will make the overloaded server more slow, but all the same, I remain reticent to issue a blanket advisory to discard all requests from non-participating clients. Hence the exhortation to reject some requests. I am happy to entertain other thoughts on how to handle this case. > 8. In Section 6.1, the last two paragraphs are completely redundant > with the general behavior specified above. I will take them out. > 9. The example in Section 6.2 is not specific to the "loss" algorithm. > It should be moved up to the top level. Sure; that is reasonable. I will see if I can make an "Examples" section or put the example elsewhere. > 10. Should Section 9 be moved to an appendix? The working group had debated removing S9 altogether, but it was decided that we should keep it [2]. Now, to be fair, we did not consider moving it to an appendix as much as removing it entirely. However, since it was felt that the section added some value to the document, it stayed. I am happy to move it to an appendix if that is your preference. > 11. In Section 10, it's not really even necessary to use TLS to > prevent spoofing. In many cases just using a connection-oriented > protocol like TLS or WS would be sufficient. Do you mean "TCP or WS" above? In light of my suggestions to modify S10 in [3], do we still need to revisit this issue? [0] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00988.html [1] http://tools.ietf.org/html/rfc6357#section-9 [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00797.html [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg01013.html Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From internet-drafts@ietf.org Wed Aug 21 11:53:23 2013 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 5686F21F9E36; Wed, 21 Aug 2013 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxp3YEg9T4pf; Wed, 21 Aug 2013 11:53:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC2F21F9CD9; Wed, 21 Aug 2013 11:53:22 -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: 4.70.p1 Message-ID: <20130821185322.18182.33561.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 11:53:22 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.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, 21 Aug 2013 18:53:23 -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 : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-05.txt Pages : 17 Date : 2013-08-21 Abstract: The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ecnoel@research.att.com Wed Aug 21 12:02:21 2013 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 7EABE21F9FC6; Wed, 21 Aug 2013 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=3.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf5bSsHByPUH; Wed, 21 Aug 2013 12:02:16 -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 3A87521F9FE3; Wed, 21 Aug 2013 12:02:01 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id DB6AA1209D9; Wed, 21 Aug 2013 15:01:58 -0400 (EDT) Received: from njfpsrvexg9.research.att.com (njfpsrvexg9.research.att.com [135.207.178.39]) by mail-green.research.att.com (Postfix) with ESMTP id 9E088E0191; Wed, 21 Aug 2013 15:01:24 -0400 (EDT) Received: from NJFPSRVEXG9.research.att.com ([fe80::e596:b2e3:df5e:6b93]) by njfpsrvexg9.research.att.com ([fe80::e596:b2e3:df5e:6b93%15]) with mapi; Wed, 21 Aug 2013 15:02:00 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Date: Wed, 21 Aug 2013 15:02:00 -0400 Thread-Topic: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.txt Thread-Index: Ac6eoOpkMBFNkShuSFu/d1RbTQEjBg== Message-ID: <63EB53DBC1840741B883EC08387B5290C23E6991@njfpsrvexg9.research.att.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 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.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, 21 Aug 2013 19:02:21 -0000 Folks, I just posted an updated version of draft-ietf-soc-overload-rate-control. I= t accounts for all the comments that I received during the WGLC.=20 Thank you again for all the comments and suggestions,=20 Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 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 internet-drafts@ietf.org Sent: Wednesday, August 21, 2013 2:53 PM To: i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05= .txt 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 : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-05.txt Pages : 17 Date : 2013-08-21 Abstract: The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From christer.holmberg@ericsson.com Wed Aug 21 23:46:11 2013 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 0371721F9C68; Wed, 21 Aug 2013 23:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.843 X-Spam-Level: X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFmYp68LEgZK; Wed, 21 Aug 2013 23:46:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 06B1421F9FCF; Wed, 21 Aug 2013 23:45:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-86-5215b387988a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 58.B6.22048.783B5125; Thu, 22 Aug 2013 08:45:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 08:45:27 +0200 From: Christer Holmberg To: "NOEL, ERIC C (ERIC C)" , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Thread-Topic: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.txt Thread-Index: Ac6eoOpkMBFNkShuSFu/d1RbTQEjBgAYdh+A Date: Thu, 22 Aug 2013 06:45:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4750F7@ESESSMB209.ericsson.se> References: <63EB53DBC1840741B883EC08387B5290C23E6991@njfpsrvexg9.research.att.com> In-Reply-To: <63EB53DBC1840741B883EC08387B5290C23E6991@njfpsrvexg9.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvjW7HZtEgg8/f2CxO/t/HYrFk13Nm iw93cy32P02waFgj58Dq0XfZxWPJkp9MHv+fzGcJYI7isklJzcksSy3St0vgylg/4RxrwR7J ii/nnrI0MLaJdjFyckgImEicefqJFcIWk7hwbz1bFyMXh5DAYUaJzTtXsEA4Sxgl/rbPYOpi 5OBgE7CQ6P6nDRIXEVjMKLFu4SNmkDizQKHE8wXFIIOEBUIlfixbyAZiiwiESby+8YoVwjaS 2NexlgXEZhFQldj7v4EZxOYV8JW4c+ErWI2QQLDExik32EFsToEQiTXfr4LVMwId9/3UGiYQ m1lAXOLWk/lMEEcLSCzZc54ZwhaVePn4H9QzihLtTxsYIep1JBbs/sQGYWtLLFv4GmqvoMTJ mU9YJjCKzUIydhaSlllIWmYhaVnAyLKKkT03MTMnvdx8EyMwhg5u+W2wg3HTfbFDjNIcLEri vJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOxYf1LOLPfLS/UfMkw7PMS8n2Sf4rVz nCs267ursljL1Ek80hl+JWte2iq6Lp2WuUBz4++9Ozeda6/a9qvw6cK65237dZ/v0Rdp+nYz +Mns9et25T5UE9yUcW/NtJnJZ/vO398rsDLtmNXF1IozaW96pwueeryyo2nZhr2l7tk3AiS/ yzm0h09XYinOSDTUYi4qTgQAemauJm8CAAA= Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.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: Thu, 22 Aug 2013 06:46:11 -0000 Hi Noel, Based on discussions with Vijay, "algo-list" is going to be changed to "alg= o-value" in draft-ietf-soc-overload-control, so you should do the same chan= ge in your draft. Otherwise I'm ok with the changes :) Regards, Christer -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 21. elokuuta 2013 22:02 To: 'internet-drafts@ietf.org'; i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Folks, I just posted an updated version of draft-ietf-soc-overload-rate-control. I= t accounts for all the comments that I received during the WGLC.=20 Thank you again for all the comments and suggestions,=20 Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 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 internet-drafts@ietf.org Sent: Wednesday, August 21, 2013 2:53 PM To: i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05= .txt 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 : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-05.txt Pages : 17 Date : 2013-08-21 Abstract: The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Thu Aug 22 08:50:35 2013 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 11CE121F995B; Thu, 22 Aug 2013 08:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=2.825, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkYe1wooJ4mb; Thu, 22 Aug 2013 08:50:30 -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 CA31A11E81EB; Thu, 22 Aug 2013 08:50:29 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 9AB8A120AD9; Thu, 22 Aug 2013 11:50:26 -0400 (EDT) Received: from njfpsrvexg9.research.att.com (njfpsrvexg9.research.att.com [135.207.178.39]) by mail-green.research.att.com (Postfix) with ESMTP id E2D8CE0E09; Thu, 22 Aug 2013 11:49:50 -0400 (EDT) Received: from NJFPSRVEXG9.research.att.com ([fe80::e596:b2e3:df5e:6b93]) by njfpsrvexg9.research.att.com ([fe80::e596:b2e3:df5e:6b93%15]) with mapi; Thu, 22 Aug 2013 11:50:28 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Christer Holmberg' , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Date: Thu, 22 Aug 2013 11:50:27 -0400 Thread-Topic: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.txt Thread-Index: Ac6eoOpkMBFNkShuSFu/d1RbTQEjBgAYdh+AABL1g+A= Message-ID: <63EB53DBC1840741B883EC08387B5290C23E6995@njfpsrvexg9.research.att.com> References: <63EB53DBC1840741B883EC08387B5290C23E6991@njfpsrvexg9.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C4750F7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4750F7@ESESSMB209.ericsson.se> 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 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.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: Thu, 22 Aug 2013 15:50:35 -0000 Christer, Thanks for the pointer, so I should replace=20 algo-list /=3D "rate" With=20 oc-algo =3D "oc-algo" EQUAL DQUOTE algo-value *(COMMA algo-value) DQUOTE algo-value =3D "rate" / other-algo other-algo =3D 1*(%x41-5A / %x61-7A / %x30-39) Where I replaced "loss" by "rate" Thanks, Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, August 22, 2013 2:45 AM To: NOEL, ERIC C (ERIC C); 'internet-drafts@ietf.org'; i-d-announce@ietf.or= g Cc: sip-overload@ietf.org; Vijay K. Gurbani (vkg@bell-labs.com) Subject: RE: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Hi Noel, Based on discussions with Vijay, "algo-list" is going to be changed to "alg= o-value" in draft-ietf-soc-overload-control, so you should do the same chan= ge in your draft. Otherwise I'm ok with the changes :) Regards, Christer -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 21. elokuuta 2013 22:02 To: 'internet-drafts@ietf.org'; i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Folks, I just posted an updated version of draft-ietf-soc-overload-rate-control. I= t accounts for all the comments that I received during the WGLC.=20 Thank you again for all the comments and suggestions,=20 Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 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 internet-drafts@ietf.org Sent: Wednesday, August 21, 2013 2:53 PM To: i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05= .txt 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 : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-05.txt Pages : 17 Date : 2013-08-21 Abstract: The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 christer.holmberg@ericsson.com Thu Aug 22 09:07:48 2013 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 B13BD21F9CF3; Thu, 22 Aug 2013 09:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcmX01qSPCu0; Thu, 22 Aug 2013 09:07:43 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBA021F9C6E; Thu, 22 Aug 2013 09:07:42 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-d9-5216374dd755 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 89.8B.22048.D4736125; Thu, 22 Aug 2013 18:07:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 18:07:40 +0200 From: Christer Holmberg To: "NOEL, ERIC C (ERIC C)" , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Thread-Topic: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.txt Thread-Index: Ac6eoOpkMBFNkShuSFu/d1RbTQEjBgAYdh+AABL1g+AAALtFAA== Date: Thu, 22 Aug 2013 16:07:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C475888@ESESSMB209.ericsson.se> References: <63EB53DBC1840741B883EC08387B5290C23E6991@njfpsrvexg9.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C4750F7@ESESSMB209.ericsson.se> <63EB53DBC1840741B883EC08387B5290C23E6995@njfpsrvexg9.research.att.com> In-Reply-To: <63EB53DBC1840741B883EC08387B5290C23E6995@njfpsrvexg9.research.att.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja6vuViQwdZ+CYuT//exWCzZ9ZzZ 4sPdXIv9TxMsGtbIObB69F128Viy5CeTx/8n81kCmKO4bFJSczLLUov07RK4Mt4+385UcFGl ornrKksD4zS5LkZODgkBE4k952exQdhiEhfurQeyuTiEBA4zSrzd9okVwlnCKPHz1G/GLkYO DjYBC4nuf9ogcRGBxYwS6xY+YgaJMwsUSjxfUAwySFggVKLl2DRGEFtEIEzi9Y1XrBC2k8SM b/PB4iwCqhJd71aDLeYV8JXo+jGFCWLXQ0aJv8eXMIEkOAVCJN4sOAZWxAh03fdTa8DizALi Eh8OXmeGuFpAYsme81C2qMTLx/9YIWwliR8bLrFA1OtJ3Jg6hQ3C1pZYtvA1M8RiQYmTM5+w TGAUm4Vk7CwkLbOQtMxC0rKAkWUVI3tuYmZOern5JkZgFB3c8ttgB+Om+2KHGKU5WJTEeTfr nQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBiQFyZQFSllNe2uUpu4yVLmBccuX2HZtkH7 aFPK8Y+1dUm9NxtFX/slM5g92hUxw0k5PTDYrUE39g3/7fQEnx1lB8s0Zl+23BfJcrhE6sel AANT+6srEi+f3fcjebrw8iveh/wvi5yTUL5clljps+Vl7/QzW9dNOLq7fee1N6eC5q3sVfFU llRiKc5INNRiLipOBACg5lGYcAIAAA== Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.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: Thu, 22 Aug 2013 16:07:48 -0000 Hi, No, you should only replace: algo-list /=3D "rate" ...with: algo-value /=3D "rate" Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]=20 L=E4hetetty: 22. elokuuta 2013 18:50 Vastaanottaja: Christer Holmberg; 'internet-drafts@ietf.org'; i-d-announce@= ietf.org Kopio: sip-overload@ietf.org; Vijay K. Gurbani (vkg@bell-labs.com) Aihe: RE: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-0= 5.txt Christer, Thanks for the pointer, so I should replace=20 algo-list /=3D "rate" With=20 oc-algo =3D "oc-algo" EQUAL DQUOTE algo-value *(COMMA algo-value) DQUOTE algo-value =3D "rate" / other-algo other-algo =3D 1*(%x41-5A / %x61-7A / %x30-39) Where I replaced "loss" by "rate" Thanks, Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, August 22, 2013 2:45 AM To: NOEL, ERIC C (ERIC C); 'internet-drafts@ietf.org'; i-d-announce@ietf.or= g Cc: sip-overload@ietf.org; Vijay K. Gurbani (vkg@bell-labs.com) Subject: RE: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Hi Noel, Based on discussions with Vijay, "algo-list" is going to be changed to "alg= o-value" in draft-ietf-soc-overload-control, so you should do the same chan= ge in your draft. Otherwise I'm ok with the changes :) Regards, Christer -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 21. elokuuta 2013 22:02 To: 'internet-drafts@ietf.org'; i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Folks, I just posted an updated version of draft-ietf-soc-overload-rate-control. I= t accounts for all the comments that I received during the WGLC.=20 Thank you again for all the comments and suggestions,=20 Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 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 internet-drafts@ietf.org Sent: Wednesday, August 21, 2013 2:53 PM To: i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05= .txt 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 : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-05.txt Pages : 17 Date : 2013-08-21 Abstract: The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Thu Aug 22 09:58:57 2013 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 299A711E81C5; Thu, 22 Aug 2013 09:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.339 X-Spam-Level: X-Spam-Status: No, score=-4.339 tagged_above=-999 required=5 tests=[AWL=2.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNjz1wtTOpjx; Thu, 22 Aug 2013 09:58:52 -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 DD40B11E81AA; Thu, 22 Aug 2013 09:58:51 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 463C6120AFF; Thu, 22 Aug 2013 12:58:49 -0400 (EDT) Received: from njfpsrvexg9.research.att.com (njfpsrvexg9.research.att.com [135.207.178.39]) by mail-green.research.att.com (Postfix) with ESMTP id 7BB7CE0E09; Thu, 22 Aug 2013 12:58:13 -0400 (EDT) Received: from NJFPSRVEXG9.research.att.com ([fe80::e596:b2e3:df5e:6b93]) by njfpsrvexg9.research.att.com ([fe80::e596:b2e3:df5e:6b93%15]) with mapi; Thu, 22 Aug 2013 12:58:51 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Christer Holmberg' , "'internet-drafts@ietf.org'" , "i-d-announce@ietf.org" Date: Thu, 22 Aug 2013 12:58:50 -0400 Thread-Topic: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.txt Thread-Index: Ac6eoOpkMBFNkShuSFu/d1RbTQEjBgAYdh+AABL1g+AAALtFAAAB1AWA Message-ID: <63EB53DBC1840741B883EC08387B5290C23E6996@njfpsrvexg9.research.att.com> References: <63EB53DBC1840741B883EC08387B5290C23E6991@njfpsrvexg9.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C4750F7@ESESSMB209.ericsson.se> <63EB53DBC1840741B883EC08387B5290C23E6995@njfpsrvexg9.research.att.com> <7594FB04B1934943A5C02806D1A2204B1C475888@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C475888@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05.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: Thu, 22 Aug 2013 16:58:57 -0000 Christer, Got it. Thanks a lot, Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, August 22, 2013 12:08 PM To: NOEL, ERIC C (ERIC C); 'internet-drafts@ietf.org'; i-d-announce@ietf.or= g Cc: sip-overload@ietf.org; Vijay K. Gurbani (vkg@bell-labs.com) Subject: VS: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Hi, No, you should only replace: algo-list /=3D "rate" ...with: algo-value /=3D "rate" Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com]=20 L=E4hetetty: 22. elokuuta 2013 18:50 Vastaanottaja: Christer Holmberg; 'internet-drafts@ietf.org'; i-d-announce@= ietf.org Kopio: sip-overload@ietf.org; Vijay K. Gurbani (vkg@bell-labs.com) Aihe: RE: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-0= 5.txt Christer, Thanks for the pointer, so I should replace=20 algo-list /=3D "rate" With=20 oc-algo =3D "oc-algo" EQUAL DQUOTE algo-value *(COMMA algo-value) DQUOTE algo-value =3D "rate" / other-algo other-algo =3D 1*(%x41-5A / %x61-7A / %x30-39) Where I replaced "loss" by "rate" Thanks, Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, August 22, 2013 2:45 AM To: NOEL, ERIC C (ERIC C); 'internet-drafts@ietf.org'; i-d-announce@ietf.or= g Cc: sip-overload@ietf.org; Vijay K. Gurbani (vkg@bell-labs.com) Subject: RE: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Hi Noel, Based on discussions with Vijay, "algo-list" is going to be changed to "alg= o-value" in draft-ietf-soc-overload-control, so you should do the same chan= ge in your draft. Otherwise I'm ok with the changes :) Regards, Christer -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of NOEL, ERIC C (ERIC C) Sent: 21. elokuuta 2013 22:02 To: 'internet-drafts@ietf.org'; i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-contro= l-05.txt Folks, I just posted an updated version of draft-ietf-soc-overload-rate-control. I= t accounts for all the comments that I received during the WGLC.=20 Thank you again for all the comments and suggestions,=20 Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Optimization, Reliability and Customer Analytics 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 internet-drafts@ietf.org Sent: Wednesday, August 21, 2013 2:53 PM To: i-d-announce@ietf.org Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-05= .txt 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 : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-05.txt Pages : 17 Date : 2013-08-21 Abstract: The prevalent use of Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already a loss-based solution to remedy known vulnerabilities of the SIP 503 (service unavailable) overload control mechanism has been proposed. This document proposes a rate-based control scheme to complement the loss-based control scheme, using the same signaling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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