Types of monitoring architectures; RE: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-08.txt

Dear All,

there are different types of monitoring architectures, particularily from perspective of QoE related performance parameters. 
Let's recall QoE (e.g., ITU-T P.10 Amendment 2):

Quality of Experience (QoE): 
	The overall acceptability of an application or service, as perceived subjectively by the end-user.  
	NOTE 1 - Quality of experience includes the complete end-to-end system effects (client, terminal, network, services infrastructure, etc.). 
	NOTE 2 - Overall acceptability may be influenced by user expectations and context. 
 
Important for MONARCH:
1st ... perceived by end-user
2nd QoE includes the complete end-to-end sytem effects ...

That said, present RTP monitoring architecture in MONARCH according clause 3 is not specific on the type of monitoring architecture. For instance, Fig. 1, it is possibly supposed that the "RTP Sender" and "RTP Receiver" entities are equal to a terminal/user equipment (UE). This would be an end-to-end IP network scenario.

However, the "RTP Sender" and "RTP Receiver" entities may be also located at the edge of an IP network, e.g. in a gateway for IP-to-non-IP interworking, i.e. an UE located in the non-IP network part. 
Note: such scenarios are considered by MEGACO gateways (I've Cc'd megaco list).

An RTP Sender/Receiver located NOT in the UE would question the value of RTP/RTCP QoE related performance measurements (because the UE is located outside the RTP domain). 

Conclusions:
- the set of meaningful performance metrics may be dependent on the location of the RTP Sender/Receiver, e.g. whether in a UE, gateway, ...
- don't see any impact on transport level metrics
- ... but the set of meaningful application level metrics

Proposal for MONARCH:
#1: insert sub-clause title "3.1 End-to-end IP network architecture" below clause 3

#2: add a sub-clause 3.2 at the end of clause 3, sth like

"3.2 RTP Sender/Receiver entities located in network nodes
The location of the RTP Sender/Receiver entity may impact the set of meaningful metrics.
For instance: application level metrics for QoE related performance metrics are questionable (or doesn't really make sense at all) when measured in a network node (terminating the RTP) instead of the user equipment."

Something like this would help to avoid confusion.
I even believe that a QoE measurement in a network node would violate the QoE definition. Would be rather something like QoE* ("remote QoE"):-(

Such information would improve the MONARCH doc in my opinion.
Sorry for that late comment.
Any views?

Regards,
Albrecht

 


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of [email protected]
> Sent: Dienstag, 29. November 2011 08:56
> To: [email protected]
> Cc: [email protected]
> Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-08.txt
> 
> 
> 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 Architectures for RTP
> 	Author(s)       : Qin Wu
>                           Geoff Hunt
>                           Philip Arden
> 	Filename        : draft-ietf-avtcore-monarch-08.txt
> 	Pages           : 25
> 	Date            : 2011-11-28
> 
>    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, following RTCP guideline
>    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-08.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-08.txt
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email protected]
> https://www.ietf.org/mailman/listinfo/avt
>