Re: RAQMON Last Call

Alan Clark wrote:
>
> Echoing the point made by Reza - even though the proportion of 
> signaling packets to media packets may be low - wouldn't it be useful 
> from a network manager/ service provider perspective to know that the 
> signaling path was experiencing a high packet loss rate?  There are 
> situations in which the user is experiencing considerable call setup 
> delay and it would be helpful to know if this was due to excessive 
> packet loss on the path to the signaling server, to the loading of the 
> signaling server or some other factor.  By having separate media path 
> and signaling counters you would get more insight into potential 
> problems.
>
> There seems to be no technical/ engineering merit to the concept of 
> combining a count of signaling and media packets - and I'm also still 
> mystified as to why the WG would want to retain this.

The delay parameters are split into application and network delay
because this is applicable to all application protocols.

Separating signaling and media packet loss counters are really only 
applicable
to application protocols (such as VoIP) which have distinct signaling and
media payload paths. 

Again, the RAQMON Basic Report is intended to provide basic metrics
which can generally apply to all application protocols.  Additional metrics
for specific applications need to be added in extension reports.


>
> Regards
>
> Alan Clark
>

Andy

>
>
>
>
> Siddiqui, Anwar A (Anwar) wrote:
>
>> you can achieve this by     
>>     - defining an extension within RAQMON PDU that identifies those
>> parameters.
>>
>>     - You can also switch off the packet loss parameter of the
>> "basic PDU" since you are providing better statistic.
>>
>> Thanks
>> Anwar
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Fardid, Reza
>> Sent: Wednesday, February 15, 2006 5:24 PM
>> To: Andy Bierman
>> Cc: [email protected]
>> Subject: RE: [RMONMIB] RAQMON Last Call
>>
>> Andy,
>>
>> A rough estimate for signaling would be < 1% of all packets for an
>> average duration (3-min) G.711 VoIP call and lower for G.729.
>>
>> Quantification of the error requires making application-specific
>> assumptions.
>> Qualitatively, it will not be possible to differentiate between
>> signaling impairments caused by network packet loss versus other
>> possible factors, such as softswtich failover.
>>
>> Regards,
>> Reza Fardid
>>
>> -----Original Message-----
>> From: Andy Bierman [mailto:[email protected]] Sent: Wednesday, 
>> February 15, 2006 1:13 PM
>> To: Fardid, Reza
>> Cc: [email protected]
>> Subject: Re: [RMONMIB] RAQMON Last Call
>>
>> Fardid, Reza wrote:
>>  
>>
>>>
>>>
>>> From a Service Provider point of view, it is important to a) measure 
>>> and differentiate signaling and media QoS metrics of delay and 
>>> packet loss, and b) report their measurements separately.  This 
>>> differentiation may gain more significance, when one SP does not 
>>> have administrative and measurement control over the end-to-end 
>>> path(s) traversed by signaling and media packets, prompting the IPPM 
>>> WG to undertake work to define Spatial Composition of Metrics. Even 
>>> though the RAQMON MIB differentiates between signaling and 
>>> application delay,
>>>   
>>
>>  
>>
>>> it does not clearly do so for packet loss.
>>>
>>>   
>>
>> What is the percentage of signaling to data packets we are talking about
>>
>> here?
>> Please try to quantify the error that counting packet loss in this
>> manner
>> will introduce.
>>
>> I do not believe there is WG consensus to change the RAQMON Basic Report
>> contents at this time.  There is a mechanism within RAQMON for defining
>> additional reports and additional report elements.  IMO, we should gain
>> implementation experience with the Basic Report we have now, and refine
>> it over time, based on deployment experience and feedback.
>>
>>  
>>
>>>
>>>
>>> Regards,
>>>
>>> Reza Fardid
>>>
>>> Covad Communications
>>>
>>>
>>>
>>>   
>>
>> Andy
>>
>>
>> _______________________________________________
>> RMONMIB mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmonmib
>>
>>
>> _______________________________________________
>> RMONMIB mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmonmib
>>
>>  
>>
>
>
>