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

Qin Wu <> Fri, 21 October 2011 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9630D21F8B77 for <>; Fri, 21 Oct 2011 02:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4DbS1wKKrcHw for <>; Fri, 21 Oct 2011 02:05:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA2B121F8B75 for <>; Fri, 21 Oct 2011 02:05:22 -0700 (PDT)
Received: from (szxga04-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Fri, 21 Oct 2011 17:03:24 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Fri, 21 Oct 2011 17:03:24 +0800 (CST)
Received: from ([]) by (MOS 4.1.9-GA) with ESMTP id AEP44032; Fri, 21 Oct 2011 17:03:24 +0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 21 Oct 2011 17:03:18 +0800
Received: from w53375q ( by ( with Microsoft SMTP Server (TLS) id; Fri, 21 Oct 2011 17:03:14 +0800
Date: Fri, 21 Oct 2011 17:03:14 +0800
From: Qin Wu <>
X-Originating-IP: []
To: Magnus Westerlund <>, IETF AVTCore WG <>,
Message-id: <>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Oct 2011 09:05:26 -0000

I will respond to your comments and update the draft soon.

----- Original Message ----- 
From: "Magnus Westerlund" <>
To: "IETF AVTCore WG" <>rg>; <>
Sent: Friday, October 21, 2011 3:36 PM
Subject: Comments on draft-ietf-avtcore-monarch-04


I have reviewed the monitoring architecture draft and have the following
comments. The review was to see if the document was ready for WG last
call. My collected judgment is still some work to do.

1. Abstract: Instead of "... , as proposed in RFC5968." please write out
the documents title. This should be done in more places where using

2. Section 1.
"  These rapidly emerging
   standards, such as RTCP XR [RFC3611]and other RTCP extension to
   Sender Reports(SR), Receiver Reports (RR) [RFC3550]are being

There is quite a lot of places in the draft where there is missing
spaces. In the above example I am missing spaces at "[3611]and",
"Reports(SR)" and "[RFC3550]are".

3. Section 1, third paragraph
"QoS/QoE" please expand acronyms on first usage.

4. section 3.
  "Monitor is a functional component defined in RFC3550 that acts as a
   source of information gathered for monitoring purposes. It may also
   collect statistics from multiple source, stores such information
   reported by RTCP XR or other RTCP extension appropriately as base
   metric or calculates composite metric."

Grammer in the above looks strange. First, isn't it "a" or "the"
monitor? Secondly, "stores" looks wrong.

5. Section 3.
"does not participate RTP session"

Missing "in the" RTP session?

6. Section 3, figure 1:
The "third party monitor" and the monitor in the management system box
both seems strange. The management system monitor would more be a
"report collector" or something like this than an actual monitor of the
RTP sessions traffic. Similarly the third party monitor needs to on the
media path as I understand it. What I can interpret from the definition
in RFC 3550 the third party monitor sees the RTP and RTCP traffic but is
not making itself visible to the RTP Session participants. Thus I think
the figure needs to be changed to make the third party monitor to get
the "1" arrow through itself.

7. Section 3.1:

Isn't the first bullet "transport level statistics" actually part of the
sentence prior to the bullet list?

8. Section 3.1:
Missing spaces

"Feedback [RFC4585]extends the standard A/V Profile[RFC3551]"
"and signalchanges in the desired"
Section 4: "multicast
      inference of network characteristics(MINC)"

9. Section 4:
"It is also
      fixed across multiple RTP sessions from the same source."

I interpret "source" in the above as an end-point or RTP node. Which
causes me to have the following comment.

This is very commonly true, but not universally true. As CNAME
identifies a synchronziation context, a given end-point could have media
sources that belong to multiple synchronization contexts in the same
session. For example have microphones and cameras from multiple rooms,
where each room will be its own synchronization context.

10. Section 4, bullet 2: Title for RFC 6035 reference

11. Section 4, bullet 3:
     "However in some cases, Identity information may be
      not part of metric and include information more than the SSRC in
      the metric block, e.g., when we set a metric interval for the
      session and monitor RTP packets within one or several consecutive
      metric interval, extra identity information (e.g., sequence number
      of 1st packet) is expected, if we put such extra identity
      information into each metric block, there may be situations where
      an RTCP XR packet containing more than two metric blocks including
      the duplicated extra identity information, reports on the same
      streams from the same source. each block have the same extra
      identity information for measurement, if each metric block carry
      such duplicated data for the measurement, it leads to redundant
      information in this design since equivalent information is
      provided multiple times, once in *every* metric block."

This is one of the longest sentences I have seen. It also has a stray
"." in it. Please do something with this to make easier to grasp.

12. Section 4. bullet 3:
This issues does not have a recommendation in the next section. I think
we should document the WG consensus on this issue. Even if it was that
this issue wasn't significant enough to do something about. Or am I
remembering the WG consensus wrong?

13. Section 4:
      this ensures immunity to packet loss, the design may bring more
      complexity and the overhead is not completely trivial in some

Can you please explain what "complexity" the above refers to?

14. Section 5.1

I think the section title should be changed to: "Using Single Metric Blocks"

15. Section 5.1. I would suggest that one replaces "small blocks" with
single metric blocks.

16. Section 5.2:
"(in gateway),e.g., one RTCP XR Packet"

To many commas?

17. Section 5.2:
"SSRC of source" missing "the"?

18. Section 5.2:
 A flow measurement tool that is not call-aware
   then forward the RTCP XR reports along with SSRC of the measured RTP
   stream which is included in the XR Block header to the network
   management system.  Network management system can then correlate this
   report using SSRC with other diagnostic information such as call
   detail records.

I guess the flow measurement tool is configured with the 5-tuple and
that its reports to the management system using a binding to that
5-tuple when reporting. Should this be mentioned?

19. Section 6.
The PDV reference is "work in progress" but you don't need to repeat it
at all the places. And in fact, if you just do a normal informational
reference to the internet draft the RFC-editor will add the "work in
prgoress" in the reference list.

20. Section 6.
"jit" field. To my knowledge the field you reference are named
"interarrival jitter" in the RFC 3550 RTCP report block structures.

21. Section 7.1:

Strictly the RTP end
   system can only conclude that its RTP has been lost in the network,
   though an RTP end system complying with the robustness principle of
   [RFC1122] should survive with essential functions unimpaired.

What is the purpose with this sentence? And what is actually seen as
"essential functions"?

22. Section 7.2:
For bidirectional unicast, an RTP system may usually detect RTCP XR
   from a translator by noting that the sending SSRC is not present in
   any RTP media packet.

So the assumption here is that the translator has its own SSRC to send
these monitoring reports. But, how does an RTP node determine that an
SSRC is associated with a translator rather than a receiver only
end-point? From a session participant I don't think you can determine if
a give SSRC is a receiver or just a monitor. They will not look
different. One needs session configuration information, and in that case
configuration information where the translator announces its node type
to the management system.

23. Section 8. I agree that this draft shouldn't have a IANA
Consideration other to say that it is has no actions. However, I think
the document should consider if it has some guidance on IANA actions for
the monitoring architecture. Some part of this is clearly about the
consumption of XR block code points that isn't a major issue. And if we
do run out a second RTCP packet type for XR block 2 could be assigned.

24. Section 9.
I think this security consideration should be have some actual
considerations. This is an architecture document for monitoring. Thus
collecting the security issues with monitoring do sound like a good
idea. For example privacy and leaking information. Need for having
protection of the monitoring reports etc.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: