Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-01.txt

Randell Jesup <rjesup@wgate.com> Mon, 03 December 2007 18:58 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGVJ-0007nK-Cg; Mon, 03 Dec 2007 13:58:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGVI-0007lN-Bh for avt@ietf.org; Mon, 03 Dec 2007 13:58:52 -0500
Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGVH-0002g0-Rc for avt@ietf.org; Mon, 03 Dec 2007 13:58:52 -0500
Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 13:58:51 -0500
To: Alan Clark <alan.d.clark@telchemy.com>
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-01.txt
References: <20071203162932.1924A4DC002@mail.globalsuite.net>
From: Randell Jesup <rjesup@wgate.com>
Date: Mon, 03 Dec 2007 13:58:50 -0500
In-Reply-To: <20071203162932.1924A4DC002@mail.globalsuite.net> (Alan Clark's message of "Mon, 3 Dec 2007 11:27:35 -0500")
Message-ID: <ybufxyjd2qd.fsf@jesup.eng.wgate.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 03 Dec 2007 18:58:51.0815 (UTC) FILETIME=[8B6B8370:01C835DE]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: 'Colin Perkins' <csp@csperkins.org>, 'AVT WG' <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Randell Jesup <rjesup@wgate.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

"Alan Clark" <alan.d.clark@telchemy.com> writes:
>>Why is Round Trip Time reported - can't this be derived from RTCP SR/ RR
>>packets?/
>
>I agree that endpoints can do this.  It is non-trivial for any midpoint
>system (e.g. a probe or router) to calculate RTD from SR/RR and requires the
>capture of a series of SR/RR exchanges, maintaining state etc.  

This is a valid point - it's hard to calculate if you're not an endpoint;
various types of midboxes can use this info, and it can be useful for
overall network-health monitoring.  I've seen it proposed (in the area of
RFC 3611) recently (and also via end-of-call SIP PUBLISH).

I should note that RFC 3611 also reports delays in ms (section 4.7.3),
using RTCP NTP times per the normal spec for DLRR/etc.

>>The playout buffer metrics seem very similar to the jitter buffer metrics
>>defined in RFC 3611. Can't the existing metrics be reused?
>
>The main issues are:
>
>(i) Size - playout buffers can be much larger, potentially 10's of seconds

Greater than 65 seconds?  That's how long the jitter buffer params in 3611
can cover (16 bits at 1ms/per).

>(ii) The playout metrics allow problems such as playout interruptions due to
>buffer starvation in TCP based systems to be monitored.

That may be useful, depending on definition (note: I haven't read the spec
to see how this is defined/transmitted).

>>Why is there a need to signal the measurement interval? The baseline RTCP
>>reports operate on the interval since the last report - is that not simpler?
>
>This requires monitoring systems to recognize sequential RTCP reports, would
>not deal properly with lost RTCP reports, and for midpoint systems would
>cause problems if routes changed.  

I don't think this adds siginificant complexity, at least not the
sequential aspect.  The RTCP has info that lets you know the sequence
numbers/timestamps received/transmitted, and the time and period.  It's
easy to figure out if an RTCP was "lost", just by retaining the last one
(see note).  However, whether the period is fixed or not, what does a
midbox/etc do if an RTCP is lost anyways?  How is this really different
(let alone tough) if the packets are of variable length?

(Note: in AVPF scenarios, you can get a number of RTCPs sent in a very
short period, and *in theory*, they could be received out-of-order due to
route-flapping, etc.  Something to realize can happen, even if it's rare.
The simplest solution (depending on what you use RTCP for) is to ignore the
"stale" out-of-order RTCP as if it were lost.)

>>Why are intervals measured in milliseconds, rather than RTCP timestamp
>>units? The use of milliseconds seems to require an additional clock at the
>>receiver.
>
>Really just convenience - this does not require an additional clock, just
>some simple math.  It also means that if the RTP clock rate associated with
>the stream changed, or the video clock rate was different to the audio clock
>rate, it may be complex for any entity other than the endpoint to figure out
>what the interval was. 

There still is confusion over RTP streams switching timestamps - whether
it's really allowed (it appears to be), and the side-effects (very
confusing for RTCP, and other things):

Random example (I probably have the G722 media type wrong):
m=audio 2345 RTP/AVP 0 99
a=rtpmap:0 PCMU/8000
a=rtpmap:99 G722/16000

This means the timestamp rate can change at any point, on a
packet-by-packet basis.  It's even theoretically allowable to alternate
G711 and G722 packets.  Totally odd and non-useful, but it illustrates the
point.  More realistic is a change from one to the other half-way through
an RTCP monitoring period.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt