IETF Logo Mail Archive

Re: [xrblock] WGLC for aft-ietf-xrblock-rtcp-xr-burst-gap-loss-02.txt

Hendrik Scholz <hs@123.org> Mon, 16 July 2012 12:42 UTC

Return-Path: <hs@123.org>
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 5612B21F8731 for <xrblock@ietfa.amsl.com>; Mon, 16 Jul 2012 05:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 CvW33yyigYM9 for <xrblock@ietfa.amsl.com>; Mon, 16 Jul 2012 05:42:37 -0700 (PDT)
Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 872F521F8723 for <xrblock@ietf.org>; Mon, 16 Jul 2012 05:42:37 -0700 (PDT)
X-RZG-AUTH: :JH8HfU+kYd9xQ6m0ynnj9hHxvZXYXks+pm8dQxa2PdmCs29qNyJDXGPSHqedfmnO
X-RZG-CLASS-ID: mo05
Received: from [192.168.1.207] ([213.218.5.34]) by smtp.strato.de (josoe mo84) (RZmta 29.19 DYNA|AUTH) with ESMTPA id l0430fo6GCYDvN for <xrblock@ietf.org>; Mon, 16 Jul 2012 14:43:21 +0200 (CEST)
Message-ID: <50040C69.7060108@123.org>
Date: Mon, 16 Jul 2012 14:43:21 +0200
From: Hendrik Scholz <hs@123.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: xrblock@ietf.org
References: <EDC652A26FB23C4EB6384A4584434A0407D54096@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0407D54096@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [xrblock] WGLC for aft-ietf-xrblock-rtcp-xr-burst-gap-loss-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: Mon, 16 Jul 2012 12:42:38 -0000

Hi,

line 238:
This definition is based on the assumption that the observer
is co-located with the RTP receiver and thus a packet loss/delay
cannot happen after observation. For RTCP this would be true
I suppose unless somebody comes up with the idea of generating
RTCP reports on B2BUAs.
In case of a 'mid point' monitoring approach the loss/discard numbers 
may be wrong as a packet may have been lost/delayed on the remaining
path.
Should we add a statement to indicate that this is end-to-end (I am
aware of companies who want to segment the RTP path and generate hop by
hop RTCP)?

line 137:
There is a superfluous space after '[MONARCH]'

I have no further comments.

Regards,
  Hendrik

-- 
Hendrik Scholz <hs@123.org>

v2.34.0 | Report a Bug | By Email | System Status