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> Wed, 21 January 2015 09:32 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 EB40C1A19EF; Wed, 21 Jan 2015 01:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level:
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 gI77T4PNlheH; Wed, 21 Jan 2015 01:32:43 -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 635071A19E5; Wed, 21 Jan 2015 01:32:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG64025; Wed, 21 Jan 2015 09:32:39 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 21 Jan 2015 09:32:36 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 21 Jan 2015 17:32:29 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Benoit Claise <bclaise@cisco.com>
Thread-Topic: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)
Thread-Index: AQHQKt3TmuSuCYaEHkGHfEXATD47wJy117MAgAA9xACACuqCAIAA+LNggAgwQDD//7JqgIAAhlhw
Date: Wed, 21 Jan 2015 09:32:28 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862C1BBF@nkgeml501-mbs.china.huawei.com>
References: <20150106174254.24975.89051.idtracker@ietfa.amsl.com> <AF745CD9-0281-46A0-B1BA-F463C65B7E13@comnet.tkk.fi> <54AEA580.6050400@cisco.com> <67EFC0DB-552D-4D0E-BBB6-DEBC87CFC1AA@comnet.tkk.fi> <54B80184.4000906@cisco.com> <51E6A56BD6A85142B9D172C87FC3ABBB862A7D96@nkgeml501-mbs.china.huawei.com> <51E6A56BD6A85142B9D172C87FC3ABBB862C0B35@nkgeml501-mbs.china.huawei.com> <54BF6F85.1020105@cisco.com>
In-Reply-To: <54BF6F85.1020105@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: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB862C1BBFnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/egWVMmHdCjguvFDLI3Z2N05uv2Q>
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>, The IESG <iesg@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: Wed, 21 Jan 2015 09:32:51 -0000
All right. I'll submit it immediately^^. BR, Rachel From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, January 21, 2015 5:21 PM To: Huangyihong (Rachel) Cc: The IESG; xrblock-chairs@tools.ietf.org; draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org; xrblock@ietf.org; Dan Romascanu Subject: Re: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT) Hi Rachel, Hi Benoit, Just ping your response. Do you think the texts we proposed below address your concern? We'll submit a new version if you're okay with these changes. Ah. Based on your last email "Varun and I are working together to bring a new version to address your concerns", I was waiting for a new draft version. I believe the changes below address my DISCUSS, but I can't say for sure. At this point, I would have to re-read the new draft version, along with the diffs. Regards, Benoit BR, Rachel From: Huangyihong (Rachel) [mailto:rachel.huang@huawei.com] Sent: Friday, January 16, 2015 9:23 AM To: Benoit Claise; Varun Singh Cc: The IESG; Tina TSOU; xrblock-chairs@tools.ietf.org<mailto:xrblock-chairs@tools.ietf.org>; draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org<mailto:draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org>; xrblock@ietf.org<mailto:xrblock@ietf.org>; Dan Romascanu Subject: RE: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT) Hi Benoit, Varun and I are working together to bring a new version to address your concerns. Please see my replies inline. BR, Rachel From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Friday, January 16, 2015 2:06 AM To: Varun Singh; Huangyihong (Rachel) Cc: The IESG; Tina TSOU; xrblock-chairs@tools.ietf.org<mailto:xrblock-chairs@tools.ietf.org>; draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org<mailto:draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org>; xrblock@ietf.org<mailto:xrblock@ietf.org>; Dan Romascanu Subject: Re: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT) Varun, Rachel, I believe that we are converging. Do I understand correctly that you want to remove the MUST NOT in "This metric MUST NOT count the lost packets for which repair might still be possible."? [Rachel]: Not exactly. What we propose in the new version is to change "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." into "Accordingly, only packets that have no further chance of being repaired are included in this report block. " Besides that, we also propose following changes: 1. Section 3, 1st paragraph, change "This packet may be stacked with other RTCP packets to form compound RTCP packets and share the average reporting interval calculated by the RTCP method described in [RFC3550]." into "The sender of this XR report can ensure it match the SR/RR packet sent in the same compound RTCP packet." 2. Section 3, 3rd paragraph, change the 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." into "still to be repaired lost packet = cumulative number of packets lost - cumulative post-repair loss count - cumulative repaired loss count "cumulative number of packets lost" is the metric from RTCP SR/RR. "cumulative post-repair loss count" and "cumulative repaired loss count" could be obtained by the way introduced in the end of this section. It is also possible to send this XR report block and SR/RR with different intervals, in which case the "cumulative number of packets lost" can't be easily compared with the post-repair metrics defined in this draft. However, the endpoint could rely on the post-repair loss count and repaired loss count to calculate the efficiency of the error resilience algorithm. " 3. Add a sub section in Section 3 after the definition of the report block structure " 3.2 Report Block Example Usage This block could be reported by the endpoint in 2 different ways: 1. Cumulative report In this case, implementations may set begin_seq to the first packet in the RTP session and remain fixed. "Post-repair loss count" and "repaired loss count" respectively equal to "cumulative post-repair loss count" and "cumulative repaired loss count". 2. Interval report Implementations may choose to use begin and end sequence number to correspond to the last RTCP interval or several RTCP intervals. If the reports are consecutive and there's no sequence number range overlap or RTCP XR packets loss, "cumulative post-repair loss count" and "cumulative repaired loss count" could be respectively calculated by sum of "post-repair loss count" and by sum of "repaired loss count". " So what do you think? What I'm missing at this point is either an OLD/NEW type of email from both of you (there were conflicting messages earlier on), or a new draft version. [Rachel]: It will be a new draft version. Regards, Benoit Hi Benoit, Comment inline. On 08 Jan 2015, at 17:42, Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>> wrote: Hi Varun, I was expecting a MUST instead of RECOMMENDED. Did the WG discuss that point? This was discussed in Vancouver IETF and decide to keep the language as close to the one in http://tools.ietf.org/html/rfc5725. Then the mistake is in RFC 5725, no? see below. In which situation would you need this exception, and what could you actually deduce if you apply it? One reason that it is not MUST is to align the end_seq to the Highest sequence number in the RTCP RR. Help me understand something. I'll repeat my question: what could you actually deduce if you apply it? I thought the goal was it the reverse. This metric MUST NOT count the lost packets for which repair might still be possible. Therefore you have to wait until all repair mechanisms have done their jobs. >From there, you send this block. One reason for synchronising the intervals of the XR end_seq and the RR's HSN is, there is no ambiguity in calculating the number of packets that are yet to be repaired: still to be repaired lost packet = cumulative number of packets lost - post-repair loss count - repaired loss count. The first is reported in the RR, the other two are in the XR, and this only works if the begin_seq points to the first packet in the session. The "still to be repaired lost packets" can help the sender adapt the FEC interval i.e., generate fewer or more FEC packets. If it were a MUST, then the end_seq will be a value smaller than the HSN unless the endpoint generates the RR+XR when all the FEC packet for an interval have arrived. Alternatively, applications that are not concerned about the "still to be repaired packets" instead wish to compare post-repair loss with repaired loss count may prefer to count only those packets for which all the FEC packets are available. For example, this information can help switch between error-repair schemes. And, if you want to better align the intervals, you align the end_seq to the Highest sequence number in the RTCP RR. Yes, and if the endpoint does not have all the FEC packet that covers the HSN, it won't be able to align the interval. 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 The RR has a highest sequence number, the cumulative lost is from the beginning of the session. Ok. The XR can point the first sequence received to begin_seq and HSN to the end_seq and then values in the RR and the XR are synchronized. Ok, I completely missed that from the draft. Do you think we need to add some examples? 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! I think this is an implementation concern. It is possible for the endpoint to report 1. Cumulatively, begin_seq points to the first packet Is this covered in the draft? I read: This packet may be stacked with other RTCP packets to form compound RTCP packets and share the average reporting interval calculated by the RTCP method described in [RFC3550<http://tools.ietf.org/html/rfc3550>] When comparing this metric with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as noted in [RFC5725<http://tools.ietf.org/html/rfc5725>] Some packets will not be repaired in the current RTCP interval, but could be repaired later. Specifically the "average reporting interval". I could not have deduced that the begin_seq could remain 1 for all "intervals". It is possible to keep it fixed. Further due to the unreliability of RTCP, many implementations pick begin_seq that spans across multiple reporting intervals. Further, the description of begin_seq does not limit the application, but does it need clarification? begin_seq: 16 bits The first sequence number that this block reports on. We can add: The first sequence number that this block reports on. It can remain fixed when calculating metrics over several RTCP reporting intervals. 2. Interval, begin_seq points to the HSN of the previous RTCP RR In which case the XR and the RTCP RRs are the same intervals However, it is correct that if the begin_seq and end_seq report on different intervals than the RTCP rr then the cumulative loss reported in the RR won't match the XR. However, in these cases the endpoint would need to rely on the post-repair loss count and repaired loss count to calculate the efficiency of the error resilience algorithm. I believe this needs some clarifying text. Thanks for engaging. Regards, Benoit --- http://www.netlab.tkk.fi/~varun<http://www.netlab.tkk.fi/%7Evarun>
- [xrblock] Benoit Claise's Discuss on draft-ietf-x… Benoit Claise
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Huangyihong (Rachel)
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Benoit Claise
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Benoit Claise
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Huangyihong (Rachel)
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Varun Singh
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Varun Singh
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Benoit Claise
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Huangyihong (Rachel)
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Huangyihong (Rachel)
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Benoit Claise
- Re: [xrblock] Benoit Claise's Discuss on draft-ie… Huangyihong (Rachel)