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

Junxiao Shi <> Sun, 19 July 2020 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF7B73A09A5 for <>; Sun, 19 Jul 2020 08:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hW_zftNfCDZA for <>; Sun, 19 Jul 2020 08:32:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95C313A09A0 for <>; Sun, 19 Jul 2020 08:32:18 -0700 (PDT)
Received: by with SMTP id 95so10347355otw.10 for <>; Sun, 19 Jul 2020 08:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hmgeT+hv5n0Pt+aeRmICm7QhS2LnDOqTiTBN89Kwu3c=; b=ZOeKhiJqDyrkMFMGv/RMTbQJe7BpgfvOdNgFG82PM4B2GervGKg78Vph9DvrrG2yPO 4DWKTPSP78G74AI7mJPvHa8UUNqh/vUOBKzskQUv6hwrJpq16VI78DatmrQh+wP1rq4m rRo5/yXwN374xqgIK/ZWkpr2tPMqb7YDlR+cX1/AaAOklez3vECt5umt9KEVAFE+gGM5 3Pzs5dOQiHYJ3Ob+5UHSVtdg6iMAfiGHkxIuDWJVkg5AHmmjAzbtWxFxXCloOXgvTY7f GgCYf2ephHBLCLBw7zlxkcqah0exdxuFoHI00FpBYtWYd89tET1hBhBgPZG88aXcqxFw FdZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hmgeT+hv5n0Pt+aeRmICm7QhS2LnDOqTiTBN89Kwu3c=; b=Fpj+ovwpZ0OQmsbHzz3983oRq2SztgdzHBmtoMy5jeFQrnA+HhpJqbTCHqvceOfWKX Q8lo2KOi7qZ4ogIwO22yFFh5NLlKdjxsSwKA4IdWE/suSLZyDmoSnP15xi5R7VFiqmXz wU99cjzTegWEXaJ7oY1PfUu8Bof4LQbYl4TgDg30CeQ9PAMMQQkv0znKurPQ+DscZ15o H+IuTAenbsmj19fy3H0JiAHg2GfeqOzlLcxKfQ35szw2s8nRkv7B2XqrYG9ZqS93/PqG H/Owyi3KrLgb/WBHg7UJalQkf+kMgAgJBYatufFth99IWo+X4KT6DKt0cFExmqyeL5Cj o4pg==
X-Gm-Message-State: AOAM532471Khpb7JS3ef7SqPvqlguZqHARzEVG0mpkjkmCDIUvzTJWhe g8IgoYad480/BWKIIEKzdXF4BF43RvghflYe51i6iLYxpLjMqkwlxyRW+y+9qUyrLIC6uCedOG8 6ih341uY4x4I=
X-Google-Smtp-Source: ABdhPJwfJS1Sr/Gp+PnvoYF7DDsJw0gnfpiBDw8dM5VIfrKWVVrIy3U5IuAcftNfAE8L1TbzQD/xqSEgFxecKEBPWo4=
X-Received: by 2002:a9d:701b:: with SMTP id k27mr15395065otj.227.1595172737575; Sun, 19 Jul 2020 08:32:17 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Junxiao Shi <>
Date: Sun, 19 Jul 2020 11:31:40 -0400
Message-ID: <>
To: "<>" <>, ICNRG <>
Cc: Susmit Shannigrahi <>, Lixia Zhang <>
Content-Type: multipart/alternative; boundary="00000000000061001205aacd18ee"
X-ua-ms: gsuite
Archived-At: <>
Subject: Re: [icnrg] [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Jul 2020 15:32:21 -0000

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

*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.
I don't see this as a good practice performance-wise.

Yours, Junxiao

On Tue, Jul 14, 2020 at 8:22 PM Lixia Zhang <> 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