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

["Luby, Michael" <[e-mail]>]

It seems like this is an unbounded problem.  What about the case when there
is out of order packet delivery, that can cause the mechanism below to cut a
source block and then start a new one packet source block, etc.

There are also cases where the receivers cannot handle variable sized source
blocks (they are expecting exactly so many packets of a fixed size per
source block), e.g., because that is how the FEC scheme is defined.  The
solution proposed doesn't work for this case as well (it will really mess up
the receivers).

I think a better approach is that all the packets from the original source
either MUST or SHOULD reach the FEC encoder in their proper sequence.  What
happens when that is not true seems to be an unbounded problem, and I don't
think we can solve it (out of scope of the specification).


On 2/11/11 6:17 AM, "Ali C. Begen (abegen)" <[e-mail]> wrote:

> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Vincent Roca
>> Sent: Friday, February 11, 2011 5:13 AM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/fecframe
> _______________________________________________
> Fecframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe