Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

From: "Alan Clark" <[email-masked]>
Date: Thu, 22 May 2003 10:14:13 -0400

Anwar

This was brought up several weeks ago on the mailing list.  This approach
was taken deliberately for several reasons:-

(i) To encourage implementors to move towards implementing the complete set
of metrics.  I've socialized this data set with a variety of service
providers, enterprise network managers, equipment manufacturers and there
seems to be general agreement that this metrics set provides a good "minimum
set" for diagnosing VoIP performance problems.

(ii) There is overhead associated with identifying whether fields are or are
not present (see Colin Perkins comment on this issue several weeks ago).

I am aware of several major equipment manufacturers and DSP software vendors
that intend to fully implement the RTCP XR VoIP metrics, and several tier
one carriers that are currently specifying that this metric set be used for
VoIP service management. There is also considerable interest from other
standards groups in this work.  

Regards

Alan Clark
Telchemy

-----Original Message-----
From: Siddiqui, Anwar A (Anwar) [mailto:[email-masked]]
Sent: Thursday, May 22, 2003 9:23 AM
To: Colin Perkins; Timur Friedman; Stephen Casner; [email-masked];
Ramon Caceres
Cc: [email-masked]
Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt

Timur, Alan

I did mention this during last IETF session. And I believe few other people
also have similar concerns. So here is the issue I am requesting this be
reconsidered and if possible be avoided.

------------------------------
Is there anyway that we can avoid hard coding VoIP metrics like it is
identified in this draft. Its not the usefulness of the metrics that I am
having difficulties with. I actually believe they are useful parameters to
be included in RTCP. But its just that its hardcoded right now ....and if an
RTP source does not have parameters to report it will keep sending these
default hard coded values! It is this kind of hardcoding in SR/RR reports
that makes us do this XR reports now. So I am requesting if it possible such
hard coding of VoIP metrics be avoided.
-------------------------------

Thanks in advance

Anwar 

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Timur Friedman" <[email-masked]>
Cc: <[email-masked]>; "Stephen Casner" <[email-masked]>; "Alan Clark"
<[email-masked]>; "Ramon Caceres" <[email-masked]>; "Kevin C.
Almeroth" <[email-masked]>; "Robert Cole" <[email-masked]>; "Nick
Duffield" <[email-masked]>; "Kaynam Hedayat"
<[email-masked]>; "Kamil Sarac" <[email-masked]>; "Magnus
Westerlund" <[email-masked]>
Sent: Monday, May 19, 2003 8:05 PM
Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt

> Thanks. Unless there are objections, we intend to request that the IESG
> consider this version for publication as a proposed standard.
>
> Colin
>
>
> --> Timur Friedman writes:
> >Hello,
> >
> >Please find attached the latest version of the RTP Control Protocol
Extended
> >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt.
> >
> >This draft was produced in response to AVT working group last call
comments.
> >
> >In addition to the changes discussed online on the AVT list, some
additional
> >detail has been added to the SDP signaling section, to allow individual
flags
> >in the Statistics Summary report blocks to be signaled.  Also, default
values
> >have been specified for the VoIP metrics section in places where there
might
> >have been some confusion about what to do if no packets had been
received.
> >And the time frame over which some of the VoIP fields are calculated has
> >also been specified.
> >
> >A PDF version of this draft is available at the following URL:
> >
>
>http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-report-
extns-06.pdf
> >
> >Regards,
> >
> >Timur Friedman
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

---

From: "Siddiqui, Anwar A (Anwar)" <[email-masked]>
Date: Thu, 22 May 2003 09:23:20 -0400

Timur, Alan

I did mention this during last IETF session. And I believe few other people also have similar concerns. So here is the issue I am requesting this be reconsidered and if possible be avoided.

------------------------------
Is there anyway that we can avoid hard coding VoIP metrics like it is identified in this draft. Its not the usefulness of the metrics that I am having difficulties with. I actually believe they are useful parameters to be included in RTCP. But its just that its hardcoded right now ....and if an RTP source does not have parameters to report it will keep sending these default hard coded values! It is this kind of hardcoding in SR/RR reports that makes us do this XR reports now. So I am requesting if it possible such hard coding of VoIP metrics be avoided.
-------------------------------

Thanks in advance

Anwar 

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Timur Friedman" <[email-masked]>
Cc: <[email-masked]>; "Stephen Casner" <[email-masked]>; "Alan Clark"

Extended
comments.
additional
flags
values
might
received.
extns-06.pdf

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 May 2003 10:39:55 -0400

Alan,

I still think we should allow every field to be optional.  I recognize the
desire to encourage reporting a complete set of stats, but I would tend to
believe that there will be environments wherein not all stats are necessary.

