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