Re: [icnrg] [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC

[Junxiao Shi <[e-mail]>]

Dear folks

I wouldn't get into the "payload in Interest" debate, but I'd say something
about forwarder memory consumption: two of three NDN forwarder
implementations consume the same amount of memory regardless of
AppParameters (payload) field.

*NDN-DPDK: buffering a small Interest or a large Interest (that is
unfragmented) consumes the same amount of memory.*
Incoming packets are received into buffer objects allocated from a memory
pool, and every buffer object has the same size.
The Ethernet adapter cannot distinguish packet length and select different
memory pools. A packet length matcher simply does not exist in DPDK. If any
Ethernet adapter has such a feature, it would be in DPDK already.
https://doc.dpdk.org/api/rte__flow_8h.html
Therefore, the buffer object size must fit the MTU configured for the
Ethernet adapter, which is the maximum Data packet length.
Any Interest or Data, small or large, consumes one buffer object, for the
duration of the PIT entry or CS entry.


*NDN-Lite: buffering an Interest with or without payload consumes the same
amount of memory.*
The PIT only stores the Interest name. The AppParameters field is not
buffered in the PIT entry.
https://github.com/named-data-iot/ndn-lite/blob/1b4f46bb3470ae0b31e768d105b34e9b7eeb33c1/forwarder/forwarder.c#L377


*NFD: memory consumption changes, at the cost of copying every packet.*
In Ethernet and UDP faces, packet buffers are truncated into packet length,
by copying every packet after it's been received. The copying occurs in
Block::fromBuffer function.
https://github.com/named-data/NFD/blob/d82134b850d1d5c474044c050857614682b5c4fd/daemon/face/datagram-transport.hpp#L183
I don't see this as a good practice performance-wise.

Yours, Junxiao

On Tue, Jul 14, 2020 at 8:22 PM Lixia Zhang <[e-mail]> wrote:

> *External Email*
> Hi Susmit,
>
> thanks a lot for helping out with the specifics regarding the
> motivations and designs behind IPOC internet-draft that we discussed last
> Friday.
> To answer the question you asked at the end about which way I’d like to
> get my comments back to all the authors: my worry about going to ICNRG is
> that I might not be able to keep up with discussions there:(
> (students and I went thru all email about IPOC this time because it’s just
> a one-time obligation)
>
> Wonder if you could help pass the following to your coauthors:
>
> 1/ I strongly suggest to avoid abusing interest packets to carry actual
> payload, IP packets in your design.
>
> a) an interest is meant to retrieve a data packet, that’s why it hangs on
> PIT at every hop until the data packet comes back (or otherwise timeout).
> Buffering lots IP packet in the PIT is *bad*, as it takes space
> and totally useless.  Data packet in CS can be useful even for
> one-one communication: in case the packet lost, retransmitted interest
> will get it from the CS just before the loss point.
>
> b) signed interest is meant to authenticate interest that causes state
> changes, not for payload authentication.
>
> 2/ if one must use NDN to carry IP packets, let’s treat each IP packet as
> a data packet in both directions, instead of just one direction.
>
> You may ask: how to “push” a received IP packet -- may try a combination
> of a few ways:
>
>    - each end could try to fetch *opportunistically*; this could
>    be pretty effective if one can make use of recognized patterns in IP packet
>    arrivals, and the opportunistic fetching interest have a not-too-short
>    lifetime.
>    - in case needed, send a probe interest to trigger the other end
>    sending an interest; this probe interest could have a very short lifetime
>    as it’s not meant to wait for data. This is still a lot better
>    than buffering IP packets in PIT.
>       - Yes there could be a bit delay but look, even in your current
>       design, the IPOC gateway has to wait for Interest form IPOC client already.
>
> The main drawback is doubling packet count, but perhaps not much
> increase on router memory consumption since
> - interest packets are small in size;
> - using real data packets to carry IP packets is probably more economical
> in byte count as compared to abusing interests to carry IP packets.
>
> Doing things in the right way would have a better potential to
> attract others to your work, I believe.
>
> Just my 2 cents,
> Lixia
>
>