[Ndn-interest] Sending files with NDN (putchunks/ndnpoke)

[César A. Bernardini]

Hi,

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.

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?

Shouldn't we create a patch and enable at compilation time it only in case
of need?

Cheers,

2018-04-17 6:14 GMT+02:00 Klaus Schneider <klaus at cs.arizona.edu>:

>
>
> On 16/04/18 03:49, César A. Bernardini wrote:
>
>> Hi Junxiao,
>>
>> Thanks for your comments,
>>
>> 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 :)
>>
>
> Well your test used a very small file size (1 MB).
>
> Is there still a 400% performance gap if you transfer larger files (let's
> say 1GB) ?
>
>
>
>> Are you familiar with some of these bottlenecks?
>>
>
> One known bottleneck is that the maximum throughput of NDN is limited and
> depends on the chunk size, RTT, CPU performance, and other things:
>
> - https://redmine.named-data.net/issues/4486
> - https://redmine.named-data.net/issues/4408
>
>
> Best regards,
> Klaus
>
>
>> Cheers,
>>
>> 2018-04-16 12:13 GMT+02:00 Junxiao Shi <shijunxiao at email.arizona.edu
>> <mailto:shijunxiao at email.arizona.edu>>:
>>
>>     Hi César
>>
>>     Don’t be surprised when you see NDN implementation is slower than IP
>>     implementation.
>>     NGINX and other major HTTPS servers have been optimized by many big
>>     companies for many years. IP routers are also optimized with “line
>>     speed forwarding” as a requirement.
>>     ndnpoke and ndnputchunks and their corresponding consumer programs
>>     are written by about three grad students. NFD is explicitly “not
>>     optimized for performance” as claimed in NFD Developer Guide
>>     introduction section.
>>     Try to hand write a HTTPS server (without using any TLS libraries)
>>     and a software IP router (forward packets between libpcap handles),
>>     and you’ll see how slow they would be.
>>
>>     Yours, Junxiao
>>
>>     On Mon, Apr 16, 2018 at 05:56 César A. Bernardini <mesarpe at gmail.com
>>     <mailto:mesarpe at gmail.com>> wrote:
>>
>>         Hi,
>>
>>         I executed the following experiment: three virtual computers
>>         connected in a speed line using NDN. I tried to send a file of
>> 1MB.
>>
>>         Using HTTPS, It took me *~0.020/0.30* seconds to retrieve the file
>>
>>         Using ndnputchunks/ndncatchunks:
>>         with ndnputchunks, it takes always *0.170* to transmit one
>>         single file. I tried with the FIXED strategy and the iterative
>>         strategy.
>>
>>         Somebody else faced the same issue? I have already seen an
>>         e-mail of one year ago but there was no interesting information.
>>
>>         We are talking about a content delivery architecture that is
>>         400% slower than HTTPS when sending unencrypted traffic.
>>
>>         Somebody tried using stream connections? at NDN core?
>>
>>         With ndnpoke, sometimes It takes (to send one chunk) ~0.020
>>         seconds and other times it takes 4.020 seconds. I tried in two
>>         different hosts: ESXi and with virtual boxes. With virtualboxes,
>>         ndnpoke transmits the whole message. With ESXi it complains that
>>         I exceed the 8800 bytes.
>>
>>         Cheers,
>>
>>
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20180423/34c5e772/attachment.html>