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.