Sent from my non-subscribed e-mail address - just for the archives...
Spencer
----- Original Message -----
From: "Spencer Dawkins" <spen...@mcsr-labs.org>
To: <draft-ietf-fecframe-interleaved-fec-sch...@tools.ietf.org>
Cc: "General Area Review Team" <gen-art@ietf.org>
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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
