[Nfd-dev] [icnrg] [EXT] about draft-irtf-icnrg-IPOC

[Lixia Zhang]

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.
Let me summarize up in a short bullet list:

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).

2/ NDN said from day-1 that it could deliver IP packets, as data. 
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):

i) effective congestion control by regulating Interest forwarding rates hop-by-hop;

ii) built-in support for (IP) multicast delivery;

iii) adaptive forwarding among multiple paths.

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).
However,

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;

ii) is lost, as multicast data delivery starts with data receiving ends sending Interest packets. 

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? 
Not returning a data packet for every Interest? 

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?

Or B must send fake data packets to match up A's interests?

(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?)

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
3/ i) + ii), and 4/ (i.e. losing (iii) in 3/)
would directly impact this transition deployment, right?

*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.

Lixia

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.


> On Jul 23, 2020, at 5:54 AM, Luca Muscariello <muscariello at ieee.org> wrote:
> 
> I think the major issue is the change of protocol semantics caused by IPoC.
> Marc Mosko (et al. I guess) has done really good work to make interest
> payload possible (within boundaries) which has never had shared consensus though.
> This is why it is not in NDN.
> 
> RFC8569 should be carefully read, including security considerations.  I personally
> do not want to use interest payload unless there is *a-very-good-reason*. 
> I would use it for datagram/stateless messaging only, or like NDN. 
> 
> The approach that I prefer from a theoretical and practical point of view
> to enable non-icn-aware-apps, is L4 proxyfication.
> Dave Oran's (best)paper at icn2016 should be read. 
> L4 proxy, IMO, maintains many of the incentives to deploy, which I mentioned in my previous emails on this topic.
> 
> http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf>
> 
> It works for NDN, CCNx and also hICN and doesn't push data in interests.
> Many good properties provided by ICN are maintained.
> Of course, namespace optimization goes away but this is where ICN must go native in the app.
> 
> IMO, the way IPoC makes use of Interest payload is like walking the tightrope.
> 
> Luca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200726/b2b848a4/attachment.html>