Subject: [AVT] Comments on draft-ietf-avt-rtcp-xr-mib-03

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Nov 2005 19:46:17 +0100

Hi,

Here are some comments on draft-ietf-avt-rtcp-xr-mib-03.

1. We need to progress the RTP MIBv2 to ensure that this really is 
alignened with it. Otherwise the text in section 2.3 is useless.

2. Section 2.4, Second paragraph. Reference to RAQMON is not filled in.

3. Section 2.5: "rtcpXrVoiceQualityMetricSTable" Isn't the S in meticS 
wrongly capatilized?

4. The indexing of the MIB. Currently a simple index per packet source 
is used. There doesn't seem to be clear ties between streams part of the 
same RTP session. Have you considered how someone looking into the MIB 
is going to find the other RTP session participants without traversing 
the complete table. The only thing that exist are the 
rtcpXrSessionIDReverseSession. As RTP sessions can contain multiple 
other sources a single reverse pointer is not sufficient.

5. It also seems that the only possible usage of the XR MIB that is 
efficient is to use notifications for entries that exceeds the treshold 
values. There doesn't seem to be a way of find entries based on source 
or destination address or the rtp session identifier.

6. What would one do if the number of entires would exceed 2^32-1? Which 
policy is used to replace entries. I think it is unlikely to happend but 
it needs to be defined I think.

7. The rtcpXrSessionIDMeasurePtID seems some what problematic. For 
example an IP address is not necessarily unique. I don't have a proposal 
for how this could be resolved.

8. the rtcpXrBaseParamCodecType should use a an identifier for the codec 
that is well defined. I would propose to use media types.

9. There are some places where ms is written mS.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Alan Clark <[email-masked]>
Date: Thu, 10 Nov 2005 18:39:17 -0500

Alan Clark wrote:

> Magnus
> I have a raw RTP MIBv2 and am about to review this with Mark Baugher - 
> the concept is simply to replace the original RTP MIB session table 
> with the RTCP XR equivalent.  There are two areas of discussion - one 
> is the general concept and the other alignment of definitions.
>
> Will be added
>> 3. Section 2.5: "rtcpXrVoiceQualityMetricSTable" Isn't the S in 
>> meticS wrongly capatilized?
>>
> Yes
>
>> 4. The indexing of the MIB. Currently a simple index per packet 
>> source is used. There doesn't seem to be clear ties between streams 
>> part of the same RTP session. Have you considered how someone looking 
>> into the MIB is going to find the other RTP session participants 
>> without traversing the complete table. The only thing that exist are 
>> the rtcpXrSessionIDReverseSession. As RTP sessions can contain 
>> multiple other sources a single reverse pointer is not sufficient.
>>
> The rtcpXrSessionIDReverseSession is really intended to deal with the 
> most common two party case.  For multi-party cases you could use the 
> RTP MIBv2 reverse tables
>
>> efficient is to use notifications for entries that exceeds the 
>> treshold values. There doesn't seem to be a way of find entries based 
>> on source or destination address or the rtp session identifier.
>>
> For small devices this is not a particular problem.  For larger 
> systems you could use the RTP MIBv2 reverse tables to do lookups
>
>> 6. What would one do if the number of entires would exceed 2^32-1? 
>> Which policy is used to replace entries. I think it is unlikely to 
>> happend but it needs to be defined I think.
>
>
> Ok - will look at this
>
>> example an IP address is not necessarily unique. I don't have a 
>> proposal for how this could be resolved.
>>
> Within a particular domain you would hope that an IP address is unique 
> - although I suppose that in very large organizations they may use 
> NATS internally.  The application for this is really to identify 
> mid-stream probes as IP endpoints are usually identifiable.
>
>> 8. the rtcpXrBaseParamCodecType should use a an identifier for the 
>> codec that is well defined. I would propose to use media types.
>>
> Ok
>
> Ok
> Regards
> Alan