<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Klaus & all,
<div class=""><br class="">
</div>
<div class="">I’d like to check-in with you regarding your plans for congestion control implementation and whether you need any support from NDN-RTC/<i class="">ndncon
</i>dev team.</div>
<div class="">From the last e-mails I gathered that few things need to be fixed in NDN-RTC:</div>
<div class=""><br class="">
</div>
<div class="">> 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).<br class="">
> 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)<br class="">
> 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.</div>
<div class=""><br class="">
</div>
<div class="">Once these fixed, will an Ubuntu image with headless NDN-RTC app be useful for you to proceed with your implementation/testing?</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Please, let me know what do you think.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">Thanks, <br class="">
<br class="">
-- <br class="">
Peter Gusev<br class="">
<br class="">
<a href="mailto:peter@remap.ucla.edu" class="">peter@remap.ucla.edu</a><br class="">
+1 213 5872748<br class="">
peetonn_ (skype)<br class="">
<br class="">
Software Engineer/Programmer Analyst @ REMAP UCLA<br class="">
<br class="">
Video streaming/ICN networks/Creative Development<br class="">
</div>
<br class="">
<blockquote type="cite" class="">On Mar 9, 2016, at 5:36 PM, Klaus Schneider <<a href="mailto:klaus@cs.arizona.edu" class="">klaus@cs.arizona.edu</a>> wrote:<br class="">
<br class="">
Hi,<br class="">
<br class="">
here is a major change to the design from the previous document.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
The "queuing time" is actually negatively related with the mismatch of the congestion window and the current queue size at the router.<br class="">
<br class="">
- the queuing time is highest around the time the congestion window has reached the optimal size<br class="">
- it is highest right before the queuing delay at the router falls below the target value (5 ms).<br class="">
<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
Does anyone know how to do this efficiently?<br class="">
<br class="">
<br class="">
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.<br class="">
<br class="">
Best regards,<br class="">
Klaus<br class="">
<br class="">
<br class="">
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.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
On 03/05/2016 01:30 PM, Klaus Schneider wrote:<br class="">
<blockquote type="cite" class="">Hi, sorry for the delay.<br class="">
<br class="">
the short-term design should be like the one I sent around, but without<br class="">
the forwarding strategy part. Plus we need a different reaction at the<br class="">
consumer. I'll have the design ready at the retreat.<br class="">
<br class="">
We can also look into some other aspects of NDN-RTC that impact<br class="">
performance and try evaluating them in mini-NDN.<br class="">
<br class="">
@Peter: Do you have any suggestions for the hackathon project?<br class="">
<br class="">
<br class="">
Regarding the original topic: Does anyone have feedback on my design<br class="">
document?<br class="">
<br class="">
Best regards,<br class="">
Klaus<br class="">
</blockquote>
<span id="cid:29A9AEF0-F9C2-475A-B259-D68E92026842"><draft_own_cong_marks.pdf></span><br class="">
</blockquote>
<br class="">
</div>
</body>
</html>