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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------