Re: [ippm] Fwd: New work relating to delay variation in AVT
Al Morton <acmorton@att.com> Fri, 13 April 2007 14:43 UTC
Return-path: <ippm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN0A-00029K-0E; Fri, 13 Apr 2007 10:43:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN08-00029D-Vm for ippm@ietf.org; Fri, 13 Apr 2007 10:43:48 -0400
Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcN07-0005SP-Kl for ippm@ietf.org; Fri, 13 Apr 2007 10:43:48 -0400
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-7.tower-146.messagelabs.com!1176475426!2038467!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 16419 invoked from network); 13 Apr 2007 14:43:46 -0000
Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-7.tower-146.messagelabs.com with SMTP; 13 Apr 2007 14:43:46 -0000
Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3DEhjU2006475 for <ippm@ietf.org>; Fri, 13 Apr 2007 10:43:45 -0400 (EDT)
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3DEhW8w006305 for <ippm@ietf.org>; Fri, 13 Apr 2007 10:43:32 -0400 (EDT)
Message-Id: <200704131443.l3DEhW8w006305@attrh9i.attrh.att.com>
Received: from acmt.att.com (acmt.mt.att.com[135.16.251.82](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20070413144332gw10010gi2e>; Fri, 13 Apr 2007 14:43:32 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 13 Apr 2007 10:42:07 -0400
To: Matthew J Zekauskas <matt@internet2.edu>, ippm@ietf.org
From: Al Morton <acmorton@att.com>
Subject: Re: [ippm] Fwd: New work relating to delay variation in AVT
In-Reply-To: <45FE76EC.6020200@internet2.edu>
References: <45FE76EC.6020200@internet2.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: Tom-PT Taylor <taylor@nortel.com>, Roni Even <roni.even@polycom.co.il>, Colin Perkins <csp@csperkins.org>, Dave Singer <singer@apple.com>
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>
Errors-To: ippm-bounces@ietf.org
At 07:41 AM 3/19/2007, Matt forwarded Tom's message: >A recent I-D by Morton dealing with delay variation made me aware of >IPPM interest in this topic. For that reason I direct your attention to >draft-ietf-avt-rtp-toffset-05.txt which, for RTP packets, provides the >means to separate delay variation introduced at the source host from >that introduced in the intervening transport network. This draft has >passed WGLC and is being forwarded to the IESG for approval. If you have >comments, please submit them as IETF Last Call comments to the IESG. > >Thanks, >Tom Taylor >AVT co-chair A minor pre-last call comment on section 4, please put this in your pocket, Tom. ... Precisely, the replacement equation for the equation in the RTP specification is, where Ri is the arrival time: D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi)) = (Rj - (Sj + Oj)) - (Ri - (Si + Oi)) I suggest: s/Ri is the arrival/Rj is the most recent arrival/ to give the right emphasis, otherwise there might be confusion about arrival order for subtraction. RFC3550 makes the order clear in the material that follows, but the text above leaves the reader with the possible misinterpretation that Ri is most recent packet. My sensitivity to this stems from finding that another standards body read IPPM's RFC 3393 on delay variation, and wrote the subtraction backwards in their spec. (but then they use the absolute value, anyway). Al Some background from RFC3550 & notes follow, for convenience: S 6.4.1, p 39 interarrival jitter: 32 bits An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As shown in the equation below, this is equivalent to the difference in the "relative transit time" for the two packets; the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units. If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) (ACM: packet with index j has just arrived, i is the previous packet, as the alpha-order implies) The interarrival jitter SHOULD be calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16 (ACM: this is clear, but here packet i has just arrived, changing the notation from the equation above) Whenever a reception report is issued, the current value of J is sampled. The jitter calculation MUST conform to the formula specified here in order to allow profile-independent monitors to make valid interpretations of reports coming from different implementations. This algorithm is the optimal first-order estimator and the gain parameter 1/16 gives a good noise reduction ratio while maintaining a reasonable rate of convergence [22]. A sample implementation is shown in Appendix A.8. See Section 6.4.4 for a discussion of the effects of varying packet duration and delay before transmission. ... A.8 Estimating the Interarrival Jitter The code fragments below implement the algorithm given in Section 6.4.1 for calculating an estimate of the statistical variance of the RTP data interarrival time to be inserted in the interarrival jitter field of reception reports. The inputs are r->ts, the timestamp from the incoming packet, and arrival, the current time in the same units. Here s points to state for the source; s->transit holds the relative transit time for the previous packet, and s->jitter holds the !!!------------------------------------ estimated jitter. The jitter field of the reception report is measured in timestamp units and expressed as an unsigned integer, but the jitter estimate is kept in a floating point. As each data packet arrives, the jitter estimate is updated: int transit = arrival - r->ts; int d = transit - s->transit; !!!!!!----------------------------- (ACM: the code fragments are clear) s->transit = transit; if (d < 0) d = -d; s->jitter += (1./16.) * ((double)d - s->jitter); _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
- [ippm] Fwd: New work relating to delay variation … Matthew J Zekauskas
- [ippm] comments on draft-ietf-ippm-multimetrics-0… Geib, Ruediger
- RE: [ippm] comments on draft-ietf-ippm-multimetri… Alan Clark
- Re: [ippm] Fwd: New work relating to delay variat… Al Morton
- Re: [ippm] Fwd: New work relating to delay variat… Dave Singer
- RE: [ippm] comments on draft-ietf-ippm-multimetri… STEPHAN Emile RD-CORE-LAN
- RE: [ippm] comments on draft-ietf-ippm-multimetri… Geib, Ruediger