[Nfd-dev] NDN Congestion Control Design

[Gusev, Peter]

Hi Klaus & all,

I’d like to check-in with you regarding your plans for congestion control implementation and whether you need any support from NDN-RTC/ndncon dev team.
From the last e-mails I gathered that few things need to be fixed in NDN-RTC:

> 1. Fix the RTT averaging. Instead of calculating the average over the whole run use either an exponential moving average or a simple moving average (e.g. over the last 10 seconds).
> 2. Manipulate lambda_max (it looks like it is too low in some cases) or completely avoid it and set lambda_d directly based on an AIMD mechanism based on packet losses. Also take the buffer size into account. (This requires some more design decisions)
> 3. Remove the retransmission suppression of the Access Strategy or set it to a value that is low enough for NDN-RTC to work correctly.

Once these fixed, will an Ubuntu image with headless NDN-RTC app be useful for you to proceed with your implementation/testing?

We plan on having large-scale tests using NDN-RTC somewhere mid-June. Apart from testing existing functionality scaled, it would be useful to also test any congestion control schemes (app- or network-level) at this time in preparation for large-scale demo later this fall.

Please, let me know what do you think.

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 9, 2016, at 5:36 PM, Klaus Schneider <klaus at cs.arizona.edu<mailto:klaus at cs.arizona.edu>> wrote:

Hi,

here is a major change to the design from the previous document.

The problem is the following: In the document I described to use the "time that the sojourn time remained above the target value" (further called "queuing time") as measure of the queue size.

Currently, I only use a binary notion of congestion (marked/not marked). I tried to use the quantitative congestion notion ("queuing time") to influence either the reaction at the consumer or the adjustment of the forwarding ratio, but could never achieve a notable performance benefit.

I just figured out the problem. Look at figures "Congestion Window" and "Congestion Marks" on slide 5 and "producer1, 0" on the last slide of the pdf.

The "queuing time" is actually negatively related with the mismatch of the congestion window and the current queue size at the router.

- the queuing time is highest around the time the congestion window has reached the optimal size
- it is highest right before the queuing delay at the router falls below the target value (5 ms).


A better metric of the amount of congestion would be "the minimum queuing delay over the last interval (100 ms)". However, I think there is a good reason why CoDel doesn't use it: It is much more complex in terms of CPU usage.

Basically, it would require to calculate a minimum over all packets in the last 100ms for *every incoming packet*. The current design only needs 1 comparison (check if queuing delay > target) instead of this minimum calculation.

Does anyone know how to do this efficiently?


If there isn't an efficient algorithm for that, I think we should stick to a stream of binary congestion marks. These also have the benefit of lower design complexity and traffic overhead.

Best regards,
Klaus


P.S. I would appreciate if you wouldn't post any of the discussion or design documents to redmine quite yet. I'll post it there myself (once it's ready) in a format which is more appropriate for a broader audience. That is, together with some explanations and measurement results.




On 03/05/2016 01:30 PM, Klaus Schneider wrote:
Hi, sorry for the delay.

the short-term design should be like the one I sent around, but without
the forwarding strategy part. Plus we need a different reaction at the
consumer. I'll have the design ready at the retreat.

We can also look into some other aspects of NDN-RTC that impact
performance and try evaluating them in mini-NDN.

@Peter: Do you have any suggestions for the hackathon project?


Regarding the original topic: Does anyone have feedback on my design
document?

Best regards,
Klaus
<draft_own_cong_marks.pdf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160429/b1d525cd/attachment.html>