Subject: [nwcrg] Review of draft-irtf-nwcrg-bats-00 - Part #1

From: Vincent Roca <[email-masked]>
Date: Wed, 21 Apr 2021 17:52:03 +0200

Dear authors, dear Raymond,

Please find below a first review of the I-D, from abstract to section 2 included.
Sorry, I couldn’t find time to do that earlier.
I hope it will be useful.

Cheers,

  Vincent

—

## Missing text common to all IRTF RFCs:

- To be added in the abstract:
        This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG).

- To be added in the introduction:
         This document is a product of and represents the collaborative work
        and consensus of the Coding for Efficient Network Communications
        Research Group (NWCRG); it is not an IETF product and is not an IETF standard.

## Main comments

** Generally speaking, it is not clear whether this doc is about BATS, a FEC scheme, or a Data Delivery
Protocol that leverages on the BATS FEC Scheme.This needs to be clarified first as there are consequences.
My understanding: this I-D focusses on the FEC Scheme.

** Could you add a terminology and definitions section? That would be useful.
There are many terms used later on (e.g., batch) that are never formally defined.

** Section 2.1:
- this is a key section (main concepts) and it needs to be perfect. It is said:
        "The BATS coding scheme can be used for a single data flow that
        includes a single source and one or multiple destinations"
Should I understand "MUST be used"? "Can" is ambiguous and I understand this is indeed the case.
- an illustration could help understanding and memorising the terminology.

** Section 2.2: instead of MTU, one would rather talk about "Path MTU" / PMTU (minimum MTU along a path in case of
a single destination, or along all paths in case of multicast).
Of course, if the network is fixed and well-known, this is much simpler. At the other spectrum, since routing can
change, this minimum PTMU can vary over the time (opt for a conservative value then).

** Section 2.2.1, fig. 1:
Infinite loops are prohibited ;-)
        for i = 1, 2, ... do
I don't understand the notation (quite unusual):
        bl[Z...T-1] = i
Is the goal to fill all bytes between offset Z and T-1 with value i?

** Section 2.2.2:
- the notation "DD" is not defined in: " o  MAX_DEG: the size of DD." (and later)
- I think there's a mistake (DDP => DD?) in:
        For the batch ID j, the encoder returns the DDP that contains...

- Be careful, by saying:
   « The DDP will also include some necessary extra information in the
   packet header so that the network nodes can identify different BATS
   sessions, and different end-to-end communication flows.  However,
   such specifications are beyond the scope of this document. »

it follows that interoperability cannot be achieved (we are talking her about headers!).
Yet I can understand that the present I-D focusses on the BATS FEC Scheme, not the DDP.
The FEC scheme does not have to care about session identification.

** Section 2.2.3:
I have the feeling that an intermediate node does not necessarily need to perform recoding. This is
just an optional process. Additionally, by specifying the BATS FEC scheme, this is more an operational
decision to recode or not, that does not impact the BATS scheme itself that is compatible with this
decision.

** Section 2.2.4
- The legend of fig.2, "depadding", is strange and contradicts the last sentence before it:
    "the recommended padding process...".

- I also have the feeling that most of the important stuff is omitted: where do we decode, how do we
manage both the inner and outer decoding, etc. I am very confused after reading it.
I think you should say the bare minimum here and refer to the appropriate section 3.

** Section 2.3
Yes I understand, and when there's a continuous data flow, without any real-time constraints, it
will work. When you only have enough data to fill 4-5 packets, nothing else during a few seconds
and cannot afford to wait, what do you do?
That's a side topic, sure, more for the DDP protocol than the BATS FEC scheme.

** Section 2.4.1:
Why a different name for the same concept in:
        Packet_Count: 16-bit unsigned integer, specifying the number K of
              packets of the BATS session.
Use K or Packet_count, not a mix of the two.

** Section 2.4.2:
It's pretty unusual, in a tight packet, to use JSON or even protobuf.
Do you really need the associated flexibility?

** Section 2.4.3
A signature in two bytes is not realistic (finding an arbitrary cleartext that collides to a target space of 2^16 is easy).
HMAC will typically be 32 bytes long, they can be truncated to 16 bytes (e.g., with HMAC-SHA256-128).
There can be other techniques depending on assumptions, but in any case we are far away from two bytes.
Please be more specific or remove it altogether. I also think this is more a DDP protocol topic than a BATS FEC 
Scheme topic.

I don't think a parity check is meaningful, integrity is part of the HMAC.

## Minor comments

** In order to produce the appropriate I-D header, if ever you use xml formatting, you can add:
  <area>IRTF</area>
  <workgroup>NWCRG</workgroup>
(see for example: https://github.com/irtf-nwcrg/draft-irtf-nwcrg-coding-and-congestion-in-transport/blob/master/draft-irtf-nwcrg-coding-and-congestion-09.xml)
It will avoid a mention "Internet Engineering Task Force".

** Section 2.2.1: it is said:
    "are filled with data bit..."
Use octets rather than bits when talking about the packet payload.