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

From: Colin Perkins <[email-masked]>
Date: Sun, 1 Jun 2003 11:02:31 -0400

Folks,

Would Magnus' proposal satisfy all involved in this discussion?
Colin

--> Magnus Westerlund <[email-masked]> writes:
> 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:
> > 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
> > 
> > 
> > --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark <[email-masked]>
> > wrote:
> > 
> > 
> >>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.
> >>
> > 
> > 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.
> > 
> > 
> >>(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.
> >>
> > 
> > Simplicity does resonate as a good argument here.
> > 
> > Dave.
> > 
> > 
> >>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,
> >>
> >>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
> >>
> >>
> >>
> >>>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-r
> >epo>>rt- extns-06.pdf
> >>>
> >>>>>Regards,
> >>>>>
> >>>>>Timur Friedman
> >>>>
> >>>>_______________________________________________
> >>>>Audio/Video Transport Working Group
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/avt
> >>>>
> >>>
> >>
> >>_______________________________________________
> >>Audio/Video Transport Working Group
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/avt
> > 
> > 
> > 
> > 
> > ------------------------
> > David R. Oran
> > Cisco Systems
> > 7 Ladyslipper Lane
> > Acton, MA 01720
> > Office: +1 978 264 2048
> > VoIP: +1 408 571 4576
> > Email: [email-masked]
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt
> > 
> 
> 
> -- 
> 
> 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]
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
[email-masked]
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Alan Clark" <[email-masked]>
Date: Sun, 1 Jun 2003 12:01:57 -0400

Colin

I agree with the approach.  I think that we have tried to achieve this with
"undefined" values for most fields - the exceptions were those that related
to packet loss .. why would you want to send a report that didn't at least
contain loss metrics??

Regards

Alan

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Sunday, June 01, 2003 11:03 AM
To: Magnus Westerlund
Cc: [email-masked]; [email-masked]
Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt

Folks,

--
Colin Perkins
[email-masked]

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 02 Jun 2003 11:08:19 -0400

Works for me.
Dave.

--On Sunday, June 01, 2003 11:02 AM -0400 Colin Perkins <[email-masked]> 
wrote:

>> >> 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.
>> >>
>> >
>> >> might be useful to allow one to indicate that a particular parameter
>> >> is not measured by populating the field with some default value.  This
>> >> To: "'Siddiqui, Anwar A (Anwar)'" <[email-masked]>; "'Colin
>> >> Perkins'" <[email-masked]>; "'Timur Friedman'"
>> >> <[email-masked]>; "'Stephen Casner'" <[email-masked]>;
>> >> "'Ramon Caceres'"
>> > tier>>one carriers that are currently specifying that this metric set
>> > be used>
>> >> for
>> >>
>> > 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
>> >>

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