[sip-overload] The frequency of re-negotiating overload control schemes
"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 02 September 2011 19:37 UTC
Return-Path: <vkg@bell-labs.com>
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 <sip-overload@ietfa.amsl.com>;
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
<sip-overload@ietfa.amsl.com>; 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
<sip-overload@ietf.org>; 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 <sip-overload@ietf.org>;
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 <sip-overload@ietf.org>; 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
<sip-overload@ietf.org>; 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" <vkg@bell-labs.com>
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" <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 <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>,
<mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>,
<mailto:sip-overload-request@ietf.org?subject=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/
- [sip-overload] The frequency of re-negotiating ov… Vijay K. Gurbani
- Re: [sip-overload] The frequency of re-negotiatin… Shida Schubert
- Re: [sip-overload] The frequency of re-negotiatin… Vijay K. Gurbani
- Re: [sip-overload] The frequency of re-negotiatin… Shida Schubert
- Re: [sip-overload] The frequency of re-negotiatin… Vijay K. Gurbani
- Re: [sip-overload] The frequency of re-negotiatin… Volker Hilt
- Re: [sip-overload] The frequency of re-negotiatin… Shida Schubert
- Re: [sip-overload] The frequency of re-negotiatin… Vijay K. Gurbani
- Re: [sip-overload] The frequency of re-negotiatin… Volker Hilt
- Re: [sip-overload] The frequency of re-negotiatin… Vijay K. Gurbani