Subject: Re: [AVT] WG Review: Recharter of Audio/Video Transport (avt)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Feb 2010 10:49:39 +0100

DISCUSS - I am concerned with the disappearance of the RTCP XR MIB from
the charter. I know that this item was delayed a lot in the previous
charter, probably because of lack of bandwidth and enthusiasm, but not
having a MIB module that allows for RTCP parameters to be queried by a
management application leaves the standard space devoid of a tool that
allows for operators to get from the network the RTCP XR information and
correlate it with the other network and QoS information. The capability
of integrated management of networks carrying voice or video traffic is
seriously impacted by the decision to drop this item from the new
charter. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of IESG Secretary
> Sent: Tuesday, January 26, 2010 9:00 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [AVT] WG Review: Recharter of Audio/Video Transport (avt)
> 
> A modified charter has been submitted for the Audio/Video 
> Transport (avt) working group in the Real-time Applications 
> and Infrastructure Area of the IETF.  The IESG has not made 
> any determination as yet.  The modified charter is provided 
> below for informational purposes only.  Please send your 
> comments to the IESG mailing list ([email-masked]) by Tuesday, 
> February 2, 2010.
> 
> Audio/Video Transport (avt)
> ----------------------------
> Last Modified: 2010-01-21
> Additional information is available at tools.ietf.org/wg/avt
> 
> Chair(s):
>  Roni Even <[email-masked]>
>  Tom Taylor <[email-masked]>
> 
> Real-time Applications and Infrastructure Area Director(s):
>  Robert Sparks <[email-masked]>
>  Cullen Jennings <[email-masked]>
> 
> Real-time Applications and Infrastructure Area Advisor:
>  Robert Sparks <[email-masked]>
> 
> Mailing Lists:
>  General Discussion: [email-masked]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/avt
>  Archive: http://www.ietf.org/mail-archive/web/avt/index.html
> 
> Description of Working Group:
> 
> The Audio/Video Transport Working Group was formed to specify 
> a protocol for real-time transmission of audio and video over 
> unicast and multicast UDP/IP. This is the Real-time Transport 
> Protocol, RTP, along with its associated profiles and payload formats.
> 
> RTP itself has been shepherded to Full Standard. Its 
> associated profiles, extensions, and payload formats are 
> currently at various levels of stardards maturity. This 
> working group's current work centers in four areas:
> 
> 1) Maintenance of the core RTP/RTCP protocols and the AVP, 
> SAVP, AVPF, and SAVPF profiles
> 
> 2) Specification and maintenance of payload formats for use with RTP
> 
> 3) Specification of metric blocks for use with the RTCP 
> Extended Report (XR) framework
> 
> 4) Extensions to the core protocols to facilitate joining, 
> synchronizing, control, and monitoring of RTP multimedia sessions
> 
> In these areas, the group is chartered to focus on the 
> following tasks. Work supporting those areas, but not 
> reflected in these tasks must not be accepted by the working 
> group without an explicit re-chartering. In particular, new 
> items supporting the fourth area are expected to be reviewed 
> in DISPATCH before being considered new charter items for this group.
> 
> 1) Maintenance of the core RTP/SRTP/RTCP protocols and the 
> AVP, SAVP, AVPF, and SAVPF profiles
> - maintain and enhance the SRTP Profile, with review and 
> input from the Security Area
> - specify how to use Explicit Congestion Notification (ECN) 
> with RTP/RTCP
> 
> 2) Specification and maintenance of payload formats for use with RTP
> - provide guidelines for payload format design
> - develop payload formats for new media codecs
> - review and revise existing payload formats to advance those 
> which are useful to Draft Standard or Standard, and to 
> declare others as Historic.
> 
> 3) Specification of metric blocks for use with the RTCP 
> Extended Report (XR) framework
> - provide a mechanism allowing identification data for a set 
> of related metric reports to be carried separately and 
> identified in those reports by reference
> - provide report blocks for delay, delay variation, and discard
> - provide report blocks for burst/gap discard and loss
> - provide report blocks supporting rapid synchronization of 
> multiple RTP streams
> - provide report blocks for jitter buffer metrics
> - provide report blocks for loss concealment metrics
> 
> 4) Extensions to the core protocols to facilitate joining, 
> synchronizing, control, and monitoring of RTP multimedia sessions
> - develop tools to support rapid acquisition of multimedia 
> streams -specify necessary extensions to support rapid 
> synchronization of multiple RTP streams
> 
> 
> Milestones:
> 
> Maintenance of the core RTP/RTCP protocols and the AVP, SAVP, 
> AVPF, and SAVPF profiles Jan-10 Submit draft explaining why 
> SRTP need not be mandatory for media transport, for 
> Informational Jan-10 Policy for Registering SRTP Transforms 
> for Proposed Standard Feb-10 Submit Port Mapping Between 
> Unicast and Multicast RTP Sessions for Proposed Standard 
> Mar-10 Submit Guidelines for Extending the RTP Control Protocol
> (RTCP) for Informational
> Mar-10 Submit Monitoring Architecture for RTP for 
> Informational Apr-10 Submit in band keying mechanism for SRTP 
> draft for Proposed Standard May-10 Submit Real-Time Transport 
> Control Protocol (RTCP) in Overlay Multicast for Proposed 
> Standard May-10 Submit Explicit Congestion Notification (ECN) 
> for RTP over UDP for Proposed Standard Nov-10 Encryption of 
> Header Extensions in the Secure Real-Time Transport Protocol 
> (SRTP) for Proposed Standard
> 
> Specification and maintenance of payload formats for use with 
> RTP Jan-10 Submit RTP Payload Format for H.264 RCDO Video for 
> Proposed Standard Jan-10 RTP Payload Format for GSM-HR for 
> Proposed Standard Jan-10 RTP Payload Format for DRA Audio for 
> Informational Feb-10 Submit RTP Payload Format for SVC Video 
> for Proposed Standard Feb-10 Submit How to Write an RTP 
> Payload Format for Informational Mar-10 Submit RTP Payload 
> Format for DV (IEC 61834) Video for Proposed Standard Mar-10 
> Submit EVBR/G.718 payload draft for Proposed Standard Mar-10 
> RTP Payload Format for MPEG2-TS preamble for Proposed 
> Standard Mar-10 RTP Payload Format for MPEG-4 Audio/Visual 
> Streams for Proposed Standard Apr-10 RTP Payload Format for 
> Enhanced Variable Rate Narrowband- Wideband Codec (EVRC-NW) 
> for Proposed Standard Apr-10 RTP Payload Format for 
> Bluetooth's SBC audio codec for Proposed Standard Apr-10 RTP 
> Payload Format for the iSAC codec for Proposed Standard 
> Sep-10 RTP Payload Format for the CELT codec for Proposed 
> Standard Sep-10 RTP Payload Format for the APTX codec for 
> Proposed Standard Sep-10 RTP profile for the carriage of 
> SMPTE 336M data for Proposed Standard Oct-10 RTP Payload 
> Format for MVC Video for Proposed Standard Dec-10 Submit RTP 
> Payload Format for MIDI for Proposed Standard
> 
> Specification of metric blocks for use with the RTCP Extended Report
> (XR) framework
> Feb-10 Submit Multicast Acquisition Report Block Type for 
> RTCP XR Mar-10 Submit RTCP XR Report Block for Measurement 
> Identity Apr-10 Submit RTCP XR Report Block for Burst/Gap 
> Discard metric Reporting Apr-10 Submit RTCP XR Report Block 
> for Burst/Gap Loss metric Reporting Apr-10 Submit RTCP XR 
> Report Block for Concealed Seconds metric Reporting Apr-10 
> Submit RTCP XR Report Block for Delay metric Reporting Apr-10 
> Submit RTCP XR Report Block for Discard metric Reporting 
> Apr-10 Submit RTCP XR Report Block for Jitter Buffer Metric 
> Reporting Apr-10 Submit RTCP XR Report Block for Loss 
> Concealment metric Reporting Apr-10 Submit RTCP XR Report 
> Block for Packet Delay Variation Metric Reporting Apr-10 
> Submit Real-time Transport Control Protocol Extension Report 
> for Run Length Encoding of Discarded Packets Apr-10 Submit 
> RTCP XR Report Block for QoE Metrics Reporting
> 
> Extensions to the core protocols to facilitate joining, 
> synchronizing, control, and monitoring of RTP multimedia 
> Jan-10 Submit Unicast-Based Rapid Acquisition of Multicast 
> RTP Sessions for Proposed Standard Jan-10 Submit Rapid 
> Synchronization of RTP Flows for Proposed Standard Jan-10 
> Submit Forward-shifted RTP Redundancy Payload Support for 
> Proposed Standard Apr-10 Submit Considerations for RAMS 
> Scenarios for Informational 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 01 Feb 2010 08:15:35 -0500

My recent call for MIB volunteers resulted in a single response aside from your 
kind offer to continue to be our MIB doctor. He might be willing to author a 
document on his own (haven't asked), but I seriously wonder if we have the 
capability to do any sort of review of the results.

Tom Taylor
AVT Co-Chair

> seriously impacted by the decision to drop this item from the new
...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Feb 2010 14:33:01 +0100

The review done by the WG would need to focus on the question 'to what
extent the MIB objects are accurately representing the behavior of the
protocol, and are useful for operational purposes'. You can assume that
the MIB-specific reviews will be performed by the MIB Doctors team. 

Dan

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Monday, February 01, 2010 3:16 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVT] WG Review: Recharter of Audio/Video Transport (avt)
> 
> My recent call for MIB volunteers resulted in a single 
> response aside from your kind offer to continue to be our MIB 
> doctor. He might be willing to author a document on his own 
> (haven't asked), but I seriously wonder if we have the 
> > DISCUSS - I am concerned with the disappearance of the RTCP XR MIB 
> > from the charter. I know that this item was delayed a lot in the 
> > previous charter, probably because of lack of bandwidth and 
> > enthusiasm, but not having a MIB module that allows for RTCP 
> > parameters to be queried by a management application leaves the 
> > standard space devoid of a tool that allows for operators 
> to get from 
> > the network the RTCP XR information and correlate it with the other 
> > network and QoS information. The capability of integrated 
> management 
> > of networks carrying voice or video traffic is seriously 
> impacted by 
> > the decision to drop this item from the new charter.
> > 
> > Dan
> > 
> ...
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 01 Feb 2010 08:45:22 -0500

Just as a technical point: we have a proposed milestone for an RTCP XR 
measurement architecture document. Would it make sense for that to discuss the 
structure of an RTCP XR MIB?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Feb 2010 14:48:27 +0100

> the MIB-specific reviews will be performed by the MIB Doctors team. 

Dan, the existing RTP MIB is bad. Unless I am gravely mistaken on what
MIB's can do, it doesn't take a number of RTP functions into account.

My impression having reviewed a number of MIBs by now is that you need
descent understanding of both the MIB and the protocol to instrument. As
RTP does have some interesting data relationships it is important to
represent them correctly. My impression when I was reviewing the
previous attempt to update the RTP MIB was that I didn't know if there
where better ways to represent the data then what was described. But I
do agree that I was able to identify the really stupid ways or missing
relationships.

Doing an XR MIB does include redoing the old one so that you have a
reasonable base to build on.

What I can understand the ones that potentially can be interested in an
RTP and RTCP XR MIB is the ones that has RTP based infrastructure
devices such as Mixers and translators. Most RTP end-points are not of
interest to instrument in the way a MIB does it. That is why we have all
these other systems for RTP monitoring.

I am afraid that if we add an charter item for MIBs then it will be one
that fails to result in any real output.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Feb 2010 14:58:04 +0100

Hi Magnus, 

See in-line. 

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Magnus Westerlund
> Sent: Monday, February 01, 2010 3:48 PM
> To: Romascanu, Dan (Dan)
> Cc: Tom Taylor; [email-masked]; [email-masked]
> > protocol, and are useful for operational purposes'. You can assume 
> > that the MIB-specific reviews will be performed by the MIB 
> Doctors team.
> > 
> 
> Dan, the existing RTP MIB is bad. Unless I am gravely 
> mistaken on what MIB's can do, it doesn't take a number of 
> RTP functions into account.
> 
> My impression having reviewed a number of MIBs by now is that 
> you need descent understanding of both the MIB and the 
> protocol to instrument. 

I agree. Also, the best place to find these two kinds of expertise together (for RTP) is in the AVT WG. 

> As RTP does have some interesting 
> data relationships it is important to represent them 
> correctly. My impression when I was reviewing the previous 
> attempt to update the RTP MIB was that I didn't know if there 
> where better ways to represent the data then what was 
> described. But I do agree that I was able to identify the 
> really stupid ways or missing relationships.
> 
> Doing an XR MIB does include redoing the old one so that you 
> have a reasonable base to build on.

Yes, if the XR MIB extends the RTP MIB, revising what is broken in the RTP MIB is necessary. 

> 
> What I can understand the ones that potentially can be 
> interested in an RTP and RTCP XR MIB is the ones that has RTP 
> based infrastructure devices such as Mixers and translators. 
> Most RTP end-points are not of interest to instrument in the 
> way a MIB does it. That is why we have all these other 
> systems for RTP monitoring.
> 
> I am afraid that if we add an charter item for MIBs then it 
> will be one that fails to result in any real output.

What are 'all the other systems for RTP monitoring'? Is there anything to offer in the standards apace to allow a network operator debug RTP traffic from the same console as other IP traffic in the network? It needs not be SNMP or MIB-based, but the RTP solution is not complete from an operational point of view without a set of adequate monitoring interfaces.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Feb 2010 15:04:46 +0100

If I am not mistaken the WG had already a document in works authored by
Alan and Amy. What happened with that one? 

Dan

> Behalf Of Tom Taylor
> Sent: Monday, February 01, 2010 3:45 PM
> To: Romascanu, Dan (Dan)
> Just as a technical point: we have a proposed milestone for 
> an RTCP XR measurement architecture document. Would it make 
> sense for that to discuss the structure of an RTCP XR MIB?
> 
> response aside 
> >> from your kind offer to continue to be our MIB doctor. He might be 
> >> willing to author a document on his own (haven't asked), but I 
> >> seriously wonder if we have the capability to do any sort 
> of review 
> >> of the results.
> >>
> >> Tom Taylor
> >> AVT Co-Chair
> >>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Feb 2010 16:12:32 +0100

> What are 'all the other systems for RTP monitoring'? Is there anything to offer in the standards apace to allow a network operator debug RTP traffic from the same console as other IP traffic in the…

When you write other IP traffic on the same console I can't answer with
certainty. However, the RTP monitoring systems we do have are:

RTCP (XR), real-time deployment with third party listner in Mixer or
translator or other node.

RTCP summary reporting (SIP based)

RFC 4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB

I can understand that there exist holes here. A new RTP + RTCP XR MIB
may help fill them. But there need to be some man power behind work
also. If the ones building systems don't have an interest in a
standardized MIB, then why should someone else write it?

cheers

Magnus Westerlund

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Feb 2010 16:19:44 +0100

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, February 01, 2010 5:13 PM
> To: Romascanu, Dan (Dan)
> interested in 
> >> an RTP and RTCP XR MIB is the ones that has RTP based 
> infrastructure 
> >> devices such as Mixers and translators.
> >> Most RTP end-points are not of interest to instrument in the way a 
> >> MIB does it. That is why we have all these other systems for RTP 
> >> monitoring.
> >>
> >> I am afraid that if we add an charter item for MIBs then 
> it will be 
> >> one that fails to result in any real output.
> > 
> > What are 'all the other systems for RTP monitoring'? Is 
> there anything to offer in the standards apace to allow a 
> network operator debug RTP traffic from the same console as 
> other IP traffic in the network? It needs not be SNMP or 
> MIB-based, but the RTP solution is not complete from an 
> operational point of view without a set of adequate 
> monitoring interfaces. 
> 
> When you write other IP traffic on the same console I can't 
> answer with certainty. However, the RTP monitoring systems we 
> do have are:
> 
> RTCP (XR), real-time deployment with third party listner in 
> Mixer or translator or other node.
> 

The link between these two and an operator console is the MIB or
something similar. 

> RFC 4711 Real-time Application Quality-of-Service Monitoring 

This one requires RAQMON to be implemented in the endpoints or devices
that terminate RTP streams. 

> 
> I can understand that there exist holes here. A new RTP + 
> RTCP XR MIB may help fill them. But there need to be some man 
> power behind work also. If the ones building systems don't 
> have an interest in a standardized MIB, then why should 
> someone else write it?
> 

We are the IESG and I think that we should be concerned with how a
standards-based solution in the Internet is operationally deployable and
manageable by standard tools even if people building the systems do not
see this as their immediate priority. 

Dan

---

From: Tom Taylor <[email-masked]>
Date: Mon, 01 Feb 2010 13:19:27 -0500

Last update was 2007, IIRC.

---

From: David R Oran <[email-masked]>
Date: Mon, 1 Feb 2010 13:45:05 -0500

As an individual:

I think it is a complete and utter waste of time to build MIBs for RTP/RTCP/RTCP-XR. I have yet to see a single instance where people were successful at configuring, instrumenting, diagnosing, or doing any sort of useful metrology of the media part of real time applications using SNMP/MIB technology. This is not just a consequence of the (arguably) poor construction of the RTP MIB. MIBs and SNMP are just a very poor semantic match for the problem space IMO.

People working on management for multicast video, video streaming, VoIP, internet Radio, etc. all seem to be using one of three methods:
a) direct capture of RTCP messages to a circular buffer by the endpoints, and using things like syslog to get them off the box, followed by ad hoc correlation and analysis tools.
b) streaming export (usually through TCP) of RTCP into a database with near-realtime ability to do SQL queries
c) streaming RTCP (either through export, 3rd party RTCP receivers, or snooping) into a streaming database system and using the query outputs to summarize by time series and generate alarms.

My video-oriented products do (a) and (b), and we think (c) has  a lot of promise.

Dave Oran.

On Feb 1, 2010, at 1:19 PM, Tom Taylor wrote:

>> Alan and Amy. What happened with that one? Dan
>> 
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
>>> Just as a technical point: we have a proposed milestone for an RTCP XR measurement architecture document. Would it make sense for that to discuss the structure of an RTCP XR MIB?
>>> 
>>>> protocol, and are useful for operational purposes'. You can assume that the MIB-specific reviews will be performed by the MIB 
>>> Doctors team.
>>>> Dan
>>>>  
>>>>> from your kind offer to continue to be our MIB doctor. He might be willing to author a document on his own (haven't asked), but I seriously wonder if we have the capability to do any sort 
>>> of review 
>>>>> of the results.
>>>>> 
>>>>> Tom Taylor
>>>>> AVT Co-Chair
>>>>> 
>>>>>> from the charter. I know that this item was delayed a lot in the previous charter, probably because of lack of bandwidth and enthusiasm, but not having a MIB module that allows for RTCP parameters to be queried by a management application leaves the standard space devoid of a tool that allows for operators
>>>>> to get from

---

From: Mark Baugher <[email-masked]>
Date: Mon, 1 Feb 2010 12:21:15 -0800

On Feb 1, 2010, at 10:45 AM, David R Oran wrote:

> This is not just a consequence of the (arguably) poor construction of the RTP MIB.

In defense of the RTP MIB, it passed expert review in the IESG for MIBs.  I just have not seen real interest in this kind of management of RTP since some IT departments said they wanted it more than a dozen years ago.

Mark

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Feb 2010 12:33:25 +0100

Dave, 

I am not sure that the problem is in semantics, or maybe I should ask
you what you exactly mean by 'semantic match'.  SNMP is still pretty
well fit for retrieving performance monitoring and status information,
and part of the job of the network operator is to get the VoIP or video
specific information and correlate it with the other events in the
network. 

When you say 'people working on management for multicast video, video
streaming, VoIP, internet Radio, etc.' you seem to make the assumption
that these people are different from the people who operate the
underlying networks. My experience is that this is true in some cases,
this is not true in other and in all cases these operators need a
consistent set of tools that helps them understand what happens at the
different layers of their networks up to the applications. 

The set of tools needs not be SNMP-centric or SNMP-based, but we need to
discuss and propose a solution in the standards space. The methods that
you describe below could for example be integrated with existing
standards efforts - syslog or sipclf for a), ipfix for b) and c). I
think that the WG needs to provide a fully deployable solution for RTP
and this cannot ignore the operational needs.

