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

Marie-Jose Montpetit <> Thu, 18 February 2021 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC58C3A11B1 for <>; Thu, 18 Feb 2021 04:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JBvYxXWSvrG6 for <>; Thu, 18 Feb 2021 04:43:18 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E43C3A11B0 for <>; Thu, 18 Feb 2021 04:43:17 -0800 (PST)
Received: by with SMTP id m22so6373107lfg.5 for <>; Thu, 18 Feb 2021 04:43:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VyaHMIDepIopyBIEQb1lgAHdPQ1QDv4uyar7FgmYf3A=; b=06UtTA+5YT3KfHbSb3Qmf2bN+FlajjLg7jORHLx395fl/oI3FaNlgBKVNC/dFQP+5O 9OrGYMWtXYeM1112WXYSRmuxwaa3AQ6QWkGcLGie6+yeyzGa5ciMC25tp0qzYPgL7Ixu d4Ped21DQFvh9146ubOscRqIpQhGbfv2Mm2fmFG/cXuCukJttyy8GfSkfVHqj7f5Vvoh zAlOcDjGTN5/lHjsLADZoS1ZbjO5wvexJHuxnn2p0kl1RNN4NopM2w6nXrECOIQ39sBe X21ybhQREe58SpYIuXi+p5fQln61oZ0sVl7R3uA0z43eIP56iZJpBTTy1IB64DT9fBBc 5kkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VyaHMIDepIopyBIEQb1lgAHdPQ1QDv4uyar7FgmYf3A=; b=Dcaky40kZVOnUb62VXaZztIHPjdpHTVJDOsiZJHXzJHRmC/JZkUMOOWryyTwK7rozt yc8rAVkvUhAhDIcwYx+oMyQY14nfuKScOqRSqOm9JAOYbsaVSp8LZr3dt2MKGMbswLm3 ZsYEOASHHgFkYNXYpgcZnj4tjM5nU+4gMFWD6+4cLtQTb5DB7PV9KT8qMHWvAkZr3VGx S9vOAp9u+Q8PPaRTL4wrtsBq6fpr58yEFbqp8kiXeZ5im6hJ+1cb4aNT9bDkjZpYuE4N rH92MC2YnOtZlFXiG5Bh7u5F3Iblyc6xMTYwXq1F+Bf82m2Iii7M7DGKo3eHpGeXTmjZ c1Iw==
X-Gm-Message-State: AOAM533X9UudJLxDcO5ITgzWVGYtZVdthwN9uEn8Cw/97tMwe+hQIpQB wJhb7VWIbn5B9Xjvgj6yEiLTG2FkFTdqVyH8HWYV9A==
X-Google-Smtp-Source: ABdhPJwrrcACCheJ0EnwW3Vzzi2E1hACFhXFMHFIZDfhlec9Q4yC9YktrVy/UPyzTHX81jl+emv3574UuvkCR8zJE6Y=
X-Received: by 2002:ac2:5191:: with SMTP id u17mr306544lfi.295.1613652195275; Thu, 18 Feb 2021 04:43:15 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 18 Feb 2021 12:43:14 +0000
From: Marie-Jose Montpetit <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Date: Thu, 18 Feb 2021 12:43:14 +0000
Message-ID: <>
To: Michael Welzl <>
Cc: iccrg IRTF list <>, roca <>, Kuhn Nicolas <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e40ed105bb9bad17"
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: Thu, 18 Feb 2021 12:43:21 -0000

See below.

Marie-José Montpetit, Ph.D.

From: Michael Welzl <> <>
Reply: Michael Welzl <> <>
Date: February 18, 2021 at 7:34:11 AM
To: Marie-Jose Montpetit <> <>
Cc: Kuhn Nicolas <> <>, roca
<> <>, iccrg IRTF list
<> <>, <>
Subject:  Re: [nwcrg] I-D Action:

Hi all,

Interesting questions, thanks!  A bit difficult to answer, too… I hope my
co-authors have ideas  ;-)

I’m intrigued by one in particular, down below:

On Feb 17, 2021, at 6:47 PM, Marie-Jose Montpetit <>

Ok so let me add to Vincent’s detailed comments with more generic ones some
of the information exists - it may just need to be re-organized.
- This is an IRTF document how is this relating to current research and
- 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?

*low* loss, far from network capacity? Why would a CC mechanism over-react?
When it’s far from the capacity, there’s nothing to react upon… did you
mean that they are too cautious and flows terminate before even reaching
the capacity limit?  I can imagine this being an interesting scenario for
coding indeed, but I’d like to understand if this is what you meant.

What I meant is that the greatest descent due to errors in TCP occurs under
very low “perceived” loss conditions (like less than 1%). This is where the
coding “gains” are the most important. Also some temporary “perceived”
congestion (when there is in fact still capacity) can have longer term
effect if the CC is very conservative (and yes someone will tell me it’s
not fully the case anymore). 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.


- Most of the gain seems to be in last-mile/access networks - any other


Marie-José Montpetit, Ph.D.

From: roca <> <>
Reply: roca <> <>
Date: February 17, 2021 at 5:52:20 AM
To: Kuhn Nicolas <> <>
Cc: roca <> <>, iccrg IRTF list
<> <>, <>
Subject:  Re: [nwcrg] I-D Action:

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.

** 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
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

  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

  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

nwcrg mailing list

nwcrg mailing list