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
- [nwcrg] I-D Action: draft-irtf-nwcrg-network-codi… internet-drafts
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-network-… Vincent Roca
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-network-… Kuhn Nicolas
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-network-… Vincent Roca