Subject: [Gen-art] Fw: Gen-ART review of draft-ietf-fecframe-interleaved-fec-scheme-05

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 6 Jan 2010 16:13:04 -0600

Sent from my non-subscribed e-mail address - just for the archives...

Spencer

----- Original Message ----- 
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Cc: "General Area Review Team" <[email-masked]>
Sent: Tuesday, January 05, 2010 7:16 PM
Subject: Gen-ART review of draft-ietf-fecframe-interleaved-fec-scheme-05

>I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-fecframe-interleaved-fec-scheme-05
> Reviewer: Spencer Dawkins
> Review Date: 2010-01-05 (way late)...
> IETF LC End Date: 2009-12-11
> IESG Telechat date: 2010-12-07
>
> Summary: This draft is almost ready for publication as a Proposed 
> Standard. In my review, I found a few uses of 2119 language that did not 
> seem to be justified (identified below as "Spencer (minor):"). The ADs 
> should consider whether these uses should be changed or left alone.
>
> Abstract
>
>   This document defines a new RTP payload format for the Forward Error
>   Correction (FEC) that is generated by the 1-D interleaved parity code
>   from a source media encapsulated in RTP.  The 1-D interleaved parity
>   code is a systematic code, where a number of repair symbols are
>   generated from a set of source symbols and sent in a repair flow
>   separate from the source flow that carries the source symbols.  The
>   1-D interleaved parity code offers a good protection against bursty
>   packet losses at a cost of decent complexity.  The new payload format
>
> Spencer (nit): "decent" doesn't seem entirely clear here. "additional"?
> "reasonable"?
>
>   defined in this document is used (with some exceptions) as a part of
>   the DVB Application-layer FEC specification.
>
> 1.  Introduction
>
>   Note that the source and repair packets belong to different source
>   and repair flows, and the sender MUST provide a way for the receivers
>   to demultiplex them, even in the case they are sent in the same
>
> Spencer (minor): I'm not used to seeing normative statements in
> Introductions, and this MUST appears prior to the requirements conventions
> in section 2, but ignoring that - isn't this a statement about the 
> mechanism
> in this draft, and not (so much) a statement about what a sender MUST do?
> (If you use the mechanism described in this draft, doesn't that satisfy 
> the
> MUST?) I'd suggest something like "... and the sender needs to use a
> mechanism that provides a way ...", punting on the 2119 language 
> completely.
>
>   transport flow (i.e., same source/destination address/port with UDP).
>   This is required to offer backward compatibility (See Section 4).  At
>   the receiver side, if all of the source packets are successfully
>   received, there is no need for FEC recovery and the repair packets
>   are discarded.  However, if there are missing source packets, the
>   repair packets can be used to recover the missing information.  Block
>   diagrams for the systematic parity FEC encoder and decoder are
>   sketched in Figure 1 and Figure 2, respectively.
>
> 1.1.  Use Cases
>
>   We generate one interleaved FEC packet out of D non-consecutive
>   source packets.  This repair packet can provide a full recovery of
>   the missing information if there is only one packet missing among the
>   corresponding source packets.  This implies that 1-D interleaved FEC
>   protection performs well under bursty loss conditions provided that L
>   is chosen large enough, i.e., L-packet duration SHOULD NOT be shorter
>   than the duration of the burst that is intended to be repaired.
>
> Spencer (minor): again, I don't think this is a 2119 SHOULD (NOT) - isn't 
> it a definition?
>
>   For example, consider the scenario depicted in Figure 4 where the
>   sender generates interleaved FEC packets and a bursty loss hits the
>   source packets.  Since the number of columns is larger than the
>   number of packets lost due to the bursty loss, the repair operation
>   succeeds.
>
> 1.3.3.  ETSI TS 102 034
>
>   The Annex E of [ETSI-TS-102-034] defines an optional protocol for
>   Application-layer FEC (AL-FEC) protection of streaming media for
>   DVB-IP services carried over RTP [RFC3550] transport.  AL-FEC
>   protocol uses two layers for protection:  a base layer that is
>   produced by a packet-based interleaved parity code, and an
>   enhancement layer that is produced by a Raptor code.  While the use
>
> Spencer (nit): could you provide a reference for "Raptor code", or at 
> least include a definition for it?
>
>   of the enhancement layer is optional, the use of the base layer is
>   mandatory wherever AL-FEC is used.  The DVB AL-FEC protocol is also
>   described in [I-D.ietf-fecframe-dvb-al-fec].
>
> 2.  Requirements Notation
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
> Spencer (nit): boy, this is late in the document, given the number of 
> normative statements that have already flown past ...
>
> 4.1.  Source Packets
>
>   The source packets MUST contain the information that identifies the
>
> Spencer (minor): this MUST (and the one at the beginning of 4.2) seem to 
> define requirements for the protocol mechanism, not behavior for the 
> endpoints - I'm thinking this isn't 2119 language. Just "... source 
> packets contain the information ..."?
>
>   source block and the position within the source block occupied by the
>   packet.  Since the source packets that are carried within an RTP
>   stream already contain unique sequence numbers in their RTP headers
>   [RFC3550], we can identify the source packets in a straightforward
>   manner and there is no need to append additional field(s).  The
>   primary advantage of not modifying the source packets in any way is
>   that it provides backward compatibility for the receivers that do not
>   support FEC at all.  In multicast scenarios, this backward
>   compatibility becomes quite useful as it allows the non-FEC-capable
>   and FEC-capable receivers to receive and interpret the same source
>   packets sent in the same multicast session.
>
> 4.2.  Repair Packets
>
>   o  Payload Type:  The (dynamic) payload type for the repair packets
>      is determined through out-of-band means.  Note that this document
>      registers a new payload format for the repair packets (Refer to
>      Section 5 for details).  According to [RFC3550], an RTP receiver
>      that cannot recognize a payload type must discard it.  This
>
> Spencer (nit): not sure what "This" refers to - the action of discarding 
> an unrecognized payload type? If so, I'm thinking "... must discard it, 
> and this action provides ..."
>
>      provides backward compatibility.  The FEC mechanisms can then be
>      used in a multicast group with mixed FEC-capable and non-FEC-
>      capable receivers.  If a non-FEC-capable receiver receives a
>      repair packet, it will not recognize the payload type, and hence,
>      discards the repair packet.
>
>