Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Jun 2012 12:48:32 +0100

Magnus,

I reviewed the changes between -13 and -14. It is perhaps a shame that Figure 1 is removed, but the other changes look okay to me.

Colin

On 30 May 2012, at 14:49, Magnus Westerlund wrote:
> WG, Colin and Albrecht,
> 
> Please check if you think the changes in this version are appropriate.
> 
> Cheers
> 
> Magnus
> 
> On 2012-05-29 04:25, [email-masked] wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
>> 
>> 	Title           : Monitoring Architecture for RTP
>> 	Author(s)       : Qin Wu
>>                          Geoff Hunt
>>                          Philip Arden
>> 	Filename        : draft-ietf-avtcore-monarch-14.txt
>> 	Pages           : 27
>> 	Date            : 2012-05-28
>> 
>>   This memo proposes an architecture for extending RTP Control Protocol
>>   (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to
>>   report new metrics regarding media transmission or reception quality,
>>   following RTCP guidelines established in 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.
>> 
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-14.txt
>> 
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Jun 2012 12:52:47 +0100

On 31 May 2012, at 09:35, Qin Wu wrote:
> ----- Original Message ----- 
> From: "Magnus Westerlund" <[email-masked]>
> To: "Qin Wu" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, May 31, 2012 2:41 PM
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-14.txt
> 
> 
> On 2012-05-31 04:03, Qin Wu wrote:
> 
>> 
>> [Qin]: I thought the figure 1 has already been incoporated into setion 3 and replaced by the description in the section 3.
>> Based on your comment, I can propose to have the following figure
>> 
>>                            +------------|
>>         ------------------>|            |<------------------
>>         |                  | Management |                  |
>>         |                  |   System   <-----             |
>>         |                  |            |    |             |
>>         |                  +------^-----+    |             |
>>         |                         |          |             |
>>         |                         |          |             |
>>         |                 +---------------+  |             |
>>         |                 |               |  |             |
>>         |                 | Third Party   |  |             |
>>         |                 | RTP Monitor   |  |             |
>>         |                 |               |  |             |
>>         |                 +---------------+  |             |
>>         |                                    |             |
>> +-------|-------+         +Intermediate --+  |    +--------|------+
>> |RTP Sender     |         | RTP System    |  |    |RTP Receiver   |
>> |               |         |               |---    |               |
>> | +-----------+ |         | +-----------+ |       | +-----------+ |
>> | |RTP Monitor| |  RTP    | |RTP Monitor| | RTP   | |RTP Monitor| |
>> | +-----------+ | Stream  | +-----------+ |Stream | +-----------+ |
>> |               |-------->|               |------>|               |
>> |               |         |               |       |               |
>> +---------------+         +---------------+       +---------------+
>> Is this figure what you are looking for?
> 
> Mostly. I don't know if we need to have the Management system in the
> picture. What I was looking for was the lower part. The one thing I
> think is poorly covered in the above figure is how a third party monitor
> gets to the information it monitors. To my understanding it exists in
> two flavors. A passive monitor that sees the RTP/RTCP stream pass it, or
> a system that gets sent RTCP reports but not RTP and uses that to
> collect information.
> 
> [Qin]: You are right, actually these two flavors have been described in the figur 1 of previous version -13.
> I can fix the figure I proposed above with the following change:
> 
>                           +---------------+
>                           |               |
>                       |-->| Third Party   |
>                       |   | RTP Monitor   |
>                       |   |               |
>                       |   +---------|-----+
>                       |Metric Report|
>                       ---------------
>                          RTP Stream
> 
>                                           Metric
> +------- -------+ Metric  +Intermediate --+Report +---------------+
> |RTP Sender     | Report  | RTP System    |       |RTP Receiver   |
> | +-----------+ |         | +-----------+ |       | +-----------+ |
> | |RTP Monitor|<------------|RTP Monitor|<----------|RTP Monitor| |
> | +-----------+ |         | +-----------+ |       | +-----------+ |
> |               |  RTP    |               | RTP   |               |
> |               | Stream  |               |Stream |               |
> |               |-------->|               |------>|               |
> +---------------+         +---------------+       +---------------+

A problem with both versions of the figure is that the Third Party RTP Monitor appears disconnected from the RTP streams that it's supposed to be monitoring.

-- 
Colin Perkins
http://csperkins.org/