Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

Kevin Gross <kevin.gross@avanw.com> Fri, 21 December 2012 22:19 UTC

Return-Path: <kevin.gross@avanw.com>
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 78DB221F85AB for <xrblock@ietfa.amsl.com>; Fri, 21 Dec 2012 14:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.812
X-Spam-Level:
X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INJK3ndtoZdV for <xrblock@ietfa.amsl.com>; Fri, 21 Dec 2012 14:19:55 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id BEE1421F859D for <xrblock@ietf.org>; Fri, 21 Dec 2012 14:19:55 -0800 (PST)
Received: (qmail 27221 invoked by uid 0); 21 Dec 2012 22:19:34 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy12.bluehost.com with SMTP; 21 Dec 2012 22:19:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=T+OL3+0f0XIJlatba+Mf2Fks98WwS21JBBFNareb9Mc=; b=EpB/vC/qErLCW4IxlD5tlEwsR+fXeK7rM8u4Q1Tb0ht2HZSIstOC2edqGY46kiA4+zXp8oGXSjfn13jH1aWcjoIjN/o5DNHkYbMK3QCAh2FH6TcNtJ1SdpZqfQJdsOMy;
Received: from [209.85.210.178] (port=37194 helo=mail-ia0-f178.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1TmAwI-0002yL-1h for xrblock@ietf.org; Fri, 21 Dec 2012 15:19:34 -0700
Received: by mail-ia0-f178.google.com with SMTP id k25so4465398iah.9 for <xrblock@ietf.org>; Fri, 21 Dec 2012 14:19:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.169.106 with SMTP id ad10mr9959881igc.88.1356128373150; Fri, 21 Dec 2012 14:19:33 -0800 (PST)
Received: by 10.50.151.135 with HTTP; Fri, 21 Dec 2012 14:19:32 -0800 (PST)
In-Reply-To: <686F7A581585402D82BDCA8F213EB5E7@china.huawei.com>
References: <FAB2D6A6BD794F67B5EF665FB7966291@china.huawei.com> <9904FB1B0159DA42B0B887B7FA8119CA021171@AZ-FFEXMB04.global.avaya.com> <-5577438416726931362@unknownmsgid> <9904FB1B0159DA42B0B887B7FA8119CA02129A@AZ-FFEXMB04.global.avaya.com> <56FF1AB29F4046F0BDCDF6F7B21FC0EC@china.huawei.com> <CALw1_Q1UfwNR+7jNx=r+P3rMR35NRdby_S+Xh1GADivvx3_r6w@mail.gmail.com> <686F7A581585402D82BDCA8F213EB5E7@china.huawei.com>
Date: Fri, 21 Dec 2012 15:19:32 -0700
Message-ID: <CALw1_Q1FqHh0SVBKudc-cJoJxw9hPUeBUwdgrf54xLwSFDfO6g@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/alternative; boundary=e89a8f2346bbf3945104d1643dec
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.178 authed with kevin.gross@avanw.com}
Cc: xrblock@ietf.org
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Dec 2012 22:19:58 -0000

Discussion below...

On Mon, Dec 17, 2012 at 6:38 PM, Qin Wu <bill.wu@huawei.com> wrote:

> **
>
>
> Section 3.2
>
> Jitter Buffer Configuration
> I think the two reporting options are potentially over simplification of
> how these systems can work. An adaptive receiver has to adapt to maximum
> latency and to delay variation. The former is accomplish by adjusting the
> playout delay, the latter by reallocating buffer space. I suggest we might
> want to report these behaviors separately, for example:
>   00 - fixed jitter buffer and delay
>   10 - adaptive playout delay
>   01 - adaptive buffer size
>   11 - adaptive delay and size
>
>
> [Qin]:Sounds good to me.
>

[KG] I've seen recent discussion from others that leads me to wonder
whether they're going to be OK with it. I hope this proposal can get a more
thorough review before being included in the draft.

>
> Block length
> Is requirement to discard reports with unexpected length
> common practice with these reports? The alternative is to allow reports to
> be revised to increased size with appended data. Original implementations
> then ignore anything beyond the original size. It's a little more flexible
> but maybe we don't want to go there. I've checked RFC 3611 and don't see
> any guidance on this. It would be nice to specify consistent behavior
> around this for all reports.
>
>
> [Qin]:Yes. I have fixed this with adding the following sentence to say:
> "
>
> The block MUST be discarded if the block length is******
>
>       set to a different value.****
> "
>

[KG] I did not claim there was anything broken in the draft so I am
confused that you claim to have fixed it. If your "Yes" reply was in
response to "Is requirement to discard reports with unexpected length
common practice with these reports?" it would be helpful to point out a
draft or two on which you've modeled this behavior.


>  Jitter buffer nominal delay
> Needs to specify reference points for reported delay: From receipt to
> playout? From RTP timestamp to playout?
>
>
>  [Qin]:One reference point is the packet that arrives exact on time.
>

We need a definition for the "exactly on time". Exactly on time according
to whom and with respect to what? The other reference point is playout
time. This also needs to be defined. Playout of first byte in the payload?

>  If one of the reference points is a playout time, and depending on
> expected use cases, higher resolution may be justified here.
>
> [Qin]:What's your suggested change? How about adding the following
> sentence to say:
> "
> It is calculated based on the difference between the receipt time and
> playout time for the packet that
> arrives exactly on time.
> "
>

I need more information before making a proposal. Who do we expect will use
Jitter buffer nominal delay information and for what purpose?

>  Jitter buffer maximum delay
> Needs to specify reference points for reported delay: From receipt to
> playout? From RTP timestamp to playout?
>
>
> [Qin]: How about adding the following sentence to say:
> "
>  Jitter buffer maximum delay is calculated based on the difference
> between the receipt time and playout time
> for the earliest arriving packet"
>

I can't evaluate this proposal until I understand who we expect will use
Jitter buffer maximum delay information and for what purpose.

>
> Jitter buffer high water mark
> Explain whether this applies to fixed jitter buffer or only to adaptive.
>
> [Qin]: I think "Jitter buffer high water mark" applies to adaptive jitter
> buffer implementation.
> its value MUST be set to jitter buffer maximum delay for fixed jitter
> buffer implementations.
> How about adding one sentence to say:
> "
> This parameter MUST be provided for
>  adaptive jitter buffer implementations and its value MUST be
>  set to JB maximum for fixed jitter buffer implementations.
> "
>
This looks like an improvement but I can't fully evaluate the proposal
until we address the issues above and have a better definition for Jitter
buffer nominal delay.