Subject: [nwcrg] Draft NC and Congestion Control

From: Emmanuel Lochin <[email-masked]>
Date: Sun, 19 Nov 2017 07:54:11 +0100

Dear Marie-Jo, Vincent,

Having quite a bit of time during my flight back, I've tried to figure 
out how to contribute to the draft proposed by MJM. As a first step and 
following my understanding of its goal, I would proposed the outline 
below to trigger the discussion. After several mapping attempts, I've 
converged to three main parts : the first one objective follows the idea 
presented by Vincent in the second presentation "NC for new members -  
Existing network codes and protocols" or the first slides of my 
presentation; while the two other parts deals with congestion-controlled 
and non-congestion controlled solutions. I also tried a slicing with 
reliable/connected vs non-reliable/non-connected or kernel vs userspace 
but the one proposed here appears to fit well. What do you reckon? 
There's certainly missing solutions, so do not hesitate to comment, add 
or suppress items.

Emmanuel

* *NC-layer layering*
     * User-space NC library (with or without encapsulation)
         * AL-FEC (coding library used by a given application)
         * Middleware AL-FEC (socket-like API, encapsulation, proxy, 
tunnel, ...)
     * Kernel NC layer (i.e. without encapsulation)
         * Below a reliable transport layer (e.g. MPTCP/IP, TCP/IP, 
SCTP/IP, DCCP/IP, TFRC/IP, ...)
         * Below a non-reliable transport layer (e.g. UDP/IP)

* *Congestion-controlled coded transport layer solutions*
     * Kernel solutions (network coded transport layer)
         * Unicast
                * Coded-TCP (MIT)
                * SpeedyTCP (SpeedyPackets)
                * Coded-DCCP/TFRC ?
                * KoDo/Transport Protocol (Steinwurf ?)
                * TCP Instant Recovery (Google -> 
draft-flach-tcpm-fec-00.txt)
         * Multicast
                * eCMT-SCTP (ISAE)
                * Coded-MPTCP (MIT)
     * User-space solutions (above UDP/IP)
         * QUIC (Google)
         * Coded-TCP (MIT)
     * User-space cross-layer solutions with transport protocol
         * TENTET (ISAE)
         * other proposal allowing the joint use of a reliable transport 
protocol and NC
             * other cross-layer schemes using ECN
             * other existing proposals/schemes (e.g. ACK pacing, ...) ?

* *Non-congestion controlled coded transport layer solutions*
     * Unicast
         * FECFRAME (INRIA)
         * TETRYS (ISAE)
     * Multicast
         * MTETRYS (ISAE)
         * DragonNet (INRIA)
         * DRAGONCAST (INRIA)
         * SCORE  (Steinwurf)
         * DONC Delay-based Opportunistic Network Coding Protocol (INRIA)
         * other ?

-- 
Emmanuel LOCHIN
Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sun, 19 Nov 2017 18:13:39 +1100

Great start.

I think we also need a section on clearly for one explaining the problem in a generic coded session as well as in a tunneled one. This is what I attempted to describe at the meeting.

Some comments below.

Hello from Sydney Australia!

mjm

> On Nov 19, 2017, at 5:54 PM, Emmanuel Lochin <[email-masked]> wrote:
> 
> Dear Marie-Jo, Vincent,
> 
> Having quite a bit of time during my flight back, I've tried to figure out how to contribute to the draft proposed by MJM. As a first step and following my understanding of its goal, I would proposed the outline below to trigger the discussion. After several mapping attempts, I've converged to three main parts : the first one objective follows the idea presented by Vincent in the second presentation "NC for new members -  Existing network codes and protocols" or the first slides of my presentation; while the two other parts deals with congestion-controlled and non-congestion controlled solutions. I also tried a slicing with reliable/connected vs non-reliable/non-connected or kernel vs userspace but the one proposed here appears to fit well. What do you reckon? There's certainly missing solutions, so do not hesitate to comment, add or suppress items.
> 
> Emmanuel
> * NC-layer layering
>         * Middleware AL-FEC (socket-like API, encapsulation, proxy, tunnel, ...)
>         * Below a reliable transport layer (e.g. MPTCP/IP, TCP/IP, SCTP/IP, DCCP/IP, TFRC/IP, ...)
I think this should be in a separate draft where we describe the existing solution. My idea is for a hierarchy of documents:
Overall code description leading on one hand to the specific codes and on the other to CC.
> 
> * Congestion-controlled coded transport layer solutions
Is there published material we can refer to?
>                * Coded-DCCP/TFRC ?
I would say TFRC and W-TFRC are candidates
>                * KoDo/Transport Protocol (Steinwurf ?)
Again: available material?
>                * TCP Instant Recovery (Google -> draft-flach-tcpm-fec-00.txt)
>         * Multicast
>                * eCMT-SCTP (ISAE)
>                * Coded-MPTCP (MIT)

>     * User-space solutions (above UDP/IP)
Would it be here or in the QUIC/NC draft?
>        * Coded-TCP (MIT)
Other solutions may exist. List: please tell us if you have something.
>         * other proposal allowing the joint use of a reliable transport protocol and NC
Yes…Maybe we also want a section on “proposed/new schemes"
> 
> * Non-congestion controlled coded transport layer solutions
>     * Unicast
>         * FECFRAME (INRIA)
>         * TETRYS (ISAE)
>     * Multicast
>         * MTETRYS (ISAE)
>         * DragonNet (INRIA)
>         * DRAGONCAST (INRIA)
>         * SCORE  (Steinwurf)
Do we need that or we put it in the top document? And again we need references as most of those will not become individual drafts.

Thanks for this and have a good flight!

mjm
> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr <http://www.isae-supaero.fr/>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 20 Nov 2017 07:53:01 +0000

Dear all,

I think this is a very good start to organize the different existing NC-CC solutions.

I wonder if including a header section on generic description would be relevant.
The main point would be to provide WG recommendation such as how to consider NC at the CC level.
E.g. NC might hide some congestion losses that are necessary for loss-based congestion control to actually identify congestion events.
There is a discussion on how you can actually signal the error recovery at the receiver to the transport (e.g. using ECN?).

Kind regards,

Nicolas KUHN
CNES/DSO/NT/ST
(+33)5 61 27 32 13

De : nwcrg [mailto:[email-masked]] De la part de Marie-Jose Montpetit
Envoyé : dimanche 19 novembre 2017 08:14
À : Emmanuel Lochin
Cc : [email-masked]
Objet : Re: [nwcrg] Draft NC and Congestion Control

Great start.

Some comments below.

mjm

On Nov 19, 2017, at 5:54 PM, Emmanuel Lochin <[email-masked]<mailto:[email-masked]>> wrote:

Dear Marie-Jo, Vincent,

               * Coded-DCCP/TFRC ?

       * Coded-TCP (MIT)

mjm

--

Emmanuel LOCHIN

Professeur ISAE

10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr<http://www.isae-supaero.fr/>

Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 30
_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Simone Ferlin <[email-masked]>
Date: Mon, 20 Nov 2017 10:13:21 +0100

Dear Nico & all,

I have not followed the discussion about signalling error recovery in
NWCRG, however, I can give some input, about the discussion we had
while implementing (XOR)-FEC inspired in TCP-IR into MPTCP:
In this more simple case, with XOR, you can recover only one packet
per 'packet block'. We reserved a bit to signal to the sender, using
ACKs, whether the XOR of a given packet block was 1) used to recover,
i.e. there was a loss in the data packets, 2) not used to recover,
i.e. the FEC rate can be recalculated, since wasted at the receiver,
i.e. no loss or 3) lost, i.e. the FEC packet for a given block did not
arrive, i.e. FEC loss.
In 3) the CC reaction is left unchanged, i.e. the CWND is reduced as
the default CC flavour at the sender (one can think about tracking FEC
losses and data loss within the same block, further optimization we
did not do yet). In 2) we have no reaction in the CC, we just
recalculate the FEC rate. However, in 1) there are some possibilities
that can be explored (open to discussion, we have entered multiple
ones with different views.). Important here is: Avoid the so-called
'loss masking' since we cannot distinguish about the origin of this
loss, i.e. whether it is a congestion or a random loss.
For these three cases we use ACK packets to signal information back to
the sender to be able to include it in the CC logic.

Cheers,

On Mon, Nov 20, 2017 at 8:53 AM, Kuhn Nicolas <[email-masked]> wrote:
> E.g. NC might hide some congestion losses that are necessary for loss-based
> congestion control to actually identify congestion events.
>
> There is a discussion on how you can actually signal the error recovery at
> the receiver to the transport (e.g. using ECN?).
>
>
>
> Kind regards,
>
>
>
> Nicolas KUHN
>
> CNES/DSO/NT/ST
>
> (+33)5 61 27 32 13
>
>
>
> I think we also need a section on clearly for one explaining the problem in
> a generic coded session as well as in a tunneled one. This is what I
> attempted to describe at the meeting.
>
>
>
> Some comments below.
>
>
>
> Having quite a bit of time during my flight back, I've tried to figure out
> how to contribute to the draft proposed by MJM. As a first step and
> following my understanding of its goal, I would proposed the outline below
> to trigger the discussion. After several mapping attempts, I've converged to
> three main parts : the first one objective follows the idea presented by
> Vincent in the second presentation "NC for new members -  Existing network
> codes and protocols" or the first slides of my presentation; while the two
> other parts deals with congestion-controlled and non-congestion controlled
> solutions. I also tried a slicing with reliable/connected vs
> non-reliable/non-connected or kernel vs userspace but the one proposed here
> appears to fit well. What do you reckon? There's certainly missing
> solutions, so do not hesitate to comment, add or suppress items.
>
> Emmanuel
>
> * NC-layer layering
> I think this should be in a separate draft where we describe the existing
> solution. My idea is for a hierarchy of documents:
>
> Do we need that or we put it in the top document? And again we need
> references as most of those will not become individual drafts.
>
>
>

---

From: Emmanuel Lochin <[email-masked]>
Date: Mon, 20 Nov 2017 10:55:49 +0100

Dear Marie-Jo,

Answers inline

On 19/11/2017 08:13, Marie-Jose Montpetit wrote:
> I think this should be in a separate draft where we describe the 
> existing solution. My idea is for a hierarchy of documents:

Ok for me, but at this time where we still collect information, I think 
we could start to write a full document first and slice it later as you 
wish ?

> Is there published material we can refer to?

Indeed, I didn't find anything for SpeedyTCP.

> I would say TFRC and W-TFRC are candidates

