<div dir="ltr"><div><div><div><div>Hi,<br><br></div>I kept checking on the example and find out that the problem of speed is due to an optimization that happens in the ESXi host. The ESXi converts all the traffic into local traffic and everything becomes just copies of memory. that explains one of the problems I had.<br><br></div>I went a bit further also with the analysis of the NDN traffic and I figure out that there are two congestion protocols: TCP + the Arizona Univ's provided cogestion protocol. I understand that it has been developed because TCP was not optimized for ICN. But is this protocol as necessary that is included by default for all the ICN users?<br><br></div>Shouldn't we create a patch and enable at compilation time it only in case of need?<br><br></div>Cheers,<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-17 6:14 GMT+02:00 Klaus Schneider <span dir="ltr"><<a href="mailto:klaus@cs.arizona.edu" target="_blank">klaus@cs.arizona.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 16/04/18 03:49, César A. Bernardini wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Junxiao,<br>
<br>
Thanks for your comments,<br>
<br>
Maybe it's not fair to compare today. But we definitively should! If we want that ICN/NDN sees the light, we need to be able to find bottlenecks and transmit large file sizes :)<br>
</blockquote>
<br></span>
Well your test used a very small file size (1 MB).<br>
<br>
Is there still a 400% performance gap if you transfer larger files (let's say 1GB) ?<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Are you familiar with some of these bottlenecks?<br>
</blockquote>
<br></span>
One known bottleneck is that the maximum throughput of NDN is limited and depends on the chunk size, RTT, CPU performance, and other things:<br>
<br>
- <a href="https://redmine.named-data.net/issues/4486" rel="noreferrer" target="_blank">https://redmine.named-data.net<wbr>/issues/4486</a><br>
- <a href="https://redmine.named-data.net/issues/4408" rel="noreferrer" target="_blank">https://redmine.named-data.net<wbr>/issues/4408</a><br>
<br>
<br>
Best regards,<br>
Klaus<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
2018-04-16 12:13 GMT+02:00 Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a> <mailto:<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizo<wbr>na.edu</a>>>:<span class=""><br>
<br>
Hi César<br>
<br>
Don’t be surprised when you see NDN implementation is slower than IP<br>
implementation.<br>
NGINX and other major HTTPS servers have been optimized by many big<br>
companies for many years. IP routers are also optimized with “line<br>
speed forwarding” as a requirement.<br>
ndnpoke and ndnputchunks and their corresponding consumer programs<br>
are written by about three grad students. NFD is explicitly “not<br>
optimized for performance” as claimed in NFD Developer Guide<br>
introduction section.<br>
Try to hand write a HTTPS server (without using any TLS libraries)<br>
and a software IP router (forward packets between libpcap handles),<br>
and you’ll see how slow they would be.<br>
<br>
Yours, Junxiao<br>
<br>
On Mon, Apr 16, 2018 at 05:56 César A. Bernardini <<a href="mailto:mesarpe@gmail.com" target="_blank">mesarpe@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:mesarpe@gmail.com" target="_blank">mesarpe@gmail.com</a>>> wrote:<br>
<br>
Hi,<br>
<br>
I executed the following experiment: three virtual computers<br>
connected in a speed line using NDN. I tried to send a file of 1MB.<br>
<br></span>
Using HTTPS, It took me *~0.020/0.30* seconds to retrieve the file<br>
<br>
Using ndnputchunks/ndncatchunks:<br>
with ndnputchunks, it takes always *0.170* to transmit one<span class=""><br>
single file. I tried with the FIXED strategy and the iterative<br>
strategy.<br>
<br>
Somebody else faced the same issue? I have already seen an<br>
e-mail of one year ago but there was no interesting information.<br>
<br>
We are talking about a content delivery architecture that is<br>
400% slower than HTTPS when sending unencrypted traffic.<br>
<br>
Somebody tried using stream connections? at NDN core?<br>
<br>
With ndnpoke, sometimes It takes (to send one chunk) ~0.020<br>
seconds and other times it takes 4.020 seconds. I tried in two<br>
different hosts: ESXi and with virtual boxes. With virtualboxes,<br>
ndnpoke transmits the whole message. With ESXi it complains that<br>
I exceed the 8800 bytes.<br>
<br>
Cheers,<br>
<br>
<br>
<br>
<br></span>
______________________________<wbr>_________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a><br>
<br>
</blockquote>
</blockquote></div><br></div>