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

[Junxiao Shi]

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> 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,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20180416/37bd94dd/attachment.html>