Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10

Al Morton <acmorton@att.com> Thu, 17 November 2005 20:33 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqSC-0005B1-QD; Thu, 17 Nov 2005 15:33:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIe-0002wu-7p for ippm@megatron.ietf.org; Thu, 17 Nov 2005 15:24:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18000 for <ippm@ietf.org>; Thu, 17 Nov 2005 15:23:28 -0500 (EST)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqZE-0007Tn-GM for ippm@ietf.org; Thu, 17 Nov 2005 15:41:19 -0500
Received: from mail121.messagelabs.com ([216.82.241.195]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ecpy9-0006oQ-Mm for ippm@ietf.org; Thu, 17 Nov 2005 15:02:53 -0500
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-5.tower-121.messagelabs.com!1132247509!7423437!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 20034 invoked from network); 17 Nov 2005 17:11:49 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-5.tower-121.messagelabs.com with SMTP; 17 Nov 2005 17:11:49 -0000
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.35](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20051117171149gw100lggl6e>; Thu, 17 Nov 2005 17:11:49 +0000
Message-Id: <6.2.1.2.0.20051117121105.021c6c38@postoffice.maillennium.att.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 17 Nov 2005 12:11:49 -0500
To: Spiros Spirou <spiros.spirou@ieee.org>
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] RTP timestamp as SrcTime in draft-ietf-ippm-reordering-10
In-Reply-To: <000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
References: <01f301c5e06b$541ee300$bd2c7c92@intranet.gr> <6.2.1.2.0.20051103114221.03e51410@postoffice.maillennium.att.com> <000601c5e44c$e3179c70$bd2c7c92@intranet.gr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

Sorry - mail tool problem, here's the complete reply:

Hi Spiros,

I don't think that you are misusing the draft,
you are simply applying the definitions under circumstances
that are somewhat different from the usual IPPM active
measurement set-up, with instruments present only at the
receivers.  Perhaps you can make measurements
more ubiquitously as a single-point measure, and the
information you derive may out-weigh the errors between
the true wire time and the RTP time stamp, as long as you
are clear about *what* was measured (both network and source
effects on transmission time).

 From RFC 2330, section 10.2:
    When appropriate, metrics should be defined in terms of wire times
    rather than host endpoint times, so that the metric's definition
    highlights the issue of separating delays due to the host from those
    due to the network.

You might attack the problem of characterizing source error by making
measurements as "close to the source" as possible.

It's usually better to light a candle than to curse the darkness.

Al



At 05:12 AM 11/8/2005, Spiros Spirou wrote:
>Hi Al,
>
>Thanks for the reply.
>
>I may be trying to misuse the draft: What I have in mind is a self-contained
>measuring device (receiver) that reports the Type-P-Reordered metric and
>associated parameters (including SrcTime for completeness).
>
>However, it seems that the requirement to report SrcTime as wire time
>prohibits a self-contained Type-P-Reordered measurement, because it
>necessitates a simultaneous measurement of the transmission wire time at the
>source. Following from your correct observations, this complication may also
>hold when earlier times (such as the RTP timestamp) are used in reporting
>the SrcTime, because one still needs to detect, estimate, and remove the
>"source jitter" component, and I don't see how these can be done at the
>receiver without measurements at the server as well.
>
>So, am I going up a dead-end? Is there a way to report the SrcTime as (the
>elusive) wire time without access to the server?
>
>Regards,
>
>Spiros


_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm