Subject: [FECFRAME-PROTO] FEC performance stats - text

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 29 Jan 2008 19:18:10 -0500

As per our discussion, this is the text for 'FEC performance stats' I
put together. Please feel free to customize.
~~~~~~~~~
The FEC performance stats are considered useful to assess the
performance of one or more FEC scheme for further performance,
monitoring etc., not necessarily real-time reaction. The stats may
inclue information such as

1) Whether FEC repair flow is used by the receiver? 
2) Which FEC scheme(s)'s repair flow(s)?
3) FEC performance (in terms of source block size etc.).

The propagation of such stats from the receiver to the sender or the 3rd
party is desirable, but optional.
~~~~~~~~~~~
Cheers,
Rajiv

_______________________________________________
FECFRAME-PROTO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe-proto

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Wed, 30 Jan 2008 08:45:55 -0800

Hi Rajiv and All,

> As per our discussion, this is the text for 'FEC performance 
> stats' I put together. Please feel free to customize.
> ~~~~~~~~~
> performance of one or more FEC scheme for further 
> performance, monitoring etc., not necessarily real-time 
> reaction. The stats may inclue information such as

We should point out that the stats should be common to all FEC schemes
(not specific to any scheme, actually). 

> 2) Which FEC scheme(s)'s repair flow(s)?

Combining 1 and 2: Receiver may collect/report information regarding
which repair flow of which FEC scheme it is using back to the sender or
a 3rd party.

> 3) FEC performance (in terms of source block size etc.).

I believe we should expand this a little bit: The FEC schemes in the FEC
Framework use source blocks. Information regarding the number of errors
in a block as a time series can be useful to see the FEC performance
variation over time.

# of errors in block n, # of errors in block n+1, ...

OR, a histogram of errors (in a block) can be useful.

# of blocks that had 0 errors (after FEC), # of blocks that had 1 error
(after FEC), ... 

So, in the long term, we will know that how many source blocks were in
error (and how many errors could not be recovered in those blocks). This
information should be smaller in size compared to the previous one. But,
I think size of the feedback is not a big concern here as it is not
delay critical. Both of them have their own advantages. 

As for the motivation, we can give IPTV as an example. In an IPTV
environment, the QoE requirement is one error per several hours and the
customer pool is very large. So, the information needs to be examined
over a long term (several hours, days maybe). We will use this
performance feedback information for long-term planning, not for
real-time FEC adaptation (as Rajiv already noted).

Any comments?

A question: Is the feedback information intended per receiver, per FEC
scheme or per repair flow? More granular data would provide a better
understanding of what is going on, but a hybrid decoding approach uses
multiple repair flows and it may be difficult which recovered what
packets.

-acbegen

> The propagation of such stats from the receiver to the sender 
> or the 3rd party is desirable, but optional.
> ~~~~~~~~~~~
> Cheers,
> Rajiv

---

From: "Ulas Kozat" <[email-masked]>
Date: Wed, 30 Jan 2008 12:13:15 -0800

I think we need to first mention why we put this monitoring and feedback
facility as a strong suggestion in the FEC framework, e.g. why it is hard if
not impossible to do at the RTP level. The second important point is to give
some examples of
possible feedback information. The third point is that we do not want to
limit the feedback signaling, it can be for accommodating a real-time
feedback need or a non-real time operation decisions.

Example 1 (non-real-time): Multiple FEC flows. Useful information can be
specifying how often a particular FEC flow actually helped the recovery
process.The information is reported to a 3rd box or back to the source.
Example 2 (real-time): Feedback information can be whether all the missing
symbols in a source block are recovered or not in a multicast or unicast
session. The information is reported back to the source, which then triggers
the early transmission of the next source block.
Example 3: Feedback information in terms of histogram of number of corrected
symbols per source block by the FEC scheme.

Ulas