Dan

> From: David R Oran [mailto:[email-masked]] 
> Sent: Monday, February 01, 2010 8:45 PM
> To: Tom Taylor
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> I think it is a complete and utter waste of time to build 
> MIBs for RTP/RTCP/RTCP-XR. I have yet to see a single 
> instance where people were successful at configuring, 
> instrumenting, diagnosing, or doing any sort of useful 
> metrology of the media part of real time applications using 
> SNMP/MIB technology. This is not just a consequence of the 
> (arguably) poor construction of the RTP MIB. MIBs and SNMP 
> are just a very poor semantic match for the problem space IMO.
> 
> People working on management for multicast video, video 
> streaming, VoIP, internet Radio, etc. all seem to be using 
> one of three methods:
> a) direct capture of RTCP messages to a circular buffer by 
> the endpoints, and using things like syslog to get them off 
> the box, followed by ad hoc correlation and analysis tools.
> b) streaming export (usually through TCP) of RTCP into a 
> database with near-realtime ability to do SQL queries
> c) streaming RTCP (either through export, 3rd party RTCP 
> receivers, or snooping) into a streaming database system and 
> using the query outputs to summarize by time series and 
> generate alarms.
> 
> >> If I am not mistaken the WG had already a document in 
> works authored 
> >> by Alan and Amy. What happened with that one? Dan
> >> 
> >>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> >>> Of Tom Taylor
> >>> Just as a technical point: we have a proposed milestone 
> for an RTCP XR measurement architecture document. Would it 
> make sense for that to discuss the structure of an RTCP XR MIB?
> >>> 
> >>>>> Subject: Re: [AVT] WG Review: Recharter of Audio/Video 
> Transport 
> >>>>> (avt)
> >>>>>

