Hello,=

&= nbsp;

Following our presentation at IETF110 and the useful feedbacks tha= t we received, here is an update of the document.

In particular the following comments were not replied by emails an= d 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=E9= :

This is an IRTF document how is th= is relating to current research and where?

CC and NC are essentially two comp= eting control loops - there is a lot of heritage on that topic (outside net= working 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 la= st-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 t= he performance is impacted 2 conflicting control loops.

We have worked on the research section and added several open rese= arch questions :

Research question 1 : "Is there a way to= dynamically adjust the codec

characteristics depending on the transmission chan= nel, the transport

protocol and application requirements ?"=

Research question 2 : "Should we apply specif= ic per-stream FEC

mechanisms when multiple streams with different re= liability 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 ?&= quot;

Research question 4 : "If transport and FEC s= enders 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 ge= neric API to allow

   dynamic interactions between a transport protocol = and a coding scheme

   ? This should consider existing APIs between appli= cation and

   transport layers."     &nb= sp;

Comments on adding more content on the partial reliability and = parameter derivation from Vincent:

While working on RFC 8681 on slidi= ng window codes, we tried to find appropriate parameter derivation

techniques. It turned out to be qu= ite difficult. You can have a look at the discussion here:

https://www.rfc-edit= or.org/rfc/rfc8681.html#name-possible-parameter-derivati

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 su= bset of the linear system to be inverted, but instead waits to have the

perfect expected rank to invert an= d recover missing packets, you won’t achieve partial reliability.

Partial reliability also impacts t= he way you use a block FEC: in that case, I’d say use small block siz= es, so

that you can solve one of them but= not necessarily all of them… except that it will also lower the robu= stness

in front of long loss periods. Thi= s is typically where sliding window codes do offer a key advantage.

(see ht= tps://hal.inria.fr/hal-01571609v1/en/)<= o:p>

We have added a new section on types of coding :

2.4. Types of coding

   [RFC8406] summarizes recommended terminology for N= etwork Coding

   concepts and constructs. In particular, the = document identifies the

   following coding types (among many others):

   o Block Coding: Coding technique where the i= nput Flow must first be

      segmented into a sequence of blo= cks; FEC encoding and decoding are

      performed independently on a per= -block basis.

   o Sliding Window Coding: general class of co= ding techniques that

      rely on a sliding encoding windo= w.

   The decoding scheme may not be able to decode all = the symbols. The

   chance of decoding the erased packets depends on t= he size of the

   tencoding window, the coding rate and the distribu= tion of erasure in

   the transmission channel. The FEC channel ma= y let the client

   transmit information related to the need of supple= mentary symbols to

   adapt the level of reliability. Partial and = full reliability could

   be envisioned.

   o Full reliability: The receiver may hold sy= mbols until the decoding

      of source packets is possible.&n= bsp; In particular, if the codec does

      not enable a subset of the linea= r system to be inverted, the

      receiver would have to wait for = a certain minimum amount of repair

      packets before it can recover al= l the source packets.

   o Partial reliability: The receiver cannot d= eliver source packets

      that could not have been decoded= to the upper layer. If the size

      of the encoding window (for Slid= ing Window Coding) and the size of

      the blocks (for Block Coding) ar= e large, the chances of recovering

      the erased symbols would increas= e. However, this would impact on

      memory requirements and the cost= of encoding and decoding

      processes.=

Cheers,

Nicolas - on the behalf of t= he authors

-----Message d'origine-----
De : nwcrg <nwcrg-bounces@irtf.org> De la part de internet-draft= s@ietf.org
Envoy=E9 : lundi 29 mars 2021 09:05
=C0 : i-d-announce@ietf.org
Cc : nwcrg@irtf.org
Objet : [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-congestion-07.= txt

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the Coding for effic= ient NetWork Communications Research Group RG of the IRTF.

        Title&= nbsp;          : Coding and co= ngestion control in transport

        Author= s         : Nicolas Kuhn=

        &= nbsp;           &nbs= p;     Emmanuel Lochin

        &= nbsp;           &nbs= p;     Francois Michel

        &= nbsp;           &nbs= p;     Michael Welzl

        &= nbsp;       Filename    &= nbsp;   : draft-irtf-nwcrg-coding-and-congestion-07.txt

        &= nbsp;       Pages    &nbs= p;      : 21

        &= nbsp;       Date     = ;       : 2021-03-29

Abstract:

   Forward Erasure Correction (FEC) is = a reliability mechanism that is

   distinct and separate from the retra= nsmission logic in reliable

   transfer protocols such as TCP. = ; FEC coding can help deal with losses

   at the end of transfers or with netw= orks having non-congestion

   losses. However, FEC coding me= chanisms should not hide congestion

   signals. This memo offers a di= scussion of how FEC coding and

   congestion control can coexist. = ; Another objective is to encourage

   the research community to also consi= der congestion control aspects

   when proposing and comparing FEC cod= ing 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 codin= g for tunnels is out-of-the scope

   of the document.

The IETF datatracker status page for this draft i= s:

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-congest= ion-07

https://datatracker.ietf.org/doc/html/draft-irtf-nwcr= g-coding-and-congestion-07

A diff from the previous version is available at:=

https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-nwcrg-co= ding-and-congestion-07

Please note that it may take a couple of minutes = from the time of submission until the htmlized version and diff are availab= le at tools.ietf.org.

Internet-Drafts are also available by anonymous F= TP at:

<= span lang=3D"EN-US" style=3D"color:windowtext;text-decoration:none">ftp://f= tp.ietf.org/internet-drafts/

_______________________________________________

nwcrg mailing list

nwcrg@irtf.org=

https://www.ir= tf.org/mailman/listinfo/nwcrg

Forwarding this email to ICCRG = in case congestion-control people are interested and willing to provide com= ments on this draft.

Thanks,

Nicolas – on the behalf of the authors

De := nwcrg <nwcrg-bounces= @irtf.org> De la part de Kuhn Nicolas
Envoy=E9 : lundi 29 mars 2021 10:14
=C0 : nwcrg@irtf.org
Objet : Re: [nwcrg] I-D Action: draft-irtf-nwcrg-coding-and-con= gestion-07.txt