Re: [nwcrg] RG Last Call for "BATS Coding Scheme for Multi-hop Data Transport"

[whyeung <[e-mail]>]

Many thanks for your detailed comments! Certainly will help make our I-D better.

Best regards,
Raymond

> On Sep 14, 2021, at 4:01 PM, Vincent Roca <[e-mail]> wrote:
> 
> Dear Authors, everybody,
> 
> As promised (a bit late however, sorry), here is my review of version -01 (draft-irtf-nwcrg-bats-01).
> 
> There is still some work to be done on this I-D before I can say it’s ready for IRSG review, but we are converging.
> Authors, could you update your document accordingly? Thanks in advance.
> 
> 
> # Main comments:
> 
> * Section 2.1
>   Could Fig. 1 be made more explicit? Just to give you an idea of what I have in mind
>   (to be improved, completed, and probably corrected):
> 
>   |
>   | {set of source packets}
>   v
> +-+-+-+-+-+-+-+
> | source node | outer coding: create batches of M BATS/coded packets each
> |             | inner coding: recode each BATS/coded packets to form DDP packets
> |             | transmit DDP packets
> +-+-+-+-+-+-+-+
>   |
>   |     {set of DDP packets}
>   v
> +-+-+-+-+-+-+-+-+-+-+
> | intermediate node | inner coding: recode DDP packets (if needed)
> |                   | transmit incoming and/or recoded DDP packets
> +-+-+-+-+-+-+-+-+-+-+
>   ...
> 
>   The textual description of what happens is not cristal clear I'd say, the above figure could help.
>   One question I have is about the partionning of the incoming set of source packets into batches: is there a fixed number of source packets per batch, is there an overlapping between consecutive batches or not?
>   It also depends on the "degree" but I understand the degree varies according to a certain distribution, so different BATS packets in a given batch will depend on a different number of source packets…
>   It’s confused in my mind, I don't have the answer to my question, could you clarify?
>   Also, in section 1.2, the "degree" definition could suggest (ambiguous) that this degree may be fixed for a given batch.
>   It did not help me.
> 
> 
> * Section 2.4
>   Strange to see a DDP that does not define any protocol version number, no session identifier (if there are multiple flows between the same endpoints).
>   A full DDP should also define what happens when the small 12-bit BID space reaches its maximum value value (wrapping to zero I guess) and if it is an issue (e.g., with a high throughput link that consummes this space very rapidly), etc.
>   I understand this is only a minimum example of DDP, not a full featured DDP and that this I-D is above all meant to specify the BATS scheme, not the DDP.
>   It should be reminded that several simplifications have been made.
> 
> 
> * Section 3.2:
>   Function DegreeSampler() computes a degree distribution table in line with a predefined distribution, and returns a random degree that matches this distribution.
>   However, looking at Fig. 7, I have the feeling that if K < MAX_DEG, there could be a bias in the actual distribution because of:
>         return min(d,K)
>   d matches the desired distribution but not: min(d,K) that will over-represent K in that case.
>   I don't know if it's an issue.
> 
> 
> * Last paragraph of Section 3.3:
>   I fully agree, especially as forwarding systematic recoded packets immediately will reduce transmission latency.
>   On the opposite, if only the linear combination approach is used by each intermediate node, latency will accumulate linearly with the number of nodes.
>   Is it realistic? I'm surprised it's not discussed.
> 
> 
> * Section 3: interoperability considerations
>   The I-D should specify clearly which GF(256) to consider, i.e., its irreducible polynomial.
>   This is what we did (we received this comment) in RFC 8681, section  3.7.1. Finite Field Definitions
>   Do not hesitate to refer to (if meaningful):
>         https://www.rfc-editor.org/rfc/rfc8681.html#name-finite-field-operations <https://www.rfc-editor.org/rfc/rfc8681.html#name-finite-field-operations>
> 
> 
> * Section 4.1:
>   - What is meant by throughput in: "The BATS code specification in Section 3 has nearly optimal throughput"?
>     I guess: BATS approaches ideal codes.
> 
>   - The sentence is a bit strange: "The belief propagation decoder in Section 3.4 guarantees the recovery..."
>     There is no guaranty. If the loss rate is too high the decoder will face problems even to recover a subset of the source packets.
>     Maybe: "the BP usually enables the recovery of (at least) a fraction of the source packets".
> 
> 
> ** Section 6: intro.
>   I find the use of the term « confidentiality » excessive.
>   If an eavesdropper can collect a sufficient number of DDP packets, he can  decode them and recover the source packets.
>   There is no hidden, encrypted, info (e.g., the coefficients or some key info) that could prevent it.
>   Okay if the eavesdropper only captures a few DDP packets, but this is not a realistic attacker model.
>   Even if we admit random coefficients are encrypted, it remains that the "confidentiality" depends on the message content (imagine a long message that contains a 32-bit secret and which is padded by thousands of null bytes).
>   This is not in line with what the security community understands by confidentiality.
>   This is also why [Bhattad05] that you refer to uses the adjective « Weakly » in the title.
>   Obfuscation is preferable IMHO.
> 
> 
> * Section 6.1: there are two instances of "must" (lower case).
>   Since this is not normative language as per RFC 2119, I don't understand what is meant.
>   Is a strong MUST more appropriate, or should it be "SHOULD"?
> 
> 
> * Section 6.2, item 3:
>   - Typo in "Original authentication". I guess it's "source" or "origin" authentication.
>   - Additionally, I think you mean "origin authentication and message integrity".
> 
> 
> * It's good practice to have an "Acknowledgement" section ;-)
> 
> 
> * A reference to rfc 8406 "Taxonomy of Coding Techniques for Efficient Network Communications" would be meaningful since this is the NWCRG foundations.
>         https://www.rfc-editor.org/rfc/rfc8406.html <https://www.rfc-editor.org/rfc/rfc8406.html>
> 
> 
> Minor comments:
> 
> * Section 2.4.1:
>   - Mq also refers the O value. To be added to:
>       "Mq: 4-bit unsigned integer to specify the value of M and q as Table 1."
>   - Also, I don't understand why the table is not organized with increasing values of Mq? It’s not wrong, I’m just surprised.
>   - You could also say if value 0 is invalid (?) and whether values 8 and above are unused in this version but left for future evolutions.
> 
> * section 3.2: s/return/returns/ in "Define a function called DegreeSampler that return an integer d"
> 
> * section 3.4: s/batches/batch/ in   "Find a batches j that is decodable."
> 
> * section 4.1: s/call/called/ in: "which is also call multicast"
> 
> * section 4.3: s/techinques/techniques/
> 
> 
> I hope it will help.
> Regards,
> 
> 
>    Vincent
> 
> 
>> Le 30 juil. 2021 à 12:44, roca <[e-mail] <mailto:[e-mail]>> a écrit :
>> 
>> Dear all,
>> 
>> Following the recent update of the I-D and in line with IETF111 discussion, we would like to officially start a RG Last Call for:
>> 	"BATS Coding Scheme for Multi-hop Data Transport » / draft-irtf-nwcrg-bats-01
>> 	https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/>
>> 
>> Since many participants may be on vacation, the call will end on Monday September 6th (5 weeks).
>> 
>> Please read it and provide feedback on the mailing list. Thanks in advance.
>> 
>> Regards,
>> 
>>     Marie-Jose and Vincent
>> 
> 
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg