Subject: RE: [Sipping] SIP overload control draft

From: "Geoff Devine" <[email-masked]>
Date: Mon, 19 Mar 2007 05:59:50 -0400

Hello Volker,

Extracted from draft-hilt-sipping-overload-01.txt Chapter 6:
*****************************************
The syntax of the Load header field is:

     Load              = "Load" HCOLON loadStatus
     loadStatus        = 0-100 SEMI serverID *( SEMI loadParam )
     loadParam         = throttleRate | validMS | generic-param
     serverID          = "target" EQUAL SIP-URI | SIPS-URI
     throttleRate      = "throttle" EQUAL 0-100
     validMS           = "validity" EQUAL delta-ms
     delta-ms          = 1*DIGIT

   The BNF for SIP-URI, SIPS-URI and generic-param is defined in [2].

   Table 1 is an extension of Tables 2 and 3 in [2].

     Header field       where   proxy ACK BYE CAN INV OPT REG
     ________________________________________________________
     Load                 r       ar   -   o   o   o   o   o
                   Table 1: Load Header Field

   Example:

      Load: 80;throttle=20;validity=500;target=p1.example.com
*****************************************
Nit:
According to the syntax, shouldn't the example be:
Load: 80;target=p1.example.com; ...  ?

I'd really like to be able to signal different resource classes using
this mechanism as a strong hint to a load balancer.  In a hierarchical
topology, the load balancer could aggregate these resource classes and
pass them to other peer proxy servers to avoid inducing work when a
resource is exhausted.  I guess I could use multiple "Load" headers and
a home-brew generic-param to achieve this though I didn't see this
behavior specified in the draft.  

For example, say I'm a media gateway controller with resources CPU,
compression codec ILBC, a trunk group for San Francisco, a trunk group
for San Jose, and a trunk group to an inter-exchange carrier for long
distance calls.  I create a generic-param called "ResourceClass" that is
known to the load balancer.

Load: 80;target=p1.example.com;ResourceClass="CPU"
Load: 10;target=p1.example.com;ResourceClass="ILBC"
Load: 50;target=p1.example.com;ResourceClass="SanFranciscoTrunkGroup"
Load: 60;target=p1.example.com;ResourceClass="SanJoseTrunkGroup"
Load: 40;target=p1.example.com;ResourceClass="IXCTrunkGroup"

Best regards,
Geoff Devine

_______________________________________________
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: Mon, 19 Mar 2007 14:59:39 +0100

Hi Geoff,
> Extracted from draft-hilt-sipping-overload-01.txt Chapter 6:
True. Thanks!

> Load: 40;target=p1.example.com;ResourceClass="IXCTrunkGroup"
This sounds similar to a discussion we had on this list end of 
December/beginning of January. In general, I think overload control 
should only indicate overload of a resource that is needed directly for 
SIP message processing. If these resources are overloaded, a device is 
not able to respond to SIP messages any more. For other resources (such 
as trunks), a device can create the correct response codes.

Thanks,

Volker

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Mar 2007 10:00:44 -0400

I think the level of detail you are proposing for conveyance is well 
outside the scope of the problem we are solving here. This kind of 
information would be useful for something like a softswitch to control a 
gateway. TGREP is a closer match to those requirements.

Here, we are working on SIP message overload between any type of sip entity.

-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

---

From: Volker Hilt <[email-masked]>
Date: Mon, 19 Mar 2007 14:59:39 +0100

Hi Geoff,
True. Thanks!

Thanks,

Volker

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Mar 2007 10:00:44 -0400

-Jonathan R.