Raptor Forward Error Correction (FEC) Schemes for FECFRAME
draft-ietf-fecframe-raptor-11

[Ballot comment]

  Please consider the editorial comments from the Gen-ART Review by
  Kathleen Moriarty on 18-Mar-2012.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07284.html

[Ballot comment]
- Its not clear to me whether the "device" mentioned in the IPR
declaration's licensing section really only means h/w devices or not,
or could badly impact e.g. an OSS implementation of this draft. I
assume the WG have considered this and are happy with the idea of the
license being specific to a "device" or at least don't seem to care (as
implied by the write-up).

- 6.2.1.2 - if the last octet is omitted then all the reserved bits
aren't sent. Would it be worth noting that it'd not be safe to omit
that octet if someone defines meanings for some of those reserved bits
in future? Would "MAY be omitted" be better (i.e. use a 2119 keyword)?
Finally, it'd have been nice if you had said that that octet SHOULD be
sent or SHOULD be omitted - why not do that?

- 7.1 - Would it be better to be explicit here about how the padding
with zeros is done? I.e., rfc6330 says that symbols K through K'-1 are
the padding symbols, the same is true here I think but good to say so,
if so rather than forcing the reader to check in rfc6330.

- 8.1.3 - Similar question about padding, though here the answer is
obvious I guess, but still maybe no harm saying.

- Section 9 defers to 6363 for security considerations, but 6330's and
5053's (identical?) security considerations seem more concrete, e.g.
they RECOMMEND using something like TELSA, whereas 6363 eventually says
"implement IPsec" but doesn't say much about what to use. It'd be good
to be clearer about what, if anything, is mandatory-to-implement or
SHOULD be used here. (This isn't a DISCUSS because all those RFCs
are normative references so in theory implementing this means doing
all of the above I guess.)

[Ballot comment]
4.1.  Definitions

  This document uses definitions that apply to FEC Framework in general
  as defined in [RFC6363].  In addition, this document uses the
  following definitions:

Not sure what "that apply to FEC Framework in general" means.
Don't you want to say something such as

  The FEC-specific terminology used in this document is defined in [RFC6363].
  In this document, as in [RFC6363], the first letter of
  each FEC-specific is capitalized along with the new terms defined here:

[Ballot discuss]
This document got a DISCUSS due to the transition of your responsible AD and the need to fix some parts of the documents before the DISCUSS is resolved into a YES.

General:
- There are a number of fields which do not say what type they are, e.g., integer or unsigned integer. On the other hand some fields are labelled as decimal number which is not applicable to the wire representation anyhow.
- How are the bytes ordered on the wire. I guess in network byte order, but that should be noted somewhere.

Here are those fields:
- Section 6.2.1.2:
  MSBL  Value range:  A decimal non-negative integer less than 8192 for
      FEC Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units
      of symbols

Remove decimal, as this is not applicable on the wire.

  Encoding Symbol Size  Name:  "T", Value range:  A decimal non-
      negative integer less than 65536, in units of octets

Remove decimal, as this is not applicable on the wire.

  Payload ID Format  Name:  "P", Value range:  "A" or "B"

The flag P can only take the binary values '0' or '1', but never "A" or "B". How is the symbolic value of 'A' reprented in P and how  is the symbolic value of 'B' reprented in P?

- Section 6.2.2., below "Figure 2: Source FEC Payload ID - Format A"

  Source Block Number (SBN), (16 bits):  An integer identifier for the
      source block that the source data within the packet relates to.

  Encoding Symbol ID (ESI), (16 bits):  The starting symbol index of
      the source packet in the source block.

How is the index to be interpreted, e.g., as unsigned integer? Please specifiy this here!

- Section 6.2.2., below "Figure 3: Source FEC Payload ID - Format B"

  Source Block Number (SBN), (8 bits):  An integer identifier for the
      source block that the source data within the packet relates to.

  Encoding Symbol ID (ESI), (24 bits):  The starting symbol index of
      the source packet in the source block.

How is the index to be interpreted, e.g., as unsigned integer? Please specifiy this here!

