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

From: "Cole, Robert G (Bob), ALABS" <[email-masked]>
Date: Sun, 1 Jun 2003 17:43:07 -0500

Colin,

I agree with Alan.  We ought to consider having a minimum
level of  compliance, else don't implement.  Beyond this minimum,
we allow for vendors choosing which of the remaining they wish to
implement.

Bob Cole

> -----Original Message-----
> From:	Alan Clark [SMTP:[email-masked]]
> Sent:	Sunday, June 01, 2003 4:02 PM
> To:	Colin Perkins; Magnus Westerlund
> Cc:	[email-masked]
> Subject:	RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt
> 
> 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,
> 
> 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
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt