[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/