- Section 6.2.3., below " Figure 4: Repair FEC Payload ID - Format A"

  Source Block Number (SBN), (16 bits)  An integer identifier for the
      source block that the repair symbols within the packet relate to.
      For format A, it is of size 16 bits.

  Encoding Symbol ID (ESI), (16 bits)  Integer identifier for the
      encoding symbols within the packet.

  Source Block Length (SBL), (16 bits)  The number of source symbols in
      the source block.

How is the number of source symbols to be interpreted, e.g., as unsigned integer? Please specifiy this here!
The same for " Source Block Length (SBL)" for Format B.


Section 8.1.3., below "Figure 6: Repair FEC Payload ID - Format A"

  Initial Sequence Number (Flow i ISN) - 16 bits  This field specifies
      the lowest 16 bits of the sequence number of the first packet to
      be included in this sub-block.  If the sequence numbers are
      shorter than 16 bits then the received Sequence Number SHALL be
      logically padded with zero bits to become 16 bits in length
      respectively.

How is the Flow i ISN to be interpreted, e.g., as unsigned integer?

  Source Block Length (SBL) - 16 bits  This field specifies the length
      of the source block in symbols.

How is this to be interpreted, e.g., as unsigned integer?

[con't from page 17]
  Encoding Symbol ID (ESI) - 16 bits  This field indicates which repair
      symbols are contained within this repair packet.  The ESI provided
      is the ESI of the first repair symbol in the packet.

How is this to be interpreted, e.g., as unsigned integer?

Section 8.1.3., below "Figure 7: Repair FEC Payload ID - Format B"

  Initial Sequence Number (Flow i ISN) - 16 bits  This field specifies
      the lowest 16 bits of the sequence number of the first packet to
      be included in this sub-block.  If the sequence numbers are
      shorter than 16 bits then the received Sequence Number SHALL be
      logically padded with zero bits to become 16 bits in length
      respectively.

How is this to be interpreted, e.g., as unsigned integer?

  Source Block Length (SBL) - 16 bits  This field specifies the length
      of the source block in symbols.

How is this to be interpreted, e.g., as unsigned integer?

  Encoding Symbol ID (ESI) - 24 bits  This field indicates which repair
      symbols are contained within this repair packet.  The ESI provided
      is the ESI of the first repair symbol in the packet.

How is this to be interpreted, e.g., as unsigned integer?

[Ballot comment]
Section 2:
- replace "Section 6defines an FEC Scheme" with "Section 6 defines an FEC Scheme2
- replace "Section 6but with optimisations for with "Section 6 but with optimisations for"
- replace  "over IP Based" Networks  "  with "over IP Based Networks"  " (move ' " ')
- Section 4.2: Add ADU to the list of abbreviations
- Section 6.2.1.2, at the bottom of the page:
  replace "An encoding format for The MSBL and Encoding" with "An encoding format for the MSBL and Encoding S"

IANA understands that there is a single IANA action required to be
completed upon approval of this document.

In the FEC Framework (FECFRAME) FEC Encoding IDs sub registry of the
Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs
registry located at:

http://www.iana.org/assignments/rmt-fec-parameters/rmt-fec-parameters.xml#fecframe-fec-encoding-ids

The following new registrations are to be made:

Value: tbd1
Description: Raptor FEC Scheme for Arbitrary Packet Flows
Reference: [ RFC-to-be ]

Value: tdb2
Description: RaptorQ FEC Scheme for Arbitrary Packet Flows
Reference: [ RFC-to-be ]

Value: tbd3
Description: Raptor FEC Scheme Optimized for Arbitrary Packet Flows
Reference: [ RFC-to-be ]

Value: tbd4
Description: RaptorQ FEC Scheme Optimized for Arbitrary Packet Flows
Reference: [ RFC-to-be ]

Value: tbd5
Description: Raptor FEC Scheme for a single sequence flow
Reference: [ RFC-to-be ]

Value: tbd6
Description: RaptorQ FEC Scheme for a single sequence flow
Reference: [ RFC-to-be ]

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Raptor FEC Schemes for FECFRAME) to Proposed Standard





The IESG has received a request from the FEC Framework WG (fecframe) to

consider the following document:

- 'Raptor FEC Schemes for FECFRAME'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-03-20. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document describes Fully-Specified Forward Error Correction

  (FEC) Schemes for the Raptor and RaptorQ codes and their application

  to reliable delivery of media streams in the context of FEC

  Framework.  The Raptor and RaptorQ codes are systematic codes, where

  a number of repair symbols are generated from a set of source symbols

  and sent in one or more repair flows in addition to the source

  symbols that are sent to the receiver(s) within a source flow.  The

  Raptor and RaptorQ codes offer close to optimal protection against

  arbitrary packet losses at a low computational complexity.  Six FEC

  Schemes are defined, two for protection of arbitrary packet flows,

  two that are optimised for small source blocks and another two for

  protection of a single flow that already contains a sequence number.

  Repair data may be sent over arbitrary datagram transport (e.g.  UDP)

  or using RTP.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-fecframe-raptor/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-fecframe-raptor/ballot/





The following IPR Declarations may be related to this I-D:



  http://datatracker.ietf.org/ipr/1186/

  http://datatracker.ietf.org/ipr/1290/

  http://datatracker.ietf.org/ipr/1509/

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
It appears my AD Review comments from -04- have still not been acted upon.
Can you please submit another draft with those comments addressed?
(If you disagree with specific points, feel free to respond
accordingly)
Thanks for doing this work.

AD review draft-ietf-fecframe-raptor

I have  a number of concerns, mostly editorial. Please address these in the document and publish an updated ID. We are still waiting for the updated IPR disclosures from Qualcomm. It would be good if they were done against the new revision.

1) the abstract says the document defines 6 fec schemes; the Intro says it defines two; section 2 enumerates one scheme for each of section 6, 7, and 8. Be consistent in what you are counting please.

2) a minor comment - definitions (4.1) and abbreviations (4.2) and notation (3.) could all be lumped together into one terminology section.

3) It is unclear whether the definitions here are the normative definitions, or whether they are normatively defined elsewhere.

4) this document and rtp-raptor share common introduction, but the text differs slightly. To make sure there are no inconsistencies that might impact interpretation and interoperability, please use consistent wording in both documents.

5)no security considerations specific to this document have been identified. I hope you mean no security vulnerabilities specific to these FEC schemes have been identified. please fix.

6) in 1, s/sends the repair packet(s) along with the source packets/
          sends the repair packets and the source packets/

I recommend taking the first sentence of the next paragraph and move it into this bullet (what the sender must do).

Then take the remaining sentences in that paragraph (what the receiver should do) and make them a bullet.

7) in 1 s/if referred to/is referred to/

8) in 2, you mention MBMSTS and dvbts as reference tokens. These are acronyms. Please spell them out on first use.

9) for all acronyms, please expand on first usage. e,g,. SPI.

10) in 6.2.1.1, 7.2.1.1, and 8.2.1.1, you say XXX and YYY as assigned by IANA. But aren't there actually 6 different values to be considered? please use 6 different variables for the RFC Editor to modify to the six iana-assigned values.

11) in figure 1, you use a P-bit, which could be confused with P=padding. Since it represents the format, why not use a bit identified by something that isn't already used in FEC documentation?

If the payload ID format name is signaled by P=0 or P=1, and neither "A" nor "B" fit into a bit, then why not call them format 0 (where P-bit=0) and format 1 (where Pbit=1)? or simply say in the text "when P==0" or "P==1" or "P is false" or "P is true"? why introduce an extra set of variable names to keep track of?

12) in 6.2.1.2 you say maximum source block size is known as Kmax, but in 7.3.2, you use MSBL in your calculations. and elsewhere you use SBL for source block length. Why even bother mentioning Kmax if MSBL works fine?

13) in 5, ADUI[i] is the concatenation of FLRP, but the text has them in RLFP order. Any reason to not be consistent? If the terms were in alphabetic order or something, I'd understand. If the order is important for calculation order, then why not concatenate them in the same order?

