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

[Michael Welzl <[e-mail]>]

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 <[e-mail]> 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
> 
> Marie-José Montpetit, Ph.D.
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
> From: roca <[e-mail]> <mailto:[e-mail]>
> Reply: roca <[e-mail]> <mailto:[e-mail]>
> Date: February 17, 2021 at 5:52:20 AM
> To: Kuhn Nicolas <[e-mail]> <mailto:[e-mail]>
> Cc: roca <[e-mail]> <mailto:[e-mail]>, iccrg IRTF list <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
> Subject:  Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-05.txt 
> 
>> 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 <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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> De la part de [e-mail] <mailto:[e-mail]>
>>> Envoyé : mardi 16 février 2021 08:43
>>> À : [e-mail] <mailto:[e-mail]>
>>> Cc : [e-mail] <mailto:[e-mail]>
>>> 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:
>>> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <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://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>
>>> 
>>> A diff from the previous version is available at:
>>> 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/>.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> 
>>> _______________________________________________
>>> nwcrg mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>>> 
>>> _______________________________________________
>>> nwcrg mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>> 
>> _______________________________________________ 
>> nwcrg mailing list 
>> [e-mail] <mailto:[e-mail]> 
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg> 
> _______________________________________________
> nwcrg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>