IETF Logo Mail Archive

Re: [sip-overload] soc-overload-control-05

"Vijay K. Gurbani" <vkg@bell-labs.com> Mon, 16 January 2012 17:42 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 BAF3221F86A8 for <sip-overload@ietfa.amsl.com>; Mon, 16 Jan 2012 09:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.503
X-Spam-Level:
X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 3SvZt8Cy27nw for <sip-overload@ietfa.amsl.com>; Mon, 16 Jan 2012 09:42:28 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0803821F86A7 for <sip-overload@ietf.org>; Mon, 16 Jan 2012 09:42:27 -0800 (PST)
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 q0GHgPwN004218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Mon, 16 Jan 2012 11:42:25 -0600 (CST)
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 q0GHgO0i016850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sip-overload@ietf.org>; Mon, 16 Jan 2012 11:42:25 -0600
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 q0GHgOaa012742 for <sip-overload@ietf.org>; Mon, 16 Jan 2012 11:42:24 -0600 (CST)
Message-ID: <4F14626D.2030807@bell-labs.com>
Date: Mon, 16 Jan 2012 11:46:21 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: sip-overload@ietf.org
References: <4EEA1BB3.7020509@bell-labs.com> <2F8FB48C17221643AD77FA295756D2A72405E641CE@njfpsrvexg6.research.att.com> <4EF9F50F.0@bell-labs.com> <2F8FB48C17221643AD77FA295756D2A724060158A8@njfpsrvexg6.research.att.com> <4F10C29E.4000009@bell-labs.com>, <4F10C307.7010507@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A72405C10594@njfpsrvexg6.research.att.com> <4F11716B.2090304@ericsson.com>
In-Reply-To: <4F11716B.2090304@ericsson.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.9
Subject: Re: [sip-overload] soc-overload-control-05
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: Mon, 16 Jan 2012 17:42:28 -0000

On 01/14/2012 06:13 AM, Salvatore Loreto wrote:
> Vijay
>
> it looks good to me too. Thanks.

Sal: Thanks.  Closing the loop on one of your previous comments
that I have not yet responded to ... see [1].

To fix this, I suggest the following change:

OLD:
9.2 Backwards Compatibility
...
    A SIP server should therefore use 5xx responses towards upstream
    neighbors that do not support overload control. The server should
    reject the same amount of requests with 5xx responses that would be
    otherwise be rejected/redirected by the upstream neighbor if it would
    support overload control. If the load condition on the server does	
    not permit the creation of 5xx responses, the server should drop all
    requests from servers that do not support overload control.

NEW:
9.2 Backwards Compatibility
...
    A SIP server should therefore follow the behaviour outlined in
    Section 5.10.2 to handle clients that do not support overload
    control.

Thanks,

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00704.html

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

v2.8.7 | Report a Bug | By Email