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

Shenghao Yang <> Fri, 02 October 2020 03:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 626A03A0D82 for <>; Thu, 1 Oct 2020 20:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ECfxUaKzbzTl for <>; Thu, 1 Oct 2020 20:18:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 517FB3A0D75 for <>; Thu, 1 Oct 2020 20:18:10 -0700 (PDT)
Received: by with SMTP id u9so44392ilj.7 for <>; Thu, 01 Oct 2020 20:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k13NNJUux++eNL4juUO1RkHyM+skw8XjPzCEh4Hp2sk=; b=vSkB5suq4VtuxcB/SdLK0jqngJEtyEZXzRCtCowmXKWto3qNn0xOCLEjkideHzygbK n1tUlwQwqOYhdLP3CqYvY05WQYhWB6Nwgpk1YoMa5U+BmFhx5osB1ERa3WrWQeqkWBAf Qtn+izCvsZ4SYv5xTN0q+2DIZazIcr9VWBnFijgTdY5s1Qc0tGs5SFU7FPlVCgJ469qW pxurDgxWW1SuFAQO+YR41+KvpH7nSS3VJP2H2oA06hxyA0vxXIR/rc8kGzepqHAEgbnx J8+4RcDZZdEIF6Vxkfe765gJEbUCgcXPWJ5yKxBxws2Cz1u9t6SdKqveVK3nYhjKMRGz BXqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k13NNJUux++eNL4juUO1RkHyM+skw8XjPzCEh4Hp2sk=; b=P1taz/Xdgf0SudlzFXspJhIjadcEB6Gr5s2qStnnlKmTK5Cv5tDvDWDy/l/9Ss7OTR XecNEv9LCD6dGHX67VgBsxwb57WZyTeCcihA/96ywxzWr9hHIPldctW6BmyCTJAjnvMH 7rgvR7i9Jf8OA4/cNMO1/a/T2Uw1uMkA8tNXg8A+20dNlPCcEzl5dX/9WK16dkhVTWsA 7fynr0eSgNCvKdjYNpwmp0OWtbrtQaOIa86sCp3BaPUpmC4fBTXDHQEDQ3nEji4akAzc 79x7BAhPeCrKQdaoPKENIYL3MsT1Si+nrbA0gtzq39HMvTcKeX8hONxmQ0O44GnwKe5u LmXw==
X-Gm-Message-State: AOAM530TesbJrpo/tWC4mmAHEcWAyURG9oLDBlebidEPOarx4xudBwLo nyA2/ct1LVqoQE0rhPKCtyju2mdGKssMDrQp81c=
X-Google-Smtp-Source: ABdhPJxdj2T68Yrju+vvZXr4ex0kPWFF2sXTxnEAiAvEYAS2Ov5pefwvxP5R3aulFTOLLtjDxBrwYut15VPTSSGi7vo=
X-Received: by 2002:a92:9401:: with SMTP id c1mr197554ili.25.1601608689415; Thu, 01 Oct 2020 20:18:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Shenghao Yang <>
Date: Fri, 02 Oct 2020 11:17:58 +0800
Message-ID: <>
To: Emmanuel Lochin <>
Cc: Vincent Roca <>,, Marie-Jose Montpetit <>
Content-Type: multipart/alternative; boundary="000000000000007bb905b0a79533"
Archived-At: <>
Subject: Re: [nwcrg] RG Item Call for Adoption for "BATS Coding Scheme for Multi-hop Data Transport"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Oct 2020 03:18:12 -0000

Dear Emmanuel,

Very thanks for your valuable comments. We will adopt these comments into
our next version. Below please find our point-to-point response to these



On Tue, Sep 8, 2020 at 3:49 PM Emmanuel Lochin <>

> Dear all,
> I already did a review end of July but may be it hasn't been
> well-received. Please find it below :
> -------- Forwarded Message --------
> Subject: [nwcrg] Review draft-yang-nwcrg-bats-03
> Date: Wed, 29 Jul 2020 09:00:22 +0200
> From: Emmanuel Lochin <> <>
> To:
> Dear all,
> After carefully reading "BATS Coding Scheme for Multi-hop Data Transport",
> I have no specific comment on it.
> The draft is well explained and self-contained. It appears almost clear to
> me concerning the implementation of BATS.
> Just some slight comments/questions :
> - Being a little bit fussy, I would just rephrase "Existing network
> protocols like TCP/IP use end-to-end retransmission and store-and-forward
> at the relays" by "Existing transport protocols like TCP use end-to-end
> retransmission while network protocols such as IP might enable
> store-and-forward at the relays". I understand that you want to point out
> that TCP/IP has the same objective that the combination of both inner/outer
> BATS codes while less efficient over multihop;

Yes, we will rephrase the sentence as suggested.

> - Correct "Suppose that a pseudorandom number generator Rand() which
> generate an unsigned integer of 32 bit" -> "generates";

Will be corrected.

> I understand that you need one BATS session per flow at the outer code and
> you write that "The inner code comprises (random) linear network coding
> applied on the coded packets belonging to the same batch.". So my questions
> are:
> - Does a batch similar to an encoding window as defined in RFC8406?

We checked the definition of sliding encoding window in RFC8406. The batch
here is different from an encoding window in several aspects. First, one
important property of a batch is that all the packets belong to the same
batch are encoded from the same set of source packets, so that a recoded
packets of a batch is also a linear combination of the same set of source
packets. Second, the number of recoded packets for each batch may not be
the same due to loss and recoding design, so that it is not feasible to
identify batches by windows of certain lengths.

> - Does the inner code must differentiate each microflow before
> re-encoding? If yes, without re-encoding (pure e2e exchange) does the
> Batch_ID field still mandatory?

We think the microflow here refers to a batch. If so, yes, the inner code
needs to distinguish different batches. Even without re-encoding, the
Batch_ID field is also mandatory for decoding. We will add a sentence in
the document to state this fact.

> - Is there a relationship between the e2e microflow and the Batch_ID?
> Meaning a Batch_ID always identifies a source/sender or a one of its
> microflow?

A Batch_ID itself does not identify a flow. Some extra packet headers are
required to specify an end-to-end flow. Such headers should be maintained
by DDP and are not specified in this document. We will add a new paragraph
in the document related to this question.

> Regards,
> Emmanuel
> On 07/09/2020 16:00, Vincent Roca wrote:
> Dear all,
> We would like to start a RG-Item call for adoption for the following I-D:
> "BATS Coding Scheme for Multi-hop Data Transport"
> This document has been around and discussed in our RG for 2 years, it’s
> time to decide.
> comment
> The call will *end on Monday Sept. 28th (3 weeks)*.
> Please read it, provide feedback, and tell us whether you are in favour of
> adopting it and if
> you would agree to review if accepted. Thanks in advance.
> Regards,
>   Marie-Jose and Vincent
> _______________________________________________
> nwcrg mailing listnwcrg@irtf.org
> --
> Emmanuel LOCHIN
> ENAC - Ecole Nationale de l'Aviation Civile
> 7, avenue Edouard Belin CS 54005, 31055 Toulouse Cedex 4 Francehttp://www.enac.fr
> _______________________________________________
> nwcrg mailing list