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

From: "Even, Roni" <[email-masked]>
Date: Sun, 25 May 2003 15:50:17 +0300

Alan,
I agree with Paul Jones. Your answer may be right but Paul pointed out that
there are other environments that may not need all the stats. So why mandate
it for them. I thought that the extensions are for all and not for a
specific implementation
Thanks
Roni Even

> -----Original Message-----
> From: Alan Clark [mailto:[email-masked]]
> Sent: Sunday, May 25, 2003 3:12 PM
> To: 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
> 
> 
> 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,
> 
> 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-av
> t-rtcp-report-
> > 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
> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt