[nwcrg] TR: I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt
Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> Mon, 29 March 2021 08:15 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 1015A3A349B; Mon, 29 Mar 2021 01:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 3_mnEjy4qTQo; Mon, 29 Mar 2021 01:15:27 -0700 (PDT)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (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 2B59C3A3492; Mon, 29 Mar 2021 01:15:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.81,287,1610409600"; d="txt'?scan'208,217";a="25705810"
IronPort-HdrOrdr: A9a23:CMt21qBSS9p1gkflHegssceALOonbusQ8zAX/mh6QxBNb4i8n8ehgPwU2XbP+VMscVsnns2NP7TFZHva+4J874V5B8bHYCDNvmy0IIZ+qbbz2jGIIVyOysdx3bptGpIeNPTeFl5/5PyR3CCZFJIazMCD4OSUg47lvhVQZCVLT40l0AtjEAacFSRNNXl7LL40DoCV6MYChxfIQxQqR/+2DHUEQOTPzuej/PnbSCULCBI95A6FgSnA0s+YLzGjwhwcXzlTqI1PzUH5khf07qjmk/a3xg607QHuxqlWg9fox59/AtWNgKEuRQnEtwDAXulccozHmApwgem0rH42jdHHon4bTqNOwkKUWlvwnDzA9E3L1i0053rr1FmC6EGTx/DRVXY9EMpOhYVQbxvf5Q4hpbhHodt29nPcqp4SBQmFhT/66sTDSlV0mlHcmwtbrccDy2FaFYMFLKRct5Ab4SpuYew9NTO/9YRiGPMrENvR/7JfaEqAaW/Usy10zNugUm9bJGb6fmES/tGQlzBN2Gxiw1Bdz8kYlHUN+dYmR55I6/+sCNUVqJheCtITZbhwQOMIXMG3BmHXQR+kChPpHX33ULwCM2jA74X6+qkx+YiRCeM15Yp3hZDISl8dqmIoYULpDqS1reN2ziw=
X-IPAS-Result: A2GiAAAPjGFg/wUBeApaGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQAeBSYEjgWkVgUEKiAKNdwOBCY4ai1OBVwwFBAcBAQEBAQEBAQEmAQwKBAEBAwEChEoCggQmOBMCEQEBAQUBAQEBAQYCAQECAoZODYNVgQcBAQEBAQEBAQEBAQEBAQEBAQEBARYCDTQeNRIBAR4CAQMBASUGOgUCCBMCARUVFgEGBwIlCxQRAgQBCQkIBgYHBIJSgxarSIEBMxqDbTwCDkGFHhCBOYFlhAISPkaGTYJNgRJDgiRzgmABAQIBFYEICQESASM0gxWCKwSBS1wZKRsjAwRNBAIJCw41BBYKFkgEAQx7DQKQVYsFMoEiDosPkVwHgWCBKYM5gUOCcF6BD5MrgTCCGIE9iTCFdwOQIZUHgg6JUpIbKBOGZ4ENXQwHMxonKyGCaQlHFwKTWYNWhUVzAjYCBgEJAQEDCYgVgQ8BAQ
From: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
To: iccrg IRTF list <iccrg@irtf.org>, "nwcrg@irtf.org" <nwcrg@irtf.org>
Thread-Topic: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt
Thread-Index: AQHXJGnjHKlG8ZCM9kiDmx9EwbAJbaqam9UQgAACa2A=
Date: Mon, 29 Mar 2021 08:15:12 +0000
Message-ID: <F3B0A07CFD358240926B78A680E166FF29EDB024@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <161700147133.22617.16871933522324496228@ietfa.amsl.com> <F3B0A07CFD358240926B78A680E166FF29EDAFFB@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF29EDAFFB@TW-MBX-P03.cnesnet.ad.cnes.fr>
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-12.5.0.1300-8.6.1012-26058.006
x-tm-as-result: No-21.513400-8.000000-10
x-tmase-matchedrid: pS5owHKhBO1NVg3Li0PCEe9VsdrlGzy3Q6/DFZugyt1bYv6Kt+uF2MxF Qxp3PhHymoRv4vCWtWMfvo9UW9ImXv+z7xWvCPyPWcC0gYMYIWiOVGny5q72hiPS9JdK3W4/zU4 H2c6gTjpvs7O6BK2XsGpSYPxhGlMN7jqH2swLxXU2aDVyTGx/pxLBqTl41fL7WAuSz3ewb22pFk uoLGicpI0ogGHrw9oBQUUiDKo91ac/o9fCvwdk6JMIKPXbrloXvHa+hRvAUH1tw+n+iKWyyCLyw WZ/CAIYOpcEOclfTPwHLxww6qa5TFOi9a5lapaRTvKpZzlxUs/kfQS18orxxfSgZ3CX4oFLriuZ AgOgHpIxzHahWmOQdrPIxdXxAeq3cc8G9KynN+Nwju9EALAXQuDTYjejIZTwEqzh2sHXZHH5ih3 vHFgxg05rYZ+cFoBAbIZCmyI98CK+WlI/IhdA9Cwgwmow2VqdC//1TMV5chPjW2KX8PkX4fzvXp GH7vLsCDUi2EYoNwRLvW+ssUrId6N75GuP9d2rWWWKbgcV5YDj6uJZtaDo+z+B/tp8itBTQWjuo lC45cDugJ7xOOWC2j2hcR9jfp1aJs0QWpqU6W2DrIfvx7TmRe6MaCZLGd2igOlK2zN496mR7BD0 B8/rLDSlDjWOe2txTTus4Pg7jbl3UZqiNERvWAlbBe5jKGf9CqIE7aqEIgZFqNN+rKg39d+XQ++ q8wX3wjvOqfCb7ERHZP3tzirchNOxwlDCh8axkoluQT32NnXvSp2iuuHtondiYU4RNQy5/RgUa2 YLotYhSMpzgOAsc1odAALK4kAOWVAl4So01gCJDLgwb/1K2cidYBYDjITpXDBk2VC+1hoNv6qGl da/jNvfL4/PTwuKy/X4d6vkLHBDRVAt3yTh9eJXLB8dCl5zjwf08UhqHYimkXDQDNUEsloubvey eQo27e/uvhXOQbpQk8sUqWeO6g==
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--21.513400-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.6.1012-26058.006
Content-Type: multipart/mixed; boundary="_004_F3B0A07CFD358240926B78A680E166FF29EDB024TWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/ZJSidiQOeiKBtIQbVHPfo6sQqaI>
Subject: [nwcrg] TR: I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.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: Mon, 29 Mar 2021 08:15:32 -0000
Forwarding this email to ICCRG in case congestion-control people are interested and willing to provide comments on this draft. Thanks, Nicolas - on the behalf of the authors De : nwcrg <nwcrg-bounces@irtf.org> De la part de Kuhn Nicolas Envoyé : lundi 29 mars 2021 10:14 À : nwcrg@irtf.org Objet : Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt Hello, Following our presentation at IETF110 and the useful feedbacks that we received, here is an update of the document. In particular the following comments were not replied by emails and generated issues and updates on the document. They are recalled here. Please let us know if you have any view or comment on this version of the document. Comments on the research aspects of the draft from Marie-José : This is an IRTF document how is this relating to current research and where? CC and NC are essentially two competing control loops - there is a lot of heritage on that topic (outside networking too) - what can NC/CC learn from that - any research questions? My experience with NC is that the most gains are in low loss networks (far from network capacity) - where in fact CC protocols over react- is there research on appropriate metrics? Most of the gain seems to be in last-mile/access networks - any other research? -> All of this to say that the draft should be clearer on the type of research that is needed again when the performance is impacted 2 conflicting control loops. We have worked on the research section and added several open research questions : Research question 1 : "Is there a way to dynamically adjust the codec characteristics depending on the transmission channel, the transport protocol and application requirements ?" Research question 2 : "Should we apply specific per-stream FEC mechanisms when multiple streams with different reliability needs are carried out ?" Research question 3 : "Should we quantify the harm that a coded flow would induce on a non-coded flow ? How can this be reduced while still benefiting from advantages brought by FEC ?" Research question 4 : "If transport and FEC senders are not collocated, if the FEC is applied only on the last mile, would this raise fairness issues ?" Research question 5 : "Should we propose a generic API to allow dynamic interactions between a transport protocol and a coding scheme ? This should consider existing APIs between application and transport layers." Comments on adding more content on the partial reliability and parameter derivation from Vincent: While working on RFC 8681 on sliding window codes, we tried to find appropriate parameter derivation techniques. It turned out to be quite difficult. You can have a look at the discussion here: https://www.rfc-editor.org/rfc/rfc8681.html#name-possible-parameter-derivati would say that partial reliability essentially impacts the type of FEC and type of codec you can use. If your codec does not enable a subset of the linear system to be inverted, but instead waits to have the perfect expected rank to invert and recover missing packets, you won't achieve partial reliability. Partial reliability also impacts the way you use a block FEC: in that case, I'd say use small block sizes, so that you can solve one of them but not necessarily all of them... except that it will also lower the robustness in front of long loss periods. This is typically where sliding window codes do offer a key advantage. (see https://hal.inria.fr/hal-01571609v1/en/) We have added a new section on types of coding : 2.4. Types of coding [RFC8406] summarizes recommended terminology for Network Coding concepts and constructs. In particular, the document identifies the following coding types (among many others): o Block Coding: Coding technique where the input Flow must first be segmented into a sequence of blocks; FEC encoding and decoding are performed independently on a per-block basis. o Sliding Window Coding: general class of coding techniques that rely on a sliding encoding window. The decoding scheme may not be able to decode all the symbols. The chance of decoding the erased packets depends on the size of the tencoding window, the coding rate and the distribution of erasure in the transmission channel. The FEC channel may let the client transmit information related to the need of supplementary symbols to adapt the level of reliability. Partial and full reliability could be envisioned. o Full reliability: The receiver may hold symbols until the decoding of source packets is possible. In particular, if the codec does not enable a subset of the linear system to be inverted, the receiver would have to wait for a certain minimum amount of repair packets before it can recover all the source packets. o Partial reliability: The receiver cannot deliver source packets that could not have been decoded to the upper layer. If the size of the encoding window (for Sliding Window Coding) and the size of the blocks (for Block Coding) are large, the chances of recovering the erased symbols would increase. However, this would impact on memory requirements and the cost of encoding and decoding processes. Cheers, Nicolas - on the behalf of the authors -----Message d'origine----- De : nwcrg <nwcrg-bounces@irtf.org<mailto:nwcrg-bounces@irtf.org>> De la part de internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> Envoyé : lundi 29 mars 2021 09:05 À : i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Cc : nwcrg@irtf.org<mailto:nwcrg@irtf.org> Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt 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 : Coding and congestion control in transport Authors : Nicolas Kuhn Emmanuel Lochin Francois Michel Michael Welzl Filename : draft-irtf-nwcrg-coding-and-congestion-07.txt Pages : 21 Date : 2021-03-29 Abstract: Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications: FEC coding for tunnels is out-of-the scope of the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-07 https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-07 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<mailto:nwcrg@irtf.org> https://www.irtf.org/mailman/listinfo/nwcrg
- [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-c… internet-drafts
- Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-a… Kuhn Nicolas
- [nwcrg] TR: I-D Action: draft-irtf-nwcrg-coding-a… Kuhn Nicolas