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

Klaus Schneider klaus at cs.arizona.edu
Mon Apr 16 21:14:05 PDT 2018



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
> 


More information about the Ndn-interest mailing list