Re: [sip-overload] Providing load information

["Parthasarathi R (partr)" <[e-mail]>]

Dale,
 
Thanks for your analysis about draft-partha-soc-overload-resource-availability-00 and draft-ietf-mediactrl-mrb-06 and providing your view point. Paul Kyzivat mentioned my work may be related to media ctrl in the beginning itself but looking at draft-ietf-mediactrl-sip-control-framework-11, I thought that they are two complementary requirements. I'm not aware of Media Broker till Spencer mentioned during my presentation in IETF-78.
 
I skimmed through draft-ietf-mediactrl-mrb-06 to find whether my entire resource availability based overload requirement will be meet by the draft. I'm not very sure about it at this moment. I'll carefully go through draft-ietf-mediactrl-mrb-06 draft and get back to you. The rationale of draft-partha-soc-overload-resource-availability-00 using Hardware resource availability is that the number of inputs to overload algorithm in upstream will be comparatively less compare to the service based (like VXML, IVR) overload mechanism. The service will keep growing for the same resource. This point is open for discussion.
 
BTW, your mail sounds like that the currently existing overload mechanism of SoC will not solve overload requirement of Media Server Broker (MSB). Please let me know whether the Vijay "oc" overload mechanism works for MSB and any other solution exists for MSB. 
 
Your cursory examination indicates that dialogs shall be used as the unit for MSB. Please let me know whether the dialogs are required as a unit or the number of messages server MSB purpose. I prefer unit as dialog as it is easily to calculate and compute in Media Servers/B2BUA.
 
The "fully busy" indicator is mentioned as "almost-out-of-the-resource" in draft-partha-soc-overload-resource-availability-00. IMO, the 100% utilization may not be advised as the device should have buffer resource for handling emergency call or RPH headers. 
 
As I mentioned to you informally, Resource demand vector (Stole your terminology as I like it :-)) between upstream and downstream is outside the scope of my draft as the data may be pushed using different configuration pushing mechanism like JavaScript, Cisco Service Advertisement Framework (SAF), and proprietary MIBS etc. I personally prefer to have SIP interface for pushing Resource demand vector as the interop is guaranteed (No need to search for some other stack) in case SIP interface is standardized. 
 
Hadriel and myself had the discussion on the same line as the array of Enterprise(Ent) SBCs interop with array of Service provider(SP) SBCs are involved between Ent and SP SIP trunk and Ent-SBC and SP-SBC are in the two different network administrative domain. The performance of both Ent-SBC and SP-SBC network shall be improved in case little policy information like total call capacity of single SBC is passed across securely in the trusted environment. Hadriel, Please correct me in case I misunderstand you. IMO, Minimum set of resource demand vector shall be formed between two trusted different administrative domains with the proper brainstorming. The minimum resource demand vector is the input to the overload algorithm. The life is easy in case the upstream and downstream are located in the same administrative domain. The proposal is in nascent stage. Please provide your inputs.  
 
The overload algorithm in my mind is simple one which uses
1) draft-partha-soc-overload-resource-availability-00 Resource availability info or draft-ietf-mediactrl-mrb-06 info
2) Resource Demand vector input through some mechanism which I mentioned above.
 
As I mentioned in IETF-78 SoC presentation, We (Muthu, Ram, Jayant and myself) are working for the simple generic SIP based overload algorithm which will be possible to implement by everybody without any further R&D:-). The algorithm may not be best of the quality but it will serve the simple deployable products requirements. The mechanism will provide the opportunity for enhancement overload algorithm as well. Welcome your inputs here as well.
 
Thanks
Partha 
 
PS: I joined in mediactrl alias for understanding the overload from mediactrl perspective
________________________________

From: [e-mail] on behalf of WORLEY, Dale R (Dale)
Sent: Fri 7/30/2010 1:52 PM
To: [e-mail]
Subject: [sip-overload] Providing load information



Looking at draft-partha-soc-overload-resource-availability-00, I notice that its purpose (providing load information from a call-processing device to an upstream device that has the choice of sending calls to it) is quite similar to draft-ietf-mediactrl-mrb-06.  (See section 5.1.4.3 et seq. and section 6.1 of the latter draft.)  (I stole this observation from Paul Kyzivat.)

However there is a difficult general problem when one element attempts to tell another element how much unreserved capacity it possesses:  The receiving element needs to be able to examine an incoming INVITE and determine the quantities of the various resources that will be needed in the destination element.  In general this is a very difficult problem unless the upstream element has detailed knowledge of the downstream element.  (E.g., how does one element determine the percentage of CPU usage that a particular offered call will demand of another element?)  In general, it seems, that an algorithm must be transmitted from one element to the other.

After a cursory examination, I think that draft-ietf-mediactrl-mrb-06 solves the problem by restricting the resource numbers to refer to dialogs, codecs, and media streams, which can be calculated by examining the SDP alone.

Another possibility is for the downstream element to transmit a "fully busy" indicator, which when false, means that it has the capacity to process any possible incoming call.  But this method would only rarely allow an element to reach 100% utilization.

Although it might be possible for the downstream element to transmit to the upstream element an algorithm for mapping an incoming INVITE into a resource demand vector -- e.g., a Javascript function that takes as input a partially parsed version of the INVITE and returns a vector of numbers.

I haven't looked up the discussions of this matter in the MEDIACTRL archives.

Dale
_______________________________________________
sip-overload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sip-overload