From internet-drafts@ietf.org Fri Sep 2 08:02: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 2744221F8AD8; Fri, 2 Sep 2011 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 uY+e68nZTe6N; Fri, 2 Sep 2011 08:02:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACF221F8A35; Fri, 2 Sep 2011 08:02:12 -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.60 Message-ID: <20110902150212.28197.75714.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 08:02:12 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-control-03.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: Fri, 02 Sep 2011 15:02:13 -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) Overload Control Author(s) : Vijay K. Gurbani Volker Hilt Henning Schulzrinne Filename : draft-ietf-soc-overload-control-03.txt Pages : 29 Date : 2011-09-02 Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-03.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-control-03.txt From Vijay.Gurbani@alcatel-lucent.com Fri Sep 2 08:10:26 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 105E621F8B78 for ; Fri, 2 Sep 2011 08:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_20=-0.74, 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 h5WYS128LYo5 for ; Fri, 2 Sep 2011 08:10:25 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 439DA21F8B49 for ; Fri, 2 Sep 2011 08:10:24 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p82FBsUm025916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Sep 2011 10:11:54 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p82FBsYM000611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Sep 2011 10:11:54 -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 p82FBsje020886 for ; Fri, 2 Sep 2011 10:11:54 -0500 (CDT) Message-ID: <4E60F2B4.8030801@alcatel-lucent.com> Date: Fri, 02 Sep 2011 10:13:56 -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.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 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.9 Subject: [sip-overload] draft-ietf-soc-overload-control-03 released 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, 02 Sep 2011 15:10:26 -0000 Folks: Pursuant to the discussion we had in Quebec City on moving the overload control work ahead by separating the loss-base overload control scheme from the general behaviour to accomodate rate-base schemes, I have posted a new revision of draft-ietf-soc-overload-control [1]. The salient changes, besides editing nits and such, are: 1) Updated the ABNF for "oc" to accommodate values > 100 (for rate-base control schemes). 2) Added a new section, Section 5 on "General behaviour". 3) Added a new section, Section 6 on "The loss-based overload control scheme". There is one section that needs to be completed --- Section 6.3. I will provide a default client algorithm for loss-base scheme next week, but until then, I thought it may help to get the current draft out to the list for feedback. Please go through the revised draft and let me know if something is amiss. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-03 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From ecnoel@research.att.com Fri Sep 2 09:26:00 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 4C6BA21F8BC4 for ; Fri, 2 Sep 2011 09:26:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZfu7WHg8ZcK for ; Fri, 2 Sep 2011 09:25:59 -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 9DC1C21F8BBB for ; Fri, 2 Sep 2011 09:25:59 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 679DC12077C for ; Fri, 2 Sep 2011 12:27:27 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 5DB4E857F for ; Fri, 2 Sep 2011 12:27:27 -0400 (EDT) Received: from concierge.research.att.com (135.207.179.20) by njfpsrvexg2.research.att.com (135.207.177.29) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 2 Sep 2011 12:23:05 -0400 Received: from njfpsrvexg6.research.att.com ([fe80:0000:0000:0000:a8f7:a94a:213.189.254.11]) by concierge.research.att.com ([135.207.24.83]) with mapi; Fri, 2 Sep 2011 12:27:21 -0400 From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: Fri, 2 Sep 2011 12:28:23 -0400 Thread-Topic: New Version Notification for draft-noel-soc-overload-rate-control-00.txt Thread-Index: AcxpjEuK5UOETw2IRXKT353PgsKrtAAAAZnA Message-ID: <2F8FB48C17221643AD77FA295756D2A71E2A794A74@njfpsrvexg6.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sip-overload] New Version Notification for draft-noel-soc-overload-rate-control-00.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: Fri, 02 Sep 2011 16:26:00 -0000 Rm9sa3MsDQoNCkkgaGF2ZSBwb3N0ZWQgYSBuZXcgZHJhZnQgdGhhdCBwcm9wb3NlcyBhIHJhdGUt YmFzZWQgY29udHJvbCBiYXNlZCBvbiB0aGUgcmVjb21tZW5kYXRpb25zIGluIGRyYWZ0LWlldGYt c29jLW92ZXJsb2FkLWNvbnRyb2wuIA0KDQpUaGlzIHdhcyBkb25lIHBlciBhZ3JlZW1lbnQgaW4g ZGlzY3Vzc2lvbnMgZm9sbG93aW5nIHRoZSBRdWViZWMgbWVldGluZy4NCg0KUGxlYXNlIHJldmll dyBbMV0gYW5kIHByb3ZpZGUgY29tbWVudHMgYXMgbmVlZGVkLg0KDQpbMV0gaHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LW5vZWwtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbC0wMC50eHQN Cg0KVGhhbmtzLCANCg0KRXJpYyBOb2VsIA0KTE1UUw0KQVQmVCBMYWJzLCBJbmMuIA0KUmV0aGlu ayBQb3NzaWJsZQ0KDQpOZXR3b3JrIERlc2lnbiBhbmQgUGVyZm9ybWFuY2UgQW5hbHlzaXMNCjIw MCBTb3V0aCBMYXVyZWwgQXZlbnVlLCBENS0zRDE5DQpNaWRkbGV0b3duLCBOSiAwNzc0OA0KUDog NzMyLjQyMC40MTc0DQplY25vZWxAYXR0LmNvbQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTEgMTI6MTYgUE0N ClRvOiBlcmljLm5vZWxAYXR0LmNvbQ0KQ2M6IGVyaWMubm9lbEBhdHQuY29tDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW5vZWwtc29jLW92ZXJsb2FkLXJhdGUt Y29udHJvbC0wMC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW5vZWwtc29jLW92 ZXJsb2FkLXJhdGUtY29udHJvbC0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBFcmljIE5vZWwgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LW5vZWwtc29jLW92ZXJsb2FkLXJhdGUtY29udHJvbA0KUmV2aXNpb246CSAw MA0KVGl0bGU6CQkgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFJhdGUgQ29udHJv bA0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMDktMDINCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQoNCkFic3RyYWN0Og0KICAgVGhlIHByZXZhbGVudCB1 c2Ugb2YgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIFtSRkMzMjYxXSBpbg0KICAg TmV4dCBHZW5lcmF0aW9uIE5ldHdvcmtzIG5lY2Vzc2l0YXRlcyB0aGF0IFNJUCBuZXR3b3JrcyBw cm92aWRlDQogICBhZGVxdWF0ZSBjb250cm9sIG1lY2hhbmlzbXMgdG8gb3B0aW1pemUgdHJhbnNh Y3Rpb24gdGhyb3VnaHB1dCBhbmQNCiAgIHByZXZlbnQgY29uZ2VzdGlvbiBjb2xsYXBzZSBkdXJp bmcgdHJhZmZpYyBvdmVybG9hZHMuIEFscmVhZHkNCiAgIFtkcmFmdC1pZXRmLXNvYy1vdmVybG9h ZC1jb250cm9sLTAzXSBwcm9wb3NlcyBhIGxvc3MtYmFzZWQgc29sdXRpb24NCiAgIHRvIHJlbWVk eSBrbm93biB2dWxuZXJhYmlsaXRpZXMgb2YgdGhlIFtSRkMzMjYxXSBTSVAgNTAzIChzZXJ2aWNl DQogICB1bmF2YWlsYWJsZSkgb3ZlcmxvYWQgY29udHJvbCBtZWNoYW5pc20uIFRoaXMgZG9jdW1l bnQgcHJvcG9zZXMgYQ0KICAgcmF0ZS1iYXNlZCBjb250cm9sIHNvbHV0aW9uIHRvIGNvbXBsZW1l bnQgdGhlIGxvc3MtYmFzZWQgY29udHJvbA0KICAgZGVmaW5lZCBpbiBbZHJhZnQtaWV0Zi1zb2Mt b3ZlcmxvYWQtY29udHJvbC0wM10uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0K From vkg@bell-labs.com Fri Sep 2 12:37:40 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 C474021F8D0C for ; Fri, 2 Sep 2011 12:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Twuh6y5iIly5 for ; Fri, 2 Sep 2011 12:37:40 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76B21F8CE9 for ; Fri, 2 Sep 2011 12:37:40 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p82JdGT2022252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Sep 2011 14:39:16 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p82JdGgB014089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Sep 2011 14:39:16 -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 p82JdGv9006571 for ; Fri, 2 Sep 2011 14:39:16 -0500 (CDT) Message-ID: <4E613160.5010701@bell-labs.com> Date: Fri, 02 Sep 2011 14:41:20 -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.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [sip-overload] The frequency of re-negotiating overload control schemes 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, 02 Sep 2011 19:37:40 -0000 Folks: One of the issues that was left rather underspecified in draft-ietf-soc-overload-control-02 was how often should the overload algorithms be re-negotiated. The -02 version took a rather liberal view and simply said that implementations must not do it too often, i.e., "... the adjacent peers MUST NOT renegotiate the overload control algorithm class per transaction, or per request-response message exchange." In -03, the text around this is far more conservative and disallows renegotiations until at least 3600s have elapsed since the last agreement. See the newly added Section 5.7 in -03 [1]. Please do read Section 5.7, and if there is a better way to accomplish renegotiation, please let me know. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-03#section-5.7 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From ecnoel@research.att.com Fri Sep 2 13:34:17 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 9747321F8D32 for ; Fri, 2 Sep 2011 13:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XQ8p2Ky+Up+H for ; Fri, 2 Sep 2011 13:34:17 -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 1057021F8D2E for ; Fri, 2 Sep 2011 13:34:16 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id A0304120742 for ; Fri, 2 Sep 2011 16:35:53 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 966BE841A for ; Fri, 2 Sep 2011 16:35:53 -0400 (EDT) Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%15]) with mapi; Fri, 2 Sep 2011 16:31:31 -0400 From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: Fri, 2 Sep 2011 16:36:41 -0400 Thread-Topic: [sip-overload] New Version Notification for draft-noel-soc-overload-rate-control-01.txt Thread-Index: AcxpjEuK5UOETw2IRXKT353PgsKrtAAAAZnAAAjHF1A= Message-ID: <2F8FB48C17221643AD77FA295756D2A71E2A794B23@njfpsrvexg6.research.att.com> References: <2F8FB48C17221643AD77FA295756D2A71E2A794A74@njfpsrvexg6.research.att.com> In-Reply-To: <2F8FB48C17221643AD77FA295756D2A71E2A794A74@njfpsrvexg6.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 Subject: Re: [sip-overload] New Version Notification for draft-noel-soc-overload-rate-control-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: Fri, 02 Sep 2011 20:34:17 -0000 Fixed section 3.4 which was incorrect. Please provide feedback from version= 01. 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 From shida@ntt-at.com Tue Sep 6 04:30: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 2DDFE21F8696 for ; Tue, 6 Sep 2011 04:30:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evoVupqODLaN for ; Tue, 6 Sep 2011 04:30:31 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 63B9D21F8680 for ; Tue, 6 Sep 2011 04:30:28 -0700 (PDT) Received: from [122.135.156.233] (port=55024 helo=[192.168.1.139]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R0tsx-0004fU-Qs; Tue, 06 Sep 2011 06:32:12 -0500 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4E613160.5010701@bell-labs.com> Date: Tue, 6 Sep 2011 20:32:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E613160.5010701@bell-labs.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1244.3) 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: fl1-122-135-156-233.tky.mesh.ad.jp ([192.168.1.139]) [122.135.156.233]:55024 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 11:30:32 -0000 I think the general approach is fine. Client sends the list and server picks one is the current=20 approach, so client has no way to present preference,=20 and as far as I can tell the server has no way to change=20 the algorithm unless client initiates the re-negotiation. I=20 don't have any problem with that as we want to keep it=20 as simple as possible but I thought I would share my=20 observation. *As far as I can read from the text, there was no text=20 saying that server can include "oc-algo" with list of=20 algorithm it supports in a response to negotiate the=20 algorithm with the client.=20 - If we want to allow client to show preference, we can=20 say that the list is composed in a order that it prefers. Whether server honor that or not is a different story.=20 It's also not clear to me the expected normative behavior surrounding "oc-algo", I am assuming that "oc-algo" only=20 shows up when negotiating but it is currently not clear. So=20 we should probably be clear with when "oc-algo" shows=20 up so client/server both know when to set it and what it means. =20 Below are my interpretation.=20 Client sets "oc-algo" in request only when it wants to=20 negotiate the algorithm to be used.=20 =20 Server knows that the negotiation is requested=20 due to the fact that "oc-algo" is present in the via.=20 It selects the algorithm and sends that in the response. No "oc-algo" shows up until the next negotiation phase. =20 Should we say anything about when timer runs out? Should we have a text mandating that if the timer runs out,=20 client negotiates the algorithm on the next request it sends=20 to the server?? Regards Shida On Sep 3, 2011, at 4:41 AM, Vijay K. Gurbani wrote: > Folks: One of the issues that was left rather underspecified > in draft-ietf-soc-overload-control-02 was how often should > the overload algorithms be re-negotiated. >=20 > The -02 version took a rather liberal view and simply said that > implementations must not do it too often, i.e., "... the adjacent > peers MUST NOT renegotiate the overload control algorithm class > per transaction, or per request-response message exchange." >=20 > In -03, the text around this is far more conservative and > disallows renegotiations until at least 3600s have elapsed since > the last agreement. See the newly added Section 5.7 in -03 [1]. >=20 > Please do read Section 5.7, and if there is a better way to > accomplish renegotiation, please let me know. >=20 > [1] = http://tools.ietf.org/html/draft-ietf-soc-overload-control-03#section-5.7 >=20 > Thanks, >=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 vkg@bell-labs.com Tue Sep 6 06:07:38 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 0CABA21F86A0 for ; Tue, 6 Sep 2011 06:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 QiAMQrwJsH7A for ; Tue, 6 Sep 2011 06:07:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C421F867E for ; Tue, 6 Sep 2011 06:07:33 -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 p86D9JHv019788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 08:09:19 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p86D9I29006752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Sep 2011 08:09:19 -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 p86D9I8u026968; Tue, 6 Sep 2011 08:09:18 -0500 (CDT) Message-ID: <4E661C01.3010803@bell-labs.com> Date: Tue, 06 Sep 2011 08:11:29 -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.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Shida Schubert References: <4E613160.5010701@bell-labs.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.10 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 13:07:38 -0000 On 09/06/2011 06:32 AM, Shida Schubert wrote: > > I think the general approach is fine. Shida: Thank you for your comments. More inline. > Client sends the list and server picks one is the current > approach, so client has no way to present preference, > and as far as I can tell the server has no way to change > the algorithm unless client initiates the re-negotiation. I > don't have any problem with that as we want to keep it > as simple as possible but I thought I would share my > observation. > *As far as I can read from the text, there was no text > saying that server can include "oc-algo" with list of > algorithm it supports in a response to negotiate the > algorithm with the client. Right; the server simply gets to choose one from the list provided by the client. > - If we want to allow client to show preference, we can > say that the list is composed in a order that it prefers. > Whether server honor that or not is a different story. That is fine with me, and more preferable than adding additional parameters showing preference (a q-value). > It's also not clear to me the expected normative behavior > surrounding "oc-algo", I am assuming that "oc-algo" only > shows up when negotiating but it is currently not clear. So > we should probably be clear with when "oc-algo" shows > up so client/server both know when to set it and what it means. > > Below are my interpretation. > > Client sets "oc-algo" in request only when it wants to > negotiate the algorithm to be used. I agree this part is unclear. Here is my view, and if you and the list agrees, I can update the draft. For the normal sake of fault-tolerance, robustness, and carrying as much state in the message itself, the oc-algo appears in every request, with one important difference. When the client first contacts the server, and thereupon every time the timer fires, the oc-algo list will contain all schemes supported by the client. Once an algorithm has been agreed to, it becomes the sole value that goes into the oc-algo parameter until re-negotiation. Sending it as the sole value allows for an backup server to continue using the same algorithm agreed to by its predecessor. > Server knows that the negotiation is requested > due to the fact that "oc-algo" is present in the via. > It selects the algorithm and sends that in the response. Yes, the above works in both cases. That is, when there is a list of algorithms and when one has been chosen and the client/server pair is in between the timer for the next negotiation going off. In the latter case, the server does not have too much latitude at choosing, but the former case (list of algorithms), the server can choose afresh. > No "oc-algo" shows up until the next negotiation phase. > > Should we say anything about when timer runs out? I believe this is present in Section 5.7: Once the client and server agree on an overload control algorithm, it MUST remain in effect for at least 3600 seconds (1 hour) before renegotiation occurs. > Should we have a text mandating that if the timer runs out, > client negotiates the algorithm on the next request it sends > to the server?? I believe it is already there in Section 5.7: Renegotiation, when desired, is simply accomplished by the SIP client sending a complete list of overload control algorithms it supports in a "oc-algo" parameter in a request going downstream. The downstream server, as before, MUST choose one algorithm from the list and MUST pare the list down to include the one chosen algorithm. The pared down list consisting of the chosen algorithm MUST be returned to the upstream SIP client in the response and stays in effect until the next renegotiation. If the last two points you make are not clear in Section 5.7, please let me know and I can see if I can highlight these in some fashion. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From shida@ntt-at.com Tue Sep 6 17:22:00 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 C7B4C21F8D2F for ; Tue, 6 Sep 2011 17:22:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDBxuCDhrjCo for ; Tue, 6 Sep 2011 17:21:59 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69821F8DDF for ; Tue, 6 Sep 2011 17:21:58 -0700 (PDT) Received: from [122.135.156.233] (port=57841 helo=[192.168.1.139]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R15va-0005Hu-0k; Tue, 06 Sep 2011 19:23:42 -0500 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <4E661C01.3010803@bell-labs.com> Date: Wed, 7 Sep 2011 09:23:40 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1244.3) 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: fl1-122-135-156-233.tky.mesh.ad.jp ([192.168.1.139]) [122.135.156.233]:57841 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 00:22:00 -0000 Hi Vijay; My comments inline.. On Sep 6, 2011, at 10:11 PM, Vijay K. Gurbani wrote: > On 09/06/2011 06:32 AM, Shida Schubert wrote: >> >> I think the general approach is fine. > > Shida: Thank you for your comments. More inline. > >> Client sends the list and server picks one is the current >> approach, so client has no way to present preference, >> and as far as I can tell the server has no way to change >> the algorithm unless client initiates the re-negotiation. I >> don't have any problem with that as we want to keep it >> as simple as possible but I thought I would share my >> observation. >> *As far as I can read from the text, there was no text >> saying that server can include "oc-algo" with list of >> algorithm it supports in a response to negotiate the >> algorithm with the client. > > Right; the server simply gets to choose one from the list > provided by the client. > >> - If we want to allow client to show preference, we can >> say that the list is composed in a order that it prefers. >> Whether server honor that or not is a different story. > > That is fine with me, and more preferable than adding additional > parameters showing preference (a q-value). > >> It's also not clear to me the expected normative behavior >> surrounding "oc-algo", I am assuming that "oc-algo" only >> shows up when negotiating but it is currently not clear. So >> we should probably be clear with when "oc-algo" shows >> up so client/server both know when to set it and what it means. >> >> Below are my interpretation. >> >> Client sets "oc-algo" in request only when it wants to >> negotiate the algorithm to be used. > > I agree this part is unclear. Here is my view, and if you > and the list agrees, I can update the draft. > > For the normal sake of fault-tolerance, robustness, and > carrying as much state in the message itself, the > oc-algo appears in every request, with one important difference. > When the client first contacts the server, and thereupon every > time the timer fires, the oc-algo list will contain all > schemes supported by the client. Once an algorithm has been agreed > to, it becomes the sole value that goes into the oc-algo parameter > until re-negotiation. Sending it as the sole value allows for > an backup server to continue using the same algorithm agreed > to by its predecessor. Okay, fair enough. I guess we should probably mandate the inclusion of "oc-algo" in that case. It is currently stated on 4.1 as "MAY" add an "oc-algo".. One can assume that not having "oc-algo" indicates that the client only supports or wants to use the default "loss" based algorithm but if that is the case we should probably have a statement saying that too. I prefer mandating the inclusion of "oc-algo" so it is always clear what the client/server means/wants. > >> Server knows that the negotiation is requested >> due to the fact that "oc-algo" is present in the via. >> It selects the algorithm and sends that in the response. > > Yes, the above works in both cases. That is, when there is a list > of algorithms and when one has been chosen and the client/server > pair is in between the timer for the next negotiation going off. > In the latter case, the server does not have too much latitude at > choosing, but the former case (list of algorithms), the server > can choose afresh. > >> No "oc-algo" shows up until the next negotiation phase. >> >> Should we say anything about when timer runs out? > > I believe this is present in Section 5.7: > > Once the client and server agree on an overload control > algorithm, it MUST remain in effect for at least 3600 seconds > (1 hour) before renegotiation occurs. > >> Should we have a text mandating that if the timer runs out, >> client negotiates the algorithm on the next request it sends >> to the server?? > > I believe it is already there in Section 5.7: > > Renegotiation, when desired, is simply accomplished by the > SIP client sending a complete list of overload control > algorithms it supports in a "oc-algo" parameter in a > request going downstream. The downstream server, as before, MUST > choose one algorithm from the list and MUST pare the list down to > include the one chosen algorithm. The pared down list consisting of > the chosen algorithm MUST be returned to the upstream SIP client in > the response and stays in effect until the next renegotiation. I must have misread it, it looks good. Regards Shida > > If the last two points you make are not clear in Section 5.7, please > let me know and I can see if I can highlight these in some fashion. > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Tue Sep 6 19:44:01 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 08BE221F8DD0 for ; Tue, 6 Sep 2011 19:44:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHcIclbT4kfS for ; Tue, 6 Sep 2011 19:44:00 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D94421F8DCA for ; Tue, 6 Sep 2011 19:43:59 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p872jjbl020718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 21:45:46 -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 p872ji8O024591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Sep 2011 21:45:45 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.33.112]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p872ji3X004038; Tue, 6 Sep 2011 21:45:44 -0500 (CDT) Message-ID: <4E66DB5F.1090205@bell-labs.com> Date: Tue, 06 Sep 2011 21:47:59 -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.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Shida Schubert References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.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.11 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 02:44:01 -0000 On 09/06/2011 07:23 PM, Shida Schubert wrote: > Okay, fair enough. > > I guess we should probably mandate the inclusion of "oc-algo" in that > case. It is currently stated on 4.1 as "MAY" add an "oc-algo".. > > One can assume that not having "oc-algo" indicates that the client > only supports or wants to use the default "loss" based algorithm but > if that is the case we should probably have a statement saying that > too. > > I prefer mandating the inclusion of "oc-algo" so it is always clear > what the client/server means/wants. Shida: Great, thanks. I will wait to see if anyone else has any other views on this, and if not, I will go ahead and update as agreed upon. > I must have misread it, it looks good. Great; thanks for giving it a good read. Ciao, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From volker.hilt@alcatel-lucent.com Wed Sep 7 05:34: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 E3E1B21F8C08 for ; Wed, 7 Sep 2011 05:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 Nx4um69qZptv for ; Wed, 7 Sep 2011 05:34:46 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6DC21F8C06 for ; Wed, 7 Sep 2011 05:34:46 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p87CaWuB006552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 07:36:33 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87CaUII002377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Sep 2011 07:36:32 -0500 Received: from [135.244.39.73] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 7 Sep 2011 07:36:31 -0500 Message-ID: <4E676532.4060408@alcatel-lucent.com> Date: Wed, 7 Sep 2011 08:36:02 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.com> <4E66DB5F.1090205@bell-labs.com> In-Reply-To: <4E66DB5F.1090205@bell-labs.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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 12:34:47 -0000 On 9/6/2011 10:47 PM, Vijay K. Gurbani wrote: > On 09/06/2011 07:23 PM, Shida Schubert wrote: >> Okay, fair enough. >> >> I guess we should probably mandate the inclusion of "oc-algo" in that >> case. It is currently stated on 4.1 as "MAY" add an "oc-algo".. >> >> One can assume that not having "oc-algo" indicates that the client >> only supports or wants to use the default "loss" based algorithm but >> if that is the case we should probably have a statement saying that >> too. >> >> I prefer mandating the inclusion of "oc-algo" so it is always clear >> what the client/server means/wants. > I agree. Following up on the previous discussion of having the client include only the current algorithm. I think the selection of the algorithm is essentially a server issue. Once the server knows which algorithms the client supports it can pick one. I'm not sure what the value is of having the client include only the currently selected algorithm and trigger a renegotiation once in a while. I think the client should always include all supported algorithms. The server gets to choose since it needs to shoulder the burden of generating the feedback for each client. In the spirit of keeping things simple, I don't think expressing preferences adds much value. The client should send a flat list the sever can choose from. The draft should, of course, have a discussion about chosing the algorithm in the server (i.e., not changing it often, etc) Thanks, Volker [as individual] From shida@ntt-at.com Wed Sep 7 06:49:27 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 33E5821F8B7A for ; Wed, 7 Sep 2011 06:49:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7UceYhr8Fzy for ; Wed, 7 Sep 2011 06:49:26 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B783121F8B70 for ; Wed, 7 Sep 2011 06:49:25 -0700 (PDT) Received: from [122.135.156.233] (port=60383 helo=[192.168.1.139]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1IWv-0003Y2-VO; Wed, 07 Sep 2011 08:51:08 -0500 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4E676532.4060408@alcatel-lucent.com> Date: Wed, 7 Sep 2011 22:51:03 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8CE63924-C744-4A00-9F7A-FB7491B4C7B0@ntt-at.com> References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.com> <4E66DB5F.1090205@bell-labs.com> <4E676532.4060408@alcatel-lucent.com> To: Volker Hilt X-Mailer: Apple Mail (2.1244.3) 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: fl1-122-135-156-233.tky.mesh.ad.jp ([192.168.1.139]) [122.135.156.233]:60383 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sip-overload@ietf.org Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 13:49:27 -0000 My comments inline.. On Sep 7, 2011, at 9:36 PM, Volker Hilt wrote: > On 9/6/2011 10:47 PM, Vijay K. Gurbani wrote: >> On 09/06/2011 07:23 PM, Shida Schubert wrote: >>> Okay, fair enough. >>>=20 >>> I guess we should probably mandate the inclusion of "oc-algo" in = that >>> case. It is currently stated on 4.1 as "MAY" add an "oc-algo".. >>>=20 >>> One can assume that not having "oc-algo" indicates that the client >>> only supports or wants to use the default "loss" based algorithm but >>> if that is the case we should probably have a statement saying that >>> too. >>>=20 >>> I prefer mandating the inclusion of "oc-algo" so it is always clear >>> what the client/server means/wants. >>=20 > I agree. >=20 > Following up on the previous discussion of having the client include = only the current algorithm. I think the selection of the algorithm is = essentially a server issue. Once the server knows which algorithms the = client supports it can pick one. I'm not sure what the value is of = having the client include only the currently selected algorithm and = trigger a renegotiation once in a while. >=20 > I think the client should always include all supported algorithms. The = server gets to choose since it needs to shoulder the burden of = generating the feedback for each client. I agre with your opinion that it is really the server side that really=20= cares what algorithm it uses, so I think this is better.=20 >=20 > In the spirit of keeping things simple, I don't think expressing = preferences adds much value. The client should send a flat list the = sever can choose from. If client doesn't benefit from certain algorithm being selected, I = agree.=20 Regards Shida >=20 > The draft should, of course, have a discussion about chosing the = algorithm in the server (i.e., not changing it often, etc) >=20 > Thanks, >=20 > Volker [as individual] > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From vkg@bell-labs.com Wed Sep 7 07:23:27 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 E253B21F8B6E for ; Wed, 7 Sep 2011 07:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 yeEgK+EfDKrW for ; Wed, 7 Sep 2011 07:23:24 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E4CC421F8B68 for ; Wed, 7 Sep 2011 07:23:23 -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 p87EP9pJ027464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 09:25:09 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87EP9tr010313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 09:25:09 -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 p87EP81R020364 for ; Wed, 7 Sep 2011 09:25:09 -0500 (CDT) Message-ID: <4E677F4B.4080708@bell-labs.com> Date: Wed, 07 Sep 2011 09:27:23 -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.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: "sip-overload@ietf.org" References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.com> <4E66DB5F.1090205@bell-labs.com> <4E676532.4060408@alcatel-lucent.com> In-Reply-To: <4E676532.4060408@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 14:23:28 -0000 On 09/07/2011 07:36 AM, Volker Hilt wrote: > Following up on the previous discussion of having the client include > only the current algorithm. I think the selection of the algorithm is > essentially a server issue. Once the server knows which algorithms > the client supports it can pick one. I'm not sure what the value is > of having the client include only the currently selected algorithm > and trigger a renegotiation once in a while. Volker: Three reasons. Consider a case where a client/server pair has agreed on an algorithm. Shortly after agreement, and before the re-negotiation timer expires, the server crashes. A backup server takes its place. The client continues to operate on the previously chosen algorithm, even if the new server supports schemes that the old server did not. The alternative is that if we send the complete algorithm list, the new server may choose a different scheme than its predecessor did, causing the client some mild discomfort. Second, it seems more explicit for the client to send only the algorithm agreed upon. Sending the entire list every time forces the server to always parse the list. Finally, given that the Via header line length is constantly increasing, it is advantageous not to insert an entire list, however small it may be. > I think the client should always include all supported algorithms. > The server gets to choose since it needs to shoulder the burden of > generating the feedback for each client. If the working group wants to go with the alternative of sending an entire list on each request, I am perfectly happy to do so; but I did want to at least provide a justification for not doing so. > The draft should, of course, have a discussion about chosing the > algorithm in the server (i.e., not changing it often, etc) The feedback we got the previous time is that we have to do a better job of simply saying that the algorithm should not change too often ("how long is too often? Once a transaction? Once a dialogue? Once every 5 minutes? Once every 10 requests?"). Hence the addition of the timer with a default value of 3600s to handle the renegotiation. If you have any alternative means to affect the same outcome deterministically, please do let me know. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From volker.hilt@alcatel-lucent.com Wed Sep 7 07:27:54 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 001FD21F8C09 for ; Wed, 7 Sep 2011 07:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 gF6QkDuLYzcw for ; Wed, 7 Sep 2011 07:27:53 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF4B21F8BDE for ; Wed, 7 Sep 2011 07:27:53 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p87ETfpV020951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 09:29:41 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87ETf3h013140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Sep 2011 09:29:41 -0500 Received: from [135.112.131.41] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 7 Sep 2011 09:29:41 -0500 Message-ID: <4E677F89.6070000@alcatel-lucent.com> Date: Wed, 7 Sep 2011 10:28:25 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.com> <4E66DB5F.1090205@bell-labs.com> <4E676532.4060408@alcatel-lucent.com> <4E677F4B.4080708@bell-labs.com> In-Reply-To: <4E677F4B.4080708@bell-labs.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 14:27:54 -0000 On 9/7/2011 10:27 AM, Vijay K. Gurbani wrote: > On 09/07/2011 07:36 AM, Volker Hilt wrote: >> Following up on the previous discussion of having the client include >> only the current algorithm. I think the selection of the algorithm is >> essentially a server issue. Once the server knows which algorithms >> the client supports it can pick one. I'm not sure what the value is >> of having the client include only the currently selected algorithm >> and trigger a renegotiation once in a while. > > Volker: Three reasons. > > Consider a case where a client/server pair has agreed on an > algorithm. Shortly after agreement, and before the re-negotiation > timer expires, the server crashes. A backup server takes its > place. The client continues to operate on the previously chosen > algorithm, even if the new server supports schemes that the old > server did not. The alternative is that if we send the complete > algorithm list, the new server may choose a different scheme > than its predecessor did, causing the client some mild discomfort. > I think this is a good case in which the server can switch. Otherwise the client forces the server into using a specific algorithm, which it may not even support. > Second, it seems more explicit for the client to send only the > algorithm agreed upon. Sending the entire list every time forces the > server to always parse the list. > Once everything is up and running all the server needs to do is look for the algorithm it is currently using. But I agree that may be slightly more work. > Finally, given that the Via header line length is constantly increasing, > it is advantageous not to insert an entire list, however small it may > be. > I think we are talking about a very small list. If you are concerned about the Via header length, we can make the identifiers very small. >> I think the client should always include all supported algorithms. >> The server gets to choose since it needs to shoulder the burden of >> generating the feedback for each client. > > If the working group wants to go with the alternative of sending > an entire list on each request, I am perfectly happy to do so; but I did > want to at least provide a justification for not doing so. > Fully understood! >> The draft should, of course, have a discussion about chosing the >> algorithm in the server (i.e., not changing it often, etc) > > The feedback we got the previous time is that we have to do a better > job of simply saying that the algorithm should not change too often > ("how long is too often? Once a transaction? Once a dialogue? > Once every 5 minutes? Once every 10 requests?"). Hence the addition > of the timer with a default value of 3600s to handle the renegotiation. > If you have any alternative means to affect the same outcome > deterministically, please do let me know. > I think it makes sense to specify this for the server side. I.e., give recommendations of when the server may consider to change an algorithm. Thanks, Volker From vkg@bell-labs.com Wed Sep 7 12: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 8B0E321F8B05 for ; Wed, 7 Sep 2011 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 UoKjeQNTyUC3 for ; Wed, 7 Sep 2011 12:37:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id B762421F8AD8 for ; Wed, 7 Sep 2011 12:37:52 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p87JdgpA004858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 14:39:42 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87JdfkT000686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 14:39:42 -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 p87Jdf1M004043 for ; Wed, 7 Sep 2011 14:39:41 -0500 (CDT) Message-ID: <4E67C906.1030909@bell-labs.com> Date: Wed, 07 Sep 2011 14:41:58 -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.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4E613160.5010701@bell-labs.com> <4E661C01.3010803@bell-labs.com> <4E66DB5F.1090205@bell-labs.com> <4E676532.4060408@alcatel-lucent.com> <4E677F4B.4080708@bell-labs.com> <4E677F89.6070000@alcatel-lucent.com> In-Reply-To: <4E677F89.6070000@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes 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 Sep 2011 19:37:53 -0000 On 09/07/2011 09:28 AM, Volker Hilt wrote: > I think this is a good case in which the server can switch. Otherwise > the client forces the server into using a specific algorithm, which it > may not even support. True; this is the flip side that I did not consider. I simply assumed that the server supported all schemes offered by the client, and would therefore zero in on the singleton algorithm in the client's list. > I think we are talking about a very small list. If you are concerned > about the Via header length, we can make the identifiers very small. That is okay. I do not forsee having too many algorithms here. On when to do re-negotiation: > I think it makes sense to specify this for the server side. I.e., give > recommendations of when the server may consider to change an algorithm. Hmmm ... I had always assumed that this will be done on the client side. However, if the client is sending the complete algorithm list in every request, then it does not make sense to do it there for obvious reasons. So it looks like we will have to do it on the server side. I will update the draft as such. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From phil.m.williams@bt.com Mon Sep 12 04:02:42 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 6C48D21F84FD for ; Mon, 12 Sep 2011 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 8bLkKBd+NqL9 for ; Mon, 12 Sep 2011 04:02:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id A515821F84DF for ; Mon, 12 Sep 2011 04:02:39 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 12 Sep 2011 12:04:42 +0100 Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 12 Sep 2011 12:04:41 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.2.127]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Mon, 12 Sep 2011 12:04:41 +0100 From: To: , Date: Mon, 12 Sep 2011 12:04:32 +0100 Thread-Topic: Comments on draft-ietf-soc-overload-control-03: oc and oc-validity Thread-Index: AcxxO8BGTrXEFPTJTb20JTprgH/ugg== Message-ID: 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: multipart/alternative; boundary="_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5D269E47EMV04UKBRdoma_" MIME-Version: 1.0 Subject: [sip-overload] Comments on draft-ietf-soc-overload-control-03: oc and oc-validity 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 Sep 2011 11:02:42 -0000 --_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5D269E47EMV04UKBRdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vijay et al, I have been reviewing draft-ietf-soc-overload-control-03 and have a few com= ments and proposals. Some of the text referring to oc and oc-validity from different sections is= rather ambiguous and sometimes inconsistent with assumptions implicitly be= ing made during recent dialogues. And whilst reviewing this, it has highlig= hted a few questions for me, i.e. how do we want a server to: * indicate that there isn't any overload, i.e. control is not require= d, * immediately terminate control when it has previously been active? We have debated the second of these recently and Vijay has included oc-vali= dity=3D0 explicitly in draft 03 to cover it. So I have put together some notes and proposals for discussion. Specific text ------------------- Consider: 4.3. The oc-validity parameter ... A non-zero value for the "oc-validity" parameter MUST only be present in conjunction with an "oc" parameter. Does this mean "oc" parameter value, or just the presence of "oc"? If a val= ue is not provided a possible interpretation is to leave any control applie= d with the prior value and restart the oc-validity time interval. In addition, although the above does not prohibit having oc-validity=3D0 wi= thout an "oc" parameter, later text would do so: 5.1. Creating and updating the overload control parameters ... The "oc-validity" parameter MUST NOT be used in a Via header that did no= t originally contain an "oc" parameter when received... although what follows immediately this suggests that it may be permissible: = ...Furthermore, when a SIP server receives a request with the topmost Via header containing only an "oc-validity" parameter without the accompanying "oc" parameter, it MUST ignore the "oc-validity" [Aside: This is rather confusing since in this context 'SIP server' should = be 'SIP client'. Can we change this?] We also have, if the SIP client has previously added an "oc" parameter: 4.1. The oc parameter ... The downstream server MUST add a value to the "oc" parameter in the response going upstream; this value represents a metric by which the requests arriving at the downstream server should be reduced. But do we really need or want to make the addition of a value mandatory? E.= g. when a server deems that control is inactive it would be unnecessary. I = recall that this has been implicitly assumed in some recent dialogue in any= case. Some proposals ------------------------- * Most of the time overload will not be present, so why not allow the= server to omit an oc value even if the client has inserted oc (currently f= orbidden)? If this method is not adopted then inactive overload would other= wise have to be indicated by sending oc-validity=3D0, since for some client= restriction algorithms, such as rate-based, there is no natural 'off' oc v= alue; * Currently in 4.3 there is no statement when the oc-validity has to = be added, it just states 'is inserted'. Should this be made more precise? * We could allow the oc-validity to be added with an oc parameter, bu= t without an oc parameter value. If control is not active at the client, th= en again it would be ignored (case above). If control is active, then if oc= -validity>0 the oc-validity timer is restarted without changing the oc valu= e; if oc-validity=3D0 control is terminated. [We could also allow the oc-va= lidity to be added in the absence of an any oc parameter, and what is curre= ntly in the latter part of 5.1 assures us that it will be ignored, although= the wording may need to be made more precise]. Views? Regards, Phil Williams --_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5D269E47EMV04UKBRdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Vijay et al,
 