Now, not to sound that I'm in disagreement with Anwar, but I think it might
be useful to allow one to indicate that a particular parameter is not
measured by populating the field with some default value.  This default
value would not indicate a "valid", but be an indicator of the fact that the
field is not present.  This would address your concern that the fields and
reporting blocks are fixed in size.

I also realize that some time will be wasted to determine that a measurement
is not present, but the same amount of time will be consumed by a system to
extract a valid value today.  So, the system performance is the same, albeit
with potentially less useful data.

Paul

----- Original Message ----- 
From: "Alan Clark" <[email-masked]>
To: "'Siddiqui, Anwar A (Anwar)'" <[email-masked]>; "'Colin Perkins'"
<[email-masked]>; "'Timur Friedman'" <[email-masked]>; "'Stephen
Casner'" <[email-masked]>; "'Ramon Caceres'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 22, 2003 10:14 AM
Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

---

From: "Alan Clark" <[email-masked]>
Date: Sun, 25 May 2003 08:11:43 -0400

Paul

If you bear in mind that RTCP XR is likely to be used to exchange
information between endpoints through the media path then there are several
implementation considerations.

(i) It is quite likely that intermediate systems such as Ethernet switches,
edge routers and shapers may scan RTCP XR payloads.  A number of such
systems already do this with RTCP SR/RR reports, either for QoS monitoring
or for active control.  With switch speeds getting to 10 gigabit then it is
important to keep parsing complexity very low.

(ii) High density gateways are pushing the density of CODECs per DSP but
also pushing RTP packet processing into the DSP.  This places severe
constraints on the available program and data memory space - again a strong
incentive to keep things as simple as possible.

Regards

Alan

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]]
Sent: Saturday, May 24, 2003 10:40 AM
To: [email-masked]; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins';
'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres'
Cc: [email-masked]
Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

Alan,

Paul

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 25 May 2003 17:46:26 -0400

--On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark <[email-masked]> 
wrote:

> information between endpoints through the media path then there are
> several implementation considerations.
>
> (i) It is quite likely that intermediate systems such as Ethernet
> switches, edge routers and shapers may scan RTCP XR payloads.  A number
> of such systems already do this with RTCP SR/RR reports, either for QoS
> monitoring or for active control.  With switch speeds getting to 10
> gigabit then it is important to keep parsing complexity very low.
>
Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put 
another way, I don't find snooping to be a valid argument in favor of fast 
parsing.
That said, I do prefer to have an encoding which uses "value not valid" 
semantics rather than "value not present", because, like is done with IEEE 
floating point, it has much better robustness in the face of cascaded 
computations that may use inappropriate arithmetic. In fact, I think that's 
where the real savings is - in not having to scatter your data reduction 
for stats with a zillion if tests and multiple code patsh based on what dat 
ayou have. You just do the computation and error propagation will take care 
of ensuring that invalid stuff is marked as such.

> constraints on the available program and data memory space - again a
> strong incentive to keep things as simple as possible.
>
Simplicity does resonate as a good argument here.

Dave.

> Now, not to sound that I'm in disagreement with Anwar, but I think it
> might be useful to allow one to indicate that a particular parameter is
> not measured by populating the field with some default value.  This
> default value would not indicate a "valid", but be an indicator of the
> fact that the field is not present.  This would address your concern that
> the fields and reporting blocks are fixed in size.
>
> I also realize that some time will be wasted to determine that a
> measurement is not present, but the same amount of time will be consumed
> by a system to extract a valid value today.  So, the system performance
> is the same, albeit with potentially less useful data.
>
> Paul
>
> <[email-masked]>; "'Timur Friedman'" <[email-masked]>;
> "'Stephen Casner'" <[email-masked]>; "'Ramon Caceres'"
> <[email-masked]> Cc: <[email-masked]>
>> having difficulties with. I actually believe they are useful parameters
>> to be included in RTCP. But its just that its hardcoded right now
>> ....and if
> an
>> http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo
>> rt- extns-06.pdf
>> > >
>> > > Regards,
>> > >
>> > > Timur Friedman

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: "Alan Clark" <[email-masked]>
Date: Sun, 25 May 2003 19:01:20 -0400

Dave,

RTCP XR can be extremely useful in supporting problem detection, call
admission control etc. as it provides a fast method for a probe, analyzer,
session controller... to get call quality related information from the
endpoint.  In general the data available in RTCP XR should not represent a
security concern - unlike SDES - and hence (I think) there is no advantage
to applying encryption and considerable disadvantage.

In an Enterprise network using VPN for inter-site connections you could
consider using SRTP for RTP payloads and rely on the VPN tunnel to protect
RTCP SDES information, which is a good compromise between management and
security.  In some other applications, notably IP Centrex, the service
provider is already handling signaling - RTCP XR gives them feedback on call
quality from the customer desktop and alerts them to customer LAN problems
that affect call quality.

Regards

