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

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

I also agree with the comments about timing considerations, i.e., many
receivers need to receive packets for a source block within a certain time
window, as otherwise they are useless, and this has an impact on how the FEC
sender operates.


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

> 
> 
>> -----Original Message-----
>> From: Luby, Michael [mailto:[e-mail]]
>> Sent: Friday, February 11, 2011 11:56 AM
>> To: Ali C. Begen (abegen); Vincent Roca; [e-mail]
>> Subject: Re: [Fecframe] Managing losses between the sending application and
>> the FECFRAME instance
>> 
>> 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.
> 
> Yup, packet loss or re-ordering can be dealt with to some extent but beyond
> the limit, the fecframe sender will continue with what it has.
>  
>> 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).
> 
> Also, true but in that case, one needs to make sure the fecframe sender will
> not see any gaps in the source packets.
>  
>> 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
> 
> And within a desired delay.
> 
>> 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).
> 
> Then, we make the recommendation above (I guess I prefer SHOULD) but then add
> that the fecframe sender/receiver implementation needs to consider the impact
> of such problems.
>  
> -acbegen
> 
>> 
>> 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
>