Subject: R: [AVT] - Some - More Comments on draft-clark-avt-rtcpxr-video-02

From: "Fiandra Riccardo" <[email-masked]>
Date: Fri, 14 Jul 2006 19:59:10 +0200

Gentlmen,
I have been following a little the discussion on this video metrics reporting, I would like to make some comments hoping these would be of some help for the work.
First point is that this is very useful stuff and the use of STB or any end-point reports is, in my opinion, one of the most powerful way to measure network and system delivery chain end-to-end performance. As I think known to all of you, using correlation methods, STB reports can be processed to indentify source of impairment (access, backbone, head-end, a certain link, etc) and assess service performance on a continuos way.
 
Here are my comments:
 
-IP Loss metrics.
I think that the number LOST packets and Expected packets should be two known values.
Beyod that, some other information are very useful:
 - Number of loss events with the definition of a loss event as in 3557 (or similar)
 - Number of loss events that violates a minimum defined distance (I think this also is a concept highlighted in 3557)
 -Optionally minimum and maximum loss periods within the report interval would help.
 
Reason for this is that suppose you have 4 (or any little number of ) lost packets in one minute of a video stream (that is roughly 20k packets for 4 Mbps stream) and that you find this number (4) often in your reports. You are very interested in knowing how spread are these lost packets (period an distance), for example to extimate the loss of quality due to the IP network or  to design and dimension a possible FEC system for video.
I think that the parameters I listed let estimate quite effectively these valuable information leaving the implemention simple. If these information are already available by means of currently defined parameters then it would be OK as it is. I am not very familiar with Gap and Bursts, but it looks these parameters are very useful and needed, on the end: would it be possible to add the parameters above to the currently defined one?
 
- Pre FEC - Post FEC
Does this refer to a FEC scheme at above the IP layer? Generally I would define an IP/RTP lost packets and  then the information on how much was recovered by means of a FEC (numeber of FEC corrected packets). Since still FEC for IPTV it is not standard nor widely available I would make it as optional.
 
- within the ITU-T J.241 we stated some of the principles included in this draft text, that is measurement reporting by the STB for IP transport, frame rate and buffer level, are reccomended way of maeasuring IPTV service performance. Even though we did not go into big detail on what and how to report, it definitevely help into stressing that passive in-service feedback-reporting based measurement are greatly helpful for IPTV.
 
I hope this helps somehow,
 
Rgds,
 
Riccardo

________________________________

Da: Alan Clark [mailto:[email-masked]]
Inviato: ven 14/07/2006 13.26
A: 'Fardid, Reza'; [email-masked]
Oggetto: RE: [AVT] More Comments on draft-clark-avt-rtcpxr-video-02

Reza

Thanks for the comments - some of which would apply equally to the RTCP HR
draft.

> Sec 3.1:
> 
> RTP and MPEG Metrics:
>  -Average Jitter is not a useful statistic for real-time
> management of Voice over IP sessions compared
>    to Jitter Percentile.  The IPPM WG is also de-emphasizing
> its use. Has its significance been proven in
>    the context of Video over IP to include it in these
> metrics sub-blocks?

We intend that RTCP XR Video be aligned with RTCP HR in the area of jitter
metrics (where it makes sense).

Also - MAPDV is a very useful metric for VoIP applications, it correlates
well with jitter buffer behavior (e.g. is a good predictor of optimum jitter
buffer size)

> Video/Audio Metrics:
> -Overwhelming network management with too many Video Service
> Quality metrics is not likely to be   productive. In
> particular, when these metrics are expected to be correlated
> to one another and to IP/RTP metrics. A single composite A/V
> quality metric and a control plane quality metric will be
> sufficient for most practical purposes.

These metrics are in discussion in other standards groups that are heavily
service provider oriented - if anything some of these groups are generating
even more metrics :-(

> Sec 3.2:
> 
> It may useful to have an indication of inactive media based
> on a configurable timer to suppress sending the sub-blocks.
> For instance, Block Type = mmm+10 can indicate Null metrics.

Good idea - we can accomodate this or some equivalent

> Sec 3.3:
> 
> Is the Number of IP Packets Expected estimated from the last
> M sessions, as an average or smoothed average?  I wonder
> about the usefulness of this estimate.  Can you please clarify?

This is as per RTCP HR - and is simply to allow you to put some metrics in
context.  I can see a potential issue with multiplexed MPEG streams over a
single IP path .. needs further clarification

Regards

Alan

> Regards,
> Reza Fardid
>
> _______________________________________________
> 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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Jul 2006 11:01:18 +0100

On 14 Jul 2006, at 18:59, Fiandra Riccardo wrote:
...
> - Pre FEC - Post FEC
> Does this refer to a FEC scheme at above the IP layer? Generally I  
> would define an IP/RTP lost packets and  then the information on  
> how much was recovered by means of a FEC (numeber of FEC corrected  
> packets). Since still FEC for IPTV it is not standard nor widely  
> available I would make it as optional.

We have several FEC schemes either completed or under development in  
the IETF.  If they're not sufficient for the IPTV community, it would  
be helpful if someone from that community brought requirements to  
either the AVT or FECFRAME working groups, so we can ensure the  
standards are useful.

Colin