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

[Vincent Roca <[e-mail]>]

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