TFRC is both a full protocol and CCID #3 in DCCP. I'm wondering whether 
somebody used to implement it inside DCCP and manage to deal with all 
CCIDs (in particular CCID #2).

What is W-TFRC ? Didn't find anything when googling... does "W" stands 
for Wireless ? Any pointer welcome.

> Again: available material?

I remember a paper from them... I have to check

> Would it be here or in the QUIC/NC draft?

As far as I understand, the objective of this draft is to list existing 
solutions, so I think both drafts are different.

Emmanuel

-- 
Emmanuel LOCHIN
Professeur ISAE

---

From: Emmanuel Lochin <[email-masked]>
Date: Mon, 20 Nov 2017 10:59:28 +0100

Dear Simone, all,

That would be great if you could provide inputs on TCP-IR. We'll give 
soon a wiki link to collect all contributions.

EL

-- 
Emmanuel LOCHIN
Professeur ISAE

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 20 Nov 2017 21:12:28 +1100

Yes W-TFRC is Wireless. There was work at the Worcester Polytechnic. 
https://www.researchgate.net/profile/Robert_Kinicki/publication/228871355_Performance_Enhancement_of_TFRC_in_Wireless_Networks/links/0a85e53c3c30fa167a000000/Performance-Enhancement-of-TFRC-in-Wireless-Networks.pdf <https://www.researchgate.net/profile/Robert_Kinicki/publication/228871355_Performance_Enhancement_of_TFRC_in_Wireless_Networks/links/0a85e53c3c30fa167a000000/Performance-Enhancement-of-TFRC-in-Wireless-Networks.pdf>

mjm

> On Nov 20, 2017, at 8:55 PM, Emmanuel Lochin <[email-masked]> wrote:
> 
> Dear Marie-Jo,
> Answers inline
> 
> Ok for me, but at this time where we still collect information, I think we could start to write a full document first and slice it later as you wish ?
> 
>>> 
> TFRC is both a full protocol and CCID #3 in DCCP. I'm wondering whether somebody used to implement it inside DCCP and manage to deal with all CCIDs (in particular CCID #2). 
> 
> What is W-TFRC ? Didn't find anything when googling... does "W" stands for Wireless ? Any pointer welcome.
> 
> As far as I understand, the objective of this draft is to list existing solutions, so I think both drafts are different.
> 
> Emmanuel
> -- 
> Emmanuel LOCHIN
> Professeur ISAE
>

---

From: Emmanuel Lochin <[email-masked]>
Date: Mon, 20 Nov 2017 11:54:06 +0100

Hi MJ

AFAIK, this solution is not implemented and is only available within 
ns-2 (and BTW, with a TFRC ns-2 version not compliant with the last 
RFC). Furthermore, there are plenty of solutions combining erasure 
coding and TFRC (I found a dozen of FEC/TFRC papers). So, do we have to 
look at all simulated solutions or we restrict to real existing 
solutions in this draft?

I'm open, we could also have a section that list real implementations, 
draft standard from simulated ones...

EL

On 20/11/2017 11:12, Marie-Jose Montpetit wrote:
> https://www.researchgate.net/profile/Robert_Kinicki/publication/228871355_Performance_Enhancement_of_TFRC_in_Wireless_Networks/links/0a85e53c3c30fa167a000000/Performance-Enhancement-of-TFRC-in-Wireless-Networks.pdf
>
> mjm
>
>> On Nov 20, 2017, at 8:55 PM, Emmanuel Lochin 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dear Marie-Jo,
>>
>> Answers inline
>>
>> Ok for me, but at this time where we still collect information, I 
>> think we could start to write a full document first and slice it 
>> later as you wish ?
>>
>>>>
>> TFRC is both a full protocol and CCID #3 in DCCP. I'm wondering 
>> whether somebody used to implement it inside DCCP and manage to deal 
>> with all CCIDs (in particular CCID #2).
>>
>> What is W-TFRC ? Didn't find anything when googling... does "W" 
>> stands for Wireless ? Any pointer welcome.
>>
>> As far as I understand, the objective of this draft is to list 
>> existing solutions, so I think both drafts are different.
>>
>> Emmanuel
>> -- 
>> Emmanuel LOCHIN
>> Professeur ISAE
>>
>> 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http://www.isae-supaero.fr
>> [email-masked] <mailto:[email-masked]>

-- 
Emmanuel LOCHIN
Professeur ISAE

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 20 Nov 2017 22:02:23 +1100

Let’s look at real implementations.

mjm
> On Nov 20, 2017, at 9:54 PM, Emmanuel Lochin <[email-masked]> wrote:
> 
> Hi MJ
> 
> AFAIK, this solution is not implemented and is only available within ns-2 (and BTW, with a TFRC ns-2 version not compliant with the last RFC). Furthermore, there are plenty of solutions combining erasure coding and TFRC (I found a dozen of FEC/TFRC papers). So, do we have to look at all simulated solutions or we restrict to real existing solutions in this draft? 
> I'm open, we could also have a section that list real implementations, draft standard from simulated ones...
> EL
> 
>>> On Nov 20, 2017, at 8:55 PM, Emmanuel Lochin <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Dear Marie-Jo,
>>> Answers inline
>>> 
>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>> 
>> 
>> 
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
> 
> -- 
> Emmanuel LOCHIN
> Professeur ISAE
>