Subject: RE: [Sipping] new draft on overload control in SIP

From: "Fernando BERRETTA" <[email-masked]>
Date: Mon, 27 Feb 2006 10:59:18 -0300

Is there no way to implement the solution similar to H323 RAS Resource
Availability Indication (RAI). Where The gateway reports its resource
status to the gatekeeper with the use of RAS Resource Availability
Indication (RAI). When a monitored resource falls below a configurable
threshold, the gateway sends an RAI to the gatekeeper that indicates
that the gateway is almost out of resources. When the available
resources then cross above another configurable threshold, the gateway
sends an RAI that indicates that the resource depletion condition no
longer exists ?

Fernando

-----Original Message-----
From: Darshan Bildikar [mailto:[email-masked]] 
Sent: Monday, February 27, 2006 5:43 AM
To: 'IETF Sipping List'
Subject: RE: [Sipping] new draft on overload control in SIP

One question...

Are we trying to solve this problem through protocol (new headers / new
method?)...

If yes, why? 

Say proxy A knows that server S1 cannot handle more than 20 Invite
transactions per second then why should it attempt new calls to that
server.
What I'm trying to say is that this problem can be solved through a
configuration mechanism i.e. a proxy already knows the rate at which
servers
can handle calls and makes sure that calls are not forwarded at more
than a
pre defined rate (also can be configured to say, drop one out of every 5
calls at 70% load). 

This kind of mechanism would be useful between proxy - proxy, proxy -
server, server - server interfaces, right? 

The basic point I am trying to make is that the problem is solvable
through
static configuration instead of SIP entities exchanging overload
information
in real time. 

Am I missing something basic here?

Darshan

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 25, 2006 12:30 PM
To: IETF Sipping List
Subject: [Sipping] new draft on overload control in SIP

Folks,

I've just submitted an I-D on the topic of overload control in SIP. 
Until it appears in the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-overload-reqs-00.t
xt

The draft talks about the general problem of overload, and points out
some serious problems with the current 503 mechanism. In particular, the
current mechanism can amplify network load substantially during periods
of overload. The draft calls out requirements for a solution.

I believe this is an important topic. Comments are welcome.

Thanks,
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Feb 2006 09:09:16 -0500

Something like this would need to be part of the solution, yes. I don't 
think the RAI model is quite right, because its meant to address 
resources like PSTN ports, where the capacity is fixed and known. In 
that regard, tgrep (draft-ietf-iptel-tgrep) is SIP's version of RAI, but 
tgrep doesn't provide congestion control.

In any case, right now, we're discussing requirements. Mecahnism comes 
later...

-Jonathan R.