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

roca <> Wed, 17 February 2021 10:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 665033A190D; Wed, 17 Feb 2021 02:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Awq5yvx_R99w; Wed, 17 Feb 2021 02:52:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF1063A18FC; Wed, 17 Feb 2021 02:52:10 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.81,184,1610406000"; d="scan'208,217";a="493448742"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 11:51:46 +0100
From: roca <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F55BC5A-7629-445F-B16B-1ECF967811F4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 17 Feb 2021 11:51:45 +0100
In-Reply-To: <>
Cc: roca <>, "" <>, iccrg IRTF list <>
To: Kuhn Nicolas <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.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: Wed, 17 Feb 2021 10:52:14 -0000

Dear authors, everybody,

Thanks a lot for this significant revision of your I-D.
Here are few comments, based on a quick review of the document.




Generally speaking, this is a great document IMHO.

** Section 2.1:
   "The Forward Erasure Correction channel carries repair symbols (from the sender to
   the receiver) and potential information signaling which packets have
   been repaired (from the receiver to the sender). "

Isn’t it a bit restrictive to say the feedback potentially carries information about repaired symbols only?
We could imagine other types of information (loss rate prior and/or after decoding for instance).
For instance, later, in section 4.3, you mention that: 
   « The receiver may indicate to the sender the number of packets that have been received or recovered. » 

** Section 2.2: 
   "The document considers one application layer stream as input packets.	
   The application layer may exploit several paths above both the FEC	
   and transport layers; this case is not further described in the	

Confusion between « paths » and « stream ». Is it the same? 
Also, since this is a key point, could you just detail a bit more what are the implications of « several paths ».
The various streams could be mapped on top of the same transport connection, or on top of different transport
connection. Consequences are totally different.

** Section 2.3:
This new section is important as it raises key questions.
However the organisation of ideas could perhaps be a bit improved (several ideas are mixed I think).
Last paragraph is okay however and contains the key messages in this section (perhaps swap last two sentences).

** Section 3.3:
I don’t understand this part of the sentence: 
   « Adapting the coding rate to the minimum required data rate of the application… »

If I decide that the code rate adds a 5% overhead, then I don’t really care about the minimum required data rate of the app.
It will increase the required data rate by 5%. 
My concern is more to know if this is compatible with the "available capacity given by the congestion control underneath"
as said just before. I suspect it just needs to be reformulated.

** Section 3.6:
I 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 <>)

** Section 4:
Are you sure that « the cost of capacity used to transmit source packets » is what you mean?
I’d say: « to transmit repair packets » instead.

** Section 4.2:
Is the assumption « If the FEC and CC channels are decoupled » meaningful when we talk about 
FEC within the transport? For me within means that they are both coupled in some way.

** Section 4.3:
   « an increasing coding rate as a probe of the channel capacity » 
Increasing the coding rate reduces the amount of redundancy added. In fact I realize that coding rate is not

** Section 5.4:
I’d suggest talking about adjusting the code rate to what is actually needed instead of saying: 
   « and tune the amount of useless repair symbols »

** Section 6 Open research questions
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:

** section 3.2: add a final « s » to « retransmission » in: « may reduce the number of retransmission » 

> Le 16 févr. 2021 à 08:45, Kuhn Nicolas <> a écrit :
> Dear all, 
> We have worked on an updated version of the draft on interactions between congestion control and network coding. 
> It will be presented in the NWCRG session of IETF110. 
> Please let us know if you have any comments or views on the comment - there is still time for further updating the document before the cut-off for draft submission. 
> Kind regards, 
> Nicolas on the behalf of the authors
> -----Message d'origine-----
> De : nwcrg <> De la part de
> Envoyé : mardi 16 février 2021 08:43
> À :
> Cc :
> Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.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-05.txt
> 	Pages           : 19
> 	Date            : 2021-02-15
> 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.  Using 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:
> 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
> _______________________________________________
> nwcrg mailing list