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

[Stephen Botzko <[e-mail]>]

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