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

> -----Original Message-----
> From: Luby, Michael [mailto:luby@qualcomm.com]
> Sent: Friday, February 11, 2011 11:56 AM
> To: Ali C. Begen (abegen); Vincent Roca; fecframe@ietf.org
> 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)" <abegen@cisco.com> wrote:
> 
> >
> >
> >> -----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
> > _______________________________________________
> > Fecframe mailing list
> > Fecframe@ietf.org
> > https://www.ietf.org/mailman/listinfo/fecframe