<div dir="ltr"><div>Dear folks</div><div><br></div><div>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.<br></div><div><br></div><div><b>NDN-DPDK: buffering a small Interest or a large Interest (that is unfragmented) consumes the same amount of memory.</b></div><div>Incoming packets are received into buffer objects allocated from a memory pool, and every buffer object has the same size.</div><div>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. <a href="https://doc.dpdk.org/api/rte__flow_8h.html">https://doc.dpdk.org/api/rte__flow_8h.html</a></div><div>Therefore, the buffer object size must fit the MTU configured for the Ethernet adapter, which is the maximum Data packet length.<br></div><div>Any Interest or Data, small or large, consumes one buffer object, for the duration of the PIT entry or CS entry.<br></div><div>
<div><br></div><div><b>NDN-Lite: buffering an Interest with or without payload consumes the same amount of memory.<br></b></div><div>The PIT only stores the Interest name. The AppParameters field is not buffered in the PIT entry.</div><div><a href="https://github.com/named-data-iot/ndn-lite/blob/1b4f46bb3470ae0b31e768d105b34e9b7eeb33c1/forwarder/forwarder.c#L377">https://github.com/named-data-iot/ndn-lite/blob/1b4f46bb3470ae0b31e768d105b34e9b7eeb33c1/forwarder/forwarder.c#L377</a></div></div><div><br></div><div><b>NFD: memory consumption changes, at the cost of copying every packet.<br></b></div><div>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.</div><div><a href="https://github.com/named-data/NFD/blob/d82134b850d1d5c474044c050857614682b5c4fd/daemon/face/datagram-transport.hpp#L183">https://github.com/named-data/NFD/blob/d82134b850d1d5c474044c050857614682b5c4fd/daemon/face/datagram-transport.hpp#L183</a></div><div>I don't see this as a good practice performance-wise.<br></div><div><br></div><div>Yours, Junxiao<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2020 at 8:22 PM Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><p style="text-align:center"><font color="red"><b>External Email</b><br></font></p>Hi Susmit,<div><br>thanks a lot for helping out with the specifics regarding the motivations and designs behind IPOC internet-draft that we discussed last Friday.</div><div>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:(</div><div>(students and I went thru all email about IPOC this time because it’s just a one-time obligation)<br><br>Wonder if you could help pass the following to your coauthors:<br><br>1/ I strongly suggest to avoid abusing interest packets to carry actual payload, IP packets in your design.</div><div><br>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).<br>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.<br><br>b) signed interest is meant to authenticate interest that causes state changes, not for payload authentication.<br><br>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.<br><br>You may ask: how to “push” a received IP packet -- may try a combination of a few ways:<br><ul><li>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.</li><li>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.</li><ul><li>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.</li></ul></ul>The main drawback is doubling packet count, but perhaps not much increase on router memory consumption since</div><div>- interest packets are small in size;</div><div>- using real data packets to carry IP packets is probably more economical in byte count as compared to abusing interests to carry IP packets.<br><br>Doing things in the right way would have a better potential to attract others to your work, I believe.</div><div><br></div><div>Just my 2 cents,</div><div>Lixia</div></div><br>
</blockquote></div></div>