14) in 6.2.1.2, "of the above" - I'm not sure what thing "the above" refers to. Please be more specific.

15) is the payload ID format identifier the same as the P-bit? Is the format signaled in the FEC Framework Configuration Information (section 6.2.2) the same as the P-bit?

16) 6.2.2 defines two formats, but never explains why two formats are needed.

17) 6.2.3, undef figure 5, whcih depicts format B, you have text that says "for format A, it is of size 16 bits.

18) in 6.2.3, it says "the interpretation ... is defined by the FEC Code Specification. Where do I find the FEC Code specification?

19) In 6.3.1, is "transport payload length" the length of the UDP or RST packet? or the length of the ADU payload? I tried to check this where l[i] is defined, but it said the scheme would tell me.

20) the sentence conistruction in 6.3.3 is a little hard to parse; could this be rewritten? It might be a lot easier throughout the document if you reduced the "Raptor as defined in [RFC5052]" to just "Raptor [RFC5052]".

For this particular paragraph, it might be better as:
"When using Raptor [RFC5053], ESI is calculated per [RFC5053] section 5.3.2.
When using RaptorQ [I-D...], ESI is calculated per [I-D...] section 4.4.2."

It might be even easier if you used mneumonic references for Raptor and RaptorQ:
When using [Raptor], ESI is calculated as per [Raptor] section 5.3.2.
When using [RaptorQ], ESI is calculated as per [RaptorQ] section 4.4.2.

21) in 7.2.x.x, you have extra spaces and missing spaces.

22) in 8.1.3, the order of elements is ISN/ESI/SBL for format A, but ISN/SBL/ESI for format B; why not use a consistent order of elements, e.g. make format B ISN/ESI/SBL to match format A?

23) in 8.2.1, why does the SBN wrap occur at 65535 and 255? In section 6 and 7, this is constrained by the SBN field size. But section 8 uses ISN, not SBN, and ISN for both formats is 16 bit, so why the constraint?

24) in 8.2.2, parentheses would help differentiate I+(LB/LP)-1 from I+LB/(LP-1).

25) Can LP ever be 0?

26) Can this ever yield a negative number? I=0, (LB/LP)=0?

27) are there any congestion control issues specific to these schemes?

28) in 12, it says "this document registers three values ...", then proceeds to enumerate 6 values.

should the even numbered ones be described as "the RaptorQ FEC scheme for ..."? rather than "the Raptor FEC scheme for ..., using raptorQ"?

29) acknowldedgements - did anybody do a thorough review of the later revisions of the draft?


30) id-nits shows some date-specific issues that need updating.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I, Greg Shepherd as the document shepherd have personally reviewed
this document and believe it to be ready for forwarding to the IESG.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had adequate review both from within and from outside
the FECFrame working group.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

There are no concerns regarding the need for additional expanded review.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns with this document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid WG consensus for this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There is no discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Only three miscellaneous warnings which can be addressed with editor's notes:

== The copyright year in the IETF Trust and authors Copyright Line
does not match the current year

== The document seems to lack a disclaimer for pre-RFC5378 work, but
was first submitted before 10 November 2008. Should you add the
disclaimer? (See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.) --
however, there's a paragraph with a matching beginning. Boilerplate
error?

-- The document date (December 9, 2010) is 32 days in the past. Is
this intentional?

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Normative and informative references are split with one reference to
draft that is currently in the editor's queue.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Section 12 describes the FEC Encoding ID values for registration
consistent with the document.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The xml code validates correctly

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document describes Full-Specified Forward Error Correction (FEC)
Schemes for the Raptor and RaptorQ codes and their application to
reliable delivery of media streams in the context of FEC Framework.

Working Group Summary
There were no seriously contentious issues during the WG process.

Document Quality
The Working Group feedback covered both the quality of the document
itself as well as the technical issues with the content of the
document.

Personal
Document Shepherd - Greg Shepherd
Responsible Area Director - David Harrington