Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
Qin Wu <bill.wu@huawei.com> Wed, 09 November 2011 02:29 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0018221F8541 for <avt@ietfa.amsl.com>; Tue, 8 Nov 2011 18:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.26
X-Spam-Level:
X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=1.339, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpd0FRsf-H1F for <avt@ietfa.amsl.com>; Tue, 8 Nov 2011 18:29:32 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 978BD21F853E for <avt@ietf.org>; Tue, 8 Nov 2011 18:29:31 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00FE8G70VE@szxga04-in.huawei.com> for avt@ietf.org; Wed, 09 Nov 2011 10:28:12 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00E6UG6P7M@szxga04-in.huawei.com> for avt@ietf.org; Wed, 09 Nov 2011 10:28:12 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX39948; Wed, 09 Nov 2011 10:28:10 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 10:28:05 +0800
Received: from w53375q (10.138.41.130) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 10:28:02 +0800
Date: Wed, 09 Nov 2011 10:28:01 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, avt@ietf.org
Message-id: <D4F9E6B3BC3745B88BEC14D88B9A4AD5@china.huawei.com>
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: 7bit
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C05B4B569@xmb-sjc-234.amer.cisco.com> <C7E873DD2F574ACCA02F6CCABE05B4E5@china.huawei.com> <E1CBF4C7095A3D4CAAAEAD09FBB8E08C05B4B798@xmb-sjc-234.amer.cisco.com> <3FEED5DF800D44DEA994B421F053578B@china.huawei.com> <E1CBF4C7095A3D4CAAAEAD09FBB8E08C05B4BB1E@xmb-sjc-234.amer.cisco.com>
Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2011 02:29:33 -0000
Yes, I agree. ----- Original Message ----- From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com> To: "Qin Wu" <bill.wu@huawei.com>; <avt@ietf.org> Sent: Wednesday, November 09, 2011 1:22 AM Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-monarch-05 More inline. > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Monday, November 07, 2011 6:01 PM > To: Charles Eckel (eckelcu); avt@ietf.org > Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05 > > Hi, Charles: > ----- Original Message ----- > From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com> > To: "Qin Wu" <bill.wu@huawei.com>; <avt@ietf.org> > Sent: Tuesday, November 08, 2011 1:21 AM > Subject: RE: [AVTCORE] comments on draft-ietf-avtcore-monarch-05 > > > Hi Qin, > > Please see inline. > > > -----Original Message----- > > From: Qin Wu [mailto:bill.wu@huawei.com] > > Sent: Sunday, November 06, 2011 10:21 PM > > To: Charles Eckel (eckelcu); avt@ietf.org > > Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-monarch-05 > > > > Hi, Charles: > > Thank for your valuable comments, please see my reply below. > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com> > > To: <avt@ietf.org> > > Sent: Saturday, November 05, 2011 6:30 AM > > Subject: [AVTCORE] comments on draft-ietf-avtcore-monarch-05 > > > > > > >I read the draft and have the following comments: > > > > > > Section 2 and 3 contain some definitions. Should we add definitions > > > there for additional terms, including interval metric, cumulative > > > metric, and sampled metric. There has been some debate on the > > > definitions of these on xrblock alias, and it would be good to have > a > > > consistent definition of these terms. > > > > [Qin]: Fair, will add them into the update. > > > > > Section 3 reads, " The Metric Block exposes real time Application > > > Quality information". Section 2 defined transport level, application > > > level, and end system metrics. As such, the use of "application > quality > > > information" seems too specific and limiting to me. > > > > [Qin]: Correct, how about change as "QoS/QoE metric information". > > Works for me. > > > > > > > Section 5.2 read, There may be situation where more than one media > > > transport protocols are used by one application to interconnect to > the > > > same session in the gateway. For example, one RTCP XR Packet is > sent to > > > the participating endpoints using non- RTP-based media transport > (e.g., > > > using SIP) in a VOIP session, one crucial factor lies in how to > handle > > > their different identities that are corresponding to different media > > > transport." > > > Are we really expecting RTCP XR packets to be used outside of an RTP > > > session? Or are we trying to say there may be multiple RTP sessions > for > > > a given VoIP session, and there is a need to be able to correlate > the > > > RTCP XR packets from each of these RTP sessions with each other? > > > > > > [Qin]: Yes, this section focuses on describing correlation of RTP > session with Non-RTP > > session for monitoring purpose. You may read RFC5104 for an example > but not limited > > to this. > > I was not able to find any description of correlating RTP and non RTP > sessions in RFC 5104. > RFC 5576 defines the "ssrc" SDP attribute, but even in that case, it > usage is defined for RTP-based media only. So am I still not sure of the > use case you have in mind here. > > [Qin]: Sorry, I give you a wrong reference, it should be RFC6035. > In that case, we may need to consider how to deal different identities that corresponding to > both RTP session and SIP session. e.g., In SIP session, we may use global call identifier, > In RTP session, we may use SSRC, how to correlate with each other is the issue we may > need to look at. The solution is to use SDES item to associate SSRC of RTP stream with > global call identifier. I see. I now understand how to interpret the text within draft-ietf-avtcore-monarch. I have some concerns regarding the mechanism in RFC 6035, as the SIP Call-ID is a globally unique ID whereas the SSRC is unique per RTP session only. That is more of an issue/limitation for RFC 6035 than a concern with draft-ietf-avtcore-monarch, and draft-ietf-avtcore-monarch addresses this by mentioning the combination of CNAME and SSRC as a potential solution. Cheers, Charles > Thanks, > Charles > > > > > Nits: > > > > > > Section 4: > > > - change " may have different monitoring requirements, design large > > > block ..." to " may have different monitoring requirements. > Designing > > > large block ..." > > > - change " it is hardly to provide" to " it is hard to provide" > > > - change " block types For example" to " block types. For example" > > > - change " consecutive metric interval" to " consecutive metric > > > intervals" > > > > [Qin]: Fixed, thanks very much. > > > > > > > > Thanks, > > > Charles > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Core Maintenance > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > >
- [AVTCORE] comments on draft-ietf-avtcore-monarch-… Charles Eckel (eckelcu)
- Re: [AVTCORE] comments on draft-ietf-avtcore-mona… Qin Wu
- Re: [AVTCORE] comments on draft-ietf-avtcore-mona… Charles Eckel (eckelcu)
- Re: [AVTCORE] comments on draft-ietf-avtcore-mona… Qin Wu
- Re: [AVTCORE] comments on draft-ietf-avtcore-mona… Charles Eckel (eckelcu)
- Re: [AVTCORE] comments on draft-ietf-avtcore-mona… Qin Wu