Re: [xrblock] Calculation of delay metrics defined in the Delay Block

Qin Wu <bill.wu@huawei.com> Fri, 28 October 2011 12:50 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 AAB6921F8AFE for <xrblock@ietfa.amsl.com>; Fri, 28 Oct 2011 05:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.905
X-Spam-Level:
X-Spam-Status: No, score=-4.905 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXZnJdtlxEYr for <xrblock@ietfa.amsl.com>; Fri, 28 Oct 2011 05:50:08 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3459A21F87D9 for <xrblock@ietf.org>; Fri, 28 Oct 2011 05:50:08 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTS00CAY0UVVK@szxga03-in.huawei.com> for xrblock@ietf.org; Fri, 28 Oct 2011 20:47:19 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTS00CSG0TMSV@szxga03-in.huawei.com> for xrblock@ietf.org; Fri, 28 Oct 2011 20:47:19 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM80847; Fri, 28 Oct 2011 20:47:18 +0800
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 20:47:10 +0800
Received: from w53375q (10.138.41.130) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 20:47:12 +0800
Date: Fri, 28 Oct 2011 20:47:11 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Alan Clark <alan.d.clark@telchemy.com>, zhaojing@sttri.com.cn, xrblock <xrblock@ietf.org>
Message-id: <83F0438BC9B94EFBB7C8E96100F9FD3F@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: multipart/alternative; boundary="Boundary_(ID_LzRiKrtpaFD1hpJ7GV+jgQ)"
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <CAD00DF6.3CCEA%alan.d.clark@telchemy.com>
Subject: Re: [xrblock] Calculation of delay metrics defined in the Delay Block
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, 28 Oct 2011 12:50:10 -0000

Re: [xrblock] Calculation of delay metrics defined in the Delay BlockHi, Alan:
I think you explaination is more precise, thank for your clarification and make correction.

Regards!
-Qin
  ----- Original Message ----- 
  From: Alan Clark 
  To: Qin Wu ; zhaojing@sttri.com.cn ; xrblock 
  Sent: Friday, October 28, 2011 7:44 PM
  Subject: Re: [xrblock] Calculation of delay metrics defined in the Delay Block


  Qin

  Strictly speaking, End System Delay is not part of Network Round Trip Delay but is part of the overall round trip delay experienced by the user.

  Network Round Trip Delay in this case should be the round trip delay measured using RTP, which includes the network transmission delay in each direction plus some processing time within the IP/UDP/RTP stack.

  End System Delay is an estimate of the additional round trip delay that the user would experience due to encoding/decoding/ buffering/ accumulation and "may" also include other delay components that are external to the RTP segment, if known. 

  The total round trip delay experienced by the user is the Network Round Trip Delay plus the End System Delay from each end.

  Also - it may be better not to describe the End System Delay in terms of "Sending side" and "Receiving side" as this may be understood to mean the sending and receiving sides of the connection not the endpoint.  

  Best Regards

  Alan


  On 10/28/11 6:10 AM, "Qin Wu" <bill.wu@huawei.com> wrote:


    End System Delay is part of  Network Round trip delay(Transmission Delay is another part of Network Round Trip Delay).
    The End System Delay is calculate based on sending side internal Delay and receiving side internal Delay.
    Sending side internal Delay = Accumulation and Encoding Delay
    Reciving Side Internal Delay = Jitter Buffer Delay + Decoding and Playout Buffer Delay.
    In my understanding, the End System Delay can be measured using DLSR or DLRR. We can choose mean value of DLSR and DLRR to stand
    for the average End System Delay.
     
    Regards!
    -Qin


      ----- Original Message ----- 
       
      From:  zhaojing@sttri.com.cn 
       
      To: xrblock <mailto:xrblock@ietf.org>  
       
      Sent: Friday, October 28, 2011 4:25 PM
       
      Subject: Re: [xrblock] Calculation of delay  metrics defined in the Delay Block
       

       

      Hi, Qin:


      Would you like to explain to me how End System Delay is  calculated?


      Is it based on DLSR or something else? It looks like a internal  calculation.


      Regards!


      -JingZhao


       
       

        a.. From: Qin Wu <bill.wu  at huawei.com <mailto:bill.wu@DOMAIN.HIDDEN> >   
        b.. To: zhaojing at  sttri.com.cn <mailto:zhaojing@DOMAIN.HIDDEN> , xrblock <xrblock  at ietf.org <mailto:xrblock@DOMAIN.HIDDEN> >   
        c.. Date: Thu, 20 Oct 2011 18:34:53 +0800   
        d.. References: <22819783.8901319076443866.JavaMail.root  at ent11 <mailto:22819783.8901319076443866.JavaMail.root@DOMAIN.HIDDEN> >   
        e.. List-id: Metric Blocks for use with RTCP's Extended Report  Framework working group discussion list <xrblock.ietf.org> 



--------------------------------------------------------------------------


         
       Hi,jing:  Please refere to RFC3550. 
       The round trip time computation method is defined as a example in  the figure 2 of RFC3550. 
        
       Regards! 
       -Qin 
       

        -----  Original Message ----- 
        From: zhaojing at  sttri.com.cn <mailto:zhaojing%20at%20sttri.com.cn>  
         To: xrblock <mailto:xrblock%20at%20ietf.org>  
         Sent: Thursday, October 20, 2011 10:07 AM 
         Subject: [xrblock] Calculation of delay metrics defined  in the Delay Block 
         
          Hi, 
         I have read Delay draft avaiable at: 
         http://tools.ietf.org/html/draft-ietf-avt-rtcp-xr-delay-02  
         
         It is not clear to me how each metric is calculated, For example,  
         it is said Mean Network Round Trip Delay metric is ypically determined  
        using  RTCP SR/RR? 
         I am not  sure I understand the rationale? Who would like to explain a little to  me? 
         
         Regards! 
         jing  Zhao   ShangHai  Research Institute of China Telecom Corporation Limited.  



       

--------------------------------------------------------------------------


      _______________________________________________
      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