[Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery

Jonathan Rosenberg <jdrosen@cisco.com> Mon, 06 November 2006 19:17 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9yN-0005Ov-Pw; Mon, 06 Nov 2006 14:17:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9yL-0005KY-P4 for sipping@ietf.org; Mon, 06 Nov 2006 14:17:30 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9yK-0003el-Ef for sipping@ietf.org; Mon, 06 Nov 2006 14:17:29 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 11:17:24 -0800
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAFIYT0WrR7O6WWdsb2JhbACMQAEUDis
X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="448341303:sNHT26431056"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6JHOQu005157 for <sipping@ietf.org>; Mon, 6 Nov 2006 11:17:24 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA6JHOin009173 for <sipping@ietf.org>; Mon, 6 Nov 2006 11:17:24 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:17:24 -0800
Received: from [130.129.65.86] ([10.21.97.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:17:23 -0800
Message-ID: <454F8A43.8000400@cisco.com>
Date: Mon, 06 Nov 2006 14:17:23 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com>
In-Reply-To: <250EF171-D4BB-4650-9C14-B7C8815FB7CE@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2006 19:17:23.0932 (UTC) FILETIME=[305D19C0:01C701D8]
DKIM-Signature: a=rsa-sha1; q=dns; l=1258; t=1162840644; x=1163704644; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:Re=3A=20draft-rosenberg-sipping-overload-reqs=20recovery; X=v=3Dcisco.com=3B=20h=3D/dXGc1TknZs+mVCq7jbtUsKSykM=3D; b=LWWiVV9ElqnaGBBPaPN3dHk17V5xAKM2RnJdJtVVk7xW15CATHQbJaOX+sv43iPwWUUoj7h8 j3DDEjqqqQB3bxNnt5K0gvzWh43a9iC82G+jZ9u88YHbD/HlFHxKUnCE;
Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: sipping <sipping@ietf.org>
Subject: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org


Cullen Jennings wrote:

> 
> A possible additional requirement....
> 
> Imagine a system (perhaps a single proxy) that could do 100cps. It is  
> in steady state doing 80cps with very few retransmission. Then for 5  
> minutes the incoming requests goes to 500cps then drops back to an  
> incoming call rate of 80cps. The question is, how long before the  
> system gets back to the state where it if is successfully processing  
> all the 80cps?

As soon as it can. Are you suggesting a requirement here? Seems like 
this is an implementation thing and wouldn't impact any protocol mechanisms.

> 
> I have seen systems that never recover - that is bad. I think one of  
> the design goals is that it is at least possible to build to systems  
> that recover back to steady state relatively quickly after an  overload 
> impulse.

Sure; but I'm not sure I see the protocol requirement.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP