[Sipping] RE: Queries and comments on draft-hilt-sipping-overload-00.txt
"Darshan Bildikar" <dbildikar@ipunity.com> Thu, 04 January 2007 04:32 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2KGs-00077t-5Y; Wed, 03 Jan 2007 23:32:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2KGq-00077o-4O for sipping@ietf.org; Wed, 03 Jan 2007 23:32:04 -0500
Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2KGp-0000ko-J8 for sipping@ietf.org; Wed, 03 Jan 2007 23:32:04 -0500
Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Jan 2007 20:26:54 -0800
From: Darshan Bildikar <dbildikar@ipunity.com>
To: 'Volker Hilt' <volkerh@bell-labs.com>
Date: Thu, 04 Jan 2007 10:01:55 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AccvU3hG3YXPFfxzTK2ceg9NSmT7ygAYoYJg
In-Reply-To: <459BD720.4050500@bell-labs.com>
Message-ID: <EXCHANGEVMGbQtF8tBY00001d3a@exchangevm.ipunity.com>
X-OriginalArrivalTime: 04 Jan 2007 04:26:54.0841 (UTC) FILETIME=[90840E90:01C72FB8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
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
My last response on this! Marked by <Darshan> -----Original Message----- From: Volker Hilt [mailto:volkerh@bell-labs.com] Sent: Wednesday, January 03, 2007 9:48 PM To: Darshan Bildikar Cc: 'sipping' Subject: Re: Queries and comments on draft-hilt-sipping-overload-00.txt > Darshan Bildikar wrote: >> 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. > > <Darshan 1> Say a downstream entity has indicated that it is loaded at 100%. > This would result in the upstream proxy NOT forwarding it ANY requests. How > does the proxy determine when to send the next request then? It would never > know EXACTLY when the downstream element becomes available. A sub/not > mechanism allows the downstream element to indicate to an upstream element, > load status at discrete points of time instead of waiting for a request > which might never come! > Usually a proxy will not entirely stop sending messages to a downstream neighbor. Instead, overload control should slowly regulate the request rate to a lower level that is acceptable to the downstream proxy. So even in an overload situation, the upstream proxy would still send some requests and therefore receive responses that contain the load status. Even in very extreme overload where a proxy entirely stops to forward requests, it can still occasionally forward a request to probe the current load status. <Darshan> With all due respect, "some requests" and "occasionally" sound very ambiguous. This should probably be better defined in the draft. (Recommended timers etc) > Also, I don't agree that this would cause a messaging overhead. It's just > one more SIP dialog per downstream element. Even with your approach an > upstream element still needs to maintain some kind of "STATE" about the load > of each downstream element. We only avoid the SIP messaging. > I think the messaging overhead is key here. Avoiding SIP messaging is important for a mechanism that deals with messaging overload. SUB/NOT also requires both parties to maintain dialog state but that might not be that significant (it still could pose a problem if memory is the bottleneck on the downstream entity). I agree that even with a header, load state needs to be kept in the upstream proxy (the draft talks about this in detail). <Darshan> I agree that the header approach might seem simpler to implement. However, in my mind a SUB/NOT mechanism seems much more straightforward and explicit. We agree to disagree here. >> 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. > > <Darshan 2> While I do agree with you, I think it's a useful feature to be > able to throttle specific traffic. There is definitely a use case for it. > Why should I waste time on generating 488 responses when I KNOW that I wont > be able to process certain requests beyond a limit. If I am able to indicate > load to an upstream entity for a specific resource, I would be able to run > my system much more efficiently. Ideally I SHOULD be able to throttle my > traffic in order to spend resources processing request I KNOW I can handle > and not reject. > I'm not yet fully convinced that the benefits of rejecting a message one hop earlier for the cases you describe really justify the complexity needed for this. What would be achieved is that a request is forwarded one hop less to a device that could still produce a meaningful response. <Darshan> Sorry if I don't seem to get the big picture. I'm thinking more from the point of view of my box that runs multiple applications and protocol stacks. Also when I have hosted applications I might have well defined SLA's with my customers. For example, I promise customer 1 that run CRBT at 20 CPS (calls per second) and customer 2 to run conferencing at 5 CPS. I need a mechanism that ENSURES that I don't get requests at > 20 CPS for my app. And I don't want to spend computing resources on rejecting requests that I cannot process. But apart from this, I think we should try to keep overload control as simple as possible and make it effective in dealing with signaling overload. <Darshan> Do look at these requirements in "draft-rosenberg-sipping-overload-reqs". They state:- "The specification for the overload mechanism should give guidance on which message types might be desirable to process over others during times of overload, based on SIP-specific considerations. For example, it may be more beneficial to process a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh with a non-zero expiration, since the former reduces the overall amount of load on the element, or to process re-INVITEs over new INVITEs." "The overload mechanism should be unambiguous about whether a load indication applies to a specific IP address, host, or URI, so that an upstream element can determine the load of the entity to which a request is to be sent." These two requirements can clearly not be satisfied with your approach. A SUB/NOT mechanism is probably what is needed. You can take a call on how you want to achieve this. >> 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. > > <Darshan 3> As I said I haven't really thought this through. My only point > being that we should try and "generify" wherever possible. If someone > decides to implement SIP mechanism for tele voting/throttling applications, > they would find that what they want to do is already ALMOST done in > overload. > The tele voting/throttling is interesting since it requires to set up throttles for a specific target at a specific point in time. So it is effectively an overload control that is known a priori. I'm not sure how this relates to the reactive overload control mechanism that we are talking about here. The load feedback would not be needed for a priory throttles. However, the procedures to throttle may be similar. My gut feeling is that it is a separate mechanism that needs to be able to work along with overload control. <Darshan> Fair enough. I appreciate the fact that overload needs to be as simple as possible. I guess we cross this bridge when we come to it! Thanks, 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