[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] questions about jitter

On 28 Oct 2004, at 13:52, Romascanu, Dan ((Dan)) wrote:
Note that RFC 3550 RTCP defines "loss" in a very weird way;
it allows 
very
late packets to not be considered "lost", and it counts
duplicates as 
multiple separate packets (so if you lose packet N, and get two of
packet
N+1, that's considered 0 loss!!!)  Also, since loss is based on the
last
packet received (packet N), if the previous packet (N-1) arrives
out-of-order (but in time to be played) after the RTCP is sent, the
RTCP
will show that as a loss, and in the next RTCP an extra packet will
be counted (and yes, this can lead to negative loss rates).

So for many uses, while amusing, the RTCP data on loss (and probably
jitter) is close to worthless, and certainly has to be
taken as at best
fuzzy data. Post-jitter data (handling late packets,
duplicates, etc) 
is
more useful in most cases.  I'm sure part of the reason
it's defined 
this
way is so an RTP stack can calculate the loss & jitter
simply without
having to communicate in any way with the jitter buffer.

And there's RFC 3611 if you need more detailed statistics.

I've run into similar issues when doing RAQMON and trying to refer RFC 3550 for some of the metrics to measure application QoS. At the end of the day we had to define new or supplementary metrics for jitter, loss and discards, and differentiate between the network and application layer metrics. It looks like RFC 3550 is in need of a revision on this respect.

While I agree with the problems, there's too much deployment to redefine the RTCP statistics in RFC 3550 now. Additional metrics can be conveyed, much like was done with RFC 3611, if there's a need.

--
Colin Perkins
http://csperkins.org/


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