---

From: David R Oran <[email-masked]>
Date: Tue, 2 Feb 2010 08:32:14 -0500

> In defense of the RTP MIB, it passed expert review in the IESG for MIBs.  I just have not seen real interest in this kind of management of RTP since some IT departments said they wanted it more tha…
That's why I said "arguably". I don't think they were poorly constructed, given the incredible mismatch of SNMP for the problem domain.

---

From: David R Oran <[email-masked]>
Date: Tue, 2 Feb 2010 08:58:35 -0500

On Feb 2, 2010, at 6:33 AM, Romascanu, Dan (Dan) wrote:

> you what you exactly mean by 'semantic match'.  
It is really difficult to get near realtime understanding of the spatio-temporal aspects of performance and problem diagnosis using MIB counters, SNMP polling and trap/inform. For one, somebody has to decide statically on the temporal granularity of the summarization into the MIB counters, or force the endpoints into a (pretty expensive) histogram approach (which isn't in the current MIB anyway).

> SNMP is still pretty
I agree in general, but for realtime media my practical experience has been otherwise. I'll note that RTP is nearly *unique* among Internet protocols by having, through RTCP, its own instrumentation built in. This is in fact a VERY powerful tool and homogenizing/re-encoding/re-mapping it into the MIB paradigm throws away much of that power.

Frankly, I wish other internet protocols were self-instrumenting like RTP.

> different layers of their networks up to the applications. 
I agree in general, but doing the unification in the toolset at the level of RTP/RTCP is what I think is wrong. In our systems, we do a lot of processing of the raw RTCP data. I would be happy arrange a demo sometime for the OPS area directorate, which might help to elucidate some of the issues with trying to extract what we extract using MIBs and SNMP. Another company, Mariner Systems, has a similar set of tools which also work on our raw data and RTCP captured by endpoints.

To be clear, we *do* use MIBs and SNMP extensively for the non-media parts of the instrumentation. We have also designed the back-end tools to export MIBs for the digested RTCP data, but since no customer has yet asked for them we haven't productized the capability.

> and this cannot ignore the operational needs.
I don't think anybody making this stuff for money ignores the operational needs. The question is what we base the interoperable part of the solution on. Perhaps the OPS area could start looking into how/whether IPFIX-based instrumentation attaches to streaming database systems. That could be a very powerful method going forward.

Aside: when we designed our custom TCP-based RTCP capture and export stuff I recall we looked at mapping to IPFIX (actually NetFlow) instead. I don't remember why we decided to punt on Netflow, but if you're interested I could go back and dig through the history.

DaveO.

---

From: Mark Baugher <[email-masked]>
Date: Tue, 2 Feb 2010 07:14:59 -0800

> That's why I said "arguably". I don't think they were poorly constructed, given the incredible mismatch of SNMP for the problem domain.

There apparently is an IETF rule that a MIB is needed for a spec to progress to Draft standard.  Or there was at the time that the MIB was published.  So long as there is some mandate to do a MIB and no clear understanding that SNMP is ill-suited to the problem domain, people will continue to want to create MIBs for RTP.

Mark

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Feb 2010 09:51:28 +0100

If this rule ever existed it certainly is not in place today. What we
want to see from the operators perspective is an analysis of the
operational requirements and a definition or recommendation about how
protocols that are being defined in the IETF are being deployed and
managed. It needs not be MIB modules, actually automatically requiring
MIB modules would prevent the WG from analyzing what tools or protocols
or data models are fit for their specific needs. My concern with the MIB
work being taken out of the charter is not that much because of the MIB
(which may or may not have been a good fit in this case) but because I
do not see any other item dealing with the manageability of RTP having
remained in the WG focus. 

Dan

> Behalf Of Mark Baugher
> Sent: Tuesday, February 02, 2010 5:15 PM
> To: David R Oran
> Cc: Tom Taylor; Romascanu, Dan (Dan); [email-masked]; [email-masked]
> > That's why I said "arguably". I don't think they were 
> poorly constructed, given the incredible mismatch of SNMP for 
> the problem domain.
> 
> There apparently is an IETF rule that a MIB is needed for a 
> spec to progress to Draft standard.  Or there was at the time 
> that the MIB was published.  So long as there is some mandate 
> to do a MIB and no clear understanding that SNMP is 
> ill-suited to the problem domain, people will continue to 
> want to create MIBs for RTP.
> 
> Mark
> 
>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 3 Feb 2010 07:44:46 -0800

IIRC the latest MIB effort started five years ago.  It typically takes a matter of months to finish a MIB, maybe longer if you need it to support unicast as well as multicast as the original MIB did.  But it should not take more than a year or two, even in the IETF.  The needed counters could have been easily added to the existing RTP MIB in a few months.  There seemed to be a lot of support for doing the new MIB at the time, but it's still not finished.  That says to me that there is no pressing need for this.

Mark