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

"Schwarz Albrecht" <Albrecht.Schwarz@alcatel-lucent.de> writes:
>there's an RTCP protocol oriented view of the problem and an application
>perspective.

Or perhaps more directly: an endpoint-oriented view, and a network/midbox
oriented view.

>Please take a more application-centric view of the problem, and consider
>also remote served users ("remote means that XR/HR are reported again
>via non-RTCP based reporting interfaces, e.g. like SIP or H.248").

Well, the transport for the information shouldn't matter.  The "user"
(network/midbox) in this scenario gets the data blocks, whether they come
by RTCP or by SIP, etc.

>Responses to your comments:
>a) relative time: ok locally, but remote processing implies a second
>piece of information in order to derivate the absolute time; I fail to
>see the benefit of relative time

Colin was saying to use an existing clock/format, such as an NTP time,
instead of ms.  And if a remote processor needs an additional bit of data
from the RTCP, then whatever is sending the report block to the remote 
processor should send the additional data as well (such as SR/RR from the
RTCP, or the relevant data from it).  That said, I'll note that
RFC 3611 has lots of stuff measured in ms in it.  And the media clock is
problematic unless we add restrictions that lock the media clock for all
payloads of a stream to the same value (which isn't going to happen, even
though it causes untold possibilities for annoyance).

>b) equidistant measurement interval size: think about statistical
>functions above the time scale of the measurement interval itself; there
>are then functions based on time series (i.e., temporal composition of
>metrics; note: the spatial composition, as considered by IPPM, is a
>different story).
>... such time series based functions are much simpler when time
>intervals are equidistant 

Sure, they're easier to calculate.  However, even under the best of
circumstances you can't count on the intervals being truly equidistant, and
in some quite possible cases (RTCP bandwidth restricted by the algorithm
due to competing traffic from the same or other endpoints,
endpoint/application issues, etc) you can get wildly non-equidistant
measurements (factors of 2x or more).  So your stats functions *have* to
handle both minor non-uniform periods (due to sampling error and real-time
preemption), and major non-uniformity (due to RTCP
bandwidth/algorithm/etc).

-- 
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