Re: [ippm] Fwd: New work relating to delay variation in AVT
Dave Singer <singer@apple.com> Fri, 13 April 2007 16:52 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 1HcP13-0005Jk-LW; Fri, 13 Apr 2007 12:52:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOOM-0002nS-1u for ippm@ietf.org; Fri, 13 Apr 2007 12:12:54 -0400
Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOOK-0003NC-IG for ippm@ietf.org; Fri, 13 Apr 2007 12:12:54 -0400
Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3DGCmWf023750; Fri, 13 Apr 2007 09:12:48 -0700 (PDT)
Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 8BDF529C002; Fri, 13 Apr 2007 09:12:48 -0700 (PDT)
X-AuditID: 11807123-a13ecbb000000b42-6e-461fac0082cb
Received: from [10.0.1.3] (singda.apple.com [17.202.35.52]) by relay5.apple.com (Apple SCV relay) with ESMTP id 31D9630400E; Fri, 13 Apr 2007 09:12:48 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06240864c2455c337f43@[10.0.1.3]>
In-Reply-To: <200704131443.l3DEhXgC024975@attrh3i.attrh.att.com>
References: <45FE76EC.6020200@internet2.edu> <200704131443.l3DEhXgC024975@attrh3i.attrh.att.com>
Date: Fri, 13 Apr 2007 09:11:52 -0700
To: Al Morton <acmorton@att.com>, Matthew J Zekauskas <matt@internet2.edu>, ippm@ietf.org
From: Dave Singer <singer@apple.com>
Subject: Re: [ippm] Fwd: New work relating to delay variation in AVT
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
X-Mailman-Approved-At: Fri, 13 Apr 2007 12:52:51 -0400
Cc: Roni Even <roni.even@polycom.co.il>, Colin Perkins <csp@csperkins.org>, Tom-PT Taylor <taylor@nortel.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 10:42 -0400 13/04/07, Al Morton wrote: >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/ thanks, this is (obviously) fine by me. > >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); -- David Singer Apple Computer/QuickTime _______________________________________________ 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