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

From: [email-masked]
Date: Mon, 15 Feb 2021 23:42:58 -0800

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:
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-05
https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-05

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/

---

From: Kuhn Nicolas <[email-masked]>
Date: Tue, 16 Feb 2021 07:45:47 +0000

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 <[email-masked]> De la part de [email-masked]
Envoyé : mardi 16 février 2021 08:43
À : [email-masked]
Cc : [email-masked]
Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt

Abstract:

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.

_______________________________________________
nwcrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: roca <[email-masked]>
Date: Wed, 17 Feb 2021 11:51:45 +0100

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.

Cheers,

  Vincent

———

Generally speaking, this is a great document IMHO.
Otherwise:

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

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 https://hal.inria.fr/hal-01571609v1/en/ <https://hal.inria.fr/hal-01571609v1/en/>)

** 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:
Mistake:
   « 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
defined. 

** 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:
https://www.rfc-editor.org/rfc/rfc8681.html#name-possible-parameter-derivati

Typo: 
** 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 <[email-masked]> a écrit :
> 
> Dear all, 
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 17 Feb 2021 12:47:30 -0500

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

mjm

Marie-José Montpetit, Ph.D.
[email-masked]

From: roca <[email-masked]> <[email-masked]>
Reply: roca <[email-masked]> <[email-masked]>
Date: February 17, 2021 at 5:52:20 AM
To: Kuhn Nicolas <[email-masked]> <[email-masked]>
Cc: roca <[email-masked]> <[email-masked]>, iccrg IRTF list
<[email-masked]> <[email-masked]>, [email-masked] <[email-masked]>
<[email-masked]>
Subject:  Re: [nwcrg] I-D Action:
draft-irtf-nwcrg-coding-and-congestion-05.txt

Dear authors, everybody,

Cheers,

  Vincent

———

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

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 https://hal.inria.fr/hal-01571609v1/en/)

** 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:
Mistake:
   « 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
defined.

** 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:
https://www.rfc-editor.org/rfc/rfc8681.html#name-possible-parameter-derivati

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

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,

-----Message d'origine-----
De : nwcrg <[email-masked]> De la part de [email-masked]
Envoyé : mardi 16 février 2021 08:43
À : [email-masked]
Cc : [email-masked]
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.

Abstract:

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.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Feb 2021 13:34:02 +0100

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 <[email-masked]> wrote:
> 
> 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 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?

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

Cheers,
Michael

> - Most of the gain seems to be in last-mile/access networks - any other research?
> 
> mjm
> 
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> From: roca <[email-masked]> <mailto:[email-masked]>
> Reply: roca <[email-masked]> <mailto:[email-masked]>
> To: Kuhn Nicolas <[email-masked]> <mailto:[email-masked]>
> Cc: roca <[email-masked]> <mailto:[email-masked]>, iccrg IRTF list <[email-masked]> <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> Subject:  Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt 
> 
>> Dear authors, everybody,
>> 
>> https://www.rfc-editor.org/rfc/rfc8681.html#name-possible-parameter-derivati <https://www.rfc-editor.org/rfc/rfc8681.html#name-possible-parameter-derivati>
>> 
>> 
>> Typo: 
>>> Le 16 févr. 2021 à 08:45, Kuhn Nicolas <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Dear all, 
>>> 
>>> De : nwcrg <[email-masked] <mailto:[email-masked]>> De la part de [email-masked] <mailto:[email-masked]>
>>> À : [email-masked] <mailto:[email-masked]>
>>> Cc : [email-masked] <mailto:[email-masked]>
>>> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
>>> 
>>> https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-05 <https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-05>
>>> https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-05 <https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-05>
>>> 
>>> https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-05 <https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-05>
>>> 
>>> 
>>> 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 <http://tools.ietf.org/>.
>>> 
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>> 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 18 Feb 2021 12:43:14 +0000

See below.

From: Michael Welzl <[email-masked]> <[email-masked]>
Reply: Michael Welzl <[email-masked]> <[email-masked]>
Date: February 18, 2021 at 7:34:11 AM
To: Marie-Jose Montpetit <[email-masked]> <[email-masked]>
Cc: Kuhn Nicolas <[email-masked]> <[email-masked]>, roca
<[email-masked]> <[email-masked]>, iccrg IRTF list
<[email-masked]> <[email-masked]>, [email-masked] <[email-masked]>
<[email-masked]>
Subject:  Re: [nwcrg] I-D Action:
draft-irtf-nwcrg-coding-and-congestion-05.txt

Hi all,

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

On Feb 17, 2021, at 6:47 PM, Marie-Jose Montpetit <[email-masked]>
wrote:

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

Cheers,
Michael

mjm

Dear authors, everybody,

Cheers,

  Vincent

———

** Section 2.1:

** Section 2.2:

** Section 2.3:

** Section 3.3:

** Section 3.6:

** Section 4:

** Section 4.2:

** Section 4.3:
Mistake:

** Section 5.4:

Typo:

Dear all,

Kind regards,

-----Message d'origine-----
De : nwcrg <[email-masked]> De la part de [email-masked]
Envoyé : mardi 16 février 2021 08:43
À : [email-masked]
Cc : [email-masked]
Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt

Abstract:

---

From: Michael Welzl <[email-masked]>
Date: Thu, 18 Feb 2021 14:02:44 +0100

Hi,

Cutting some clutter:

> What I meant is that the greatest descent due to errors in TCP occurs under very low “perceived” loss conditions (like less than 1%).
> 
I’m sorry, I’ll have to ask for more clarification, I’m afraid. With “perceived”, surely you mean loss that’s perceived at the transport layer? Low loss leads to the greatest descent there? What is it that you have in mind - situations where the cwnd has grown to be very large (because loss is low), and then, when loss happens, it’s devastating (because, e.g., halving it is a huge effect)?  I could agree with that.

> 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.
> 
I don’t fully subscribe to this “2 conflicting control loops” view. It depends on the scenario, I guess. E.g., if congestion control operates on unreliable data transfer, and FEC operates on top, repairing losses, then these are quite separate functions, doing separate things, not conflicting.

Anyway, it’s fair that you ask for more clarity in the draft, but that’s why I’m trying to really understand your concrete questions or concerns.

Cheers,
Michael

---

From: Emmanuel Lochin <[email-masked]>
Date: Fri, 19 Feb 2021 17:55:25 +0100

Hi all,

Le 18/02/2021 à 14:02, Michael Welzl a écrit :
>>
>> 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.
>>
> I don’t fully subscribe to this “2 conflicting control loops” view. It 
> depends on the scenario, I guess. E.g., if congestion control operates 
> on unreliable data transfer, and FEC operates on top, repairing 
> losses, then these are quite separate functions, doing separate 
> things, not conflicting.
>
> Anyway, it’s fair that you ask for more clarity in the draft, but 
> that’s why I’m trying to really understand your concrete questions or 
> concerns.

Agree with Michael, there is no control loop for NC. At least, for the 
NC discussed so far at NWCRG.
I mean the generation of encoded packets does not depend on feedback 
while their sending lays on a transport protocol.

EL

-- 
Emmanuel LOCHIN
ENAC - Ecole Nationale de l'Aviation Civile
7, avenue Edouard Belin CS 54005, 31055 Toulouse Cedex 4 France
http://www.enac.fr
https://elochin.github.io/

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 19 Feb 2021 16:57:54 +0000

All points well taken. But highlighting the research problems and who is
going that research is still something the draft should be more  focused
on. Not just a review of what has been done :)

mjm

From: Emmanuel Lochin <[email-masked]> <[email-masked]>
Reply: Emmanuel Lochin <[email-masked]> <[email-masked]>
Date: February 19, 2021 at 11:55:27 AM
To: Michael Welzl <[email-masked]> <[email-masked]>, Marie-Jose
Montpetit <[email-masked]> <[email-masked]>
Cc: roca <[email-masked]> <[email-masked]>, iccrg IRTF list
<[email-masked]> <[email-masked]>, Kuhn Nicolas <[email-masked]>
<[email-masked]>, [email-masked] <[email-masked]> <[email-masked]>
Subject:  Re: [nwcrg] I-D Action:
draft-irtf-nwcrg-coding-and-congestion-05.txt

Hi all,

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.

I don’t fully subscribe to this “2 conflicting control loops” view. It
depends on the scenario, I guess. E.g., if congestion control operates on
unreliable data transfer, and FEC operates on top, repairing losses, then
these are quite separate functions, doing separate things, not conflicting.

Anyway, it’s fair that you ask for more clarity in the draft, but that’s
why I’m trying to really understand your concrete questions or concerns.

Agree with Michael, there is no control loop for NC. At least, for the NC
discussed so far at NWCRG.
I mean the generation of encoded packets does not depend on feedback while
their sending lays on a transport protocol.

EL

--
Emmanuel LOCHIN
ENAC - Ecole Nationale de l'Aviation Civile
7, avenue Edouard Belin CS 54005, 31055 Toulouse Cedex 4
Francehttp://www.enac.frhttps://elochin.github.io/

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 22 Feb 2021 16:50:01 +0000

Hello

Following the comments on the mailing lists, there has been a quick update on the draft to save some cycles.
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/?include_text=1

Thank you very much for the feedback that help improve the document.
Please see inline how the comments have been :

(1)    addressed in the update , or

(2)    added to the issues of the GITHUB repo for further discussions during next IETF and updates of this document.

Cheers,

Nicolas

De : Michael Welzl <[email-masked]>
Envoyé : jeudi 18 février 2021 13:34
À : Marie-Jose Montpetit <[email-masked]>
Cc : Kuhn Nicolas <[email-masked]>; roca <[email-masked]>; iccrg IRTF list <[email-masked]>; [email-masked]
Objet : Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt

