Re: [Fecframe] AD review draft-ietf-fecframe-raptor-07

[Thomas Stockhammer <[e-mail]>]

Dave, all,

great comments! Thanks!

a new draft has been submitted addressing the comments as document inline.
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-08.txt


> A slightly modified copy provided here: 
> <begin>
> 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.
> 
> 3) It is unclear whether the definitions here are the normative
> definitions, or
> whether they are normatively defined elsewhere. I recommend a minor
> change:
> /This document uses the following definitions./This document uses the
> following definitions from [RFC6363]./
> /This document uses the following abbreviations/This document uses the
> following abbreviations from [RFC6363]/

[T] The definitions and abbreviations are normatively and in addition to RFC6363.
The new text is:
"This document uses definitions that apply to FEC Framework in general as defined in RFC6363. In addition, this document uses the following definitions:"

and the same for abbreviations

> 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.

[T] The wording in the latest draft has been updated in the common parts.


> 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.
> in 9, /No security considerations/No security vulnerabilities/+

[T] done

> 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.

[T] done

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

[T] done

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

[T] done

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

[T] SPI was added to the acronyms. Further checking for acronyms done.


> 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.

New names are

- XXX(RFC5053-ARBITRARY)
- XXX(RFC6330-ARBITRARY)
- XXX(RFC5053-OPTIMISED)
- XXX(RFC6330-OPTIMISED)
- XXX(RFC5053-SINGLE)
- XXX(RFC6330-SINGLE)


> 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?

[T] Despite this may be a good idea, this signaling is also used in other documents and it would be confusing to rename and change syntax and semantics now. I would only apply this if it is really considered a bug.  



> 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?

[T] I understand the confusion, but MSBL and Kmax are different. MSBL is a restriction for this scheme. Kmax is a restriction for the codes itself in RFC5053 and RFC6330. The text has been updated accordingly. 


> 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?


[T] The order has been changed on the text.


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

[T] It is now explicitly referred to "FEC Scheme Specific Information"


> 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?

[T] Yes, this is more explicit now.


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

[T] This explanation is added to section 6.2.2:
"The two formats enable different use cases. Format A is appropriate in case the stream has many typically smaller source blocks and Format B is applicable if the stream has fewer large source blocks each with many encoding symbols."

> 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.

[T] Done! It is 8 bit and format B


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

[T] Reference is now made to RFC 5053 and 6330.

> 
> 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.

[T] It is the ADU! This is clarified.

> 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]".

[T] Done


> 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."

[T] Done

> 
> 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.

[T] Done

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

[T] Done

> 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?

[T] Done

> 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?

[T] Correct, I have removed this sentence as it does not apply there.

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

[T] Done

> 25) Can LP ever be 0? 

[T] No

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

[T] Good question. The question is more if there can be cases where no packets are included in the source block. or is LB always greater LP.

This is added as a condition: The Source Block Length LB MUST be chosen such that it is at least as large as the largest Source Packet Information Length LP.


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

[T] No

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

[T] changed to 6

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


[T] changed! Great spotting!


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

[T] Yes, someone was added.

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

[T] Checked and updated

> <end>
> 
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
> 

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.