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
- [ippm] RTP timestamp as SrcTime in draft-ietf-ipp… Spiros Spirou
- Re: [ippm] RTP timestamp as SrcTime in draft-ietf… Al Morton
- Re: [ippm] RTP timestamp as SrcTime in draft-ietf… Spiros Spirou
- Re: [ippm] RTP timestamp as SrcTime in draft-ietf… Al Morton
- Re: [ippm] RTP timestamp as SrcTime in draft-ietf… Al Morton
- Re: [ippm] RTP timestamp as SrcTime in draft-ietf… Spiros Spirou