Re: [xrblock] Mirja Kühlewind's No Objection on draft-ietf-xrblock-independent-burst-gap-discard-02: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 04 August 2016 14:26 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EEA12DA18 for <xrblock@ietfa.amsl.com>; Thu, 4 Aug 2016 07:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 83KL_5p3E-2k for <xrblock@ietfa.amsl.com>; Thu, 4 Aug 2016 07:26:16 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B80E12D95C for <xrblock@ietf.org>; Thu, 4 Aug 2016 07:26:12 -0700 (PDT)
Received: (qmail 15767 invoked from network); 4 Aug 2016 16:19:28 +0200
Received: from p5dec2461.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.97) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Aug 2016 16:19:28 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <D464DA9D-2B3A-4119-80AC-FBA1775D516D@csperkins.org>
Date: Thu, 4 Aug 2016 16:19:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ED96051-6F38-4F19-8593-6F804F6ADC75@kuehlewind.net>
References: <20160802151727.27859.51417.idtracker@ietfa.amsl.com> <D464DA9D-2B3A-4119-80AC-FBA1775D516D@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xrblock/OvnL9uXujwhAqNXUrc4-ceY0LKs>
Cc: draft-ietf-xrblock-independent-burst-gap-discard@ietf.org, xrblock-chairs@ietf.org, The IESG <iesg@ietf.org>, xrblock@ietf.org
Subject: Re: [xrblock] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-xrblock-independent-burst-gap-discard-02=3A_=28with_COMM?= =?utf-8?q?ENT=29?=
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 04 Aug 2016 14:26:18 -0000

hi Colin, 

okay. Maybe just provide a clear pointer to the respective text in RFC 3550 sections 6.2 and 6.3?

Thanks,
Mirja


> Am 03.08.2016 um 11:59 schrieb Colin Perkins <csp@csperkins.org>rg>:
> 
>> On 2 Aug 2016, at 16:17, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-xrblock-independent-burst-gap-discard-02: No Objection
>> 
>> 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 https://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:
>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-independent-burst-gap-discard/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Sorry still not an RT(C)P expert, but one question out of curiosity:
>> 
>> Would it be a valid operation if I send one MIR Block per burst (by
>> adapting the measurement duration dynamically), in case I really want to
>> know the length of each burst separately? 
>> 
>> If so (or also if not, I guess), would it make sense to give
>> recommendations about how often one should send feedback, or is this
>> generally covered elsewhere (provide pointer!) that applies for this
>> case?
> 
> The rules that determine the RTCP reporting interval are in RFC 3550 sections 6.2 and 6.3. That RFC is referenced from this draft. The measurement interval would typically match the RTCP reporting interval, but you could measure over a different interval if you wanted (the associated RFC 6776 report describes the measurement interval). 
> 
> I don’t think this needs guidance, or if it does, it would be general guidance for any user of XR blocks, and not specific to this particular block.
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
>