[nwcrg] Comments for draft-yang-nwcrg-bats-02

[Vincent Roca <[e-mail]>]

Dear authors, all,

I read the BATS document and have the following comments.
This is something I wanted to do before going any further.

Globally speaking I would say that if there are a few issues here
and there (which is normal for a -02 version), globally it’s understandable.
A few important technical details are missing, a few choices should be
better motivated (I think in particular of the header format), but it seems
globally sound.

Cheers,   Vincent

—————

Intro:

- Minor comment: it is said:
   "The BATS coding scheme can be used for various data delivery
   applications like file transmission, video streaming, etc."
but the same applies to all FEC schemes.

- I think that BATS, as specified here, is for a single data flow
(single source). It should be prominently mentionned.


Section 2.2:

- I guess that the sender first computes the K value, then pads if needed.
It's presented the other way round, assuming K exists, and padding if needed.

- This comment leads me to another one: I think that F is the total number of
bytes to send since this is a piece of information that must be communicated
to the receiver. How does it work if the sender has a first burst of F bytes
to send, then another burst of F' bytes, etc. Does it require to initiate
a new BATS session?


Section 2.4:

- it is said:
   o  T' is not larger than the maximum coded packet payload size.
T' is the coded packet length (this is said at the end of section 2.3.1).
All the coded packets are this size, so what is the point of this
recommendation for T' parameter?


Section 2.5.1:

- typo in first sentence: this is BID, not ID.

- As I understand the F and M header field semantics, "i" is the integer
carried in these 8-bit or 3-bit fields respectively used to compute 2^^i.
In that case, it's better to avoid calling these fields F and M as this is
a bit misleading. Something else is preferable.

- It follows that the size F of data to transmit is not that flexible.
More generally, the provided header format creates limits on the various
numeric values. I suggest that these limits be explicitely mentionned.

- Since M_i is 3 bits, M can be at most 2^3 = 8. This contradicts
recommendations of section 2.4 that suggests values up to 128.


Section 2.5.2:

- I now understand what is meant by T'. This is not what I understood first.
The document needs to say that T' is the size of the coefficient vector plus
coded data, and that the O value is the number of bytes required to store
the coefficient vector. Please clarify.


Section 3.1:

- BATS makes use of a PRNG, refered to as Rand() in the document.
In order to have a full specification, this PRNG must be specified.
I would suggest our TinyMT32 / RFC 8682 PRNG.
https://datatracker.ietf.org/doc/rfc8682/
If ever you're using something else, I'd be interested to understand why.


Section 3.2:

- I'm not sure that a specification that says:
   Using Rand() sample d packets among all the source packets.
enables interoperable implementations. Many details are hidden here
and you need to specify the exact algorithm (e.g., in pseudo-code or C99/C11
code).
The same is true for the generator matrix and more generally for sections 3.2


Section 3.3:

- The title "3.3.  Inner Code Encoder (Recoder) Recommendations"
is misleading. Recommendations suggests that an alternative could be valid
but not recommended. Here, in order to have interoperability, we need strict
guidelines if there are non trivial algorithms.

- typo? It is said: "it can be verified that whether", I think "that"
should be removed.


Section 5.1:

- I wouldn't say that:
   Thus, with the use of BATS codes, information confidentiality
   throughout the data transport process is assured.
as it depends on the cleartext...
A cleartext that is composed of a lot of zeros, plus here and there, a few
non-zero bytes, will likely be transformed into coded data that reveal these
scarce non-zero bytes. This is not the case (fortunately) with cryptographic
primitives.
That being said, I understand and agree that it hides (up to a certain
point) the cleartext.


Section 5.2:

- I have the feeling that attestation will be useless in front of an
attacker that will forge bogus packets. It's not just a matter of having
certified nodes and softwares.

- typo: IP-sec => IPsec