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

From: Shenghao Yang <[email-masked]>
Date: Fri, 2 Oct 2020 11:17:58 +0800

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
comments.

Best,

Shenghao

On Tue, Sep 8, 2020 at 3:49 PM Emmanuel Lochin <[email-masked]>
wrote:

> 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 <[email-masked]> <[email-masked]>
> To: [email-masked]
>
> 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"
> https://datatracker.ietf.org/doc/draft-yang-nwcrg-bats/
>
> 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 [email-masked]://www.irtf.org/mailman/listinfo/nwcrg
>
> --
> Emmanuel LOCHIN
> ENAC - Ecole Nationale de l'Aviation Civile
> 7, avenue Edouard Belin CS 54005, 31055 Toulouse Cedex 4 Francehttp://www.enac.frhttps://elochin.github.io/
>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg
>

---

From: Shenghao Yang <[email-masked]>
Date: Sat, 3 Oct 2020 17:53:10 +0800

Dear Colin,

Thanks for your suggestion about research related aspects. In our next
version, we will add a paragraph in the Introduction section, and a new
section to elaborate the research issues.

The purpose of this document is a preliminary BATS coding scheme for
researchers and engineers so that they can further develop network
communication applications/protocols based on BATS codes. Towards a
sophisticated BATS code based network protocol/application, several
important research directions should be considered. In addition to the
security issues, another important research is to design the corresponding
congestion control and routing algorithms for BATS codes.

Best,

Shenghao

On Wed, Sep 9, 2020 at 2:56 AM Colin Perkins <[email-masked]> wrote:

> The draft clearly describes the approach – as a protocol specification, it
> seems pretty good. The draft also clearly describes where the approach
> might be useful.
>
> The draft doesn’t, however, seem to include much discussion of what is the
> research contribution. The references show that there has been research in
> this space, but the draft doesn’t explain why it should be published on the
> IRTF stream rather than by the IETF. What’s the current research?
>
> Colin
>
>
>
>
> On 7 Sep 2020, at 15:00, Vincent Roca <[email-masked]> wrote:
>
> Dear all,
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 5 Oct 2020 22:40:09 +0100

Thanks – look forward to the update.
Colin

> On 3 Oct 2020, at 10:53, Shenghao Yang <[email-masked]> wrote:
> 
> Dear Colin, 
> 
> Thanks for your suggestion about research related aspects. In our next version, we will add a paragraph in the Introduction section, and a new section to elaborate the research issues. 
> 
> The purpose of this document is a preliminary BATS coding scheme for researchers and engineers so that they can further develop network communication applications/protocols based on BATS codes. Towards a sophisticated BATS code based network protocol/application, several important research directions should be considered. In addition to the security issues, another important research is to design the corresponding congestion control and routing algorithms for BATS codes. 
> 
> Best, 
> 
> Shenghao
> 
> On Wed, Sep 9, 2020 at 2:56 AM Colin Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> The draft clearly describes the approach – as a protocol specification, it seems pretty good. The draft also clearly describes where the approach might be useful. 
> 
> The draft doesn’t, however, seem to include much discussion of what is the research contribution. The references show that there has been research in this space, but the draft doesn’t explain why it should be published on the IRTF stream rather than by the IETF. What’s the current research?
> 
> Colin
> 
> 
> 
> 
>> On 7 Sep 2020, at 15:00, Vincent Roca <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Dear all,
>> 
>> 	https://datatracker.ietf.org/doc/draft-yang-nwcrg-bats/ <https://datatracker.ietf.org/doc/draft-yang-nwcrg-bats/>
>> 
>> This document has been around and discussed in our RG for 2 years, it’s time to decide.
>> 
>> 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
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>