<div dir="ltr"><div dir="ltr"><div>Hi,</div>I read one paper titled "TCP/ICN: Carrying TCP over Content Centric
and Named Data Networks" quite a while ago. This paper made the same argument as Lixia, with some data to back it up.</div><div>Best Regards</div><div>Rafee</div></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;">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>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Best Regards</div><div>Rafee</div><div><a href="http://www.mohammadrafee.com" target="_blank">www.mohammadrafee.com</a><br></div></div></div></div></div>