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

Alissa Cooper <alissa@cooperw.in> Fri, 20 February 2015 00:08 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: expand-draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@virtual.ietf.org
Delivered-To: xrblock@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id ADCF31A1A66; Thu, 19 Feb 2015 16:08:36 -0800 (PST)
X-Original-To: xfilter-draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC541A1A78 for <xfilter-draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietfa.amsl.com>; Thu, 19 Feb 2015 16:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level:
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 G1SMk1fcCyFa for <xfilter-draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietfa.amsl.com>; Thu, 19 Feb 2015 16:08:33 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABA41A1A66 for <draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietf.org>; Thu, 19 Feb 2015 16:08:33 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EE7C32092E for <draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietf.org>; Thu, 19 Feb 2015 19:08:32 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 19 Feb 2015 19:08:32 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=KCgnmA6V+fLN+09c C+yClrG2ooY=; b=CUMj9eNzUqLGMpNQFtEvTazc30wZFGnHaOKGezB/EASjHElq cVGSbAdTmH42ZQHA7/6XtSsWoR/aYgscztdT9sCutR9a3D9IXdrrt+zUXXdf1U64 GK7MQ5xXpC3kruMR+aOpnKJ55m1WdAqIi7PJAvQTjBD6yzVojDWJwVX6aPE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=KCgnmA6V+fLN+09cC+yClrG2ooY=; b=C/o48mUK0G5PcjT8GvsL dWpMvwG+a5a4DPLJepo11myh+l5dDgAWAQe/cTViQgCxtQvX6tm3cNtieipxkiCZ /cRcLfpy7IRJ9dtKyIOI20O/Cv2cOhETmpmRYwBQfu0jMIGI6KA6JHYvrFwK1uAj /VbBg0tk0CriXHB//8V+g7o=
X-Sasl-enc: r0pr+n2nZCD4rOYqZFD1UY8ya7gY0NGG+cNYDzw/bT+F 1424390912
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id A517BC002A6; Thu, 19 Feb 2015 19:08:30 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E038BFE9-FA79-4869-852F-10A8D0EB5BA2"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <D8D0E465-9579-40FE-A5CC-0BC242A83FA4@comnet.tkk.fi>
Date: Thu, 19 Feb 2015 16:08:28 -0800
Message-Id: <E6F872CD-F0E1-4182-A0E6-5D326179C118@cooperw.in>
References: <20150216091455.22596.26011.idtracker@ietfa.amsl.com> <4D63769E-E2DC-43B9-B35A-EF4CE0A0544E@comnet.tkk.fi> <54E1BE8B.8080200@cisco.com> <880EC1F3-10AA-454B-82F8-11377FC2512D@comnet.tkk.fi> <54E31664.4000506@cisco.com> <D8D0E465-9579-40FE-A5CC-0BC242A83FA4@comnet.tkk.fi>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/trh5G0uGL6M_Dd0n13vcA-ybSd4>
Cc: xrblock-chairs@ietf.org, draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@ietf.org, Varun Singh <varun@comnet.tkk.fi>, IESG <iesg@ietf.org>, xrblock@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: Fri, 20 Feb 2015 00:08:36 -0000

Hi Benoit,

Are you able to clear based on the -11?

Thanks,
Alissa

On Feb 17, 2015, at 2:33 AM, Varun Singh <varun@comnet.tkk.fi> wrote:

> Thanks Benoit for the feedback. -11 will fix the text.
> 
>> On 17 Feb 2015, at 12:22, Benoit Claise <bclaise@cisco.com> wrote:
>> 
>> On 16/02/2015 13:32, Varun Singh wrote:
>>> 
>>>> 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> 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.
>> I believe I now understand the source of confusion.
>> I understood "This metric MUST NOT count the lost packets for which repair might still be possible" as "This metric MUST NOT be calculated until the repair mechanism has done its job."  
>> Based on my understanding, this was preventing the implementation of the Interval report, i.e. align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs... unless you were sure the repair mechanism was over.
>> 
>> The addition of your example above would be beneficial to the draft IMO, on top of the new text proposed by Rachel  in our private conversation (and which aligns with your sentence below)
>> 
>> “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. So if implementations want these packets to be reported as repaired, they MUST NOT align the begin_seq and end_seq to the RTCP intervals.”
>> 
>> 
>>> If implementations want to report these packets as repaired they MUST NOT align the begin_seq and end_seq to the RTCP intervals.
> 
>