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

Varun Singh <varun@comnet.tkk.fi> Mon, 16 February 2015 12:32 UTC

Return-Path: <varun@comnet.tkk.fi>
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 89F641A1ADC; Mon, 16 Feb 2015 04:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level:
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 McN2h1nxJqLW; Mon, 16 Feb 2015 04:32:28 -0800 (PST)
Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5851A0087; Mon, 16 Feb 2015 04:32:27 -0800 (PST)
Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D294B115323_4E1E35AB; Mon, 16 Feb 2015 12:32:26 +0000 (GMT)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 4B2851152F3_4E1E35AF; Mon, 16 Feb 2015 12:32:26 +0000 (GMT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 3CD661E148; Mon, 16 Feb 2015 14:32:26 +0200 (EET)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CTTqMOL-9xi8; Mon, 16 Feb 2015 14:32:20 +0200 (EET)
Received: from [10.100.2.205] (wireless-86-50-147-16.open.aalto.fi [86.50.147.16]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 52EB31E0FC; Mon, 16 Feb 2015 14:32:20 +0200 (EET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5CC6ADE9-FE0E-45F1-8FFC-F68E18661D18"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Varun Singh <varun@comnet.tkk.fi>
In-Reply-To: <54E1BE8B.8080200@cisco.com>
Date: Mon, 16 Feb 2015 14:32:19 +0200
Message-Id: <880EC1F3-10AA-454B-82F8-11377FC2512D@comnet.tkk.fi>
References: <20150216091455.22596.26011.idtracker@ietfa.amsl.com> <4D63769E-E2DC-43B9-B35A-EF4CE0A0544E@comnet.tkk.fi> <54E1BE8B.8080200@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/2ijNkHYxfKD7XYWxcMokpTrbSNA>
Cc: xrblock-chairs@ietf.org, The IESG <iesg@ietf.org>, xrblock@ietf.org, draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietf.org
Subject: Re: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10: (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: Mon, 16 Feb 2015 12:32:31 -0000

> On 16 Feb 2015, at 11:55, Benoit Claise <bclaise@cisco.com> wrote:
> 
> On 16/02/2015 10:31, Varun Singh wrote:
>> Hi Benoit,
>> 
>> Thank you for reviewing the proposal, comments inline.
>> 
>> 
>>> On 16 Feb 2015, at 11:14, Benoit Claise <bclaise@cisco.com <mailto:bclaise@cisco.com>> wrote:
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> The following MUST versus RECOMMENDED is still an issue
>>> 
>>>  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. 
>>> 
>>> This goes against
>>> 
>>> 2. Interval report
>>> 
>>>   Some implementations may align the begin_seq and end_seq number with
>>>   the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
>>>   This is NOT RECOMMENDED as packets that are not yet repaired in this
>>>   current RTCP interval and may repaired in the future will not be
>>>   reported in subsequent reports.
>>> 
>> 
>> 
>> The not recommended is if the receiver strictly aligns the begin_seq and end_seq to 
>> the HSNs of consecutive reports.
>> Example below:
>> 
>> a) HSN is 20, begin_seq is 10 end_seq is 20.
>> b) HSN is 30, begin_seq is 20 end_seq is 30.
>> If 17 and 19 were packets lost and not yet repaired in a) and 
>> subsequently repaired in b) then it won't be reported because the 
>> sequence numbers do not belong in b)’s interval, but to the previous 
>> begin and end seq,
> But you can not do that (Interval report, i.e. align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs, as in your example) according to that sentence ": This metric MUST NOT count the lost packets for which repair might still be possible.", right? What do I miss?

I think we are in agreement. 

The paragraphs attempts to highlight that (in this particular case) when those lost packets are repaired in the next interval, they won’t be reported as repaired or lost. If implementations want to report these packets as repaired they MUST NOT align the begin_seq and end_seq to the RTCP intervals.

>> therefore it is not recommended to align the begin_seq 
>> and end_seq to HSN of consecutive RTCP reports, unless repairs occur 
>> within that interval. 
>> 
>> Hence, (hopefully the next paragraph in the section clarifies) receivers 
>> should prefer begin_ and end_seq use longer than an RTCP interval.
>> 
>> 
> Regards, Benoit