Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 16 July 2010 15:32 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 C27123A6A0E for <sip-overload@core3.amsl.com>; Fri, 16 Jul 2010 08:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599]
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 7sxt8ZWcB3xf for <sip-overload@core3.amsl.com>; Fri, 16 Jul 2010 08:32:38 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 74E283A67CC for <sip-overload@ietf.org>; Fri, 16 Jul 2010 08:32:36 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6GFWZkY010237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 10:32:35 -0500 (CDT)
Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6GFWY7g020555; Fri, 16 Jul 2010 10:32:35 -0500 (CDT)
Message-ID: <4C407BF8.7090002@bell-labs.com>
Date: Fri, 16 Jul 2010 10:34:16 -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.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <4C3B9BAE.6080905@bell-labs.com> <430FC6BDED356B4C8498F634416644A91FE89647FD@mail> <4C3FDE1C.4020505@bell-labs.com> <430FC6BDED356B4C8498F634416644A921187F71F8@mail>
In-Reply-To: <430FC6BDED356B4C8498F634416644A921187F71F8@mail>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject: Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives
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: Fri, 16 Jul 2010 15:32:51 -0000

On 07/16/2010 09:01 AM, Hadriel Kaplan wrote:
>> Using a timestamp, OTOH, has the nice property that each thread can
>> generate a timestamp without needing to enter a critical section.
>>
>> Allowing implementations to use any one of the above absolves us
>> from impacting the architecture of a specific implementation.
>
> Right that's what I assumed the reason for a timestamp was, but I
> didn't mean it couldn't be based on a timestamp - just that we should
> pick one encoding format.

Hadriel: OK; in that case, I will go ahead and update the ABNF to
use a timestamp only instead of a pure sequence number.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/