Use of RTCP statistics for estimating QoS of VoIP
Paul E. Jones
paulej at PACKETIZER.COM
Thu Nov 7 01:05:25 EST 2002
This document (now H.460.9) first appeared about a year ago. After the
author presented the paper, it was agreed without debate to create a new
work item for it. At this last meeting, the author presented the paper, as
scheduled, for approval. During interim meetings, there were no
contributions against the document, which is the accepted procedure for
raising technical issues and trying to make changes to progressing work
During the last meeting, Mike Buckley did express concern over this
document. I think Mr. Buckley's concerns were all valid and he pointed us
to this Internet Draft. However, I had a decision to make: to hold progress
on this document until the IETF produces an RFC or to allow the document to
go forward as scheduled and as desired by the contributor.
Given that this contributing company had made the document available about a
year ago and received no formal contributions against it, it really was not
my place to hold up progress at the last moment. While I certainly had the
wherewithal to put the document on hold, I just didn't think that is the
right thing to do and it certainly was not the desire of the contributor.
With that said, though, we did make changes at the meeting to the document
to prepare for this forthcoming RFC. It was agreed that we will create
either an Annex or Amendment to add the necessary fields to the existing
data structures so that the additional information can be reported once the
RFC is available.
Unfortunately, Mr. Buckley was not available during the second week at the
meeting to discuss some of those decisions. Even some of my communication
with him via e-mail was unsuccessful due to bounced messages. We hoped that
the decisions we made would be acceptable to him. While I definitely value
the input he provides and I hold his opinions in high regard, I felt like it
was better to publish this document now with the aforementioned changes and
plans, so as to meet the wishes of the contributor and try to address the
concerns of Mr. Buckley at the same time. After all, there was no guarantee
that the RFC would be published between now and the next SG16 meeting in May
2003 and we certainly cannot wait indefinitely on the IETF to complete work.
----- Original Message -----
From: "Alan Clark" <alan at telchemy.com>
To: <paulej at packetizer.com>
Cc: <ITU-SG16 at echo.jf.INTEL.COM>
Sent: Wednesday, November 06, 2002 10:49 AM
Subject: Use of RTCP statistics for estimating QoS of VoIP
> I am responding to the recent SG16 email that encouraged direct input from
> those not participating directly in the work of the Study Group.
> One particular recent issue relates to the recent addition of QoS
> based on RTCP statistics. We have spent the last three years analyzing
> modeling the effects of IP network impairments on VoIP and would like to
> share our experience on this issue.
> RTCP statistics were intended to provide a "rough" real time feedback
> between endpoints to give some sense of network quality and facilitate
> potential adaptation. IP network impairments are transient in nature and
> the "averaged" metrics that RFC1889 produces are as a result very
> misleading. The addition of QoS reporting based on RFC1889 metrics is, in
> our opinion, a backward step as it infers that these statistics are useful
> for VoIP quality estimation whereas they are in fact almost meaningless.
> (i) Packet Loss - counts
> RFC1889 counts of loss are not compensated for duplicate packets, hence it
> is possible to have incorrect and even negative (!!) loss counts.
> (ii) Packet Loss- distribution
> Voice quality is very sensitive to the distribution of packet loss - if 2%
> loss occurs but the losses are spread out evenly then with PLC quality
> be affected only marginally, if 1% loss occurs but losses occur during
> intervals (typically the case) then quality can be affected quite
> RFC1889 does not consider the distribution of lost packets and hence
> loss numbers can only grossly be equated to call quality (i.e. loss rate
> 20% is bad but you couldn't say for sure if 2% was bad or not)
> (iii) Jitter - metric
> The average packet-to-packet delay variation used in RFC1889 does not
> properly reflect the effects of congestion related delay changes. For
> (a) if congesion occurs and a queue starts to fill then delay increases
> however the packet-to-packet delay change may be small however the
> in delay may cause the jitter buffer to resynchronize at some stage.
> (b) LAN congestion can cause short term spikes in delay, and hence may
> to packet discards. The average packet-to-packet delay variation will not
> reflect this due to the smoothing effect of the averaging algorithm.
> (iv) Jitter - reporting interval
> As jitter is reported as a running average with a scaling factor of 16, an
> RTCP report only describes the jitter level during the 200mS or so prior
> the report being generated and says nothing about the jitter level during
> the much larger period between reports.
> We have spoken to, and worked with, people in the industry that have been
> looking at this issue in detail and have found general agreement with the
> comments above. Unfortunately, there are also a fair number of people
> blindly accept that something must be "ok" because it is "in a standard"
> this obviously raised the concern that incorporating these metrics into
> H series of standards further proliferates this viewpoint.
> Within the IETF AVT group this issue was discussed almost a year ago, and
> the group agreed to develop a set of metrics that were more accurate and
> appropriate for VoIP QoS reporting purposes. These include measures of
> packet loss, packets discarded due to jitter, length and density of bursts
> and gaps (of combined loss and discard), delay, call quality metrics...
> This is contained in the following:-
> I would very much appreciate understanding the technical rationale behind
> incorporating RFC1889 based metrics into VoIP QoS reports, given the
> comments above.
> Alan Clark
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com
More information about the sg16-avd