[Sipping] Overload/Congestion mechanisms - design choices and issues
Jonathan Rosenberg <jdrosen@cisco.com> Tue, 27 June 2006 20:51 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKWX-0002lA-QO; Tue, 27 Jun 2006 16:51:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKWU-0002dt-FH for sipping@ietf.org; Tue, 27 Jun 2006 16:51:02 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvKWT-0001vv-0p for sipping@ietf.org; Tue, 27 Jun 2006 16:51:02 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jun 2006 16:51:01 -0400
X-IronPort-AV: i="4.06,184,1149480000"; d="scan'208"; a="91140154:sNHT31283740"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5RKp0no000194 for <sipping@ietf.org>; Tue, 27 Jun 2006 16:51:00 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 16:51:00 -0400
Received: from [161.44.34.166] ([161.44.34.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 16:50:59 -0400
Message-ID: <44A19A32.6010909@cisco.com>
Date: Tue, 27 Jun 2006 16:50:58 -0400
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: IETF Sipping List <sipping@ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jun 2006 20:50:59.0822 (UTC) FILETIME=[652AE8E0:01C69A2B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Subject: [Sipping] Overload/Congestion mechanisms - design choices and issues
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
I've submitted an update to the overload requirements document. I've made some changes based on list feedback since the last meeting. Until the document appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sipping-overload-reqs-01.txt I didnt submit as a WG -00 since, AFAIK, we have no charter item for this work and there can't be a work item for it until that happens. We also are fortunate to have had two documents produced that propose solutions to meet the requirements: http://www.ietf.org/internet-drafts/draft-malas-sipping-congestion-header-01.txt http://www.ietf.org/internet-drafts/draft-hilt-sipping-hopbyhop-overload-00.txt I think these two drafts are a good start. However, there are many issues to be addressed that are not covered by the drafts. Here are some thoughts on some of the issues and design choices involved here: ISSUE 1: inband with SIP vs. parallel protocol One approach to solving the overload mechanism is to extend SIP with new information to report overload, as both drafts have done. Another approach is to design a parallel protocol that runs between elements which you could apply to any other protocol, SIP or otherwise. This is the approach proposed in GOCAP, which Steve posted a reference to. My personal opinion is that I prefer a SIP extension. There are several reasons for this. The main one is that a parallel protocol is inherently more complicated, as it requires its own syntaxes, state machines, messages, and so on, and also adds complexity due to the need to define interfaces into the elements whose load is being managed. As such, I think it raises the bar much higher for implementation, and I think this protocol should be simple as possible to drive implementation. We already have some overload management in SIP; it just doesn't work well. Its totally appropriate to extend SIP to improve whats there. ISSUE 2: how to make sure that overload information passed in SIP messages is only processed by the upstream server This issue is largely a SIP machinery problem, and there are several solutions. A few are proposed in Volker's draft. I personally prefer the approach of including congestion information in a response, and using an IP address in that header field to indicate the server for which overload is being reported. ISSUE 3: what is the nature of the overload information Volker proposes a value between 0 and 100, and Daryl proposes a multidimensional value from 0 to 5. You really can't answer this design issue until you answer the next, which is one of the two BIG design issues I think. ISSUE 4: how does an element respond to overload information When an upstream element has a set of load indicators from downstream elements, how does it use that information to decide which server to send it to, or whether it should reject the request. How does it do this in a way that keeps the network throughput up? How does it make sure that it still distributes load in a reasonable way across the downstream elements? This is big isssue #1. ISSUE 5: how does a downstream element determine which incoming traffic to process based on upstream server? There are many aspects to this issue. One of the harder ones is a policing function. Think of a server has having input queus, one for each upstream element. The server processes requests from an upstream element by taking a request off that queue. What is the queuing discipline implemented by this server? If you just do something basic like round-robin, you end up in an interesting situation of rewarding upstream elements which DONT implement the mechanism! There needs to be a way of verifying that elements are sending at a reduced rate based on the congestion indications, and of determining a rate to allocate to upstream elements which don't support it. This is big issue #2. ISSUE 6: What is the temporal scope of reported congestion information? When an upstream element receives congestion information, how long does it consider it valid for? What does it do when it receives no information from a downstream element? What does it do if it cannot reach a downstream element? ISSUE 7: How does the system work for upstream elements which are not "servers" I tend to think of the overload mechanism as having two modes. One mode is where an element knows of all of the upstream elements sending it traffic. It uses this knowledge to figure out what kind of rate to proportionally allocate to each upstream element. In the other mode, we have somethign like an edge proxy, which has many many clients that connect to it. How does that edge element implement overload handling? Certainly it does; if the network as a whole is overloaded, you need to push back to the actual source so that the overall load being sent into the network is reduced. That source are the endpoints themselves. In this mode, the existing 503 mechanism works better. But, you want the edge proxy to push back gradually, sending 503 (or something else) to some fraction of the clients, so that you reduce the input load proportionally. I'm sure there are many more issues and many other ways to look at them. Hopefully this helps get discussions going on what a mechanism document needs to cover. Thanks, 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
- [Sipping] Overload/Congestion mechanisms - design… Jonathan Rosenberg
- Re: [Sipping] Overload/Congestion mechanisms - de… Volker Hilt
- Re: [Sipping] Overload/Congestion mechanisms - de… Jeroen van Bemmel
- RE: [Sipping] Overload/Congestion mechanisms - de… Roy, Radhika R.
- Re: [Sipping] Overload/Congestion mechanisms - de… Indra Widjaja
- Re: [Sipping] Overload/Congestion mechanisms - de… Volker Hilt
- Re: [Sipping] Overload/Congestion mechanisms - de… Volker Hilt
- Re: [Sipping] Overload/Congestion mechanisms - de… Gonzalo Camarillo