Hi all,

On Feb 17, 2021, at 6:47 PM, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

*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.
[NK] I have added these elements on the GITHUB for discussion during the next meeting or update of the document.

Cheers,
Michael

- Most of the gain seems to be in last-mile/access networks - any other research?
[NK] I have added these elements on the GITHUB for discussion during the next meeting or update of the document.

mjm

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: roca <[email-masked]><mailto:[email-masked]>
Reply: roca <[email-masked]><mailto:[email-masked]>
Date: February 17, 2021 at 5:52:20 AM
To: Kuhn Nicolas <[email-masked]><mailto:[email-masked]>
Cc: roca <[email-masked]><mailto:[email-masked]>, iccrg IRTF list <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt

Dear authors, everybody,

Cheers,

  Vincent

———

Generally speaking, this is a great document IMHO.
[NK] Thank you very much.
Otherwise:

** Section 2.1:

[NK] You are right. Updated as follows : ‘ The Forward
   Erasure Correction channel carries repair symbols (from the sender to
   the receiver) and information from the receiver to the sender (e.g.
   signaling which packets have been repaired, loss rate prior and/or
   after decoding, etc.). ‘

** Section 2.2:

[NK] This was not clear in the previous version of the document. Updated as follows:

   The application layer may be composed of several streams above each

   FEC and transport layers instances.  The different streams could

   exploit different paths between the sender and the receiver or not.

   The document considers one application layer stream as input packets

   above a combination of FEC and transport layers.  The case of

   multiple application level streams above multiple FEC and transport

   layers instances is currently out of the scope of the document and

   not further described.
** Section 2.3:

[NK] This was indeed not clear. We have tried to move things around and hope it is better.

   End users may share a bottleneck that may not be ruled by a quality

   of service mechanism that should ensure the fairness between the

   different flows.  In this case, the share of available capacity

   between single flows can help assess when one flow starves the other.

   As one example, for residential accesses, the data-rate can be

   guaranteed for the customer premises equipment, but not necessarily

   for the end user.  The quality of service that guarantees fairness

   between the different clients can be seen as a policy concern

   [I-D.briscoe-tsvarea-fair].

   While past efforts have focused on achieving fairness, quantifying

   and limiting harm caused by new algorithm (or algorithms with coding)

   is more practical [BEYONDJAIN].  This document considers fairness as

   the impact of the addition of coded flows on non-coded flows when

   they share the same bottleneck.

   This document assumes that the non-coded flows respond to congestion

   signals from the network.  This document does not aim at contributing

   to the definition of fairness at a wider scale.

** Section 3.3:

[NK] That was not clear indeed. Updated as follows:

   The coding rate applied at the application layer mainly depends on

   the available capacity given by the congestion control underneath.

   The coding rate could be adapted to avoid adding overhead when the

   minimum required data rate of the application is not provided by the

   congestion control underneath.  When it is not the case, coding would

   reduce packet losses and improve the quality of experience.

** Section 3.6:

[NK] We have added an issue on the GITHUB. Partial reliability should be better described in the document.
In the mean time, we have added the following in all sections on partial reliability.

Partial reliability impacts the type of FEC and

   type of codec that can be used.

** Section 4:

[NK] Updated as follows :

There is a trade-off

   between1) the capacity that could have been exploited to transmit

   source packets and 2) the benefits brought out by transmitting repair

   symbols (e.g. unlocking the receive buffer if this is limiting).

** Section 4.2:

[NK] We removed the sentences.

** Section 4.3:
Mistake:
   « 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
defined.
[NK] Indeed. We have added a definition of coding rate and updated as follows :

   There is an important flexibility in the trade-off, inherent to the

   use of coding, between (1) reducing goodput when useless repair

   symbols are transmitted and (2) helping to recover sooner from

   transmission and congestion losses.  The receiver may indicate to the

   sender the number of packets that have been received or recovered.

   The sender may exploit this information to tune the coding ratio.  As

   one example of flexibility of this case, coupling an increased

   transmission rate with an increasing or decreasing coding rate could

   be envisioned.  A server may use an decreasing coding rate as a probe

   of the channel capacity and adapt the congestion control transmission

   rate.

** Section 5.4:

[NK]    The useless repair symbols only impact the load of the network

   without actual gain for the coded flow.  That being said, using

   feedback signaling, FEC mechanisms can measure the actually used

   symbols and adjust the coding rate.

[NK] Added in the issues list.
Typo:
** section 3.2: add a final « s » to « retransmission » in: « may reduce the number of retransmission »

[NK] Thanks.

Le 16 févr. 2021 à 08:45, Kuhn Nicolas <[email-masked]<mailto:[email-masked]>> a écrit :

Dear all,

Kind regards,

-----Message d'origine-----
De : nwcrg <[email-masked]<mailto:[email-masked]>> De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mardi 16 février 2021 08:43
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt

Abstract:

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<http://tools.ietf.org/>.

_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg
_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg