<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="">Top posting: after catching up with this whole thread (I believe the msg below from Luca is the last one), I found myself mostly share Luca's view expressed in his msg.<div class="">Let me summarize up in a short bullet list:<div class=""><br class=""></div><div class="">1/ CCNx or NDN, it's all under the same ICN umbrella. So to me, whether allowing an Interest to carry payload is not a simple format question, but an architectural one (and Luca is right, that is why NDN does not support it).</div><div class=""><br class=""></div><div class="">2/ NDN said from day-1 that it could deliver IP packets, as data. </div><div class="">When delivering IP packets as data, the major ICN architectural features can be utilized (perhaps except in-network caching, as IP is datagram between connected parties):</div><div class=""><br class=""></div><div class="">i) effective congestion control by regulating Interest forwarding rates hop-by-hop;</div><div class=""><br class=""></div><div class="">ii) built-in support for (IP) multicast delivery;</div><div class=""><br class=""></div><div class="">iii) adaptive forwarding among multiple paths.</div><div class=""><br class=""></div><div class="">3/ When carrying IP packets in interests in one direction, one thinks one can still get (iii) due to 2-way exchange (but see 4/ below).</div><div class="">However,</div><div class=""><br class=""></div><div class="">i) is lost, as the interest rate *has* to keep up with IP traffic volume in the direction from "interest sending" node to "data sending" node;</div><div class=""><br class=""></div><div class="">ii) is lost, as multicast data delivery starts with data receiving ends sending Interest packets. </div><div class=""><br class=""></div><div class="">4/ In addition to losing congestion control ability, when traffic volumes in the two directions (A to B, B to A) are not exactly symmetric, there could be further complication: what if A-B IP packet count (carried by Interests) is higher than that of B-A IP packets carried by data? </div><div class=""><ul class="MailOutline"><li class="">Not returning a data packet for every Interest? </li></ul></div><div class=""><br class=""></div><div class="">if so: not only that'd waste lots hanging PIT entries in the network, but wouldn't that also cause confusions at A? As A could not tell whether it's due to B not having enough IP packets to send, as opposed to its interests get lost due to path broken or just congestion, and may no longer be able to do adaptive forwarding?</div><div class=""><br class=""></div><div class="">Or B must send fake data packets to match up A's interests?</div><div class=""><br class=""></div><div class="">(similarly, if B-A IP packet count is higher, special means would be needed to probe A to send the right amount of interests; and if we think "what if": what if there is congestion in A-B direction but not in B-A direction?)</div><div class=""><br class=""></div><div class="">5/ I recall seeing an earlier msg from Greg explaining that IPoC is intended as a transition technology: it seems that the identified issues of</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">3/ i) + ii), and 4/ (i.e. losing (iii) in 3/)</div></blockquote><div class="">would directly impact this transition deployment, right?</div><div class=""><br class=""></div><div class="">*If* so (let me know if anyone sees bugs in above), I'd repeat my suggestion in the msg to nfd-dev (which triggered this thread): if one sees a gain from carry IP packets in ICN, let’s do the right thing of treating every IP packet as a ICN data packet.</div><div class=""><br class=""></div><div class="">Lixia</div><div class=""><br class=""></div><div class="">PS: my msg to nfd-dev wrongly cited potential resource saving for doing the right thing, hope this msg corrected it by looking from architectural impact.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 23, 2020, at 5:54 AM, Luca Muscariello <<a href="mailto:muscariello@ieee.org" class="">muscariello@ieee.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_default"><div class="gmail_default"><span style="font-family:monospace" class="">I think the major issue is the change of protocol semantics caused by </span><span style="font-family:monospace" class="">IPoC.</span></div><div class="gmail_default"><span style="font-family:monospace" class="">Marc Mosko (et al. I guess) has done really good work to make interest</span></div><div class="gmail_default"><font face="monospace" class="">payload possible (within boundaries) which has never had shared consensus though.</font></div><div class="gmail_default"><font face="monospace" class="">This is why it is not in NDN.</font></div><div class="gmail_default"><font face="monospace" class=""><br class=""></font></div><div class="gmail_default"><font face="monospace" class="">RFC</font><span style="font-family:monospace" class="">8569 </span><span style="font-family:monospace" class="">should be carefully read, including security considerations. I personally</span></div><div class="gmail_default"><font face="monospace" class="">do not want to use interest payload unless there is *a-very-good-reason*. </font></div><div class="gmail_default"><font face="monospace" class="">I would </font><span style="font-family:monospace" class="">use it for datagram/stateless messaging only, or like NDN. </span></div><div class="gmail_default"><span style="font-family:monospace" class=""><br class=""></span></div><div class="gmail_default"><span style="font-family:monospace" class="">The approach that I prefer </span><span style="font-family:monospace" class="">from a theoretical and practical point of view</span></div><div class="gmail_default"><span style="font-family:monospace" class="">to enable non-icn-aware-apps, </span><span style="font-family:monospace" class="">is L4 proxyfication.</span></div><div class="gmail_default"><font face="monospace" class="">Dave Oran's (best)paper at icn2016 should be read. </font></div><div class="gmail_default"><font face="monospace" class="">L4 proxy, IMO, maintains many of the incentives to deploy, which I mentioned in my previous emails on this topic.</font></div><div class="gmail_default"><font face="monospace" class=""><br class=""></font></div><div class="gmail_default"><font face="monospace" class=""><a href="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf" class="">http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf</a></font></div><div class="gmail_default"><font face="monospace" class=""><br class=""></font></div><div class="gmail_default"><font face="monospace" class="">It works for NDN, CCNx and also hICN and doesn't push data in interests.</font></div><div class="gmail_default"><font face="monospace" class="">Many good properties provided by ICN are maintained.</font></div><div class="gmail_default"><font face="monospace" class="">Of course, namespace optimization goes away but this is where ICN must go native in the app.</font></div></div><div class="gmail_default" style="font-family:monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace">IMO, the way IPoC makes use of Interest payload is like walking the tightrope.</div><div class="gmail_default" style="font-family:monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace">Luca</div></div></div></div></div></div></blockquote></div><br class=""></div></div></body></html>