Re: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Fri, 09 January 2015 01:55 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD71A7022; Thu, 8 Jan 2015 17:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ2PEhFTQwRI; Thu, 8 Jan 2015 17:55:03 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0501C1A1A32; Thu, 8 Jan 2015 17:55:02 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRA60385; Fri, 09 Jan 2015 01:55:01 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 Jan 2015 01:54:59 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 9 Jan 2015 09:54:52 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, The IESG <iesg@ietf.org>
Thread-Topic: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)
Thread-Index: AQHQKdg7xzQOTyCZ9k65QKNKUxQ9mJy1Ud/wgACCQoCAASjt4A==
Date: Fri, 09 Jan 2015 01:54:50 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862A4BF6@nkgeml501-mbs.china.huawei.com>
References: <20150106174254.24975.89051.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB862A4801@nkgeml501-mbs.china.huawei.com> <54AEA0CB.2040207@cisco.com>
In-Reply-To: <54AEA0CB.2040207@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.144]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/nPRgYa_vPnHmje1usBVXK5S8EVA>
Cc: "xrblock-chairs@tools.ietf.org" <xrblock-chairs@tools.ietf.org>, "draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org" <draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org>, "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 01:55:06 -0000

Hi Benoit,

Please see inline.

BR,
Rachel


> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Thursday, January 08, 2015 11:23 PM
> To: Huangyihong (Rachel); The IESG
> Cc: xrblock-chairs@tools.ietf.org;
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org;
> xrblock@ietf.org
> Subject: Re: [xrblock] Benoit Claise's Discuss on
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and
> COMMENT)
> 
> Hi Rachel,
> > Hi Benoit,
> >
> > Thank you for the comments. Please see my replies inline.
> >
> > BR,
> > Rachel
> >
> >
> >> -----Original Message-----
> >> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Benoit
> >> Claise
> >> Sent: Wednesday, January 07, 2015 1:43 AM
> >> To: The IESG
> >> Cc: xrblock-chairs@tools.ietf.org; xrblock@ietf.org;
> >> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org
> >> Subject: [xrblock] Benoit Claise's Discuss on
> >> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS
> >> and
> >> COMMENT)
> >>
> >> Benoit Claise has entered the following ballot position for
> >> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: Discuss
> >>
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> http://www.ietf.org/iesg/statement/discuss-criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repai
> >> r-loss-count
> >> /
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> DISCUSS:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >> 1. post-repair loss count: 16 bits
> >>
> >>        Total number of packets finally lost after applying one or more
> >>        loss-repair methods, e.g., FEC and/or retransmission, during the
> >>        actual sequence number range indicated by begin_seq and
> end_seq.
> >>        This metric MUST NOT count the lost packets for which repair
> might
> >>        still be possible. Note that this metric MUST measure only primary
> >>        source RTP packets.
> >>
> >> I see the MUST above, and the RECOMMENDED below.
> >>
> >>     Thus it is RECOMMENDED that this report block should be generated
> >>     only for those source packets that have no further chance of being
> >>     repaired and not for any other packets. This block needs to specify
> >>     its own measurement period to avoid ambiguity in calculating the
> >>     post-repair loss count.
> >>
> >> I was expecting a MUST instead of RECOMMENDED.
> >> Did the WG discuss that point?
> >> In which situation would you need this exception, and what could you
> >> actually deduce if you apply it?
> > [Rachel]: We haven't given it some careful thought until you brought it up. But
> we agree that this is a issue of inconsistency. So I propose to change the
> RECOMMEND sentence into following:
> > " Accordingly, only packets that have no further chance of being repaired are
> included in this report block. This block needs to specify its own measurement
> period to avoid ambiguity in calculating the post-repair loss count."
> > Will it make sense to you?
> Yes, thanks.
> >
> >>
> >> 2. Question:
> >>     The relationship
> >>     between the metrics in this report block and the pre-repair loss
> >>     metric of RTCP XR could be expressed in the following formula:
> >>
> >>        cumulative number of packets lost = post-repair loss count +
> >>        repaired loss count + to be repaired lost packet
> >>
> >>     "cumulative number of packets lost" is the metric from RTCP SR/RR.
> >>     "post-repair loss count" and "repaired loss count" are the metrics
> >>     defined in this draft.
> >>
> >> Am I correct that it's difficult (if not impossible) to compare those
> >> values with a small granularity because:
> >> 1. RFC 3550 section 6.4.1 SR: Sender Report RTCP Packet sends the
> >> "cumulative number of packets lost" with timestamps 2.
> >> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count sends "post-repair loss
> count"
> >> and "repaired loss count" with sequence numbers.
> >> On top of that, the intervals are different!
> > [Rachel]: The Report Blocks in SR and RR packets give the cumulative number
> of packets lost, and the sequence number range of the interval (by comparing
> the extended highest sequence number received fields on consecutive packets).
> See RFC 3550 section 6.4.4.
> Ok, I overlook this "extended highest sequence number received", but this is
> just one boundary of the interval.

[Rachel]: Another boundary of the interval is the sequence number 1. 

> > The XR report block defined in this document has explicit sequence number
> ranges. The sender of the XR reports can ensure it match the SR/RR packet
> sent in the same compound RTCP packet. Given this, they will be comparable.
> We could recommend this is done in the update.
> If you chose to do so, does it imply that the SR/RR will be sent with a little of
> delay (due to the FEC)?

[Rachel]: No, it doesn't have to be. The begin_seq could be set to 1, but the end_seq could be set to the sequence number of packet which is the last one applied repair mechanisms and smaller than extended highest sequence number received. Thus, it can be still compared:
     to be repaired lost packet = cumulative number of packets lost - post-repair loss count - repaired loss count.
Where " still to be repaired lost packet " is in the range of from end_seq to extended highest sequence number received.

> > It's also possible to send this XR report block and SR/RR reports with different
> intervals, in which case they won't be easily comparable.
> > Maybe we should add some clarification words in the next version.
> Thanks.
> 
> Regards, Benoit
> >
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> COMMENT:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >> - The abstract mentions:
> >>     This document defines an RTP Control Protocol (RTCP) Extended
> Report
> >>     (XR) Block that allows reporting of post-repair loss count metrics
> >>     for a range of RTP applications.
> >>
> >> This draft introduces two metrics: post-repair loss count and
> >> repaired loss count This is slightly confusing.
> >> I believe you want to include the two metrics in the abstract.
> >> Alternatively:
> >> NEW:
> >>     This document defines an RTP Control Protocol (RTCP) Extended
> Report
> >>     (XR) Block that allows reporting of post-repair loss-related metrics
> >>     for a range of RTP applications.
> >>
> >>
> >> -
> >>     In
> >>     addition,  another metric, repaired loss count, is also introduced in
> >>     this report block for calculating the pre-repair loss count during
> >>     the this range,
> >>
> >> the this -> chose one.
> >>
> > [Rachel]: Will do. Thanks.
> >> _______________________________________________
> >> xrblock mailing list
> >> xrblock@ietf.org
> >> https://www.ietf.org/mailman/listinfo/xrblock
> > .
> >