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

Qin Wu <bill.wu@huawei.com> Thu, 17 January 2013 09:03 UTC

Return-Path: <bill.wu@huawei.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 5FBA021F88A2 for <xrblock@ietfa.amsl.com>; Thu, 17 Jan 2013 01:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.619
X-Spam-Level:
X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 7TZaiLPogPfu for <xrblock@ietfa.amsl.com>; Thu, 17 Jan 2013 01:03:17 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7B521F869B for <xrblock@ietf.org>; Thu, 17 Jan 2013 01:03:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANP83426; Thu, 17 Jan 2013 09:03:12 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Jan 2013 09:02:55 +0000
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Jan 2013 09:03:08 +0000
Received: from w53375 (10.138.41.149) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Jan 2013 17:03:05 +0800
Message-ID: <927AAAAC26834AFC9B18DFE6D75DF4EA@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Alan Clark <alan.d.clark@telchemy.com>, Roni Even <ron.even.tlv@gmail.com>, "Dan (Dan)" <dromasca@avaya.com>, "'Kevin Gross'" <kevin.gross@avanw.com>
References: <CD1C881F.4D69E%alan.d.clark@telchemy.com>
Date: Thu, 17 Jan 2013 17:03:04 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0421_01CDF4D4.83E54FE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
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: Thu, 17 Jan 2013 09:03:26 -0000

Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txtHi,Alan:
Thank for your clarification.That's what I thought in my second proposal below, i.e., choose the reference point as the average delay for all the received packets during the measurement Interval.
I think the choosing the 1st packet received as the reference point is also reasonable.

Regards!
-Qin
  ----- Original Message ----- 
  From: Alan Clark 
  To: Roni Even ; Dan (Dan) ; 'Kevin Gross' ; Qin Wu 
  Cc: 'xrblock' 
  Sent: Thursday, January 17, 2013 5:38 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt


  Hi Roni

  That is correct.

  With regard to the choice of reference point - this would typically be the first packet however could also be based on a running average of the delay.  A jitter buffer does need to deal with timing drift, which could cause a gradual empty or fill of the buffer, and also with delay increases/reductions due to route changes - this can be addressed either by detecting the condition and resetting the reference point or by using the running average delay value.

  Best Regards

  Alan 


  On 1/16/13 4:15 PM, "Roni Even" <ron.even.tlv@gmail.com> wrote:


    Hi Alan,
    If you insert the received packet at 40 ms and you are currently start  reading from 0 you are delaying by 40 ms and 40 ms is the nominal delay.  So it does not matter what is the jitter buffer size, you are expecting to render or decode a packet if it arrives between 0 or 40 ms compared to the first packet. I assume for fixed buffer this will not change but for adaptive buffer the nominal delay may change.
    I agree on the last sentence of your explanation, the question is how you define the on-time insertion point or expected time. I believe you  are saying it is based on the first packet that arrives.
    Roni
     

    From: Alan Clark [mailto:alan.d.clark@telchemy.com] 
    Sent: 16 January, 2013 6:29 PM
    To: Roni Even; Dan (Dan); 'Kevin Gross'; Qin Wu
    Cc: 'xrblock'
    Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

    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>  <http://www.avanw.com/> , www.X192.org <http://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>  <http://www.AVAnw.com> , www.X192.org <http://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