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

[Qin Wu <[e-mail]>]

----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>
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 |               |
|               |-------->|               |------>|               |
+---------------+         +---------------+       +---------------+

> 
> 2. I also wonder if we shouldn't really remove the word architecture
> from this document and instead have the title be "Guidelines for the RTP
> Monitoring Framework"
> 
> [Qin]: Are you proposing to replace the word "architecture" with "framework"?

No, you will have to be a bit more intelligent in selecting words. But
Architecture implies an explanation of how things are supposed to fit to
together in total. I don't see this document reaching this bar. That was
why I suggested a new title. Based on that title one can remove the use
of architecture with calling it description of the frame work like for
section 3 and Guidelines for the framework for section 5. What to
replace architecture with depends on the context.

[Qin]: Agree.

> 
> 3. In some sense I wished we could keep the old figure 1 somewhere in
> the document. But I guess it would require even more discussion around
> the management system.
> 
> [Qin]: Management system may not have RTP functionality. Therefore shouldn't it be
> beyond scope of the RTP monitoring architecture? In the current draft, we have briefly 
> discussed interaction between RTP monitor and management system with the following
> description:
> "
> The RTP monitor also exposes real time Application QoS/QoE metric
>    information in the appropriate report block format (e.g.,RTCP XR or
>    other non-RTP means) to the management system. 
> "

In reality I think a RTP monitoring architecture do need to discuss the
management side of things. But this document isn't up to the task. It
describes the RTP side of the monitoring. That is why I think calling it
a framework might be better and not imply that all pieces are present.

[Qin]: I see.