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

["Ulas Kozat" <[e-mail]>]

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

On Jan 30, 2008 8:45 AM, Ali Begen (abegen) <[e-mail]> wrote:

> Hi Rajiv and All,
>
> > 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
>
> We should point out that the stats should be common to all FEC schemes
> (not specific to any scheme, actually).
>
> > 1) Whether FEC repair flow is used by the receiver?
> > 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
> > _______________________________________________
> > FECFRAME-PROTO mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/fecframe-proto
> >
>
> _______________________________________________
> FECFRAME-PROTO mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/fecframe-proto
>

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