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

Alan Clark <alan.d.clark@telchemy.com> Wed, 16 January 2013 16:29 UTC

Return-Path: <alan.d.clark@telchemy.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 24DBA21F8A2F for <xrblock@ietfa.amsl.com>; Wed, 16 Jan 2013 08:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 TQvcBHx+tZTm for <xrblock@ietfa.amsl.com>; Wed, 16 Jan 2013 08:29:43 -0800 (PST)
Received: from smtp01.myhostedservice.com (smtp01.myhostedservice.com [216.134.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id BE59921F85D2 for <xrblock@ietf.org>; Wed, 16 Jan 2013 08:29:38 -0800 (PST)
Received: from mail01.netplexity.net (172.29.251.14) by SMTP01.netplexity.local (172.29.211.9) with Microsoft SMTP Server id 14.2.328.9; Wed, 16 Jan 2013 11:29:33 -0500
Received: from [192.168.1.117] (UnknownHost [97.67.102.65]) by mail01.netplexity.net with SMTP; Wed, 16 Jan 2013 11:29:25 -0500
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 16 Jan 2013 11:29:11 -0500
From: Alan Clark <alan.d.clark@telchemy.com>
To: Roni Even <ron.even.tlv@gmail.com>, "Dan (Dan)" <dromasca@avaya.com>, 'Kevin Gross' <kevin.gross@avanw.com>, Qin Wu <bill.wu@huawei.com>
Message-ID: <CD1C3F87.4D64F%alan.d.clark@telchemy.com>
Thread-Topic: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt
Thread-Index: AQK+Ebml6GvPlzlE/fVLKWSBf4dMVpZr0DkQgAAZjrY=
In-Reply-To: <03aa01cdf3fa$58f1d630$0ad58290$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3441180564_23089579"
Cc: 'xrblock' <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: Wed, 16 Jan 2013 16:29:48 -0000

Hi Roni

Nominal delay is the delay that is applied to a packet that arrives at its
expected time (i.e. 0 jitter) - and corresponds to the late window of the
jitter buffer

Jitter buffer size can be ambiguous as the term is sometimes used to mean
the late window and sometimes the overall buffer size.

For example.

A jitter buffer is configured to have 200ms of overall buffer space.
Initially packets are inserted into this at the 40ms point and hence incur
40ms of delay as they propagate to the 0ms ³read² point. If all the packets
arrive with zero jitter they would all incur 40ms of delay within the
buffer.

If a packet arrives 10ms later than expected then it is written to the
buffer at the (40-10)ms point however if a packet arrives more than 40ms
late then it is discarded.

If a packet arrives 50ms earlier than expected it is written to the
(40+50)ms point and would wait 90ms before being played out.

With an adaptive jitter buffer, If the jitter level is high and packets are
being discarded then the insertion point for on-time packets could be moved
to say 100ms. This results in the delay for on-time/ zero jitter packets
being 100ms but would reduce the discard rate

So the nominal delay is the time difference/ buffer size difference between
the on-time insertion point and the point at which packets are read out and
decoded.

Regards

Alan


On 1/16/13 10:01 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

> Hi Alan,
> I am not sure what applies a nominal delay means. Is the first packet defines
> the start of the jitter buffer and nominal delay is the size of the fixed
> jitter buffer.  
> When saying that the jitter buffer may increase or reduce is this for the
> adaptive jitter buffer?
>  
> Roni
>  
> 
> From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On Behalf Of
> Alan Clark
> Sent: 16 January, 2013 2:18 PM
> To: Dan (Dan); Kevin Gross; Qin Wu
> Cc: xrblock
> Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt
>  
> 
> A typical jitter buffer uses the first packet received as its timing
> reference, and applies a nominal delay to that before playing out.  During
> later operation, the jitter buffer may increase or reduce the nominal delay or
> may pick a new reference packet. This nominal delay represents the ³late
> window² - so if a packet arrives more than ³nominal delay ms² after its
> expected time then it will be discarded.
> 
> ³On time² - in this case - refers to the expected arrival time of the packet
> when calculated with reference to the first or a later selected reference
> packet.
> 
> Jitter buffer implementations don¹t necessary do this mathematically however
> this is a generalized description that models the behavior of most jitter
> buffers used for VoIP and Videoconferencing.
> 
> Playout buffers used in video streaming applications operate quite
> differently. Basically a received chunk of encoded video is added to the
> playout buffer - encoded video is read from the buffer. When the buffer level
> drops below a threshold then another chunk of video is requested from the
> server. There is an equivalent to ³nominal delay² as the buffer will always
> try to make sure there is at least a minimal level of video in the buffer
> before playing out - however there would not be the equivalent of an ³on time²
> packet.
> 
> Regards
> 
> Alan
> 
> 
> On 1/16/13 5:36 AM, "Dan (Dan)" <dromasca@avaya.com> wrote:
> Kevin, Qin,
>  
> Do you want to discuss this one2one, or should we organize a short conference
> call? Do other think that they can contribute to clarify the issues, or want
> to participate? 
>  
> Dan
>  
>  
>  
> 
> From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On Behalf Of
> Kevin Gross
> Sent: Tuesday, January 15, 2013 11:08 PM
> To: Qin Wu
> Cc: xrblock
> Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt
> 
> I think we need to have a phone call to discuss this whole thing.
> 
> 
> Kevin Gross
> 
> +1-303-447-0517
> 
> Media Network Consultant
> 
> AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.avanw.com/> ,
> www.X192.org <http://www.X192.org>  <http://www.X192.org>
>  
> 
> On Mon, Jan 14, 2013 at 8:27 PM, Qin Wu <bill.wu@huawei.com> wrote:
> 
> Hi,Kevin:
> 
> I like to make some additioal clarification to your question.
> 
> I think the packet arrives exactly on time, is also referred to the packet
> that has nominal delay.
> 
> So we have two ways to address this.
> 
> a. It is more like implementation specific issue,e.g., rely on timing
> information in the headers of previous
> 
> packet and current packet or rely on time window to determine this. So we can
> leave this to the specific
> 
> implemenations. 
> 
> 
> 
> b. we can explain the packet that arrives exactly on time as the packet that
> has nominal delay.
> 
> The nominal delay can either be choosen as the jitter buffer delay for the
> packet with minimal delay(i.e.,
> 
> the reference packet is choosen as the packet with minmal delay) or average
> delay for all the packets that arrives
> 
> within the implementation specific time window during the measurement
> interval.
> 
> I am not sure we should details to talk about this, but If we take (b), we
> prefer to add the following sentence in the draft to say:
> 
> "Note that the reference packet is generally selected as the packet
>  with minimum delay based on the most common criterion (see Sections 1
> <http://tools.ietf.org/html/rfc6798#section-1>  and 5.1 of [RFC5481
> <http://tools.ietf.org/html/rfc5481> ]).
> 
> "
> 
> Let me know what you think about this.
> 
> 
> 
> Regards!
> 
> -Qin
> 
> ----- Original Message -----
> 
> From: Qin Wu <mailto:bill.wu@huawei.com>
> 
> To: Kevin Gross <mailto:kevin.gross@avanw.com>
> 
> Cc: xrblock <mailto:xrblock@ietf.org>
> 
> Sent: Monday, January 14, 2013 8:46 AM
> 
> Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt
> 
> 
> 
> Kevin:
> 
> As I clarified to you in the previous email, "implemention specific time
> window" described in Burst Gap drafts will be used to identify a "packet that
> arrives exactly on time".
> 
> That is to say, if the receiving packet falls within  implemention specific
> time window and can be sucessfully playout, such packet will be regarded as
> packet that arrives exactly on time.
> 
> Hope this clarifies.
> 
> 
> 
> Regards!
> 
> -Qin
> 
> ----- Original Message -----
> 
> From: Kevin Gross <mailto:kevin.gross@avanw.com>
> 
> To: Qin Wu <mailto:bill.wu@huawei.com>
> 
> Cc: xrblock <mailto:xrblock@ietf.org>
> 
> Sent: Sunday, January 13, 2013 6:04 AM
> 
> Subject: Re: offlist//Re: [xrblock] Fw: I-D Action:
> draft-ietf-xrblock-rtcp-xr-jb-02.txt
> 
> 
> Qin, 
> 
> 
> 
> Of the jitter buffer delay metric, the draft currently says "It is calculated
> based on the difference between the receipt time and the playout time for the
> packet that arrives exactly on time."
> 
> 
> 
> My issue is that I don't know how to identify a "packet that arrives exactly
> on time".
> 
> 
> Kevin Gross
> 
> +1-303-447-0517 <tel:%2B1-303-447-0517>
> 
> Media Network Consultant
> 
> AVA Networks - www.AVAnw.com <http://www.AVAnw.com>  <http://www.AVAnw.com> ,
> www.X192.org <http://www.X192.org>  <http://www.X192.org>
>   
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
> 
>  
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
>