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

Benoit Claise <bclaise@cisco.com> Wed, 21 January 2015 09:21 UTC

Return-Path: <bclaise@cisco.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 502AE1A0E10; Wed, 21 Jan 2015 01:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.91
X-Spam-Level:
X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 jIcMyLofoc-f; Wed, 21 Jan 2015 01:21:14 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96621A0BE8; Wed, 21 Jan 2015 01:21:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67877; q=dns/txt; s=iport; t=1421832074; x=1423041674; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=zeo4Rn4Oxz1pAuufvk+jPrVy+m4lDW70U4yZY9vTQt8=; b=A+3nfPE20dF/q5L+RXF+noZkJQYS2wrN+ihfKhYtNwcoGZA4LOuhlCnw 67qPKw1PJ69eP/dpuiDhcDg75zeZk9A0j+zZsFmTendF+z8W7GuhDzNsE 0fKGARP/U2yEXZ0SF40J8I4iZldRw972kSCxy25kSJvYOGAcov4ptlFYx U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQEAFJuv1StJssW/2dsb2JhbABbFoItgRVYxhyFdQKBZAEBAQEBfYQMAQEBAwEtRQYBBQsLEQQBAQEJFgEBAgQHCQMCAQIBNAkIBg0BBQIBARuIBQgN0HUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxcLBgFQBgEJhCAFjHqFJoVQgRQ2gkaCHyGFbIIxgz0igVtXgT09MQGBAwgXgSABAQE
X-IronPort-AV: E=Sophos;i="5.09,440,1418083200"; d="scan'208,217";a="320891565"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Jan 2015 09:21:11 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0L9L9mI030171; Wed, 21 Jan 2015 09:21:09 GMT
Message-ID: <54BF6F85.1020105@cisco.com>
Date: Wed, 21 Jan 2015 10:21:09 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Huangyihong (Rachel)" <rachel.huang@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>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB862C0B35@nkgeml501-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------040003010902020603040109"
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/yrTEO9ljafGms_9K-q3sa4PdDzo>
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:21:18 -0000

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; 
> 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 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, 1^st    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, 3^rd    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 inhttp://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>
>