I have been reviewing draft-ietf-soc-overload-control-03 and have a fe= w comments and proposals.
 
Some of the text referring to oc and oc-validity from different sectio= ns is rather ambiguous and sometimes inconsistent with assumptions implicit= ly being made during recent dialogues. And whilst reviewing this, it has hi= ghlighted a few questions for me, i.e. how do we want a server to:
  • indicate that there isn’t any overload, i.e. control is not requi= red,
  • immediately terminate control when it has previously been acti= ve?
 
We have debated the second of these recently and Vijay has included oc= -validity=3D0 explicitly in draft 03 to cover it.
 
So I have put together some notes and proposals for discussion.
 
Specific text
-------------------
 
Consider:
 
4.3.  The oc-validity parameter=
   …
   A non-zero value for th= e "oc-validity" parameter MUST only be present
   in conjunction with an = "oc" parameter.
 
Does this mean "oc" parameter value, or just the presence of= "oc"? If a value is not provided a possible interpretation is to= leave any control applied with the prior value and restart the oc-validity= time interval.
In addition, although the above does not prohibit having oc-validity= =3D0 without an "oc" parameter, later text would do so:
 
5.1.  Creating and updating the= overload control parameters
   …
   The "oc-validity&q= uot; parameter MUST NOT be used in a Via header that did not
   originally contain an &= quot;oc" parameter when received…
 
although what follows immediately this suggests that it may be permiss= ible:
 
      =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            ̷= 0;Furthermore,
   when a SIP server recei= ves a request with the topmost Via header
   containing only an &quo= t;oc-validity" parameter without the accompanying
   "oc" paramete= r, it MUST ignore the "oc-validity"
 
[Aside: This is rather confusing since in this context ‘SIP serv= er’ should be ‘SIP client’. Can we change this?]
 
We also have, if the SIP client has previously added an "oc"= parameter:
 
4.1.  The oc parameter
   …
   The downstream server M= UST add a value to the "oc" parameter in the
   response going upstream= ; this value represents a metric by which the
   requests arriving at th= e downstream server should be reduced.
 
But do we really need or want to make the addition of a value mandator= y? E.g. when a server deems that control is inactive it would be unnecessar= y. I recall that this has been implicitly assumed in some recent dialogue i= n any case.
 
Some proposals
-------------------------
 
  • Most of the time overload will not be present, so why not allow the ser= ver to omit an oc value even if the client has inserted oc (currently forbi= dden)? If this method is not adopted then inactive overload would otherwise= have to be indicated by sending oc-validity=3D0, since for some client restriction algorithms, such as rate= -based, there is no natural ‘off’ oc value;
  • Currently i= n 4.3 there is no statement when the oc-validity has to be added, it just s= tates ‘is inserted’. Should this be made more precise?
  • = We could allow the oc-validity to be added with an oc parameter, but withou= t an oc parameter value. If control is not active at the client, then again= it would be ignored (case above). If control is active, then if oc-validit= y>0 the oc-validity timer is restarted without changing the oc value; if oc-validity=3D0 control is term= inated. [We could also allow the oc-validity to be added in the absence of = an any oc parameter, and what is currently in the latter part of 5.1 assure= s us that it will be ignored, although the wording may need to be made more precise].
 
Views?
 
Regards,
 
Phil Williams
 
 --_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5D269E47EMV04UKBRdoma_-- From salvatore.loreto@ericsson.com Fri Sep 23 06:16: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 8B1A221F8C6D for ; Fri, 23 Sep 2011 06:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 vGmyNLOl4nu4 for ; Fri, 23 Sep 2011 06:16:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AB7FB21F8C6E for ; Fri, 23 Sep 2011 06:16:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b2-4e7c87464544 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 30.E9.20773.7478C7E4; Fri, 23 Sep 2011 15:19:03 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 15:19:02 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B1F0B245F; Fri, 23 Sep 2011 16:19:02 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7D23251467; Fri, 23 Sep 2011 16:19:02 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1F63C51447; Fri, 23 Sep 2011 16:19:02 +0300 (EEST) Message-ID: <4E7C8745.3060305@ericsson.com> Date: Fri, 23 Sep 2011 16:19:01 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "sip-overload@ietf.org" References: <20110923122246.5878021F8B3D@ietfa.amsl.com> In-Reply-To: <20110923122246.5878021F8B3D@ietfa.amsl.com> X-Forwarded-Message-Id: <20110923122246.5878021F8B3D@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Volker Hilt Subject: [sip-overload] Fwd: SOC-Not having a session at IETF 82 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, 23 Sep 2011 13:16:30 -0000 hi there, it seems that no one of the main contributors will attend the IETF82 meeting in Taipei, so Volker and I have decided not to request any session. We of course will continue all the work in the mailing list best regards Salvatore Loreto www.sloreto.com