Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt

Kuhn Nicolas <> Mon, 29 March 2021 08:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 528663A3494 for <>; Mon, 29 Mar 2021 01:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-SAhJDFyWhK for <>; Mon, 29 Mar 2021 01:13:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9864F3A3492 for <>; Mon, 29 Mar 2021 01:13:49 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.81,287,1610409600"; d="scan'208,217"; a="25705749"
IronPort-HdrOrdr: A9a23:/EZ3qa6z/0HkbmdB3gPXwRqBI+orLtY04lQ7vn1ZYRZeftWE0+Wnm/oG3RH54QxhPk0Is/roAsi9aFnb8oN45pRUGL+kUhXvtmfAFvAa0aLJxTr8FyristNMzKsISdkDNPTcBUV35PyKhTWQPM0nxLC8n5yAocf74zNTQRpxa6dmhj0JdTqzNkFtXgFJCd4YOfOnl656jgGtc3gWcci3b0NtN4OoyrH2vanrbhIcCxks5BPmt0LO1JfAHwWFxRBbajtTwN4ZgBb4ujbk7aauuezT8H/h/lLT9JhflZ/AzdZOFaW3+6ooAwjskQqhacBdXaSDtlkO0YKSwWst+eOjnz4Qe+pWr0ncdH2voQb8sjOQoAoG2jvH8xu4iWGmidHlTDg6YvAx/b5xQ1/80Q4cm/1SlIhMxHmUspJLCwioplWH2/H4EyxP0nCSnEBnq8ovthVkIPojQa4UqZZa8FJeEZ8GEi6/9ZsuF/N2CtrAoPlMd1eXaG3Yo3lvzNSgUm9bJGb9fmES/sqP0zZXm3hlz0wXgMwH901wia4Adw==
From: Kuhn Nicolas <>
To: "" <>
Thread-Topic: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt
Thread-Index: AQHXJGnjHKlG8ZCM9kiDmx9EwbAJbaqam9UQ
Date: Mon, 29 Mar 2021 08:13:43 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-tm-as-product-ver: SMEX-
x-tm-as-result: No-5.619500-8.000000-10
x-tmase-matchedrid: vidldv5+ihlpqVqRsz8yXdpe3l9SY7mKNj5YnJydBoPa1k28YGld4orX D+bADTRBCUkBXkWB98zJfFIPuKf5SGegi+BqmE9/GeO7qZlPlkr5eXPiU1Wdb5aiEpuHKYssftw Z3X11IV0=
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--5.619500-8.000000
x-tmase-version: SMEX-
Content-Type: multipart/alternative; boundary="_000_F3B0A07CFD358240926B78A680E166FF29EDAFFBTWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Mar 2021 08:13:55 -0000


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:

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.


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



Nicolas - on the behalf of the authors

-----Message d'origine-----
De : nwcrg <> De la part de
Envoyé : lundi 29 mars 2021 09:05
À :
Cc :
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


   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


   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:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:


nwcrg mailing list<>