[sip-overload] draft-ietf-soc-overload-control-09
"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 06 July 2012 21:23 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 373C011E80F3 for <sip-overload@ietfa.amsl.com>; Fri, 6 Jul 2012 14:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.099
X-Spam-Level:
X-Spam-Status: No, score=-108.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 t0Fhpnn8kX1W for <sip-overload@ietfa.amsl.com>; Fri, 6 Jul 2012 14:23:45 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEED11E808F for <sip-overload@ietf.org>; Fri, 6 Jul 2012 14:23:45 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q66LO1BS022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Fri, 6 Jul 2012 16:24:02 -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 q66LO1vV026499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sip-overload@ietf.org>; Fri, 6 Jul 2012 16:24:01 -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 q66LO1kw014683 for <sip-overload@ietf.org>; Fri, 6 Jul 2012 16:24:01 -0500 (CDT)
Message-ID: <4FF758D7.3010203@bell-labs.com>
Date: Fri, 06 Jul 2012 16:29:59 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0
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.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: [sip-overload] draft-ietf-soc-overload-control-09
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, 06 Jul 2012 21:23:46 -0000
Folks: The last iteration of the loss-based draft's default algorithm [1] was presented in the Paris IETF. List discussions right before the meeting [2] indicated that the algorithm will need to go through one more revision. The reasons for this revision are outlined as the last two bullet items in [2]. I believe that to address these two bullet items, we have to make the algorithm responsive to the traffic mix, i.e., category 1 and category 2 prioritization markers need to reflect the mix of the traffic at any point in time. That way, the algorithm can adequately respond to any situation. In an emergency situation, the number of category 2 requests will dominate, so the reduction will occur from these whereas in non-emergency situations, normal messages will dominate the traffic mix and it makes sense to cull requests from category 1 as much as we can before moving to category 2. An updated algorithm that takes the changing traffic mix into account is now part of the revised version of the draft, version -09 [3]. I would appreciate review of the updated algorithm by the WG to make sure it is on the right track. I have also attended to all but two of the comments in [2]. I need to think on how to attend to the comments related to S5.4 in [2]. Besides these, I do not believe that there are any other outstanding comments. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-08#section-6.3 [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00764.html [3] http://tools.ietf.org/html/draft-ietf-soc-overload-control-09 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/
- [sip-overload] draft-ietf-soc-overload-control-09 Vijay K. Gurbani