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

From: Volker Hilt <[email-masked]>
Date: Tue, 02 Jan 2007 23:08:45 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Darshan Bildikar" <[email-masked]>
Date: Wed, 3 Jan 2007 10:05:04 +0530

Hello Volker,

Thank you for the response. 

My responses inline marked by <Darshan>

BR
Darshan

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]] 
Sent: Wednesday, January 03, 2007 9:39 AM
To: Darshan Bildikar
Cc: 'sipping'
Subject: Re: Queries and comments on draft-hilt-sipping-overload-00.txt

Yes, it should.

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

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. 

What did you have in mind for the rich set of overload parameters?
<Darshan> By rich set, I only meant overload PER resource instance on the
SIP downstream entity. 

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

It would also allow me to partition resources on my box beautifully as I
would be able to control requests I receive for a particular resource. (I'm
thinking more from the point of view of an AS running services).

<Darshan> See previous response

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

Volker

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 3 Jan 2007 08:52:52 -0500

I think it is important to focus on overload of the ability to PROCESS SIP
messages.  In particular, the focus should be on the situation where, if
the SIP messages keep coming, the box will crash (usually preceded by
unproductive thrashing).

As such, the mechanism and messaging must be as "lightweight" as possible,
in order to avoid making the machine congestion worse.

The other kinds of resource specific overload mechanisms you discuss sound
very useful.  But I don't think it is a good idea to try to overload them
on THIS effort.

Janet

"Darshan Bildikar" <[email-masked]> wrote on 01/02/2007 11:35:04 PM:

> > "draft-rosenberg-sipping-overload-reqs-01"? Does it take into
cognisance
> the
> > fast running out of ports for video conferencing but might still be
able
> to

---

From: Volker Hilt <[email-masked]>
Date: Wed, 03 Jan 2007 11:17:36 -0500

> load status at discrete points of time instead of waiting for a request
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.

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

> traffic in order to spend resources processing request I KNOW I can handle
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.

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.

> they would find that what they want to do is already ALMOST done in
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.

Thanks,

Volker

---

From: "Darshan Bildikar" <[email-masked]>
Date: Thu, 4 Jan 2007 10:01:55 +0530

My last response on this!

Marked by <Darshan>

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]] 
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> With all due respect, "some requests" and "occasionally" sound
very ambiguous. This should probably be better defined in the draft.
(Recommended timers etc)

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

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

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

<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

---

From: Volker Hilt <[email-masked]>
Date: Fri, 05 Jan 2007 10:13:21 -0500

> very ambiguous. This should probably be better defined in the draft.
Yes, you are right, the draft needs to be more specific there.

> SUB/NOT mechanism is probably what is needed. You can take a call on how you

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