[AVT] Review of draft-hunt-avt-monarch-01

[Qin Wu <[e-mail]>]

Hi, all:
I haven't seen the updating of the monitoring architecture document by issuing the new version.
So I provide some review on the current version of draft-hunt-avt-monarch-01.
Please see my comments inline.
Hope it helps move this work foward.

Regards!
-Qin
-------------------------------------------------------------------------------------------------

                    Monitoring Architectures for RTP
                     draft-hunt-avt-monarch-01.txt

[Qin] Suggest to change the title into "Guideline for Monitoring using RTCP XR Report Block"

Abstract

   This memo proposes an architecture for extending RTCP with a new RTCP
   XR (RFC3611) block type to report new metrics regarding media
   transmission or reception quality, as proposed in
   draft-ietf-avt-rtcp-guidelines (work in progress [replace with RFC
   number]).  
   
[Qin]: s/draft-ietf-avt-rtcp-guidelines/RFC5968

This memo suggests that a new block should contain a
   single metric or a small number of metrics relevant to a single
   parameter of interest or concern, rather than containing a number of
   metrics which attempt to provide full coverage of all those
   parameters of concern to a specific application.  Applications may
   then "mix and match" to create a set of blocks which covers their set
   of concerns.  Where possible, a specific block should be designed to
   be re-usable across more than one application, for example, for all
   of voice, streaming audio and video.

1.  Introduction

   Any proliferation of metrics for transport and application quality
   monitoring has been identified as a potential problem for RTP/RTCP
   interoperability.  Different applications layered on RTP may have
   some monitoring requirements in common, which should be satisfied by
   a common design.  The objective here is to define an extensible
   framework and a small number of re-usable metrics to reduce
   implementation costs and to maximise inter-operability.  Work-in-
   progress on [GUIDELINES]
   
   [Qin]: s/Work-in-progress on [GUIDELINES]/RFC5968

   has stated that, where RTCP is to be
   extended with a new metric, the preferred mechanism is by the
   addition of a new RTCP XR [RFC3611] block.  
   
   [Qin]: As described in RFC5968, 
   "
          *  New RTP profiles may define a profile-specific extension to
         RTCP SR and/or RR packets, to give additional feedback (see
         [RFC3550], Section 6.4.3).  It is important to note that while
         extensions using this mechanism have low overhead, they are not
         backwards compatible with other profiles.  Where compatibility
         is needed, it's generally more appropriate to define a new RTCP
         XR block or a new RTCP packet type instead.

   "
   It is not recommened to extend RTCP SR and or RR to give additional fedback,
   becos the profile-specific extension is not back compatible with other profile.
   Therefore it is a good choice to define a new RTCP XR or a new RTCP message.
   So I suggest to reword the text from
 "
 where RTCP is to be
   extended with a new metric, the preferred mechanism is by the
   addition of a new RTCP XR [RFC3611] block
 "
to 
   "
   where RTCP extension used to convey some new metric is limited for specific profile, the preferred
   mechanism is by the additional of a new RTCP XR [RFC3611] Report block.
   "
-----------------------------------------------------------------------------------
   [snap]
   This memo assumes that
   any requirement for a new metric to be transported in RTCP will use a
   new RTCP XR block.

   [GUIDELINES] provides advice on when and how new metrics should be
   introduced, including recommending that metrics are based on existing
   standards whenever possible.

   [Qin]: It seems this section is not complete and waits for being enriched.
   Suggest to invite more inputs and contribution. I am willing to
   contribute this section by providing some inputs.
   

   [Qin]: Suggest to remove the last six paragraphs, instread,summarize contents of 
   section 3~8 to fill the Introduction section.

[snap]


[Qin]: It is better to add one new section to discuss metrics classification,
e.g., classify metrics into transport layer metrics and application layer metrics.
I am willing to contribute to this section.

3.  Using small blocks

   [Qin]: I think here it is better to highlight that the concepts of using of small RTCP XR metrics
   are
   a) make most of small RTCP XR metrics reusable for most of applications.
   b) make smaller number of small RTCP XR metrics apply for some specific application.
   c) application indepent reusable small RTCP XR metrics and application specific small RTCP XR metrics 
      are part of metric components pool.
   c) each application can pick out reusable small RTCP XR metrics and some of application
      specific small RTCP XR metics from this component pool.
   Does it make sense to reflect these concepts in this section.

4.  The identity block

   Any measurement must be identified.  However if metrics are delivered
   in small blocks there is a danger of inefficiency arising from
   repeating this information in a number of metrics blocks within the
   same RTCP packet, 
   
[Qin]: s/RTCP packet/RTCP XR blcok

  in cases where the same identification information
   applies to multiple metrics blocks.

   An instance of a metric must be identified using information which is
   likely to include most of the following:

   o  the node at which it was measured,

   o  the source of the measured stream (for example, its CNAME),

   o  the SSRC of the measured stream,

   o  the sequence number of the first packet of the RTP session,

   o  the extended sequence numbers of the first packet of the current
      measurement interval, and the last packet included in the
      measurement,

   o  the duration of the most recent measurement interval and

   o  the duration of the interval applicable to cumulative measurements
      (which may be the duration of the RTP session to date).

  [Qin]: I think this document should focus on guideline for monitoring using RTCP XR
   rather than discussing new Identify blcok.
   Also this section is too lenthy and overlapped with draft-ietf-avt-rtcp-xr-meas-identity-02.
   Suggest t highlight some concept of using tag field and simplify the texts in this section.

6.  Application to translators
7.  Application to RFC 5117 topologies

[Qin]: It seems section 6 is relevant to section 7, suggest to merge both together.