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

whyeung <whyeung@ie.cuhk.edu.hk> Wed, 15 September 2021 08:06 UTC

Return-Path: <whyeung@ie.cuhk.edu.hk>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A193F3A0874 for <nwcrg@ietfa.amsl.com>; Wed, 15 Sep 2021 01:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ie.cuhk.edu.hk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCSzzmaruaX8 for <nwcrg@ietfa.amsl.com>; Wed, 15 Sep 2021 01:06:45 -0700 (PDT)
Received: from outmailgw.ie.cuhk.edu.hk (outmailgw.ie.cuhk.edu.hk [137.189.96.60]) (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 83C6B3A0865 for <nwcrg@irtf.org>; Wed, 15 Sep 2021 01:06:44 -0700 (PDT)
Received: from eng.ie.cuhk.edu.hk (engdrbd1.ie.cuhk.edu.hk [137.189.96.28]) by outmailgw.ie.cuhk.edu.hk (8.14.7/8.14.7) with ESMTP id 18F86UAU005699; Wed, 15 Sep 2021 16:06:31 +0800
DKIM-Filter: OpenDKIM Filter v2.11.0 outmailgw.ie.cuhk.edu.hk 18F86UAU005699
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ie.cuhk.edu.hk; s=default; t=1631693191; bh=Z+tT0GBr0EP95J9i6mjEKrske/dD3+FnrkY7ddLuloU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=MC8V/hHqOiUPPsrBTDe3eUWsrLyK4Q9Cy/7iY7c0FkiygYxuva/H+lTcS9jXHWhl3 QuDrfXxH/qrjZUZHsEI6hMKwp/5i5f621SzgHHndbVT96pbhiRkBvv4+gjwDBfirGh tapsT3WoFKCQV7R2FAOQOMJ8kQKX4qoMrQLnP5fhNTEpEfpVCjo8/wdjjzRz0rzGHj LnyCq1QopZAQUYTIltmm5PhKJDbDKzL1pnSV2uwxTFv0R8JFkgTlNdFB62rHBuhw4e p2l+MYuUBXNc8/7du8bEBYdRvAclTjy6MZqwGddp21NUdOPcWBYBznoKlZ+R1zYMmY Ut2iSlyfucjXA==
Received: from imailgw2.ie.cuhk.edu.hk (imailgw2.ie.cuhk.edu.hk [137.189.99.106]) by eng.ie.cuhk.edu.hk (8.15.2/8.15.2) with ESMTP id 18F86TSU021039; Wed, 15 Sep 2021 16:06:30 +0800
Received: from smtp-tls.ie.cuhk.edu.hk (smtp-tls.ie.cuhk.edu.hk [137.189.99.109]) by imailgw2.ie.cuhk.edu.hk (8.14.4/8.14.4) with ESMTP id 18F87Egc007173; Wed, 15 Sep 2021 16:07:14 +0800
Received: from smtpclient.apple ([10.10.55.49]) (authenticated bits=0) by smtp-tls.ie.cuhk.edu.hk (8.14.4/8.14.4) with ESMTP id 18F88EiA003388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Sep 2021 16:08:15 +0800
From: whyeung <whyeung@ie.cuhk.edu.hk>
Message-Id: <DAA66E13-561F-4443-9D04-7080FAB4B89E@ie.cuhk.edu.hk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_69D73DDD-13CD-4C86-9BC3-97FC1A5AD024"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Wed, 15 Sep 2021 16:06:27 +0800
In-Reply-To: <89960E4C-E2DC-4D8B-9BC8-6C30CD1B5A1B@inria.fr>
Cc: nwcrg@irtf.org, draft-irtf-nwcrg-bats.authors@ietf.org, Marie-Jose Montpetit <marie@mjmontpetit.com>
To: Vincent Roca <vincent.roca@inria.fr>
References: <993F22CE-FE37-4C90-B8A1-C2934D714179@inria.fr> <89960E4C-E2DC-4D8B-9BC8-6C30CD1B5A1B@inria.fr>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Scanned-By: MIMEDefang 2.73 on 137.189.99.106
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/sJcBEdMTy1DKeS8P30_npXz6BFE>
Subject: Re: [nwcrg] RG Last Call for "BATS Coding Scheme for Multi-hop Data Transport"
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2021 08:06:51 -0000

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 <vincent.roca@inria.fr> 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 <vincent.roca@inria.fr <mailto:vincent.roca@inria.fr>> 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
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg