<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Thanks for taking this up. Since the document is in last call in the ICNRG, these comments ought to make it to the whole group (I don’t think it’s my place to forward, so Susmit or others can decide how to handle this).</p>
<p dir="auto">As a reminder, Last Call is our formal review process, so the timing is excellent, as these will help us decide whether it’s appropriate to move IPOC forward, or recommend it be recycled for more work.</p>
<p dir="auto">For me personally, these points recapitulate the intense conversations Ilya Moiseenko and I had when working on our paper a few years ago. Many of these issues are what led us to tackle TCP as the Internet protocol to tunnel over ICN rather than raw IP. I still think that was the right choice (of course today we probably would have QuIC rather than TCP, but that’s another possibly relevant discussion).</p>
<p dir="auto">In general, I think it’s way better to converge a layer 4 protocol on top of a different layer 3 protocol than to attempt recursive tunneling L3 over L3. For people interested, I think the paper is still fairly relevant: <a href="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf" style="color:#3983C4">http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf</a></p>
<p dir="auto">Cheers, DaveO.</p>
<br><p dir="auto">On 14 Jul 2020, at 20:21, Lixia Zhang wrote:</p>
</div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="E2F49856-0A89-4F14-8F12-23A1436BEA19"><div 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></div></div></blockquote>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">_______________________________________________<br>
Nfd-dev mailing list<br>
Nfd-dev@lists.cs.ucla.edu<br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" style="color:#777">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a></p>
</blockquote><p dir="auto">DaveO</p>
</div>
</div>
</body>
</html>