Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-09

["Roni Even" <[e-mail]>]

Hi Magnus,
As far as I remember section 3 was written to provide general information
about the usage of the monitoring reports and not to address specific
solutions for conveying the information. I see no problem with mentioning
the RTP MIB but note that there was a milestone in the past to update it and
there was no interest in doing it.
I think that the updated -10 version provides enough information. 

Roni Even

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Magnus Westerlund
> Sent: Wednesday, February 15, 2012 3:57 PM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Comments on draft-ietf-avtcore-monarch-09
> 
> Hi,
> 
> As a WG chair I got the request to start a WG last call on this
> document. I have been a bit slow to get to this, but when I looked at
> the document before starting the WG last call I think the document
> isn't really ready for a WG last call. Thus instead I request that the
> WG helps develop the document to be ready for WG last call.
> 
> The main issue I see with this document is focused on section 3 which
> is intended to provide an overview of the monitoring architecture for
> RTP.
> I see a number of issues with this section and especially figure 1.
> 
> 1. Figure one fails to place third party monitor in relation to any of
> the packet flows. I think they belong on the RTP/RTCP paths between the
> sender, intermediate and the receiver.
> 
> 2. I think the document needs to discuss a bit about how the
> information flows from the different nodes to the management systems.
> There is an arrow 5 from the RTP sender to the management system. First
> of all I think this arrow should be separated from the other 5. In
> addition I think there should exist arrows from the Third party
> monitor, the monitor in the intermediate and receiver directly to the
> management systems. And these arrows could be RTCP information being
> forward in real-time. However, they could also be other solutions.
> 
> 3. In general I think 3.1 should discuss what exist already for
> monitoring which there is no discussion. Like the RTP MIB. I can also
> see other solutions like using IPfix to capture a packet flow and then
> process using an RTP and RTCP receiver.
> 
> 4. The document argues for RTCP XR based monitoring, but can you please
> provide a clear indication of what the benefits are.
> 
> Below is a number of issues I found
> 
> 5. Title: "Monitoring Architectures for RTP" is the plural in
> architectures intentional? If, you better have the document live up to
> that. The abstract doesn't appear to match that either.
> 
> 6. Section 1.
>   "As more users and subscribers rely on real time application
> services,
>    uncertainties in the performance and availability of these services
>    are driving the need to support new standard methods for gathering
>    performance metrics from RTP applications."
> 
> What users and subscribers are you discussing above? The ones using RTP
> to build services or the actual user of the service using RTP?
> 
> 7. Section 1, These rapidly emerging
>    standards, such as RTCP XR [RFC3611]
> 
> Please expand abrivetations on first usage. And in this case I think
> the correct title should be used prior to the reference ... such as
> "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611] ...
> 
> 8. Section 1. " Quality of Experience (QoE)." Can you please include
> some reference that explains the concept of QoE?
> 
> 9. Section 1: "Since different applications layered on RTP may have
>    some monitoring requirements in common, therefore these metrics
>    should be satisfied by a common design."
> 
> The above sentence needs to be reformulated.
> 
> 10. Section 2: Section title doesn't match content.
> 
> 11. Section 2: One example of such metrics is the QoE Metric
>       specified in QoE metric reporting Block [MQ].
> 
> I don't think that reference is a good example. The reference defines
> how to transport and identify a large number of application level
> metrics in RTCP XR, rather than being an example of a metric.
> 
> 12. Section 2:
> Composed metrics
> 
>       Metrics that are calculated based on direct metric or combination
>       of direct metric and derived metrics.
> 
> What is an derived metric? Appears to be an reference without an
> explanation.
> 
> 13. Section 2:
>    Interval metrics
> 
>       It is referred to as the metrics of which the reported values
>       apply to the most recent measurement interval duration between
>       successive metrics reports
> 
> Is "interval duration" actually good English? To me the duration of an
> interval is the actual interval.
> 
> 14. Section 2:
>    Sampled metrics
> 
>       It is referred to as the metrics of which the reported values
> only
>       apply to the value of a continuously measured or calculated that
>       has been sampled at end of the interval.
> 
> Doesn't the above exclude metrics measured at give instance. Or is that
> what "sampled at end of the interval" means? But then it isn't actually
> an interval, is it?
> 
> 15. Section 3.1:
> According to the definition of
>    monitor in the RTP Protocol [RFC3550], the end system that source
> RTP
>    streams, an intermediate-system that forwards RTP packets to End-
>    devices or a third party that does not participate in the RTP
> session
>    (i.e., the third party monitor depicted in figure 1) can be
>    envisioned to act as the Monitor within the RTP monitoring
>    architecture.
> 
> Shouldn't the RTP receiver be included in the above?
> 
> 16. Section 3.1: When considering the monitoring architecture, I think
> it is important to remember that we have topologies like the SSM, where
> few sources are potentially distributed to many receivers and where
> feedback is aggregated in feedback targets for potential processing and
> filtering back upstream.
> 
> 17. Section 3.2:
>    o  RTCP NACK is used to provide feedback on the RTP sequence number
>       of the lost packets [RFC4585].
> 
> In this case I would be a bit careful. Because the sequence numbers
> reported on in NACK may in fact be a subset of all lost packets.
> Already the media stream receiver creating NACK requests may in fact
> filter on which sequence number is reported. There was a proposal for a
> informative block (draft-ietf-avt-rtp-selret-05.txt) that allowed for
> this type of information. There is other cases where a receiver will be
> able to determine that it doesn't need to ask for some lost packets.
> 
> 18. Section 3.3:
> For instance, application level metrics for QoE
>    related performance parameters are usually measured at the user
>    device in the home network.
> 
> I think you need to be careful with "usually" here. There is a lot of
> hidden assumptions going into this sentence. I would recommend that one
> attempts to be more objective and less assuming in the description.
> Also there is a question what definition you have of a given location.
> Like the home network which might look significant different depending
> on where and whos network you look at.
> 
> 19. Section 4:
> o  Using large block.
> 
> I think "large" is a bad term, when you in reality are talking about
> compound or aggregated metrics blocks. I would suggest picking some
> other term and ensure that "large" isn't used in this meaning.
> 
> 20. Section 4:
> "It may be also fixed across multiple RTP sessions from
>       the same source. "
> 
> I think the above is missing "at the same time".
> 
> 21. Section 5.1:
> To avoid this pitfall, this memo proposes the use of small RTCP XR
>    metrics blocks each containing a very small number of individual
>    metrics characterizing only one parameter of interest to an
>    application running over RTP.
> 
> This one is similar with 19. Instead of small, maybe single metric or
> something like this.
> 
> 22. Section 5.2:
> non- RTP-based / non-RTP-based
> 
> 23. Section 5.3:
> This memo proposes to
>    define a new XR Block that will be used to convey the common time
>    period and the number of packets sent during this period [MI].
> 
> "this memo" is reference the monarch document no the MI, which I think
> is the intention.
> 
> 24. Section 5.3:
>  If
>    the measurement interval for a metric is different from the RTCP
>    reporting interval, then this measurement duration in the [MI]
> SHOULD
>    be used to specify the interval.
> 
> New RTCP XR metric blocks that rely
>    on the Measurement information block [MI] MUST specify the response
>    in case the new RTCP XR metric block is received without an
>    associated measurement information block;
> 
> Normative statements? in a informative draft. Is the intention to quote
> the drafts text, then please make it a quote.
> 
> 25. Section 6.
> This implies the creation of a subsidiary namespace to
>    enumerate the PDV metrics which may be transported by this block, as
>    discussed further in [PDV] .
> 
> I would like to note that this assume a certain simularity in metric
> structure that allows the different metrics values to be carried in the
> same basic structure.
> 
> 26. I have also noted a number of cases where the "." is not in the
> appropriate place, often additional space before the ".".
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt