Subject: Re: [Sipping] Re: comment on draft-hilt-sipping-overload-01

From: Volker Hilt <[email-masked]>
Date: Fri, 01 Jun 2007 15:40:29 -0400

Xavier Marjou wrote:
>> If you are concerned about hiding overload information, it is certainly
>> possible to only send load information to the proxies you trust. These
>> proxies would, by definition, support overload control and would
>> therefore remove this information.
>>
>> It would also be possible to add an indication that a proxy supports
>> overload control (e.g. to the Via header) to avoid that the header is
>> sent to proxies which don't support overload control. In this case, only
>> proxies that do support overload control would get this header.
> 
> Relying on the IP address to guess the identity of an upstream proxy
> is one possibility in some specific situations. However, in other
> situations, the IP address can change over time or be spoofed. With an
> upstream element that behaves as a UA for retrieving overload
> information, the server can check the identity of this UA with a
> standard SIP mechanism.
> 
If a server is concerned about the identity of its neighbors, it can use
transport level authentication e.g. via TLS.

>> The SUB/NOT approach for overload control raises an number of questions:
>> - the subscription process will take some time. Is a proxy allowed to
>> forward traffic to a downstream neighbor before it has set up an
>> overload subscription?
>>   * If no, this has a significant impact on the delay of SIP messages.
>> In particular, since a request may go through a chain of proxies and
>> each of them may need to subscribe to the downstream neighbor.
>>   * If yes, overload control is not effective until the subscription is
>> set up. But if a proxy is overloaded, setting up the subscription may
>> take some time and, in the worst case, may not even be successful.
>> During this time, the proxy will receive unthrottled traffic.
>> - the notify messages that convey load information will add to the
>> overall load, which is undesirable in an overload situation.
>> - each server needs to maintain subscriptions for all its upstream
>> neighbors. It needs to spend resources managing these subscriptions,
>> which can put a significant burden on the server, in particular, if it
>> is dealing with many upstream neighbors.
>> - each proxy would be required to implement a full UAS/UAC for
>> SUBSCRIBE/NOTIFY if the proxy wants to participate in overload control
>> (which each proxy should do!).
>>
>> Overall, I think SUB/NOT is a pretty large-caliber weapon for the
>> problem at hand and a lighter-weight solution would be preferable.
>>
> I agree that some resources are needed to "maintain one subscription
> per upstream proxy" and that "each proxy needs to implement a UA":
> however this is needed in order for the server to be sure of the id of
> each upstream proxy to which overload info is sent.
> 
As mentioned above, I don't think this can only be achieved with SUB/NOT.

> This SUB/NOT mechanism is not necessarily slower. 

I agree.

> If an upstream
> element has not yet subscribed to the overload information, nothing
> prevents this upstream proxy from routing regular SIP requests to the
> server, and nothing prevents the server to use the 503 answer. Once
> the upstream element has decided to subscribe and has succesfully
> received load-information, it can route regular SIP requests taking
> into account the load of the server.
> 
I think that that SUB/NOT will add some complexity and overhead and 
therefore the benefits of this approach should be very clear. It is, 
however, certainly an interesting alternative to consider.

Volker

_______________________________________________
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

---

From: Volker Hilt <[email-masked]>
Date: Fri, 01 Jun 2007 15:45:29 -0400

Asveren, Tolga wrote:
> [TOLGA]Why would that be a significant delay? This would happen only
> once. For TCP/SCTP there is already the delay introduced by connection
> setup (TLS would add up even more on top of that), would an extra SIP
> transaction introduce a huge additional delay?

The overall impact will depend on how often a proxy talks to another 
proxy with which it has not yet established subscription. If this occurs 
frequently, there will likely be an impact on request delay. It also 
will have an impact on throughput since a server has to create 3 
requests (SUB/OK/Req) instead of one. However, I agree that in a stable 
environment, the impact on delay and throughput will probably be small.

> [TOLGA]I believe the answer should be "no", but in any case this second
> argument could also be a drawback for a solution, where overload
> information is embedded in a response. A response would be delayed if
> the proxy is overloaded, and meanwhile other entities would continue to
> pump messages. 

True, a response-based mechanism also has to wait one RTT until a first 
response is received. Other entities that contribute traffic will 
however have received overload information and would therefore slow down.

> Furthermore, an entity would receive information about
> overload status of the proxy only after it sent a request to it; it is
> possible that proxy is overloaded by requests sent by other entities.

I think this is an interesting difference between the two approaches:
- with SUB/NOT a proxy would keep notifying its subscribed upstream 
neighbors about changes in the overload status. This would happen no 
matter if the upstream neighbors have traffic to send or not. Upstream 
neighbors will not transmit after an overload notify has been received.
- with a response-based mechanism, only upstream neighbors that actually 
transmit data are informed about the overload status. They will stop 
transmitting after receiving the first response, which contains the 
overload indication.

> [TOLGA]If hysteresis is provided properly, hopefully there won't be many
> NOTIFYs. I would think, proxies would inform their neighbors about
> getting overloaded, before the load gets extreme. In any case, I agree
> that there could be cases, where a notification needs to be sent, while
> the proxy is overloaded but again, would that add significant extra
> processing to the proxy? Sending notifications probably would be a
> higher priority operation in the proxy compared to processing requests. 

This may be a problem if a server has a number of upstream neighbors and 
reaches its high watermark. At this point it would need to inform all 
its neighbors asap. It may be possible to smoothen these notifies by 
spreading them out and defining slightly different watermarks for each 
upstream neighbor.

> [TOLGA]IMHO, the advantage of relying on notifications is that it is a
> proactive mechanism, whereas utilizing replies is a reactive one. 

The difference here seems mainly for servers that do not transmit. They 
would stay informed by a SUB/NOT mechanism. The flipside is, of course, 
that these neighbors need to be updated.

> OTOH,
> if replies are used in a timely manner, e.g. before extreme overload
> happens, we could end up with something quasi-proactive.
> One more thing in favor of notifications is that they can convey
> information about when the overload level decreases in a proactive way,
> rather than waiting for a request.

I think this may make a difference in case a server is asked to stop 
entirely, i.e., extreme cases of overload. In these cases, it may be 
acceptable to wait until a timer expires. In all other cases, responses 
should provide a feedback channel that allows decreasing the load level 
as needed.

> I am not saying that a notifications based mechanism is definitely the
> preferred choice, but I guess shouldn't be eliminated quickly either. 

I fully agree! SUB/NOT is an interesting alternative and it certainly 
needs more discussion in the draft.

Volker

---

From: [email-masked]
Date: Sun, 3 Jun 2007 14:37:09 -0400

<[email-masked]>
        <[email-masked]> <[email-masked]>
--text follows this line--
As someone said before, there are two different cases -- one is the
proxy with a small number of upstream sources, the other is the
"public" proxy which is fed by many sources on an ad-hoc basis.  It's
not clear to me that the same mechanism is appropriate for both
cases.  I'd love to see some examples of real systems of both types
with overload-protection mechanisms.

Dale

---

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 5 Jun 2007 21:32:56 +0200

> transport level authentication e.g. via TLS.

I don't fully buy it: authentication with TLS could be a possibility
but would require additional work for authentication (cf
draft-gurbani-sip-domain-certs-04)