[nwcrg] Review of draft-irtf-nwcrg-bats-00 - Part #1
Vincent Roca <email@example.com> Wed, 21 April 2021 15:52 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A8A3A2D65 for <firstname.lastname@example.org>; Wed, 21 Apr 2021 08:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9JZMbeR-3dD for <email@example.com>; Wed, 21 Apr 2021 08:52:17 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [22.214.171.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17233A2D4E for <firstname.lastname@example.org>; Wed, 21 Apr 2021 08:52:08 -0700 (PDT)
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A+D50Y6GeWjIzGbOHpLqENseALOonbusQ8zAX?= =?us-ascii?q?/mp6ICY1TuWzkceykPMHkSLlkTp5YhsdsP2JJaXoex3h3LFv5415B9yfdS3ron?= =?us-ascii?q?GhIo0nzYaK+VLdMgn/8uIY6qt6aah5D7TLYGRStsrx7AmmH9tI+rDuzImTmezc?= =?us-ascii?q?w31xJDsHV4hc6W5CajqzIwlTTAlCCYFRLuv+2vZ6?=
X-IronPort-AV: E=Sophos;i="5.82,240,1613430000"; d="scan'208,217";a="379293008"
Received: from xbn44-4_migr-88-165-27-50.fbx.proxad.net (HELO [192.168.0.34]) ([126.96.36.199]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2021 17:52:04 +0200
From: Vincent Roca <email@example.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D3280F43-B716-47AE-99BE-2B095BF7A517"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 21 Apr 2021 17:52:03 +0200
Cc: Vincent Roca <firstname.lastname@example.org>, email@example.com
X-Mailer: Apple Mail (2.3445.104.11)
Subject: [nwcrg] Review of draft-irtf-nwcrg-bats-00 - Part #1
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 15:52:28 -0000
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.