Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 10 Apr 2005 17:25:00 +0300

Amy,
 
I cannot agree with your choice for several reasons:
 
1. RTP is the principal protocol developped by this WG, while RTCP XR is an extension. For this reason it is mandatory that the RTCP XR MIB document refers to the relation to the RTP MIB. Now this reference could say in theory 'There is no relation between the RTCP XR MIB and the RTP MIB', but ...
2. Several people expressed the opinion and argued that the two MIB modules are related in their tables structure, and have a sub-set of redundant objects. Alan Clark acknowledged this relation in his mail, and referred to the common subset:
> Based on a comparison of the RTP MIB with the RTCP XR MIB it appears 
> that the RTP MIB does require a significant update in the areas 
> that are common 
> to both, hence the issue of RTP MIB vs RTCP XR MIB is not 
> just one of making 
> the XR MIB point back to the RTP MIB. 
> 
3. Beyond the structure relation there is another relation derived from the fact that the RTP MIB and the RTCP XR MIB may be deployed in the same network. Having a pre RFC 3550 RTP MIB, while the RTCP XR MIB is post RFC 3550 is inconsistent. This aspect was discussed and agreed by the WG as soon as the first RTCP XR submission was presented to the WG. 
4. Last but not least this WG has chartered the RTP MIB revision and the RTCP XR MIB to be completed together. Instead of wasting our energy with this long discussion I would advice that we work on the RTP MIB update and finish it in time, so that the RTCP XR MIB is not further delayed.  

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Amy Pendleton
Sent: 08 April, 2005 9:39 PM
To: Avt@Ietf. Org
Cc: Magnus Westerlund; [email-masked]; Romascanu, Dan (Dan)
Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

I want to voice my opinion on the issue of relationship between these MIB's and the requested reference to the RTP MIB from the new RTCP XR MIB.

The RTCP XR MIB is designed to fulfill real vendor and customer requirements for an open standard mechanism that enables RTCP XR metric reporting to their network management systems so the metrics can be used to diagnose service quality and network problems.  As it stands today, a number of vendor's products are supporting proprietary versions of this MIB ahead of the open standard.  While offering implementations ahead of standards is fairly typical, and necessary due to standards bodies politics, it is not something customers and network management vendors like to do long term.  

I agree that the RTP MIB has problems and needs to be cleaned up, but I do not wish to continue delaying a very important draft just to prevent a small amount of overlap in field content. I fail to see the value in providing references between the two MIBs.

My choice would be to leave things as they are: separate MIBS. 

Thanks, 
Amy Pendleton 

-----Original Message----- 
From: Romascanu, Dan (Dan) [ mailto:[email-masked]] 
Sent: Thursday, April 07, 2005 11:02 AM 
To: Alan Clark; Avt@Ietf. Org 
Cc: Magnus Westerlund; Colin Perkins; [email-masked] 
Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB 

I have no strong opinion for now, but is there not a 4th option? Update the RTP MIB with the necessary changes as described in Alan's mail and some more that may be required? This would imply recycling to Proposed, but we will have a document at the required level of quality, and in full synch with the RTCP XR MIB 

Regards, 

Dan 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]]On Behalf Of 
> Alan Clark 
> Sent: 06 April, 2005 11:01 PM 
> To: Avt@Ietf. Org 
> Cc: Magnus Westerlund; Colin Perkins; Amy Pendleton 
> Subject: RE: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB 
> 
> 
> 
> Based on a comparison of the RTP MIB with the RTCP XR MIB it appears 
> that the RTP MIB does require a significant update in the areas 
> that are common 
> to both, hence the issue of RTP MIB vs RTCP XR MIB is not 
> just one of making 
> the XR MIB point back to the RTP MIB. 
> 
> RTP MIB session table changes needed are at least:- 
> 
> - the table index needs to be changed to Unsigned32 
> - the IP addresses and Ports need to be changed from the 
> TDomain/TAddress form to the Inet form used by the XR MIB 
> - it makes sense (IMHO) to change the call state object in 
> the RTP MIB to 
> the form used in the latest version of the XR MIB that allows 
> this to be 
> used as a table index - this breaks the table into a 
> non-overlapping set of 
> active sessions and completed sessions 
> - the joins/ leaves/ Byes objects should be moved out of the 
> RTP MIB session 
> table to a table specific to multicast 
> - the RTP MIB does have a start time but not an end time 
> 
> Basically if these changes are made then the basic session table of 
> the RTP MIB has been completely changed to be identical to the basic 
> session table 
> of the RTCP XR MIB. 
> 
> This suggests three potential courses of action:- 
> 
> (1) Leave things as they are 
> 
> (2) Update the RTCP XR MIB with an inverse session table and then use 
> this to obsolete the RTP MIB 
> 
> (3) Leave the RTP MIB as-is, but provide a row pointer in the XR MIB 
> to point to the corresponding row of the RTP MIB 
> 
> Does anyone have an opinion on the relative merits of these three 
> options - and any specific recommendations related to the 
> implementation thereof? 
> 
> Regards 
> 
> Alan Clark 
> 
> 
> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]]On Behalf Of 
> Alan Clark 
> Sent: Wednesday, April 06, 2005 9:32 AM 
> To: David R Oran; Mark Baugher 
> Cc: Avt@Ietf. Org 
> Subject: FW: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB 
> 
> 
> 
> Dave, Mark 
> 
> I am starting to analyze the differences between the RTP MIB and RTCP 
> XR MIB.  As a first step I ran the RTP MIB through a couple of MIB 
> validation tools - reports below. 
> 
> The RTP MIB uses the TDomain/ TAddress concept, which was superceded 
> by TransportAddress/ TransportDomain.  In the RTCP XR MIB we used the 
> InetAddress approach (RFC2851) which I understand is the 
> preferred approach 
> for representing layer addressing.  The TAddress approach 
> provides an Octet 
> String that has to be interpreted according to the TDomain 
> type .. the Inet 
> approach simply presents IP Address and Port as two separate 
> objects.  Can 
> you explain why the TDomain approach has merit over the Inet 
> approach - or 
> should we re-write the RTP MIB to use Inet? 
> 
> Regards 
> 
> Alan 
> 
> > 
> > 
> -------------------------------------------------------------- 
> ------------ 
> -- 
> > ---------------- 
> > 
> > Validation report - SMILINT 
> > File: RTPMIB.mib 
> > 
> > Line  Severity  Problem 
> > 109 5 index of row `rtpSessionInverseEntry' can exceed OID 
> size limit by 
> 525 
> > subidentifier(s) 
> > 202 6 index element `rtpSessionDomain' of row 
> `rtpSessionInverseEntry' 
> > should but cannot have a size restriction 
> > 6 index element `rtpSessionDomain' of row 
> `rtpSenderInverseEntry' should 
> but 
> > cannot have a size restriction 
> > 6 index element `rtpSessionDomain' of row 
> `rtpRcvrInverseEntry' should but 
> > cannot have a size restriction 
> > 357 5 index of row `rtpSenderInverseEntry' can exceed OID 
> size limit by 
> 270 
> > subidentifier(s) 
> > 448 5 `TAddress' object should have an accompanied `TDomain' object 
> > 507 6 use Integer32 instead of INTEGER in SMIv2 544 5 index of row 
> > `rtpRcvrInverseEntry' can exceed OID 
> size limit by 271 
> > subidentifier(s) 
> > 655 5 `TAddress' object should have an accompanied `TDomain' object 
> > 731 6 use Integer32 instead of INTEGER in SMIv2 
> > 
> > ----------------------------------------------------- 
> > Validation report - MIB Smithy 
> > 
> > RTPMIB.mib [RTP-MIB:rtpRcvrInverseEntry] : warning : INDEX object 
> > 'rtpSessionDomain' is of type 'OBJECT IDENTIFIER' and may exceed 128 
> > subidentifier maximum. No refinements possible. 
> > 
> > RTPMIB.mib [RTP-MIB:rtpRcvrInverseEntry] : warning : INDEX object 
> > 'rtpRcvrAddr' value may exceed maximum of 128 
> subidentifiers for OBJECT 
> > IDENTIFIER length by 128 subidentifier(s). 
> > 
> > RTPMIB.mib [RTP-MIB:rtpRcvrInverseEntry] : warning : All 
> INDEX objects in 
> > this table are auxiliary (i.e., from other tables). 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSenderInverseEntry] : warning : INDEX object 
> > 'rtpSessionDomain' is of type 'OBJECT IDENTIFIER' and may exceed 128 
> > subidentifier maximum. No refinements possible. 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSenderInverseEntry] : warning : INDEX object 
> > 'rtpSenderAddr' value may exceed maximum of 128 
> subidentifiers for OBJECT 
> > IDENTIFIER length by 128 subidentifier(s). 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSenderInverseEntry] : warning : All 
> INDEX objects 
> in 
> > this table are auxiliary (i.e., from other tables). 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : INDEX object 
> > 'rtpSessionDomain' is of type 'OBJECT IDENTIFIER' and may exceed 128 
> > subidentifier maximum. No refinements possible. 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : INDEX object 
> > 'rtpSessionRemAddr' value may exceed maximum of 128 
> subidentifiers for 
> > OBJECT IDENTIFIER length by 128 subidentifier(s). 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : INDEX object 
> > 'rtpSessionLocAddr' value may exceed maximum of 128 
> subidentifiers for 
> > OBJECT IDENTIFIER length by 128 subidentifier(s). 
> > 
> > RTPMIB.mib [RTP-MIB:rtpSessionInverseEntry] : warning : All 
> INDEX objects 
> in 
> > this table are auxiliary (i.e., from other tables). 
> > 
> > 0 error(s), 10 warning(s) 
> > 
> 
> 
> 
> _______________________________________________ 
> Audio/Video Transport Working Group 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/avt 
> 
> 
> _______________________________________________ 
> Audio/Video Transport Working Group 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/avt 
> 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Apr 2005 14:51:43 +0200

Hi,

Having watched this discussion it seems from my perspective that the 
right thing for the WG to do is the following:

- Updated the RTP MIB for a more modular design with a common session 
identification table as the root. From this common root different 
modules for reporting on the session can be added.
- Update the reporting parts of the RTP MIB to be added to the common 
root. Split it into reasonable modules based on functionality.
- Make RTCP XR MIB also as an addition to the common session root.

The reason for this proposal is to make the RTP and RTCP XR MIBs a truly 
integrated solution while still avoiding any strict requirement to 
implement reporting modules that is not desired in specific 
applications. It is quite obvious that there is a central common part 
for all reporting that is the session id in form of addresses and ports 
combined with when the session happened.

I do understand the desire to take the road with least work now for RTCP 
XR MIB, however I think that will significantly hurt the future for 
management for RTP, both as i currently are and when additional things 
are added.

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]