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

[roca <[e-mail]>]

Dear authors,

Thank you for updating the I-D.
As discussed yesterday during our meeting, we can now start a RG LC for this new version.
I’ll have a look at your answers when reviewing it.

Regards,
 
    Vincent

> Le 28 juil. 2021 à 10:03, Shenghao Yang <[e-mail]> a écrit :
> 
> Dear Vincent, 
> 
> Thanks for the detailed comments. We just updated the doc: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/>
> 
> In 01, we made the following major changes to address these comments. 
> 
> 1. A new section, 1.2 Terminology and Definitions, is added to define some terms.
> 
> 2. Section 2 is changed to A Use Case of BATS Coding Scheme. We modified the content of this section so that it is an example about how to use a BATS coding scheme in a Data Delivery Protocol. 
> 
> See also our point-to-point response below.
> 
> 
> Best, 
> 
> authors of draft-irtf-nwcrg-bats
> 
> On Wed, Apr 21, 2021 at 11:53 PM Vincent Roca <[e-mail] <mailto:[e-mail]>> wrote:
> 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.
> 
> We see that the confusion may come from Sec 2. In the beginning of Sec 2, we add a section to make it explicit that this document is not about a Data Delivery Protocol. The purpose of describing a DDP is to make the role of the BATS coding scheme clear. We change the title of Sec 2 to A Use Case of BATS Coding 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.
> 
> We add Sec 1.2 Terminology and Definitions
>  
> 
> ** 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.
> 
> The BATS coding scheme can also be used in the scenario with two sources of the same file. Both sources can encode the file independently using this coding scheme. A destination can receive batches from both sources. To make things clear, we specify that we describe a data delivery process that involves one source, one  destination, and multiple intermediate nodes. We also add an illustration to the network model. 
> 
> 
> ** 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).
> 
> We use PMTU in the new version. 
>  
> 
> ** 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?
> 
> We updated the figure to resolve both issues.
>  
> 
> ** 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...
> 
> We redefine MAX_DEG as a positive integer, and rephrase the sentence that generates confusion.  
> 
> - 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.
> 
> In the new version, this paragraph is removed as this section focuses on how to use a BATS coding scheme in data delivery, instead of specifying a DDP. 
>  
> 
> ** 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.
> 
> Yes, it is possible. We add the description that a DDP may choose forwarding without recoding. 
>  
> 
> ** Section 2.2.4
> - The legend of fig.2, "depadding", is strange and contradicts the last sentence before it:
>     "the recommended padding process...".
> 
> We change related descriptions as padding insertion and  deletion. 
>  
> - 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.
> 
> We emphasize in the new version that the decoder decodes the inner code and the outer code jointly. 
>  
> 
> ** 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.
> 
> The BATS coding scheme described in this document is not supposed to be the most efficient one when the number of packets is very small.  We add this remark in the new version. 
> 
> ** 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.
> 
> Remove Packet_Count. 
> 
> ** 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?
> 
> The sentence about  JSON is removed. 
> 
> 
> ** 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.
> 
> We remove Sec 2.4.3 about packet footer, which is of primary importance about how to use a BATS coding scheme. 
> 
> 
> ## 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 <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.
> 
> 
> _______________________________________________
> nwcrg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg