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

Junxiao Shi <> Tue, 21 July 2020 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AD8E3A132B for <>; Mon, 20 Jul 2020 20:01:13 -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 InYexBY6E9F7 for <>; Mon, 20 Jul 2020 20:01:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 971B93A1308 for <>; Mon, 20 Jul 2020 20:01:10 -0700 (PDT)
Received: by with SMTP id k6so16033177oij.11 for <>; Mon, 20 Jul 2020 20:01:10 -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=RjYnPjcUH99TF4kZM8P4Py45EityzpJ0tpu2ZPGMEMg=; b=vP+cTrtti8tloa7HnT8IT+SSq/eVP0VpwT6d1i9pxByNwcLwEhepnsvDXickWhU4DP 4lHv+xdHFUeCarBV8M2Mp8b4hov0GU9Zjq49ocNTAyY93xpPrsnFxzt/aW8hw5NrdjXD PawpN7QAd6SEy4cSqAtxzFv4TARjnrHRcK6LKHk0+Fb+Rb94JGOr1LRGowBLtG8DgzUd QUnDtoLeMQmRRCgKSTYdIO7kJe+Z+7PjVJEEPXOxii9GSwCBRK5Rx47aevt2lGGmlgEl RsDX0xaLjiJy5JCShCsugP8oQvPFVossHCvncsgnZAxHHnVOXh/7wbNRek4x03O+HlyP oxTw==
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=RjYnPjcUH99TF4kZM8P4Py45EityzpJ0tpu2ZPGMEMg=; b=DyLn/7fJq/Qgayqq7KM0e77VN0/s1ewefnOOGtE4BB4jEzeFceXwm8I9ShkHy9s940 3Nm6lyX+ycZOZiH1etNTJwYRwZUJxlJcyYtP+pWkYAbgfdLIXmU5ncuPHaCHWEg3s4Rh 23e4yf1j3r4ni+KzFGpFKT/nGqbrFhY8zK/f2AArVUIWjHBsuRaYoeGXPJLxMfhHS03e GZKX/KjOdBBpNyhKzU0615Yf0VXFlsrGYDeo5I+U2H9/0ruVTuHbuLzUU2neUvJkTHLW drQYzY+sE7bfCkxWefWxgkNGw95Wj4uagNOOFtcatkRD5K9CwbyJfp6hwxX1tGODuHhW J7+A==
X-Gm-Message-State: AOAM532TFbm0Whh2dN4MhS+anYfauFV0YTO9+4MiRKmx8EVdqyhA4nze pJzg6H7QEPC5cV7Cs+HzSO5map5xJV6WF7HIKYoIZX03CdcrD3pvU1Rech+6NK1kP2WPYBO736U fRdaVz0BnELs=
X-Google-Smtp-Source: ABdhPJxg9v6V/nYq5fW7i9IKPavk276sXLSdRtLe2VyWWJ0/Q492e1K6zgiXzdU9fkPYCyhW8UBPQAIM0iJsHdZJpXc=
X-Received: by 2002:aca:f1d5:: with SMTP id p204mr1539570oih.171.1595300470048; Mon, 20 Jul 2020 20:01:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Junxiao Shi <>
Date: Mon, 20 Jul 2020 23:00:57 -0400
Message-ID: <>
To: "Shannigrahi, Susmit" <>
Cc: "<>" <>, ICNRG <>, Greg White <>, Lixia Zhang <>
Content-Type: multipart/alternative; boundary="000000000000d3ed7205aaead5af"
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: Tue, 21 Jul 2020 03:01:14 -0000

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