Subject: Re: [icnrg] [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC

From: Junxiao Shi <[email-masked]>
Date: Sun, 19 Jul 2020 11:31:40 -0400

Dear folks

I wouldn't get into the "payload in Interest" debate, but I'd say something
about forwarder memory consumption: two of three NDN forwarder
implementations consume the same amount of memory regardless of
AppParameters (payload) field.

*NDN-DPDK: buffering a small Interest or a large Interest (that is
unfragmented) consumes the same amount of memory.*
Incoming packets are received into buffer objects allocated from a memory
pool, and every buffer object has the same size.
The Ethernet adapter cannot distinguish packet length and select different
memory pools. A packet length matcher simply does not exist in DPDK. If any
Ethernet adapter has such a feature, it would be in DPDK already.
https://doc.dpdk.org/api/rte__flow_8h.html
Therefore, the buffer object size must fit the MTU configured for the
Ethernet adapter, which is the maximum Data packet length.
Any Interest or Data, small or large, consumes one buffer object, for the
duration of the PIT entry or CS entry.

*NDN-Lite: buffering an Interest with or without payload consumes the same
amount of memory.*
The PIT only stores the Interest name. The AppParameters field is not
buffered in the PIT entry.
https://github.com/named-data-iot/ndn-lite/blob/1b4f46bb3470ae0b31e768d105b34e9b7eeb33c1/forwarder/forwarder.c#L377

*NFD: memory consumption changes, at the cost of copying every packet.*
In Ethernet and UDP faces, packet buffers are truncated into packet length,
by copying every packet after it's been received. The copying occurs in
Block::fromBuffer function.
https://github.com/named-data/NFD/blob/d82134b850d1d5c474044c050857614682b5c4fd/daemon/face/datagram-transport.hpp#L183
I don't see this as a good practice performance-wise.

Yours, Junxiao

On Tue, Jul 14, 2020 at 8:22 PM Lixia Zhang <[email-masked]> wrote:

> *External Email*
> Hi Susmit,
>
> thanks a lot for helping out with the specifics regarding the
> motivations and designs behind IPOC internet-draft that we discussed last
> Friday.
> 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:(
> (students and I went thru all email about IPOC this time because it’s just
> a one-time obligation)
>
> Wonder if you could help pass the following to your coauthors:
>
> 1/ I strongly suggest to avoid abusing interest packets to carry actual
> payload, IP packets in your design.
>
> 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).
> 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.
>
> b) signed interest is meant to authenticate interest that causes state
> changes, not for payload authentication.
>
> 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.
>
> You may ask: how to “push” a received IP packet -- may try a combination
> of a few ways:
>
>    - 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.
>    - 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.
>       - 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.
>
> The main drawback is doubling packet count, but perhaps not much
> increase on router memory consumption since
> - interest packets are small in size;
> - using real data packets to carry IP packets is probably more economical
> in byte count as compared to abusing interests to carry IP packets.
>
> Doing things in the right way would have a better potential to
> attract others to your work, I believe.
>
> Just my 2 cents,
> Lixia
>
>

---

From: Junxiao Shi <[email-masked]>
Date: Mon, 20 Jul 2020 23:00:57 -0400

Hi Susmit

> But do we have to buffer the payload in the PIT? I know this is how this
> is done in NFD - but what do we lose if we throw away the payload (or
> application parameters) before populating the intermediate PITs? This might
> require changes in the forwarding pipeline.
>

If the forwarder doesn't store the whole Interest, its strategy cannot
retransmit the Interest except when processing an Interest or a Nack.

Also, a recent protocol clarification forces the forwarder to store the
entire Interest packet if it supports both PIT aggregation and Nack
returning.
https://redmine.named-data.net/issues/4535 note-16 requires the forwarder
to include the original Interest packet in a Nack returned to downstream.
To satisfy this requirement, the forwarder has to separately store the last
Interest from each downstream node. Sending the Nack from upstream to
downstream would not work, because the Interest enclosed in an upstream
Nack reflects the original Interest from at most one downstream node, while
other downstream nodes may have sent a different set of InterestLifetime,
HopLimit, as well as unrecognized non-critical fields.

NDN-Lite could get away with storing only the name and CanBePrefix flag
because it does not support Nack returning. The NDN protocol (
http://hdl.handle.net/10150/625652 chapter 3) defines Nack returning to be
optional, so this is a valid implementation choice, at the expense of
slower link failure recovery.

Yours, Junxiao

---

From: Greg White <[email-masked]>
Date: Wed, 22 Jul 2020 22:57:58 +0000

It sounds like the practical consequences of including the IP packet in an NDN interest may not be that large. But that doing so violates principles of usage considered important by several members of the NDN community.

In my earlier response<https://mailarchive.ietf.org/arch/msg/icnrg/L4ZC_WVH9YOTknRzqxJEJDdSqlo/> to Luca on this subject, I suggested that we add some text in Section 4.1<https://tools.ietf.org/html/draft-irtf-icnrg-ipoc-01#section-4.1> to make it clear that in order for IPoC to work with NDN, some changes to the current NDN forwarder behavior would be needed.  It looks like that won’t be sufficient.

How to move forward?

One option would be to eliminate all mentions of NDN in the IPoC draft.  The protocol (as written) then becomes a CCNx-specific one.

That said, if a future implementor decides to implement IPoC on NDN, and uses the AppParameters field to encapsulate the IP packet, is there a mechanism to prevent them from doing so?  If not, perhaps a better choice would be to include in Section 4.1 a few sentences that discuss the situation with the current NDN protocol definition, and the implications of using AppParameters.

As has been said previously, IPoC is intended as a transition technology, and it could be one of many that eventually get designed to handle various transition scenarios (just like there have been many IPv4-to-IPv6 transition technologies).  So, a future protocol could be designed that presumes both endpoints have routable prefixes and thus utilizes the traditional NDN pull in both directions.  IPoC itself could also be updated in the future to make use of mechanisms like the Reflexive Interest<https://datatracker.ietf.org/doc/draft-oran-icnrg-reflexive-forwarding/?include_text=1> (if that is adopted).

-Greg

From: Junxiao Shi <[email-masked]>
Date: Monday, July 20, 2020 at 9:01 PM
To: "Shannigrahi, Susmit" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>, ICNRG <[email-masked]>, Greg White <[email-masked]>, Lixia Zhang <[email-masked]>
Subject: Re: [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC

Hi Susmit

But do we have to buffer the payload in the PIT? I know this is how this is done in NFD - but what do we lose if we throw away the payload (or application parameters) before populating the intermediate PITs? This might require changes in the forwarding pipeline.

If the forwarder doesn't store the whole Interest, its strategy cannot retransmit the Interest except when processing an Interest or a Nack.

Also, a recent protocol clarification forces the forwarder to store the entire Interest packet if it supports both PIT aggregation and Nack returning.
https://redmine.named-data.net/issues/4535 note-16 requires the forwarder to include the original Interest packet in a Nack returned to downstream. To satisfy this requirement, the forwarder has to separately store the last Interest from each downstream node. Sending the Nack from upstream to downstream would not work, because the Interest enclosed in an upstream Nack reflects the original Interest from at most one downstream node, while other downstream nodes may have sent a different set of InterestLifetime, HopLimit, as well as unrecognized non-critical fields.

NDN-Lite could get away with storing only the name and CanBePrefix flag because it does not support Nack returning. The NDN protocol ( http://hdl.handle.net/10150/625652 chapter 3) defines Nack returning to be optional, so this is a valid implementation choice, at the expense of slower link failure recovery.

Yours, Junxiao

---

From: Luca Muscariello <[email-masked]>
Date: Thu, 23 Jul 2020 14:54:05 +0200

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

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

On Thu, Jul 23, 2020 at 12:58 AM Greg White <[email-masked]> wrote:

> It sounds like the practical consequences of including the IP packet in an
> NDN interest may not be that large. But that doing so violates principles
> of usage considered important by several members of the NDN community.
>
>
>
> In my earlier response
> <https://mailarchive.ietf.org/arch/msg/icnrg/L4ZC_WVH9YOTknRzqxJEJDdSqlo/>
> to Luca on this subject, I suggested that we add some text in Section 4.1
> <https://tools.ietf.org/html/draft-irtf-icnrg-ipoc-01#section-4.1> to
> make it clear that in order for IPoC to work with NDN, some changes to
> the current NDN forwarder behavior would be needed.  It looks like that
> won’t be sufficient.
>
>
>
> How to move forward?
>
>
>
> One option would be to eliminate all mentions of NDN in the IPoC draft.
> The protocol (as written) then becomes a CCNx-specific one.
>
>
>
> That said, if a future implementor decides to implement IPoC on NDN, and
> uses the AppParameters field to encapsulate the IP packet, is there a
> mechanism to prevent them from doing so?  If not, perhaps a better choice
> would be to include in Section 4.1 a few sentences that discuss the
> situation with the current NDN protocol definition, and the implications of
> using AppParameters.
>
>
>
> As has been said previously, IPoC is intended as a transition technology,
> and it could be one of many that eventually get designed to handle various
> transition scenarios (just like there have been many IPv4-to-IPv6
> transition technologies).  So, a future protocol could be designed that
> presumes both endpoints have routable prefixes and thus utilizes the
> traditional NDN pull in both directions.  IPoC itself could also be updated
> in the future to make use of mechanisms like the Reflexive Interest
> <https://datatracker.ietf.org/doc/draft-oran-icnrg-reflexive-forwarding/?include_text=1>
> (if that is adopted).
>
>
>
> -Greg
>
>
>
>
>
> *From: *Junxiao Shi <[email-masked]>
> *Date: *Monday, July 20, 2020 at 9:01 PM
> *To: *"Shannigrahi, Susmit" <[email-masked]>
> *Cc: *"<[email-masked]>" <[email-masked]>, ICNRG <
> [email-masked]>, Greg White <[email-masked]>, Lixia Zhang <
> [email-masked]>
> *Subject: *Re: [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC
>
>
>
> Hi Susmit
>
>
>
>
>
> http://hdl.handle.net/10150/625652 chapter 3) defines Nack returning to
> be optional, so this is a valid implementation choice, at the expense of
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 26 Jul 2020 15:13:10 -0700

> On Jul 19, 2020, at 8:31 AM, Junxiao Shi <[email-masked]> wrote:
> 
> Dear folks
> 
> I wouldn't get into the "payload in Interest" debate, but I'd say something about forwarder memory consumption: two of three NDN forwarder implementations consume the same amount of memory regardless of AppParameters (payload) field.

I knew I would not be able to keep up ahead of the time:-(
Junxiao, I realized that the comments in my msg was wrong as soon as the msg went out (I'll explain in a later reply), but you seem falling into similar trap; I would not cite specific implementation constraints in an architecture design discussion.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 26 Jul 2020 16:33:18 -0700

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 <[email-masked]> wrote:
> 
> payload possible (within boundaries) which has never had shared consensus though.
> RFC8569 should be carefully read, including security considerations.  I personally
> 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>
> 
> 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