[Sipping] Re: Queries and comments on draft-hilt-sipping-overload-00.txt

[Volker Hilt <[e-mail]>]

Darshan Bildikar wrote:
> 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)
> 
Yes, you are right, the draft needs to be more specific there.

> <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. 

The header mechanism does satisfy the above two requirements. The 
overload control specification can (and already does to some extent) 
give guidance on which message types should be processed over others in 
an upstream entity that has received a overload indication.

The header should also not be ambiguous about the element to which a 
load indication applies. This is determined by the address that is put 
into the Load header. I agree with you that better explanations are 
needed in the draft (remember that it still is a -00 draft).

Volker


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP