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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 11 Apr 2005 16:25:06 +0300

Magnus,

I agree and support your proposal. 

I have however a concern related to your third point:

> - Make RTCP XR MIB also as an addition to the common session root.

If by this you mean making the RTCP XR MIB a subtree under the RTP MIB, I believe that this is not necessary, and also contrary to the design recommendations of the Operations and Management Area http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt

   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.

This does not affect the integrality that you are trying to reach for the RTP MIB and RTCP XR MIB, as a OID is just a pointer in the management objects space. As long as the RTP MIB and RTCP XR MIB are different MIB modules defined by two different documents I suggest that we follow the MIB Guidelines recommendations. 

Regards,

Dan

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: 11 April, 2005 3:52 PM
> To: Romascanu, Dan (Dan)
> Cc: Amy Pendleton; Avt@Ietf. Org; [email-masked]
> Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB
> 
> 
> 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]
> 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Apr 2005 15:45:33 +0200

Hi Dan,

Sure, I don't want to go against any recommendations. This was only due 
to my lack of MIB knowledge. The important thing is to get good 
integration and extensibility.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 11 Apr 2005 14:16:51 -0400

Magnus

I can try and implement this approach during the next week, and have a
revised draft(s) done by next Monday

Alan

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

Hi Dan,

Cheers

Magnus

Romascanu, Dan (Dan) wrote:
> If by this you mean making the RTCP XR MIB a subtree under the RTP MIB, I
believe that this is not necessary, and also contrary to the design
recommendations of the Operations and Management Area
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.
txt
> This does not affect the integrality that you are trying to reach for the
RTP MIB and RTCP XR MIB, as a OID is just a pointer in the management
objects space. As long as the RTP MIB and RTCP XR MIB are different MIB
modules defined by two different documents I suggest that we follow the MIB
Guidelines recommendations.

--

Magnus Westerlund

---

From: Mark Baugher <[email-masked]>
Date: Fri, 15 Apr 2005 10:30:57 -0700

Alan, Amy
   I have some comments and questions regarding the rtcpXrSessionIDTable 
of the RTCP XR MIB.

1. The MIB uses the abstraction "call," which is not defined.  It is 
outside of RTP as well as RTCP XR.  This is a signaling abstraction.  
Somehow, signaling information is used to create and initialize objects 
in the MIB but it is not described where the information is obtained 
and the issues related to different signaling protocols.  We need 
consistency in object definition to get interoperable implementations.  
Are you sure that implementers of the different systems that use this 
MIB will have the same notion of what a call is?  This should at least 
be addressed, probably in section 2, since there are sometimes RTP 
means for obtaining information but mostly this will come from diverse 
signaling protocols that may have different and even ambiguous 
definitions for some signaling objects.

2. Section 2 calls this a table of session information.  The table 
description says that each row is created for each endpoint.  So, it is 
not a session table though "session" is in the name.  The DESCRIPTION 
says its a table of call records and should give a reference to where a 
"call record" is defined.  It looks like it could be organized by SSRC, 
which is an optional value for the table's SessionIdentifier object.  
When organized by SSRC, then most of this table is redundant when there 
is more than on SSRC from the source of a "call."  But how does an 
implementer know that there should be a table row per SSRC or not?  Is 
there some definition of "call record" that would ensure that two 
implementations would do this in the same way?

3. The table is indexed by rtcpXrSessionIDIndex.  How is this value 
obtained for an efficient search?  That is, a management application 
might want to search rows in the rtcpXSessionIDTable by the source 
address and port, destination address and port, the session address 
combined with the SSRC, or something that meaningfully identifies the 
call.  SessionIDIndex is an arbitrary number and not descriptive 
information.  Why wouldn't a management application be forced to scan 
the entire table to find the rows corresponding to session or SSRC 
values?  How do you avoid doing this?

4. rtcpXrSessionIDSessionIdentifier can be either a "billing record 
correlation identifier" or an SSRC.  Where is "billing record" defined? 
  Are billing record identifiers unique?  Is this identifier likely to 
be in 1:1 correspondence with the SSRC or not?   If it is not, what 
keeps one implementation from choosing to create one row per SSRC and 
another one to do it differently?

5. rtcpXrSessionIDCallStartTime is not defined.  Is this object 
initialized from call signaling or when the first packet was observed?

6. It is not defined how rtcpXrSessionIDCallStopTime is to be 
determined?  Is this from the signaling?

7. Is it fair to say that UDP is the only transport protocol that will 
ever be used for a "call?"

8. rtcpXrSessionIDSrceIdenType and rtcpXrSessionIDDestIdenType does not 
state where the information is obtained, what to do if the information 
is not available from signaling, and how the corresponding Identifiers 
are obtained.

Mark

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 15 Apr 2005 15:29:05 -0400

Mark

Thanks for the comments - we are planning to work on the MIB over the
weekend hence any additional input would be welcome, particularly if you can
provide this today.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mark Baugher
Sent: Friday, April 15, 2005 1:31 PM
To: Alan Clark; Amy Pendleton
Cc: Avt@Ietf. Org
Subject: [AVT] comments on
draft-ietf-avt-rtcp-xr-mib-01.txtrtcpXrSessionIDTable

Alan, Amy

Mark

---

From: Mark Baugher <[email-masked]>
Date: Sat, 16 Apr 2005 08:15:01 -0700

Alan
   Here are my additional comments on your MIB.  Regarding the structure 
of the MIB and the session table, the RTP MIB, separates session 
information from stream (SSRC-based) information into two tables.  In 
general, when there is a 1:N relationship between two objects, those 
objects should not be columns in the same row.  The RTP MIB also has 
reverse-index tables for getting a session table index through a table 
that's indexed by session addresses or SSRC values.  That way, the 
management application does not need to read the entire table only to 
discard the rows that it does not need.  In general, a reverse-index 
table is a better design than scanning the session table looking for a 
row that contains a particular identifier, but there will always be two 
table updates on a write and two table accesses on a read.  In other 
words, if the session table contains more than a few rows, then it's 
more efficient on average to use a reverse-index table.

   Given the above points on session table structure, I'd say 
rtcpXrSessionIDReverseSession and rtcpXrSessionIDAltMeasurePT don't 
belong in a session table but in a table organized around SSRC - unless 
you get rid of the session table altogether in favor of a call table.  
A call can have a single pair of SSRCs, one in each direction, or an 
arbitrary number.  What's allowed is determined by the signalilng.  The 
two row pointers in the session table are treating an M:N relationship 
as a 1:1 relationship for signaling protocols that don't restrict 
session and SSRC to be 1:1.

   There are lots of underspecified objects in this MIB.  As I said 
above, this is the case with the "call" abstraction, which might have a 
different definition if it were a SIP, H.323, or gateway-terminated 
call.  A lot of other objects in the MIB needs MUCH more definition.  I 
list a few, but this list is not exhaustive.

o How is the rtcpXrSessionIDStartTime value determined?  Is it a 
SysUpTime reading from when the first packet was observed?  Or when the 
row was created?  Or when the signaling completed?

o rtcpXrBaseParamVocoderType of p 12 does not describe where the 
information originates.  If the information can come from signaling or 
from RTP, then it needs to be stated which is to be used.

o rtcpXrBaseParamFrameDuration references SDP ptime.  But what if SDP 
is not used in the call signaling?

o For the RTCP XR parameters references seem to be consistently given 
and the source seems clear - they come from RTCP.  I think you should 
try and put a reference on practically every object that contains a 
signaling parameter or a metric.

o rtcpXrBaseParamCallQualityRLQ gives a reference in the definition.  
I'd move ITU g.107 to a SMI REFERENCE.  This seems to apply to 
rtcpXrBaseCallQualityExternalRCQ and other parameters that reference 
ITU documents.

I don't have time right now to list my comments on the history table.  
I'll make an effort to do that in the next revision.  Frankly, I don't 
know why you adopted this particular table structure  and aggregation 
of call information from unspecified signaling protocols.  I'm not sure 
this is going to work.  I do think that the indexing scheme in the RTP 
MIB is what you want for session and SSRC information.  A cleaner 
structure would be to have layered MIBs as was done in H-series but 
with a MIB for each call signaling protocol that you wish to monitor.  
The call signaling MIB would then point to a row in an RTP MIB session 
table, which in turn has multiple SSRCs rows in another table pointing 
to it.

Mark