[Sipping] Re: Queries and comments on draft-hilt-sipping-overload-00.txt
Volker Hilt <volkerh@bell-labs.com> Wed, 03 January 2007 04:09 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xR1-0003yl-CD; Tue, 02 Jan 2007 23:09:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xQz-0003yX-S2 for sipping@ietf.org; Tue, 02 Jan 2007 23:09:01 -0500
Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1xQx-0001Xp-HW for sipping@ietf.org; Tue, 02 Jan 2007 23:09:01 -0500
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0348m44019119; Tue, 2 Jan 2007 22:08:48 -0600 (CST)
Received: from [127.0.0.1] ([135.104.20.69]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l0348mW02551; Tue, 2 Jan 2007 23:08:48 -0500 (EST)
Message-ID: <459B2C4D.8000701@bell-labs.com>
Date: Tue, 02 Jan 2007 23:08:45 -0500
From: Volker Hilt <volkerh@bell-labs.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Darshan Bildikar <dbildikar@ipunity.com>
References: <EXCHANGEVMMxB6rbe3g00001461@exchangevm.ipunity.com>
In-Reply-To: <EXCHANGEVMMxB6rbe3g00001461@exchangevm.ipunity.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 192.11.226.42
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: 'sipping' <sipping@ietf.org>
Subject: [Sipping] Re: Queries and comments on draft-hilt-sipping-overload-00.txt
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
Darshan Bildikar wrote: > 1) How does this document relate to > "draft-rosenberg-sipping-overload-reqs-01"? Does it take into cognisance the > requirements defined in this document? > Yes, it should. > 2) It is envisioned that overload information is exchanged through a header > in response messages. Why not a more EXPLICIT mechanism like > SUBSCRIBE/NOTIFY? Define an event package for overload and define a body > that can be used to indicate a rich set of overload parameters to the > upstream entity. > Using SUBSCRIBE/NOTIFY would require a proxy to subscribe to a downstream neighbor when (or before) sending requests to this neighbor to inquire the current load status. This would cause some messaging overhead, in particular, for proxies that talk to many downstream neighbors. The nice property of using a response header is that it is very light-weight and it automatically provides feedback from the downstream entities a proxy is currently talking to. What did you have in mind for the rich set of overload parameters? > 3) The draft talks about overload w.r.t certain resources. If a sub/not > mechanism was used, it would allow overload control to be more "fine > grained". For example, the SUBSCRIBE message would indicate what resource > the requester is wants the overload throttling and statistics for. > Overload control is used when a SIP entity is unable to handle all incoming messages because it ran out of resources it needs for processing messages. To an upstream neighbor, it really does not matter which resource on the downstream element is the bottleneck. What matters is that the downstream element can't process all messages and, thus, the load has to be reduced. As long as the downstream element has enough capacity to return a meaningful response (e.g. 488 if a PSTN gateway runs out of trunk lines) it should do so. > A use case that I can think of > > I have two applications on my box; CRBT and video conferencing. I might be > fast running out of ports for video conferencing but might still be able to > do CRBT at 100%. I should be able to control the load based on the REQUEST > URI. I don't think this is a valid example for the use of overload control. If the box is still able to do CRBT, it should also be able to reject the additional requests for video conferencing. > I'm thinking that the SUBSCRIBE shall indicate, "Give me overload statistics > as if I were sending you this REQUEST URI". I'm assuming that a request URI > maps to a "resource" but there could be a better way this could be done. > > This mechanism would help throttling based on SIP method, URI, host, port > etc and will be able to support REQ 18 defined in > draft-rosenberg-sipping-overload-reqs-01". > > Two things that I haven't really thought through. > > 1) Throttling based on codecs and media lines would be useful. For example, > I can support audio right now, but NOT video. > 2) Is it possible to make this mechanism more generic? It is after all a > throttling mechanism and could be applied to domains OTHER than overload > control. For example, Tele voting applications where an application server > indicates filtering to a switch i.e. "Notify every 100'th INVITE to me" > I don't think that the scope of overload control should be extended into these domains. Overload control specifically helps devices to deal with signaling overload. If a device is still able to return a SIP response it is not in signaling overload and should create a response with the appropriate response code. Volker _______________________________________________ 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] comments regarding draft-hilt-sipping-o… Venkatesh
- Re: [Sipping] comments regarding draft-hilt-sippi… Albrecht.Schwarz
- RE: [Sipping] comments regarding draft-hilt-sippi… Dolly, Martin C, ALABS
- RE: [Sipping] comments regarding draft-hilt-sippi… Liu, Guang Xuan (Mike)
- RE: [Sipping] comments regarding draft-hilt-sippi… Hadriel Kaplan
- RE: [Sipping] comments regarding draft-hilt-sippi… Albrecht.Schwarz
- Re: [Sipping] comments regarding draft-hilt-sippi… Venkatesh
- RE: [Sipping] comments regarding draft-hilt-sippi… Hadriel Kaplan
- [Sipping] Utilization in draft-hilt-sipping-overl… Hadriel Kaplan
- Re: [Sipping] comments regarding draft-hilt-sippi… Venkatesh
- Re: [Sipping] comments regarding draft-hilt-sippi… Volker Hilt
- Re: [Sipping] Utilization in draft-hilt-sipping-o… Volker Hilt
- RE: [Sipping] comments regarding draft-hilt-sippi… Drage, Keith (Keith)
- [Sipping] Queries and comments on draft-hilt-sipp… Darshan Bildikar
- [Sipping] Re: Queries and comments on draft-hilt-… Volker Hilt
- [Sipping] RE: Queries and comments on draft-hilt-… Darshan Bildikar
- Re: [Sipping] RE: Queries and comments on draft-h… Janet P Gunn
- [Sipping] Re: Queries and comments on draft-hilt-… Volker Hilt
- [Sipping] RE: Queries and comments on draft-hilt-… Darshan Bildikar
- [Sipping] Re: Queries and comments on draft-hilt-… Volker Hilt