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

From: David R Oran <[email-masked]>
Date: Mon, 4 Apr 2005 12:02:37 -0400

Well, chalk me up on Mark's side of this one. It seems that the XR MIB 
is in fact a logical extension of the RTP MIB precisely *because* it 
shares things like SSRC, session addresses, and other parameters.

If implementing the RTP MIB is a in fact a burden for somebody 
implementing the XR MIB, I'd like to see justification for that 
position, since I find it hard to swallow that there are 
(non-duplicative) things in the RTP MIB that aren't of interest to the 
consumer of the XR MIB. The converse is of course not true.

If there are in fact such things in the RTP MIB, perhaps the right 
response is to make them optional there, rather than construct 
something with duplication of data, bringing with it all the 
opportunities for inconsistency, non-fate shared state, etc.

Dave.

On Mar 30, 2005, at 3:58 PM, Alan Clark wrote:

>
> Mark
>
> You pointed out yesterday that the two documents have the same section 
> 2.1,
> which basically says that they both relate to RTP sessions, senders and
> receivers.
>
> There may be a small number of common elements in the tables, for 
> example
> source/dest IP address, UDP port and SSRC, however the commonality 
> doesn't
> extend much beyond that.  The XR MIB has been designed for a specific
> application and a number of implementors have been providing useful
> feedback.  We don't want implementors to HAVE to implement the RTP MIB 
> in
> order to implement the RTCP XR MIB - if we try and build in any 
> dependencies
> then this would be the consequence (which I'm sure you aren't 
> advocating).
>
> I suggest that section 2 of the XR MIB be updated to clarify the
> relationship between the two MIBs and if we identify any common 
> objects then
> the XR MIB can point out the relationship.
>
> Regards
>
> Alan
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark Baugher
> Sent: Wednesday, March 30, 2005 10:51 AM
> To: Romascanu, Dan (Dan)
> Cc: Magnus Westerlund; Colin Perkins; Avt@Ietf. Org; Amy Pendleton
> Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB
>
>
> Dan
>    I pointed out what I thought were redundancies to Alan yesterday on
> this list.
>
> Mark
> On Mar 30, 2005, at 1:07 AM, Romascanu, Dan ((Dan)) wrote:
>
>> Mark,
>>
>> Installing multiple MIB modules is not a problem, but redundancies
>> should be avoided. If you are already aware about some, you may want
>> to point it specifically to the authors.
>>
>> Alan seems to be saying that the RTP MIB and RTCP-XR MIB are
>> completely separate entities and that applications may install and use
>> them independently one of the other. Even if we agree that this is the
>> case, there will be deployment scenarios where both will be used, and
>> we need to avoid redundant objects and ease the usage of the
>> applications that would use both. This is what the 'relationship'
>> section should clarify.
>>
>> Regards,
>>
>> Dan
>>
>>
>>
>>> -----Original Message-----
>>> From: Mark Baugher [mailto:[email-masked]]
>>> Sent: 30 March, 2005 1:26 AM
>>> To: Romascanu, Dan (Dan)
>>> Cc: Magnus Westerlund; Alan Clark; Colin Perkins; Amy
>>> Pendleton; Avt@Ietf. Org
>>> Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB
>>>
>>>
>>> Dan
>>> On Mar 29, 2005, at 7:23 AM, Romascanu, Dan ((Dan)) wrote:
>>>
>>>> Actually this is not necessarily a bad thing. The MIB module should
>>>> reflect what is manageable by SNMP, and this may be a subset of the
>>>> whole protocol functionality. The scope is to create SNMP
>>> agents that
>>>> can be implemented in host, network devices or applications and be
>>>> used by management applications for interoperable
>>> management. Small is
>>>> good in many cases.
>>>>
>>>> The question on the table is whether the RTCP-XR MIB and
>>> the RTP MIB
>>>> have any dependencies.
>>>
>>> My concern is with redundancies and the need to install multiple
>>> flavors of RTP MIBs to get a complete protocol-management solution.
>>>
>>> Mark
>>>
>>
>> _______________________________________________
>> 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
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

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

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 4 Apr 2005 12:18:49 -0400

Dave

1. It complicates the situation - for example - I know of one networking
company that is implementing only the RTCP XR MIB history table and not the
individual call/session tables.  Hence there would be some circumstances in
which you would need to implement the RTP MIB and some where you wouldn't?

2. The fact that both share the SSRC and "some" parameters is not a
sufficient reason to implement ALL of the RTP MIB .. for example IP
addresses and UDP ports are implemented independently by many MIBS?  Is the
right answer to update the RTP MIB to expose some of the parameters (e.g. as
TCs) ?

3. The RTCP XR MIB is, in the same sense as the VoIP Metrics block within
RFC3611, targetted at VoIP management and not at more general RTP session
monitoring.  Maybe we need to think of it as the VoIP Metrics MIB?

Regards

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
David R Oran
Sent: Monday, April 04, 2005 12:03 PM
To: Alan Clark
Cc: Magnus Westerlund; Mark Baugher; Amy Pendleton; Romascanu,Dan (Dan);
Colin Perkins; Avt@Ietf. Org
Subject: Re: [AVT] Follow up to AVT meeting - RTCP XR MIB vs RTP MIB

Dave.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: David R Oran <[email-masked]>
Date: Mon, 4 Apr 2005 12:28:45 -0400

> which you would need to implement the RTP MIB and some where you 
One can (in principle) do the same thing with the RTP MIB - implement 
just the history. If that flexibility is documented in some 
requirements document, then we should go back and apply that 
independence requirement to the RTP MIB as well. I agree it may 
complicate the tactical situation to get these things in sync, but it 
definitely simplifies the architecture and will make the medium-to-long 
term situation a whole lot less complicated by not introducing an extra 
degree of freedom in implementation slice-and-dice.

> sufficient reason to implement ALL of the RTP MIB ..
as I said, if there's good reason to make parts of the RTP MIB option, 
then lets do it.

> for example IP
> addresses and UDP ports are implemented independently by many MIBS?
For the same application session? I suspect that's a bug if they are 
trying to represent the same state at the same level of abstraction.

>  Is the
"TCs"? Technical corrections? If that's what you abbreviation means, 
then yes, that seems a good way forward.

> monitoring.  Maybe we need to think of it as the VoIP Metrics MIB?
That's fine by me as well, as long as it doesn't duplicate stuff in the 
RTP MIB ad is fate-shared with the equivalent session information in 
the RTP MIB. I have no problem calling it this, but I don't think it 
changes the underlying dependency on the RTP MIB.

Cheers, Dave.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Tue, 12 Apr 2005 09:32:11 -0700

Alan,
   I spent some time this weekend reading the RTP XR MIB have have some 
comments.  One, I mention below.  Others, I'll post to the list as a 
MIB review contribution.  This note concerns the relationship of the 
RTP MIB and the RTCP XR MIB.

On Apr 4, 2005, at 9:18 AM, Alan Clark wrote:
...
> monitoring.  Maybe we need to think of it as the VoIP Metrics MIB?

After reading it, I agree because there is so much non-RTP/RTCP 
information in the MIB.  The RTCP XR MIB is really not an RTP/RTCP MIB 
because it has objects that come from SDP information and maybe from 
other signaling sources.  For example, RTP and RTCP have no reliable 
way of recording when a call (an RTP session) stops.  The 
rtcpXrSessionIDCallStopTime definition of p. 8 does not say how the end 
of the call is determined, but it likely does not come from an RTCP 
BYE, which is unreliable.  Another example: 
rtcpXrSessionIDSrceIdentifier, p 9, is non-RTP information, an E.164, 
Distinguished Name, or URL.  None of this information comes from RTCP 
XR.  The description for rtcpXrBaseParamFrameDuration on pg. 14 
references the SDP ptime attribute.  This list is not exhaustive.

I'd urge you to rename this MIB and re-write section 2 to clarify that 
the components of the MIB are not restricted to RTP/RTCP session 
information and counters, but it uses information from the signaling.  
This is not what I would expect in a protocol MIB but it seems like a 
reasonable approach to managing an application that includes multiple 
protocol layers.  If we wanted to manage voip metrics/quality/history 
information using an RTP/RTCP protocol MIB, then there would need to be 
at least one more MIB that captured the signaling information such as a 
SIP MIB.  This is how I understand it was done by H.323, which has MIBs 
for all of its protocols and references the RTP MIB for the RTP 
protocol.  It's clear that this is not the design approach for your 
MIB.  To change it would be a lot more work than updating address 
objects or using new MIB compiler.

Mark