Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Vincent Roca
> Sent: Friday, February 11, 2011 5:13 AM
> To: fecframe@ietf.org
> Subject: [Fecframe] Managing losses between the sending application and the FECFRAME instance
> 
> And this is point 2:
> 
> Managing losses between the sending application and
> the FECFRAME instance
> ---------------------------------------------
> 
> It is often implicitly assumed in FEC Schemes that there
> is no loss between the sending application and the
> FECFRAME Instance that performs FEC encoding. That's
> reasonable (we apply FECFRAME on lossy channels)
> but we should not design solutions that break if ever
> this happens, no matter the reason.
> 
> (NB: this may be caused by having FECFRAME on a
> middlebox whereas the application flow is generated
> on a remote server. Or perhaps because of strange
> (bad?) FECFRAME implementations that may loose
> ADUs, e.g. in case the machine is frozen during a few
> seconds, or for any other reason, bugs included.)
> 
> All FEC Schemes that make use of an Explicit Source
> FEC Payload ID (be it Generic or not ;-)) are safe, since
> they define their own sequential numbering space.
> 
> However this is not the case for FEC Schemes that reuse
> (for instance) the RTP sequence number. In that case, an
> erasure between the application (therefore RTP) and
> the FECFRAME Instance creates a gap in the RTP sequence
> number space that needs to be signaled somehow to the
> receiver.
> 
> The simplest way of addressing this situation consists in
> saying that source block creation needs to consider this
> possibility and start a new block if ever this happens.
> Since all the existing FEC Repair Payload IDs for FEC
> schemes that rely on RTP sequence numbers, signal to
> the receiver in the FEC Repair Payload ID:
>   - the base RTP SN of the block and
>   - the source block length,
> that's sufficient.

I like this fix, but maybe we should add a note. Since this will cause source block sizes to vary over time, the overhead may also vary over time. And so this should be a surprise to the sender or receiver. We should add a small note on this.

-acbegen

> A consequence is that the block size can vary if there
> are erasures on this path, and this phenomenon is not
> under control. As an extreme case:
> 
> ...<pkt SN=6> LOST <pkt SN=8> LOST <pkt SN=10>...
> -------------------------------------------> time
> 
> There's a block that is composed of a single packet
> (SN=8). That's bad but the FEC Scheme does not break.
> And of course this situation is the sign that something
> should be re-considered in the design.
> 
> So this is an easy fix to the problem, that does not
> require major changes to current I-D.
> 
> This discussion is already included in our new O&M
> proposal, section 10.2, "Within End-Systems vs. within
> Middleboxes".
> 
> Opinions?
> 
> Cheers,
> 
>     Vincent and Ali
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe