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

Thomas Stockhammer <stockhammer@nomor.de> Fri, 24 February 2012 22:43 UTC

Return-Path: <stockhammer@nomor.de>
X-Original-To: fecframe@ietfa.amsl.com
Delivered-To: fecframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7322721F8744 for <fecframe@ietfa.amsl.com>; Fri, 24 Feb 2012 14:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+zTQN-xV37J for <fecframe@ietfa.amsl.com>; Fri, 24 Feb 2012 14:43:31 -0800 (PST)
Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id C950621F873A for <fecframe@ietf.org>; Fri, 24 Feb 2012 14:43:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1330123403; l=9141; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=hG4tmzuerGvcp6GFpN26eHaYBUI=; b=cfPedBweKw8Jeg1ZpdF+2w6g+oVtdPzV9JRzfqoIeZ4MvDeql78Fo5Fau8qvStxOaO0 wC7Ym3E1LGBCWhkiQaNwnfYhDzK5iqBI+SEYvs2CgHVdhtiVIUoCdZci6PHhpij/7wFiK hFEnmw59gibxez08zGDYGaxAV/ODQ8vxA3E=
X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Efz/7Ks9
X-RZG-CLASS-ID: mo00
Received: from [192.168.1.4] (188-192-154-212-dynip.superkabel.de [188.192.154.212]) by smtp.strato.de (cohen mo35) (RZmta 27.7 DYNA|AUTH) with ESMTPA id a03d42o1OLrZ9f ; Fri, 24 Feb 2012 23:43:05 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Thomas Stockhammer <stockhammer@nomor.de>
In-Reply-To: <4D77BA6BE9584BEA8AA3114C03CB834A@davidPC>
Date: Fri, 24 Feb 2012 23:43:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD148619-86F8-4AAF-861C-AB8EE373F101@nomor.de>
References: <4D77BA6BE9584BEA8AA3114C03CB834A@davidPC>
To: David Harrington <ietfdbh@comcast.net>
X-Mailer: Apple Mail (2.1257)
Cc: draft-ietf-fecframe-raptor@tools.ietf.org, fecframe-chairs@tools.ietf.org, fecframe@ietf.org
Subject: Re: [Fecframe] AD review draft-ietf-fecframe-raptor-07
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2012 22:43:32 -0000

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
> ietfdbh@comcast.net (preferred for ietf)
> dbharrington@huaweisymantec.com
> +1 603 828 1401 (cell)
> 

---
Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 || 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.