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

Hello Qin,

to 1) Physical monitoring architecture
Of course consideration of generic physical entities (PE), not specific to any network reference architectures defined by SDOs (like your refered entities).
There would be just a few PE types ("given by the limited set of RTP topology components (RFC 5117)").

to 2) (RFC 3550) Monitor function
Right, that's a functional entity. The applicability of a monitor may be limited, dependent on ... (like in P.NAMS).

to 3) your IMS network example
Don't see the need to refer from MONARCH to a specific network architecture like IMS.
Please also note that IMS is a functional architecture, not a physical architecture.

Regards,
Albrecht

PS
There are multiple options for adding the "RTP monitoring architecture" to a functional/physical network architecture:
a) integrated approach: extension of existing functional entities or/and addition of RTP monitoring architectural components, extension or/and addition of signalling/management interfaces for control and configuration of RTP monitoring services, and reporting interfaces for measurement data ...
b) overlay approach: separate specification to ...


PSS
BTW: there's a discussion paper with regards to the location of a monitor function in an IMS H.248 gateway entity:
Measurements and statistics in IMS - Use Cases
http://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_58_Kyoto_Japan/Docs/C3-100469.zip
This is just fyi.



> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Qin Wu
> Sent: Freitag, 2. Dezember 2011 02:55
> To: Schwarz, Albrecht (Albrecht); [email protected]
> Cc: [email protected]
> Subject: Re: [AVTCORE] Types of monitoring architectures; RE:
> I-D Action: draft-ietf-avtcore-monarch-08.txt
>
> Hi, Albrecht:
> No offence, I am not really convinced with your proposal on
> physical monitoring architecture.
>  my counterquestion is what does physical monitoring
> architecture looks like in your mind?
> How many components do we have in such physical monitroing
> architecture? what are they?
> Take IMS network architecture as a example, they may have
> P-CSCF,S-CSCF, SIP PBX, SBC, why do you believe monitor
> described in draft-ietf-avtcore-monarch is mapped into
> P-CSCF, S-CSCF, SBC, Media Gateway, Media Gateway Controller
> should be in the scope of IETF RTP monitoring archtiecture draft?
>
> Monitor described in  draft-ietf-avtcore-monarch is well
> defined in the section 3 of RFC3550 as follows:
> "
>
>    Monitor: An application that receives RTCP packets sent by
>       participants in an RTP session, in particular the reception
>       reports, and estimates the current quality of service for
>       distribution monitoring, fault diagnosis and long-term
> statistics.
>       The monitor function is likely to be built into the
> application(s)
>       participating in the session, but may also be a separate
>       application that does not otherwise participate and
> does not send
>       or receive the RTP data packets (since they are on a separate
>       port).  These are called third-party monitors.  It is also
>       acceptable for a third-party monitor to receive the RTP data
>       packets but not send RTCP packets or otherwise be counted in the
>       session.
>
> "
> Isn't how to implent monitor into IMS netowork archtiecture a
> implentation specific issue?
> If this issue are really interesting, isn't it a good idea to
> produce another new document to talk about this?
> One good example for this motivation is this draft I like to
> share with you:
> http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-taxonom
> y-00#section-4.6
>
> Regards!
> -Qin
> ----- Original Message -----
> From: "Schwarz, Albrecht (Albrecht)"
> <[email protected]>
> To: "Qin Wu" <[email protected]>; <[email protected]>
> Cc: <[email protected]>
> Sent: Friday, December 02, 2011 12:20 AM
> Subject: RE: [AVTCORE] Types of monitoring architectures; RE:
> I-D Action: draft-ietf-avtcore-monarch-08.txt
>
>
> My replies below ...
> -Albrecht
>
> > -----Original Message-----
> > From: Qin Wu [mailto:[email protected]]
> > Sent: Donnerstag, 1. Dezember 2011 02:42
> > To: Schwarz, Albrecht (Albrecht); [email protected]
> > Cc: [email protected]
> > Subject: Re: [AVTCORE] Types of monitoring architectures; RE:
> > I-D Action: draft-ietf-avtcore-monarch-08.txt
> >
> > Hi,
> > ----- Original Message -----
> > From: "Schwarz, Albrecht (Albrecht)"
> > <[email protected]>
> > To: "Qin Wu" <[email protected]>; <[email protected]>
> > Cc: <[email protected]>
> > Sent: Thursday, December 01, 2011 1:24 AM
> > Subject: RE: [AVTCORE] Types of monitoring architectures; RE:
> > I-D Action: draft-ietf-avtcore-monarch-08.txt
> >
> >
> > My replies below inline,
> > Albrecht
> >
> > > -----Original Message-----
> > > From: Qin Wu [mailto:[email protected]]
> > > Sent: Mittwoch, 30. November 2011 04:51
> > > To: Schwarz, Albrecht (Albrecht); [email protected]
> > > Cc: [email protected]
> > > Subject: Re: [AVTCORE] Types of monitoring architectures; RE:
> > > I-D Action: draft-ietf-avtcore-monarch-08.txt
> > >
> > > Hi,
> > > ----- Original Message -----
> > > From: "Schwarz, Albrecht (Albrecht)"
> > > <[email protected]>
> > > To: <[email protected]>
> > > Cc: <[email protected]>
> > > Sent: Tuesday, November 29, 2011 7:32 PM
> > > Subject: [AVTCORE] Types of monitoring architectures; RE: 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?
> > >
> > > [Qin]:
> > > Albrrecht, if you follow ealry list discussion on
> > > draft-hunt-avt-monarch-01, you will see the rough consensus
> > > to position this document was
> > > this daft should focus on guidelines for defining reporting
> > > blocks. That is to say the main purpose of MONARCH draft
> is how to
> > > provide guidelines for the development of new RTCP XR block
> > > types in XRBlock working group.
> >
> > [ABS] ... then the title "monitoring architectures" is misleading.
> > Proposal: keep title, revise scope section on focus
> >
> > [Qin]: No, the title is *RTP* monitoring architecture, we can
> > not expand scope into IP monitoring architecture.
>
> [ABS] That's wasn't the intent! Did just focus on the key word.
>
> >
> > >
> > > Therefore how and where to collect the metric from RTP
> > > endpoint is not scope of this document, in my opinion. since
> > > you may have many ways to do this and different vendors have
> > > their different appoaches. It will be better to leave this
> > > beyond the scope. But you are right, it will be more
> > > reasonable to measure QoE related performance metric at the
> > > RTP receiver.
> >
> > [ABS] I would disagree. At least your statement should be
> > conditional, sth like
> > "QoE related performance metrics may be measured in a RTP
> > receiver, IF the RTP receiver function is located in user
> > equipment (e.g. IP terminal), because QoE performance metrics
> > are tightly coupled to the point of view of a 'user'.
> > ... IF NOT, then ..."
> >
> > [Qin]: I am not sure user equipment or IP terminal is the
> > right term from RTP perspective.
> >
> > Also if you read P.NAMS, P.NAMS model for calculating QoE
> > related metric can be placed either at the network or at the client.
> > So I disagree with what you said.
>
> [ABS] Not convinced at all.
> Guess you are referring to the "mid-point" models, right?
> The usage of such that models depends on "prior knowledge
> ..." information.
> Thus, the applicability is conditional. You may not make such
> a general statement.
>
>
> >
> > Also as I said, how and where to collect the metric from RTP
> >  endpoint is not scope of this document. It depends on the
> > model you are choosing, e.g., four operation modes specified
> > in P.NAMS.
> > Apparently this should not be specified again in RTP
> > monitoring architecture document.
> >
> > >
> > > Another point is it is not clear to me how RTP monitoring has
> > > to do with architectureend to end IP network architecture .
> > > this draft mostly focus on discussing RTP level stuff.
> > > Therefore I am quite doubt that we should describe anything
> > > in this document like how
> > > RTP entties is mapped into network entities/nodes at the IP layer.
> >
> > [ABS] I don't got any problems to talk about architectural
> > framework for monitoring in this document. Such information
> > is required and this is the only IETF AVT doc about it.
> > The solution to this issue is rather simple to me:
> > - split the MONARCH "monitoring architecture" in
> > 1) a functional monitoring architecture (let's call it 'FMA') and
> > 2) a physical monitoring architecture (... 'PMA').
> >
> > - the present MONARCH doc would describe the FMA at the level
> > of RTP entities (i.e., Fig. 1 entities, incl. all the RTP
> > topology components according RFC 5117)
> >
> > - there are many options of functional-to-physical mappings,
> > i.e. how a FMA would be mapped on a PMA
> > - the mapping is typically dependent on considered network
> > architecture (like SIP, H.323, MGCP, IMS, wireless, etc networks)
> >
> > - the present MONARCH doc would describe the FMA-to-PMA
> > mapping IF all RTP receiver/sender entities would be located
> > in physical IP terminals (UEs)
> > - etc
> >
> > [Qin]: I can understand your point, but you can not do that.
> > Since this document is only focus on *RTP* monitoring
> > architecture, that is what it said in AVTCore milestone:
> > "
> >
> > Goals and Milestones:
> >
> >   Feb 2011 - Submit Monitoring Architecture for RTP for
> Informational
> >
> > "
>
> [ABS] If you go back to my first email on this subject, and
> if you look at my proposal: that's not a lot, nothing which
> violates the charter, goals and milestones.
>
>
> > Also if you really don't see how to map FMA to PMA, you may
> > look at the P.NAMS models specifed in ITU-T P.NAMS.
> > As for how to use RTP monitoring architecture or RTP XR
> > Report in the IMS network architecture, you may look at:
> > http://tools.ietf.org/html/rfc6035
>
> [ABS] That's the SIP reporting interface, i.e., applicable
> primarily for physical IP user equipment with embedded RTP
> sender/receiver function and SIP UA function.
> However, the applicability of RFC 6035 is limited for a
> SIP-to-PSTN gateway (because the RTP sender/receiver would be
> located NOT in user equipment. Also the P.NAMS mid-point
> model fails for such a scenario.
>
> > ITU-T H.248.48.
> > But I haven't check the current status of H.248.48.
>
> [ABS] Work is finalized, see
> http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T09-SG16-1
> 11121-TD-PLEN-0419
>
> >
> > >
> > > But as the author of this document, I am interested and open
> > > to other opinions.:-)
> >
> > [ABS] Like to add a further aspect: a "functional monitoring
> > architecture" may be considered as a network overlay,
> > something which adds additional capabilities (here:
> > measurement services, reporting services on top of basic RTP
> > services).
> > Such an overlay concept is nothing new: e.g., the
> > MultiService Forum did define a "Performance Measurement &
> > Monitoring (PMM)" overlay network, or IETF RMON may be also
> > considered as such.
> >
> > >
> > > > 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
> > > >>
> > > > _______________________________________________
> > > > Audio/Video Transport Core Maintenance
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/avt
> > >
> > =
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email protected]
> https://www.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt