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

"Alan Clark" <alan.d.clark@telchemy.com> writes:
>>>(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).
>
>Well.... most would be up to 20 seconds however you could potentially have a
>TCP based streaming system with a much larger buffer 

Ok, but you'll need to make a justification why the 65 seconds available
for reporting in 3611 isn't sufficient.  (65 seconds doesn't mean you can't
have a deeper buffer, just that the 3611 stats won't show more than 65.)

>>>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.)
>
>If the midpoint is a router or SBC handling 50,000 concurrent streams
>through a distributed network processor architecture (i.e. each packet may
>be assigned to any microengine) then it is more practical to simply capture
>an RTCP packet and relay it up to a metrics processing / traffic analysis
>function than to have to track relationships between adjacent RTCP payloads.

Except that the "metrics-processing/traffic-analysis" engine *can* track
relationships between adjacent RTCP payloads, I assume.  And it only
matters if you need to do something active based on the loss of an RTCP
packet (which is normally possible, though over TCP it wouldn't be lost).

So I understand the router/SBC scenario, but you haven't shown why that
leads to a requirement.

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