Re: [nwcrg] I-D Action: draft-irtf-nwcrg-network-coding-satellites-09.txt

Vincent Roca <vincent.roca@inria.fr> Tue, 18 February 2020 16:15 UTC

Return-Path: <vincent.roca@inria.fr>
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 51A6E1208A3 for <nwcrg@ietfa.amsl.com>; Tue, 18 Feb 2020 08:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 546V4RZ3WGTt for <nwcrg@ietfa.amsl.com>; Tue, 18 Feb 2020 08:15:25 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 EE5E412087E for <nwcrg@irtf.org>; Tue, 18 Feb 2020 08:15:24 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,456,1574118000"; d="scan'208,217";a="339614111"
Received: from unknown (HELO [172.20.10.2]) ([176.161.234.40]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2020 17:15:22 +0100
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <AD46A22E-2782-4C16-92B4-729356879E93@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_84930EE4-9DDD-4CB6-8A78-5945724B8591"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 18 Feb 2020 17:15:20 +0100
In-Reply-To: <157605282804.11396.8679616680059990904@ietfa.amsl.com>
Cc: Vincent Roca <vincent.roca@inria.fr>, Nwcrg <nwcrg@irtf.org>
To: Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr>, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
References: <157605282804.11396.8679616680059990904@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/TOA-tCkzHvTWmQygkouT0lbjuco>
Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-network-coding-satellites-09.txt
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: Tue, 18 Feb 2020 16:15:30 -0000

Dear authors, all,

I have read your document and found it almost ready.
What follows are pretty easy to address.

Then I think we should be able to continue with IRSG (to be confirmed).

Cheers,   Vincent

—————

Abstract:

- It is said:
   The objective is to
   contribute to a larger deployment of network coding techniques in
   SATCOM to complement already implemented loss recovery mechanisms.
I'm just wondering what "already implemented loss recovery mechanisms" refer to.
I know there are bit error detection/recovery mechanism, of course TCP will
recover from losses, but what do you mean here exactly?


Section 1:

- typo:
   ...retransmissions add
   significant delays because especially in geostationary system with
   over 0.7 second round-trip delays.
I think "because" should be removed.


Section 2:

- typo: "that one single gateway support." => supports


Section 3.2:

- typo: "to better utilize a satellite broadcast capabilities." => remove "a"

- Reference:
   ...more flexible sliding window encoding schemes that allow decoding
   before receiving the whole block an added delay benefit [RFC8406].
I suggest you now reference: RFC 8681
        Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
as it is available.


Section 3.4:

- maybe the following sentence is too strong:
   adding network coding techniques will prevent the end-to-end
   retransmission from occurring since the packet losses will be
   recovered.
I'd rather say "will reduce the need for end-to-end retransmissions since packet losses
would probably be recovered."


Section 4.1:

- Last sentence: adding a reference to the coding and CC document makes sense here.


Section 4.2:

- typo: "discussed on the previous section." => "discussed in section 3.5."


Section 4.3:

- Could you check whether this is VNF or NFV? Both are used. Please, also add
an expansion of those acronyms.


- Throughout the document:
please replace "draft" by "document" as you probably expect it not to remain in
the "draft" status forever...


----
Vincent Roca, PhD/HDR, PRIVATICS team leader, Inria research institute, France
https://privatics.inrialpes.fr/people/roca/

> Le 11 déc. 2019 à 09:27, internet-drafts@ietf.org a écrit :
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Coding for efficient NetWork Communications Research Group RG of the IRTF.
> 
>        Title           : Network coding for satellite systems
>        Authors         : Nicolas Kuhn
>                          Emmanuel Lochin
> 	Filename        : draft-irtf-nwcrg-network-coding-satellites-09.txt
> 	Pages           : 15
> 	Date            : 2019-12-11
> 
> Abstract:
>   This document is the product of the Coding for Efficient Network
>   Communications Research Group (NWCRG).  It conforms to the directions
>   found in the NWCRG taxonomy [RFC8406].  Thus, the scope of the
>   document is network coding as a linear combination of packets in and
>   above the network layer.  Physical and MAC layer coding are beyond
>   the scope of the document.  The draft focuses on a multi-gateway
>   satellite system and identifies the use-cases where network coding
>   provides significant performance improvements.  The objective is to
>   contribute to a larger deployment of network coding techniques in
>   SATCOM to complement already implemented loss recovery mechanisms.
>   The draft also identifies open research issues related to the
>   deployment of network coding in SATCOM systems.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-09
> https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg