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

Qin Wu <> Tue, 25 October 2011 05:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1AF211E8091 for <>; Mon, 24 Oct 2011 22:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.824
X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=0.022, 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 5D9vT+NW+G8W for <>; Mon, 24 Oct 2011 22:46:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1AF3411E80DB for <>; Mon, 24 Oct 2011 22:46:36 -0700 (PDT)
Received: from (szxga03-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Tue, 25 Oct 2011 13:45:48 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Tue, 25 Oct 2011 13:45:48 +0800 (CST)
Received: from ([]) by (MOS 4.1.9-GA) with ESMTP id AEQ67998; Tue, 25 Oct 2011 13:45:47 +0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 25 Oct 2011 13:45:45 +0800
Received: from w53375q ( by ( with Microsoft SMTP Server (TLS) id; Tue, 25 Oct 2011 13:45:40 +0800
Date: Tue, 25 Oct 2011 13:45:39 +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: Tue, 25 Oct 2011 05:46:37 -0000

Hi, Magnus:
Thank for your valuable review. please see inline.

----- Original Message ----- 
From: "Qin Wu" <>
To: "Magnus Westerlund" <>om>; "IETF AVTCore WG" <>rg>; <>
Sent: Friday, October 21, 2011 5:03 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04

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

[Qin]: Okay, fixed.

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".

[Qin]: Okay, fixed in the whole document.

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

[Qin]: Fixed.

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.

[Qin]: Fixed.

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

Missing "in the" RTP session?

[Qin]: Fixed, thanks.

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.

[Qin]: Early the intention of the original text is to not differentiate the role of report collector

And report generator. But I agree with your comment and will fix this in the new version.

7. Section 3.1:

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

[Qin]: Agree, fixed.

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)"

[Qin]: Agree, fixed.

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.

[Qin]: Agree with your thinking, but here what we emphasize is "across multiple RTP session"

Does this really conflict with what you said?

Anyway I will reword this in the new vesion.

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.

[Qin]: Agree, fixed.

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?

[Qin]: Yes, the issue wasn't significant and I remembered the consensus is 

to replace tag with the SSRC and use SSRC to identify and correlate and group

 participants between reports. The sequence numbering information and

 measurement interval can be defined in a new RTCP XR block if needed, 

but is not related to identity. Therefore I will add one section to talk about how to deal with this issue.

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?

[Qin]: complexity is referred to packetization complexity.

14. Section 5.1

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

[Qin]: Okay.

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

[Qin]: Okay.

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

To many commas?

[Qin]: Okay, fixed.

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

[Qin]: Okay, fixed.

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?

[Qin]: Make sense, will add it to the next version.

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.

[Qin]: Okay.

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

[Qin]: You are right, fixed.

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"?

[Qin]: I think essential functions are referred to as "media distribution"

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.

[Qin]: That's what I want to said in part. And I agree that node type should also be announced.

I will reflect the draft to reflect this.

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.

[Qin]: The WG consensus is space depletion is not issue

if you really want space expansion, you can define one XR block type

 for vendor-specific extensions, with an enterprise number included 

to identify the vendor making the extension. So I prefer to say

"There is no IANA action in this document"

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.

[Qin]: I agree with your suggestion. Will add new text to address the 

security issue with the monitoring.


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:
Audio/Video Transport Core Maintenance