<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Susmit,<div class=""><br class="">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 class="">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 class="">(students and I went thru all email about IPOC this time because it’s just a one-time obligation)<br class=""><br class="">Wonder if you could help pass the following to your coauthors:<br class=""><br class="">1/ I strongly suggest to avoid abusing interest packets to carry actual payload, IP packets in your design.</div><div class=""><br class="">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 class="">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 class=""><br class="">b) signed interest is meant to authenticate interest that causes state changes, not for payload authentication.<br class=""><br class="">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 class=""><br class="">You may ask: how to “push” a received IP packet -- may try a combination of a few ways:<br class=""><ul class=""><li class="">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 class="">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 class=""><li class="">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 class="">- interest packets are small in size;</div><div class="">- 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 class=""><br class="">Doing things in the right way would have a better potential to attract others to your work, I believe.</div><div class=""><br class=""></div><div class="">Just my 2 cents,</div><div class="">Lixia</div></body></html>