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