Re: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe)

[Vincent Roca <[e-mail]>]

Hello David,

> 1)
> 2)

I'm okay too.


> 3)
>   [...]
>
>   Implementers SHOULD make feedback available using an in-band or
>   out-of-band asynchronous reporting mechanism. A standardized
>   reporting mechanism, such as syslog or SNMP notifications, is
>   RECOMMENDED.

I have several comments WRT the above paragraph.

* syslog is standardized in RFC 5424, so we probably need to refer
to this RFC, and similarly we need to refer to RFC 3411 for SNMP.
Since implementing/using one of these protocols is RECOMMENDED, these
references should go to the Normative References section (both are
Standards Track documents, so there's no downward ref issue here).

* Otherwise I'm a little confused by the juxtaposition of the two
sentences. The first one says that an in-band solution, e.g. RTCP
based, is RECOMMENDED (as one solution among others), while the
second sentences RECOMMENDS the use of an out-of-band solution.

If I put these two comments together, I would suggest something like:

    Implementers SHOULD make feedback available using either an in-band
    or out-of-band asynchronous reporting mechanism. When an out-of-band
    solution is preferred, a standardized reporting mechanism, such as
    syslog [RFC5424] or SNMP [RFC3411], is RECOMMENDED.

* Is that sufficient to increase the probability that independent
products interoperate? No, we need to go a bit further and define
SNMP notification/syslog message formats. So the followup should be
to start defining a MIB... Unless the implementer chooses an in-band,
RTCP based, approach, which already includes useful information
from the FECFRAME point of view.

* We RECOMMEND two different out-of-band solutions, which creates
interoperability risks. As I understand, mappings exist between the
syslog/SNMP solution: RFC 5675 explains how to map SNMP notifications
to syslog messages, while RFC 5676 discusses the opposite mapping.
I don't know if these mappings are common or not, but this may also
increase the probability that different products interoperate.
So we can perhaps add a third sentence:

    When required, a mapping mechanism between the syslog and SNMP
    reporting mechanisms COULD be used, as described in [RFC5675]
    and [RFC5676].


> 4)
I'm okay with your proposal plus Ali's update.


> 5)

I admit understanding this paragraph is somewhat difficult.
The first RECOMMENDATION is within the first paragraph:

      ...it is RECOMMENDED that the paths
      between the hosts where the sending applications run and the
      middlebox that performs FEC encoding be as reliable as possible

This is only a RECOMMENDATION and in practice, for whatever reason,
there MIGHT be a packet loss/reordering/delayed delivery on this
path (i.e. sending application -> FECFRAME middlebox). Therefore
the FECFRAME instance MUST NOT break if ever this happens, so we
need to look a little bit further and give RECOMMENDATIONS on
how to design a FEC Scheme that tolerates it. Just in case...

It turns out the issue only arises with FEC Schemes that do NOT
use any Explicit Source FPI (since there is no renumbering of
symbols that are actually part of a source block). There are a few
solutions (some of them mentioned). Which one is preferred is
use-case specific (depends on the flow nature).

IMO this discussion SHOULD be included in the framework document
and any FEC Scheme that is concerned by the problem SHOULD at least
highlight the general requirement and point to this framework
discussion.

Initial discussion:
http://www.ietf.org/mail-archive/web/fecframe/current/msg00841.html
More recently, WRT RTP for Raptor(Q):
http://www.ietf.org/mail-archive/web/fecframe/current/msg00884.html
The same applies to our draft-galanos-fecframe-rtp-reedsolomon-03
document, of course.

In order to help clarify the point, here's what I suggest:

NEW:
<added>
    At the sending side, the general reliability RECOMMENDATION
    for the path between the sending applications and the middlebox
    is important but it MAY NOT guaranty that a loss, reordering or
    important delivery delay cannot happen, for whatever reason.
    If such a rare event happens, this event SHOULD NOT compromize
    the operation of the FECFRAME instances, neither at the sending
    nor receiving side.
    This is particularly important
</added>
    with FEC schemes that do not modify the ADU for backward
    compatibility purposes (i.e. do not use any Explicit Source FEC
    Payload ID) and rely for instance on the RTP sequence number field
    to identify FEC source packets within their source block. In this
    case, packet loss or packet reordering leads to a gap in the RTP
    sequence number space seen by the FECFRAME instance.  Similarly,
    varying delay in delivering packets over this path can lead to
    significant timing issues.  With FEC schemes that indicate in the
    Repair FEC Payload ID, for each source block, the base RTP
    sequence number and number of consecutive RTP packets that belong
    to this source block, a missing ADU or an ADU delivered out of
    order could cause the FECFRAME sender to switch to a new source
    block.  However, some FEC schemes and/or receivers may not
    necessarily handle such varying source block sizes.  In this case,
    another solution SHOULD be considered that is use-case specific
    and whose consequences need to be carefully considered (e.g., by
    duplicating the last ADU received before the loss, or by inserting
    a zero'ed ADU, depending on the ADU flow nature).


> 6)

I agree with Ali's comment.


> 7) regarding ADU Bundles, the use of passive voice hurts this text:
> OLD
>    "the repair flow(s) SHOULD only be received by
>     receivers that are authorized to receive all the associated ADU
>     flows."
>NEW:
>     "receivers SHOULD drop the repair flow(s) unless they are
>      authorized to receive all the associated ADU flows."

No, the new text changes the initial intent. The "SHOULD" is for the
sender, not for the receiver. Since there's a misunderstanding, this
means that the original text is bad, so you can blame us for that.
So here is a new proposal:

OLD:
      Therefore, when defining the bundle of ADU flows that
      are globally protected and when defining which receiver receives
      which flow, the repair flow(s) SHOULD only be received by
      receivers that are authorized to receive all the associated ADU
      flows.
NEW:
      Therefore, when defining the bundle of ADU flows that
      are globally protected and when defining which receiver receives
      which flow, the sender SHOULD make sure that the ADU flow(s) and
      repair flow(s) of that bundle will only be received by receivers
      that are authorized to receive all the ADU flows of that bundle.


Cheers,

   Vincent