Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"
Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> Mon, 18 November 2019 15:42 UTC
Return-Path: <Nicolas.Kuhn@cnes.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 7272A120A20 for <nwcrg@ietfa.amsl.com>; Mon, 18 Nov 2019 07:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 oIyh1iNqE3t6 for <nwcrg@ietfa.amsl.com>; Mon, 18 Nov 2019 07:42:10 -0800 (PST)
Received: from mx2.cnes.fr (mx2.cnes.fr [194.199.174.201]) (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 A7739120A1C for <nwcrg@irtf.org>; Mon, 18 Nov 2019 07:42:09 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.68,320,1569283200"; d="scan'208,217"; a="30930890"
X-IPAS-Result: A2HGAQDYutJd/wIBeApbChoBAQEBAQEBAQEDAQEBAREBAQECAgEBAQGBfoEcgV0TgSoHCoQgkRd/gjyGHY9qgWMECQEBAQEBAQEBASABDAoBAYRAAheCMTgTAg4BAQEEAQEBAQEFAgEBAgKFVEwMhicCAQMBARgDBgo7BAIIAxACAQgNFRYBBgMCAgIlCxQRAgQBDQUIBoMVgkYDNgewN4EyGoQjAg5BhR4QgTaBZYM2iRGBEAFGgU5JNT6CGzwLAQECAQEWgQ8FAQcFBgEHFAYFBwkfAgaCUjKCLASKfAiBfBKCfYVHJG6INI5MQQeBPHGCN4EXg0yKI4QtdYFJc4Z1hCcDi0GOSIFBhneCEwiCcI5WgQpxMxonKyGCbAlHEZE6F4dZgQuFP3QBjB0OgSKBDwEB
X-URL-LookUp-ScanningError: 1
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
To: "'lloyd.wood@yahoo.co.uk'" <lloyd.wood@yahoo.co.uk>, "'nwcrg@irtf.org'" <nwcrg@irtf.org>, 'Vincent Roca' <vincent.roca@inria.fr>
CC: 'Marie-Jose Montpetit' <marie@mjmontpetit.com>
Thread-Topic: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"
Thread-Index: AQHVi6tETrE+7trmnUuJfIRAHJmiKKdy8p+QgAldWQCAFOQFsA==
Date: Mon, 18 Nov 2019 15:41:07 +0000
Deferred-Delivery: Mon, 18 Nov 2019 15:41:09 +0000
Message-ID: <F3B0A07CFD358240926B78A680E166FF1ED01C41@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <D63FBBF9-CA7C-4AD1-9480-D335612FE708@inria.fr> <1665181122.766936.1572059555355@mail.yahoo.com> <F3B0A07CFD358240926B78A680E166FF1ECDFA49@TW-MBX-P03.cnesnet.ad.cnes.fr> <1360597091.280256.1572946390860@mail.yahoo.com>
In-Reply-To: <1360597091.280256.1572946390860@mail.yahoo.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-25050.007
x-tm-as-result: No--29.223000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/mixed; boundary="_004_F3B0A07CFD358240926B78A680E166FF1ED01C41TWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/z3A3nXKqMHlVUhCet7xLv4LduNA>
Subject: Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"
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: Mon, 18 Nov 2019 15:42:15 -0000
Dear Lloyd, all, We have updated the draft and hope this covers most of the issues. This update also covers the comments from Vincent. We will present this update on Thursday’s meeting. Please let us know if you have further comments on this version. Moreover, see inline for some comments on your email. Thanks, Nicolas De : lloyd.wood@yahoo.co.uk <lloyd.wood@yahoo.co.uk> Envoyé : mardi 5 novembre 2019 10:33 À : nwcrg@irtf.org; Vincent Roca <vincent.roca@inria.fr>; Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> Cc : Marie-Jose Montpetit <marie@mjmontpetit.com> Objet : Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites" (If a new draft is issued, does the last call clock restart?) Nicolas " I guess we should not go back to the "network coding"-like title." Since this draft talks about network coding, it needs to explicitly state that, often, imo. Whenever this draft talks about coding, it means network coding -- and it does need to state that to avoid losing the satellite-oriented audience. [NK] Looking again at the Taxonmy draft, it appears we can actually use the network coding title. I have changed that in the document. Thank you. Considering for instance geostationary satellite system (GEO), physical or link layer erasure coding mechanisms recover transmission losses within a negligible delay compared to link delay. The whole point of a FECFRAME and its two layers of coding is to recover and correct bit errors with no delay. This is not considered an erasure coding mechanism, which is very much a network coding concept. It really isn't possible to talk about DVB-S(2|2x) without some mention of FECFRAME. [NK] We present BBFRAME and PLFRAME. For more information on the DVB standards, we ask the reader to go to DVB document. The objective is more to explain how multigateway systems work – no need to go further in the detail to understand the use-cases in my opinion. Further exploiting coding techniques at application or transport layers is an opportunity for releasing constraints on the physical layer Having coding at the physical layer releases constraints on higher layers. They can be viewed as supplementary, or different points in a design tradeoff space. Why you'd want to free up physical layer overhead engineered and carefully tuned for the channel and link for something that isn't, imposing more overhead -- well, that's a good question. [NK] We have tried to clarify that in the updated version. We do not speak about releasing the physical layer constraints – let each of the network and physical operate separately (which will probably be the case in deployed environments). It focuses on situations where coding is not widely deployed in current SATCOM systems. Coding is widely deployed in every current satcom system. You mean network coding *for applications and transports traversing satellite links*. I can't stress enough how much this matters. The implication that this will somehow 'fix' satellite systems that don't have the coding that is considered desirable does the draft a disservice. [NK] Same as before – we have tried to make that clearer in the introduction. inconsistent typo: "out door" (using multiple paths does not guarantee an improvement of both the reliability and the total capacity). I believe you mean "using multiple paths does not guarantee an improvement of *either* the reliability *or* the total capacity). Express it in Boolean algebra... [NK] Updated (sentence partially removed) Sorry, commenting on this draft requires far more time than I have available, so I'll stop here. [NK] Thanks for your comments. best Lloyd Wood lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> http://about.me/lloydwood On Wednesday, 30 October 2019, 20:40:17 GMT+11, Kuhn Nicolas <nicolas.kuhn@cnes.fr<mailto:nicolas.kuhn@cnes.fr>> wrote: Dear Lloyd, Thank you for your feedback. Please find comments to your points in-line. We have submitted an updated version of the draft. We have also prepared slides to discuss the different points during the next IETF meeting. Cheers, Nicolas -----Message d'origine----- De : nwcrg <nwcrg-bounces@irtf.org<mailto:nwcrg-bounces@irtf.org>> De la part de lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> Envoyé : samedi 26 octobre 2019 05:13 À : nwcrg@irtf.org<mailto:nwcrg@irtf.org>; Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>> Cc : Marie-Jose Montpetit <marie@mjmontpetit.com<mailto:marie@mjmontpetit.com>> Objet : Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites" https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ some comments, since I haven't seen much traffic on this: Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front? [NK] In PR #51 : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction. I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc. They're stated as out of scope... If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be '_network_ coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity. [NK] In PR #52 , we have changed: "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." by "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems." For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level. For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title. Discussion of BBFRAME without discussing the FECFRAME (BBFRAME with coding) appears to be an omission. Is this imagining a world where FECFRAME, and its convolutional layers of coding are considered completely unnecessary due to path coding within the BBFRAME? If so (and it won't gain much traction) this would need to be stated. I don't think claiming that FECFRAME is link/channel and out of scope really flies; BBFRAME is a link construct too. [NK] In the representation that is proposed in Fig 2, we consider that the physical gateway turns BBFRAME into PLFRAME. We did not want to go more into the details on how this is achieved. We have added in PR #53 Fig 2: PEP is primarily a transport-level function; firewalls are primarily network and transport. Having one outdour unit (dish at gateway?) when the other end (user terminal) has both an indoor and outdoor unit (IDU and ODU) seems a simplification. No idea what the stepped end user boxes mean; if four end users, four boxes the same size might convey that better, with numbers on them. 1, 2, 3, 4 ... n [NK] We have reworked the figure in PR #54 . We hope this is clearer. minor nits: section 4.1 - PEP is Enhancing, not Enhancement. PEP_s_ usually split... section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well. ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist. [NK] Thanks for the nits on the PEP. For the comment on ACM, we have updated the text (PR #55) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough." We have updated the conference in PR #56 and PR #57 This document has a difficult task (trying to build something from nothing) but at least it's readable enough to debate. [NK] Thanks a lot ! best Lloyd Wood lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> http://about.me/lloydwood On Wednesday, 16 October 2019, 01:37:00 GMT+11, Vincent Roca <vincent.roca@inria.fr<mailto:vincent.roca@inria.fr>> wrote: Hello everybody, A first RG Last Call for the « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04 draft in April this year enabled to collect many highly valuable feedbacks. They have been taken into consideration according to the authors who produced an update. It’s now time to start a second RG LC for version -06: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ We would like to collect your comments by Wednesday 6th, November (3 weeks). Thanks in advance. Marie-Jose and Vincent _______________________________________________ nwcrg mailing list nwcrg@irtf.org<mailto:nwcrg@irtf.org> https://www.irtf.org/mailman/listinfo/nwcrg _______________________________________________ nwcrg mailing list nwcrg@irtf.org<mailto:nwcrg@irtf.org> https://www.irtf.org/mailman/listinfo/nwcrg A new version of I-D, draft-irtf-nwcrg-network-coding-satellites-07.txt has been successfully submitted by Nicolas Kuhn and posted to the IETF repository. Name: draft-irtf-nwcrg-network-coding-satellites Revision: 07 Title: Coding techniques for satellite systems Document date: 2019-10-29 Group: nwcrg Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-network-coding-satellites-07.txt Status: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ Htmlized: https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-07 Htmlized: https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites Diff: https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-07 Abstract: This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). This document follows the taxonomy document [RFC8406] and considers coding as a linear combination of packets that operate in and above the network layer. In this context, this memo details a multi-gateway satellite system to identify use-cases where coding is relevant. As example, coding operating in and above the network layer can be exploited to cope with residual losses or provide reliable multicast services. The objective is to contribute to a larger deployment of such techniques in SATCOM systems. This memo also identifies open research issues related to the deployment of coding in SATCOM systems, such as the interaction between congestion controls and coding techniques. 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. The IETF Secretariat
--- Begin Message ---A new version of I-D, draft-irtf-nwcrg-network-coding-satellites-08.txt has been successfully submitted by Nicolas Kuhn and posted to the IETF repository. Name: draft-irtf-nwcrg-network-coding-satellites Revision: 08 Title: Network coding for satellite systems Document date: 2019-11-18 Group: nwcrg Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-network-coding-satellites-08.txt Status: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ Htmlized: https://tools.ietf.org/html/draft-irtf-nwcrg-network-coding-satellites-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-network-coding-satellites Diff: https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-network-coding-satellites-08 Abstract: This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). This document follows the taxonomy document [RFC8406] and considers coding as a linear combination of packets that operate in and above the network layer. In this context, this memo details a multi-gateway satellite system to identify use-cases where network coding is relevant. As example, network coding operating in and above the network layer can be exploited to cope with residual losses or provide reliable multicast services. The objective is to contribute to a larger deployment of such techniques in SATCOM systems. This memo also identifies open research issues related to the deployment of network coding in SATCOM systems, such as the interaction between congestion control and network coding techniques. 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. The IETF Secretariat--- End Message ---
- [nwcrg] 2nd RG Last Call for draft "Network codin… Vincent Roca
- Re: [nwcrg] 2nd RG Last Call for draft "Network c… lloyd.wood@yahoo.co.uk
- Re: [nwcrg] 2nd RG Last Call for draft "Network c… Kuhn Nicolas
- Re: [nwcrg] 2nd RG Last Call for draft "Network c… lloyd.wood@yahoo.co.uk
- Re: [nwcrg] 2nd RG Last Call for draft "Network c… Vincent Roca
- Re: [nwcrg] 2nd RG Last Call for draft "Network c… Vincent Roca
- Re: [nwcrg] 2nd RG Last Call for draft "Network c… Kuhn Nicolas