Alan

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Sunday, May 25, 2003 5:46 PM
To: Alan Clark; Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin
Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres'
Cc: [email-masked]
Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

Dave.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 May 2003 09:10:02 +0200

Hi,

Looking at this discussion it seems that one can make two resolutions.

1. Do not mandate calculation of all fields in report block. I would 
think that a SHOULD calculate all field is a good level. Text motivating 
that all fields should be calculated is good.

2. Keep the structure as is, define for each field a "NOT VALID" value.

I think this is reasonable compromise. It keeps the VoIP report block 
simple to process and at the same time a implementor that is unable to 
provide a measurement does not need to.

Best Regards

Magnus

Alan Clark wrote:
>>>(i) To encourage implementors to move towards implementing the complete
>>
>>set
>>
>>>seems to be general agreement that this metrics set provides a good
>>
>>"minimum
>>
>>>(ii) There is overhead associated with identifying whether fields are or
>>
>>are
>>
>>>I am aware of several major equipment manufacturers and DSP software
>>
>>vendors
>>
>>>one carriers that are currently specifying that this metric set be used
>>
>>for
>>
>>>I did mention this during last IETF session. And I believe few other
>>
>>people
>>
>>>that makes us do this XR reports now. So I am requesting if it possible
>>
>>such
>>
>>>>>And the time frame over which some of the VoIP fields are calculated
>>>>
>>has
>>
>>>>>also been specified.
>>>>>

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: David Oran <[email-masked]>
Date: Mon, 26 May 2003 10:30:52 -0400

--On Sunday, May 25, 2003 7:01 PM -0400 Alan Clark <[email-masked]> 
wrote:

> endpoint.
Of course. I agree 100%. I only was reacting to using snooping as a 
mainstream way to see the packets. What we really need is 3rd-party RTCP 
monitoring that works for unicast sessions as well as multicast sessions.

> In general the data available in RTCP XR should not represent a
How do you know what is RTCP without parsing every packet at wire rate? 
What about RTP/RTCP over TCP? What about NATs that move RTP/RTCP into 
arbitrary ports? What about eCRTP with tunnels? What about RTP through 
IPSEC VPN tunnels?

I would say there is no downside to encrypting RTCP since snooping monitors 
are a losing proposition anyway and I wouldn't want to stand up and try to 
prove that there is no security advantage to encrypting the packets.

I can actually think of an advantage - it's pretty "out-there", but just 
illustrative. Suppose I have an ISP with whom I've contracted for 
"scavenger" style voice service. What they do is monitor my RTCP and if I'm 
getting too good voice service in the middle of the day they stomp on my 
session just to "encourage" me to buy their higher grade of service.

Another advantage of encryption is if somebody is using the RTCP for 
billing adjustments. On the assumption I can't hide my quality stuff from 
eavesdroppers, I may instead be motivated to lie, which is to everybody's 
detriment.

All that said, I am in fact in complete agreement with the current spec as 
far as using fixed reporting blocks rather than variable length encoding, 
so perhaps we should just drop this aspect of the discussion.

> provider is already handling signaling - RTCP XR gives them feedback on
> call quality from the customer desktop and alerts them to customer LAN
> problems that affect call quality.
>
It's bad enough to have to do heurisitic packet inspection to separate out 
different flows. Are you seriously suggesting that a VPN gateway separate 
out invididual packets of a flow and send only some through the tunnel? 
Ycccchh.

Dave.

> computations that may use inappropriate arithmetic. In fact, I think
> that's where the real savings is - in not having to scatter your data
> reduction for stats with a zillion if tests and multiple code patsh based
> on what dat ayou have. You just do the computation and error propagation
> will take care of ensuring that invalid stuff is marked as such.
>
>> I still think we should allow every field to be optional.  I recognize
>> the desire to encourage reporting a complete set of stats, but I would
>> tend to believe that there will be environments wherein not all stats are
>> necessary.
>>
>>> This was brought up several weeks ago on the mailing list.  This
>>> approach was taken deliberately for several reasons:-
>>>
>>> providers, enterprise network managers, equipment manufacturers and
>>> there seems to be general agreement that this metrics set provides a
>>> good
>> "minimum
>>> that intend to fully implement the RTCP XR VoIP metrics, and several
>>> tier one carriers that are currently specifying that this metric set be
>>> used
>> for
>>> identified in this draft. Its not the usefulness of the metrics that I
>>> am having difficulties with. I actually believe they are useful
>>> parameters to be included in RTCP. But its just that its hardcoded
>>> right now ....and if
>> an
>>> default hard coded values! It is this kind of hardcoding in SR/RR
>>> reports that makes us do this XR reports now. So I am requesting if it
>>> possible
>> such
>>> > Thanks. Unless there are objections, we intend to request that the
>>> > IESG consider this version for publication as a proposed standard.
>>> >
>>> > Colin
>>> >
>>> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 May 2003 16:19:37 -0400

Dave,

My original point was not related to variable reporting block sizes.
Rather, it was related to the requirement that we report so many fields if
we report anything at all.  For example, if the flag to report jitter is
included in the Statistics Summary Report block, then all of the fields
min_jitter, max_jitter, mean_jitter, and dev_jitter MUST be included.
Perhaps I don't want to waste the processing time to calculate the standard
deviation or mean?  One is left with no choice, unfortunately.

What I'd like to see is either a flag to indicate that each of those fields
are present or to fill the fields with some "dummy" value that is known to
indicate that the value is not provided.  Granted, having the stats there
might be helpful, but it somewhat removes the flexibility from the equipment
manufacturer.  I'd question why we even have any flags at all to indicate
the presence/absence of certain fields, if we don't want to be flexible with
sub-fields with a particular group of fields.

Paul

----- Original Message ----- 
From: "David Oran" <[email-masked]>
To: "Alan Clark" <[email-masked]>; "Paul E. Jones"
<[email-masked]>; "'Colin Perkins'" <[email-masked]>; "'Timur
Friedman'" <[email-masked]>; "'Stephen Casner'" <[email-masked]>;
"'Ramon Caceres'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 26, 2003 10:30 AM
Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 26 May 2003 19:16:49 -0400

Paul

The VoIP metrics block is intended to be relatively self contained, hence
you shouldn't need to use other blocks in normal usage.

It is quite common to report jitter, as in RFC1889, however this can
actually be quite difficult to relate to VoIP performance.  Quite a few test
equipment vendors have tried to use RTCP stats as a basis for VoIP QoS
reporting and some have tried to use packet-to-packet delay variation as a
basis for estimating jitter buffer size, which doesn't work too well (see
below).  The approach taken in the RTCP XR VoIP metrics is based on the
premise that in a VoIP (or similar real time) application you "really" need
to know what the effects of jitter are - i.e. what proportion of packets are
getting discarded and what is the jitter buffer size.   This is preferable
since jitter itself is a time varying effect and most jitter buffers exhibit
dynamic behavior.

High levels of jitter are often due to excessive congestion on access links,
narrow bandwidth WAN connections and 10 Mbit LANs.  This leads to time
varying jitter levels, and to short term variations in delay (due to the
integrating effect of queues).  If we use PPDV to measure jitter then the
following problems can result:-

(i) A short term increase in traffic level can cause the queue in a router
to fill, leading to a short term increase in delay accompanying an increase
in jitter.  The observable increase in PPDV may be quite small however the
jitter buffer may run out of packets due to the delay increase and hence
resynchronize.  Say the jitter buffer was set to 50mS, the jitter level
increased from 10mS to 30mS and the delay increased by 30mS - PPDV would see
a 30mS jitter level and would not predict any discards.  If on the other
hand we measured packet delay variation with respect to the base delay (i.e.
absolute packet delay variation) then we would see an apparent increase in
delay variation from 10mS to 60mS and would predict excessive numbers of
discards.

(ii) Say we have two RTP streams, each suffering from 10Mbit Ethernet + hub
LAN congestion, and our VoIP end systems have identical adaptive jitter
buffers.  10BaseT congestion can lead to substantial packet delay
transients, which would lead to discards.   On one stream the congestion is
fairly uniform, and on the other it is concentrated in short periods.  In
the first case, having an adaptive jitter buffer may not be too helpful as a
delay transient may lead to the jitter buffer increasing in size however the
following packets may have less delay variation.  In the second case the
adaptive jitter buffer can be very helpful, as the increase in jitter
triggers a buffer size increase which reduces discards during the following
period of high delay variation.

(iii) Packet delay variation measurements, for example that used in RFC1889,
provide snapshots of the jitter level at some point in time.  RFC1889 uses a
running average with a scaling factor of 16, and hence provides some idea of
the jitter level during the preceding few hundred milliseconds.  It is quite
difficult to conceive of a jitter measurement that would provide a good
cumulative view of the RTP session to date - unless you started measuring
means/ standard deviations and potentially skew and kurtosis.  The number of
packets discarded due to jitter is a "factual" measurement that provides a
view of the cumulative effect of jitter on the RTP session.

>From a practical perspective, knowing the discard rate and jitter buffer
size saves much guesswork.  If the discard rate is zero and the jitter
buffer size is high then it may be safe to reduce the jitter buffer size. If
the discard rate is high and the jitter buffer is fixed and small then it
would make sense to increase it's size.  etc.

Regards

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Paul E.
Jones
Sent: Monday, May 26, 2003 4:20 PM
To: David Oran; Alan Clark; 'Colin Perkins'; 'Timur Friedman'; 'Stephen
Casner'; 'Ramon Caceres'
Cc: [email-masked]
Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

Dave,

Paul