Re: [sip-overload] draft-ietf-soc-overload-control-02

"Vijay K. Gurbani" <vkg@bell-labs.com> Wed, 30 March 2011 13:44 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: sip-overload@core3.amsl.com
Delivered-To: sip-overload@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510E23A6B59 for <sip-overload@core3.amsl.com>; Wed, 30 Mar 2011 06:44:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJEP5rkHzY-D for <sip-overload@core3.amsl.com>; Wed, 30 Mar 2011 06:44:46 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 133533A6B57 for <sip-overload@ietf.org>; Wed, 30 Mar 2011 06:44:43 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2UDkL2S014285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sip-overload@ietf.org>; Wed, 30 Mar 2011 08:46:21 -0500 (CDT)
Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.41.21]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p2UDkKaW013447 for <sip-overload@ietf.org>; Wed, 30 Mar 2011 08:46:21 -0500 (CDT)
Message-ID: <4D93349D.8060804@bell-labs.com>
Date: Wed, 30 Mar 2011 08:48:13 -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.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
To: sip-overload@ietf.org
References: <EDC0A1AE77C57744B664A310A0B23AE21EB2B35C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE21EB2B35C@FRMRSSXCHMBSC3.dc-m.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
Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 30 Mar 2011 13:44:47 -0000

On 03/29/2011 08:58 AM, DRAGE, Keith (Keith) wrote:
> OK so you asked me to look at section 12 in the soc meeting and I
> have done so.
[...]
> My understanding for allowing this is simplicity in the sender (to
> treat all 100 and 1xx in a similar manner at the sender), rather than
> expectation that the receiver will receive it. I think this point
> needs to be made clearer.

Keith: Well ... Section 12 considers simplicity in the receiver
as well as the sender.  The sender of the response does not need to
couple TU-provided information (oc) with the response being
generated at the transaction layer (100), and on the
receiving side, the receiver does not have to provide the
oc information from the 100 to the TU.

If this is not clear, I will make another stab at this.
I have to update Section 12 to incorporate Victor's comment
regarding 100rel anyway.  So, stay tuned for the next revision.

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/