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

From: Vincent Roca <[email-masked]>
Date: Fri, 11 Feb 2011 11:13:27 +0100

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.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Feb 2011 06:17:39 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Roca
> Sent: Friday, February 11, 2011 5:13 AM
> To: [email-masked]
> Subject: [Fecframe] Managing losses between the sending application and the FECFRAME instance
> 
> And this is point 2:
> 

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
 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 11 Feb 2011 08:56:19 -0800

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)" <[email-masked]> wrote:

> 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
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Feb 2011 09:03:16 -0800

> From: Luby, Michael [mailto:[email-masked]]
> Sent: Friday, February 11, 2011 11:56 AM
> To: Ali C. Begen (abegen); Vincent Roca; [email-masked]
> Subject: Re: [Fecframe] Managing losses between the sending application and the FECFRAME instance
> 

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.
 
> solution proposed doesn't work for this case as well (it will really mess up

Also, true but in that case, one needs to make sure the fecframe sender will not see any gaps in the source packets.
 
> either MUST or SHOULD reach the FEC encoder in their proper sequence.  What

And within a desired delay.

> 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

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 11 Feb 2011 13:54:06 -0500

RTP retransmission may also be useful in such cases (source to FECFRAME
instance) , if the delay increase is acceptable.  That might be worth
noting.

Stephen Botzko

On Fri, Feb 11, 2011 at 12:03 PM, Ali C. Begen (abegen) <[email-masked]>wrote:

> 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.
>
> Also, true but in that case, one needs to make sure the fecframe sender
> will not see any gaps in the source packets.
>
> 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
>
> >
> > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > >> Of Vincent Roca
> > >> Subject: [Fecframe] Managing losses between the sending application
> and the
> > >> FECFRAME instance
> > >>
> > >> And this is point 2:
> > >>

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 11 Feb 2011 11:40:58 -0800

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)" <[email-masked]> wrote:

> 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
> 
>>