Subject: [Fecframe] Framework draft section on feedback

From: Mark Watson <[email-masked]>
Date: Mon, 17 Nov 2008 09:30:28 -0600

Here¹s what I suggest for the section on feedback in the framework draft:

<t>Many applications require some kind of feedback on transport performance:
how much data arrived at the receiver, at what rate, when etc. When FEC is
added to such applications, feedback mechanisms may also need to be enhanced
to report on the performance of the FEC (for example how much lost data was
recovered by the FEC).</t>
<t>When used to provide instrumentation for engineering purposes, it is
important to remember that FEC is generally applied to relatively small
blocks of data (in time) and so feedback information averaged over longer
periods of time than the FEC block size will likely not provide sufficient
information for engineering purposes. For example see <xref
target="I-D.ietf-avt-post-repair-rtcp-xr"></xref>.</t>
<t>Applications which used feedback for congestion control purposes MUST
calculate such feedback on the basis of packets received before FEC recovery
is applied. If this requirement conflicts with other uses of the feedback
information then the application MUST be enhanced to support both
information calculated pre- and post- FEC recovery. This is to ensure that
congestion control mechanisms operate correctly based on congestion
indications recieved from the network, rather than on post-FEC recovery
information which would give an inaccuate picture of congestion
conditions.</t>
<t>New applications which require such feedback SHOULD use RTP/RTCP <xref
target="RFC3550"></xref>.</t>

...Mark
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: David R Oran <[email-masked]>
Date: Mon, 17 Nov 2008 18:06:41 -0500

this WFM.
DaveO.

On Nov 17, 2008, at 10:30 AM, Mark Watson wrote:

> Here’s what I suggest for the section on feedback in the framework  
> draft:
>
> <t>Many applications require some kind of feedback on transport  
> performance: how much data arrived at the receiver, at what rate,  
> when etc. When FEC is added to such applications, feedback  
> mechanisms may also need to be enhanced to report on the performance  
> of the FEC (for example how much lost data was recovered by the  
> FEC).</t>
> <t>When used to provide instrumentation for engineering purposes, it  
> is important to remember that FEC is generally applied to relatively  
> small blocks of data (in time) and so feedback information averaged  
> over longer periods of time than the FEC block size will likely not  
> provide sufficient information for engineering purposes. For example  
> see <xref target="I-D.ietf-avt-post-repair-rtcp-xr"></xref>.</t>
> <t>Applications which used feedback for congestion control purposes  
> MUST calculate such feedback on the basis of packets received before  
> FEC recovery is applied. If this requirement conflicts with other  
> uses of the feedback information then the application MUST be  
> enhanced to support both information calculated pre- and post- FEC  
> recovery. This is to ensure that congestion control mechanisms  
> operate correctly based on congestion indications recieved from the  
> network, rather than on post-FEC recovery information which would  
> give an inaccuate picture of congestion conditions.</t>
> <t>New applications which require such feedback SHOULD use RTP/RTCP  
> <xref target="RFC3550"></xref>.</t>
>
> ...Mark

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Nov 2008 16:24:13 -0800

I am OK with this text as well. There are just a couple of typos in the
text :)
 
-acbegen

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Watson
	Sent: Monday, November 17, 2008 7:30 AM
	To: [email-masked]
	Subject: [Fecframe] Framework draft section on feedback

	Here's what I suggest for the section on feedback in the
framework draft:
	
	<t>Many applications require some kind of feedback on transport
performance: how much data arrived at the receiver, at what rate, when
etc. When FEC is added to such applications, feedback mechanisms may
also need to be enhanced to report on the performance of the FEC (for
example how much lost data was recovered by the FEC).</t>
	<t>When used to provide instrumentation for engineering
purposes, it is important to remember that FEC is generally applied to
relatively small blocks of data (in time) and so feedback information
averaged over longer periods of time than the FEC block size will likely
not provide sufficient information for engineering purposes. For example
see <xref target="I-D.ietf-avt-post-repair-rtcp-xr"></xref>.</t>
	<t>Applications which used feedback for congestion control
purposes MUST calculate such feedback on the basis of packets received
before FEC recovery is applied. If this requirement conflicts with other
uses of the feedback information then the application MUST be enhanced
to support both information calculated pre- and post- FEC recovery. This
is to ensure that congestion control mechanisms operate correctly based
on congestion indications recieved from the network, rather than on
post-FEC recovery information which would give an inaccuate picture of
congestion conditions.</t>
	<t>New applications which require such feedback SHOULD use
RTP/RTCP <xref target="RFC3550"></xref>.</t>
	
	...Mark

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Nov 2008 19:49:05 -0500

On Nov 17, 2008, at 6:06 PM, David R Oran wrote:

>> mechanisms may also need to be enhanced to report on the  
>> performance of the FEC (for example how much lost data was  
>> <t>When used to provide instrumentation for engineering purposes,  
>> it is important to remember that FEC is generally applied to  
>> relatively small blocks of data (in time) and so feedback  
>> information averaged over longer periods of time than the FEC block  
>> size will likely not provide sufficient information for engineering  
>> purposes.

s/engineering purposes/FEC engineering purposes/

I am not sure that this sentence wouldn't be better as

it is important to remember that FEC is generally applied to  
relatively small blocks of data (in time) and so FEC feedback  
information may need to be averaged over longer periods of time than  
the FEC block size for other purposes.

Regards
Marshall

>> For example see <xref target="I-D.ietf-avt-post-repair-rtcp-xr"></ 
>> xref>.</t>
>> MUST calculate such feedback on the basis of packets received  
>> before FEC recovery is applied. If this requirement conflicts with  
>> other uses of the feedback information then the application MUST be