Re: [MEDIACTRL] [sip-overload] [dispatch] SIP Resource availabilityEvent package

["Sheshadri Shalya (svshesha)" <[e-mail]>]

Rahul,
Thanks for your comments/suggestions. See responses inline:

Thanks,
Shesh

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of RahulSrivastava
71616
Sent: Wednesday, September 01, 2010 6:32 PM
To: Parthasarathi R (partr)
Cc: [e-mail]; [e-mail]
Subject: Re: [sip-overload] [dispatch] SIP Resource availabilityEvent
package


I have some queries/suggestions on this draft:

1. Can we have a figure for network topology where this device is being
targetted and which 
   entity performs which function? This will make document very clear.
<svshesha>
In Section 6, we have indicated the use cases. We can add topology
diagram to make those use cases clear. The topologies could be 

  1. SIP server -------- Resource monitor 
  2. SIP server -----Proxy ------Resource monitor
   
</svshesha>

2.  value="cpu|memory|ds0|dsp|storage|([a-z][a-z0-9])*"/>
    This CPU is total system CPU or process CPU? 
    If its per process CPU and SIPServer is multi process (with single
entry point) does it add the values 
    or how much it should be indicated. 
<svshesha>
This CPU is total system CPU. Based on the system architecture,
additional sub-types could be added as required.
</svshesha>

    
3.  does this draft mandates resource monitor works on different CPUs? 
    If not some then does it need to substract its own CPU while
applying overload alogorithm.

<svshesha>
This draft does not mandate the resource monitor on different CPUs. This
again depends on the system architecture. 
</svshesha>

4.  "ICMP message received during dialog creation from the Notifying
      entity" ----> Is it ICMP error?

<svshesha>
It is for ICMP error. We will update the text to be more specific.
</svshesha>
    
     Hence is this mandatory for SIP Servers to know ping status of
SIPServers?

<svshesha>
I am not clear on the question here. In case if you are asking to know
whether SIP server is alive or not, then, it is covered as part of
SUB/NOT mechanism mentioned in the draft.
</svshesha>

5.  If SIPServer has more than one incoming pxys and each of the pxys
subscribe for this events. This SUBSCRIPTION
    becomes heavy. Do we need to see those areas or this is ok?
<svshesha>
The intention here is to have single to few resource monitoring entity
with multiple devices reporting to these resource monitors. In case, the
resource monitoring entity is monitoring multiple devices, even in that
case, as there is only one SUBSCRIPTION per device, it is not going to
be heavy.
</svshesha>

Regards,
Rahul
************************************************************************
******************
 This email and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained here in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this email in error, please
notify the sender by phone or email immediately and delete it!
 
************************************************************************
*****************

----- Original Message -----
From: "Parthasarathi R (partr)" <[e-mail]>
Date: Wednesday, September 1, 2010 9:06 am
Subject: Re: [sip-overload] [dispatch] SIP Resource availability Event
package
To: Michael Miller <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail],
[e-mail]

> Michael,
> 
> Thanks for the comment. In the draft, Almost-out-of-resource 
> element for the particular resource has to be used whenever the 
> resource is reaching the critical condition (threshold) and it is 
> explained in sec 5.4.1. Almost-out-of-resource indication provides 
> the alert to the administrator about overuse of the specific 
> resource in a particular device. I'll add the text in the resource 
> availability indication mechanism for providing more clarity.
> 
> Thanks
> Partha
> 
> ________________________________
> 
> From: Michael Miller [mailto:[e-mail]]
> Sent: Wed 9/1/2010 3:05 AM
> To: Parthasarathi R (partr)
> Cc: <[e-mail]>; [e-mail]; [e-mail]; 
> [e-mail]: Re: [dispatch] SIP Resource 
> availability Event package
> 
> 
> This draft looks pretty good. Should there be language that saids 
> management servers are alerted of critical conditions or is that 
> outside of this draft?
> 
> Michael L. Miller
> Sent from my Mobile Device
> 
> On Aug 30, 2010, at 12:51 PM, "Parthasarathi R (partr)" 
> <[e-mail]> wrote:
> 
> 
> 
> 	
> 	Resource availability information from SIP devices improves the 
> manageability of SIP devices by providing a framework for multiple 
> applications like Resource utilization monitoring, overload 
> handling in SIP based media servers. 
> 
> 	This draft was discussed in IETF-78 SoC WG and considered as 
> outside the scope of SOC as it focus on SIP overload based on non-
> critical resources like DS0, DSP. By looking at the mediactrl WG 
> charter and working documents, I doubt that this draft will falls 
> under current media-ctrl work. As this draft helps in SIP based 
> devices manageability, I looked for SIP manageability related WG 
> but Sip-ops mailing alias only exists and there is no WG 
> associated with it. So, I'm putting this document in dispatch WG 
> for further proceedings. 
> 
> 	Abstract is as follows:
> 
> 	"Collecting Resource availability information in Session 
> Initiation Protocol (SIP) devices in real time helps in better 
> manageability of resources in the SIP network. Resource 
> availability monitoring in SIP devices helps administrator to take 
> informed decision and corrective measures to tackle under or over 
> resource utilization in the network. Resource availability 
> information can also be used for SIP overload control in SIP based 
> Media servers by passing resource demand vector between devices. 
> This document defines resource availability XML document and the 
> mechanisms that can be used to exchange the document between SIP 
> entities."
> 	
> 
> 	The draft is available at http://datatracker.ietf.org/doc/draft-
> partha-dispatch-resource-availability/ 
> <http://datatracker.ietf.org/doc/draft-partha-dispatch-resource-
> availability/> . Could you please provide your valuable comments.
> 
> 	Thanks
> 
> 	Partha
> 
> 	
> 	
> 
> ________________________________
> 
> 	From: IETF I-D Submission Tool [mailto:[e-mail]]
> 	Sent: Mon 8/30/2010 7:50 PM
> 	To: Parthasarathi R (partr)
> 	Cc: Sheshadri Shalya (svshesha)
> 	Subject: New Version Notification for draft-partha-dispatch-
> resource-availability-00 
> 	
> 	
> 
> 	
> 
> 
> 	A new version of I-D,
draft-partha-dispatch-resource-availability-
> 00.txt has been successfully submitted by Parthasarathi R and 
> posted to the IETF repository.
> 	
> 	Filename:        draft-partha-dispatch-resource-availability
> 	Revision:        00
> 	Title:           Session Initiation Protocol (SIP) Resource 
> availability Event package
> 	Creation_date:   2010-08-30
> 	WG ID:           Independent Submission
> 	Number_of_pages: 17
> 	
> 	Abstract:
> 	Collecting Resource availability information in Session
Initiation
> 	Protocol (SIP) devices in real time helps in better managebility
of
> 	resources in the SIP network.  Resource availability monitoring
in
> 	SIP devices helps administrator to take informed decision and
> 	corrective measures to tackle under or over resource utilization
in
> 	the network.  Resource availability information can also be used
for
> 	SIP overload control in SIP based Media servers by passing
resource
> 	demand vector between devices.  This document defines resource
> 	availability XML document and the mechanisms that can be used to
> 	exchange the document between SIP entities.
>                                                                   
>                      
> 	
> 	
> 	The IETF Secretariat.
> 	
> 	
> 	
> 
> 	_______________________________________________
> 	dispatch mailing list
> 	[e-mail]
> 	https://www.ietf.org/mailman/listinfo/dispatch
> 	
> 
> 
_______________________________________________
sip-overload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sip-overload