[Nfd-dev] practical congestion-control for app developers

[Klaus Schneider]

Hey Peter, sorry for the late reply.

> 
> I asked this in NFD call several months ago. The answer was: react to congestion mark with AIMD algorithm.

I think more accurate is "react to a congestion mark similar as to a 
packet timeout". It doesn't have to be AIMD.

A good reference is RFC 3168 https://tools.ietf.org/html/rfc3168#section-5.1

"We emphasize that a *single* packet with the CE codepoint set in an IP 
packet causes the transport layer to respond, in terms of congestion 
control, as it would to a packet drop."

> Klaus mentioned that a
>> CUBIC-like algorithm performed much better in his tests. So, I would
>> not point to the current implementation in ndn-cxx as the "recommended
>> algorithm".

Indeed we do have the CUBIC implementation now in ndnSIM: 
https://gerrit.named-data.net/#/c/ndnSIM/+/4859/

It's not in ndncatchunks yet though.

> 
> Now, from an app-developer-who-cares-about-congestion-control point of view, I’m wondering: an application (consumer) needs to react to congestion marks received with data packets — "how exactly?" and which "inspiration examples" shall I follow in order to implement such a mechanism in my app?
> 

Well that depends on the application. If the application is anything 
like a reliable TCP file transfer, you can look at 
https://github.com/named-data-ndnSIM/ndnSIM/blob/master/apps/ndn-consumer-pcon.cpp

If the AIMD version is enough, you can also use the SegmentFetcher that 
Junxiao mentioned: 
https://github.com/named-data/ndn-cxx/blob/502b47956c067683f9fd75c3a0d3040c8d14e452/src/util/segment-fetcher.cpp

> Or is there a library/shim code that abstracts this logic from the end developer that can be utilized?

This should be the SegmentFetcher. See 
https://redmine.named-data.net/issues/4364


However, if the application does not need reliable transport (you're 
probably talking about NDN-RTC), then the task becomes harder.

You probably want something closer to DCCP 
(https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol) or 
QUIC (https://en.wikipedia.org/wiki/QUIC). Both provide congestion 
control for unreliable transport (more like UDP + congestion control).

Maybe you can give us some ideas about how your current congestion 
control works (not sure if it changed since our last discussion), then 
we can discuss ways to incorporate the congestion marks.

Best regards,
Klaus



On 31/08/18 09:58, Davide Pesavento wrote:
> On Wed, Aug 29, 2018 at 9:43 PM Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>>
>>> In the paper (PCON by Klaus) I see there are parallels with TCP congestion window algorithms, is this the way to go for a general-purpose developer?
>>> How this was implemented in ndncatchunks?
>>> Or is there a library/shim code that abstracts this logic from the end developer that can be utilized?
>>
>>
>> ndn-cxx has SegmentFetcher that implements the recommended algorithm
> 
> Recommended by who? IIRC this topic was briefly discussed again not
> log ago in a platform call, and both Lixia and Klaus were not happy
> with the current behavior of our AIMD implementation (halving the
> window being too aggressive and so on). Klaus mentioned that a
> CUBIC-like algorithm performed much better in his tests. So, I would
> not point to the current implementation in ndn-cxx as the "recommended
> algorithm".
> 
> Thanks,
> Davide
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>