Subject: Re: AW: [Sipping] Comments on draft-hilt-sipping-overload-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 17:38:19 -0500

inline.

Volker Hilt wrote:

> Christian, Gonzalo,
> 
>>
>> yes, the draft should talk about overload state that needs to be 
>> propagated upstream in cases like the one you describe.
>>
> Yes, this case probably needs more attention in the draft.
> 
>>> what about an IMS/FMC like architecture where
>>> application servers (Ax) and e.g. MGCF functionality (C) are hidden 
>>> behind the IMS cloud (B).
>>>
>>> A1---\
>>> A2----B--- C
>>> A3---/  IF C enters overload it will only inform B to reduce the load 
>>> send to C by x% (although the traffic from Ax is the reason for this).
> 
> 
> Yes. It is up to B to decide what to do. If B knows that it is in a 
> controlled environment and C is its *only* downstream neighbor, B can 
> use hop-by-hop overload control to indicate overload to its upstream 
> neighbors if C is overloaded. Essentially B can consider C as a message 
> processing resource in this scenario. If this resource is overloaded B 
> signals overload to its upstream neighbor.

No; I don't think it signals overload upstream. This violates the 
definition of what overload means. Rather, I think it rejects the 
request, and we need a way to say that a request was rejected because 
all downstream servers were congested. We need to specify behavior on 
receipt of such a response. The usual questions about retrying come up...

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP