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

Luca Muscariello <muscariello@ieee.org> Thu, 23 July 2020 12:54 UTC

Return-Path: <muscariello@ieee.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C453A0A4E for <icnrg@ietfa.amsl.com>; Thu, 23 Jul 2020 05:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z0TJ9fLkh1y for <icnrg@ietfa.amsl.com>; Thu, 23 Jul 2020 05:54:18 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11013A0A4D for <icnrg@irtf.org>; Thu, 23 Jul 2020 05:54:17 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id f1so4510888wro.2 for <icnrg@irtf.org>; Thu, 23 Jul 2020 05:54:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SMbGfGrjVW4MOY3y07SK8ryGc9iob+Lk4+F/P7JZkpk=; b=FKg30J/wi3I96fpC0zbpKwoxKHNNuvW5a7g/kbOR5Vicap7UUgh0Cg7jFal6Y5HZzH zZ6Qf3Ck81C0Ubv8KHc+rmbJFqacdzd92IBjju86xvUttASDh3IK9+v3/bw5JUCAW4oi c5cU8EyRr4EG7LNIYliHick3AfG169rHXxCnw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SMbGfGrjVW4MOY3y07SK8ryGc9iob+Lk4+F/P7JZkpk=; b=LlugSJIW6cVBZTX5ZY9uws4qrqbK8gteaWiOGqi9eO/6IBk2QwoChQNeHCCwydFSEw a0wNqGmwjGTs0sPY/a/ha2aaC47s7Nlz4nH/EajIMqjpVz0WFTZb35rb+BLJ4lLK6yuB 9GrzFnEFRSJX7hAuI9RM0Jl+PeHaHsTV8YpwypfIlFgXG/EPuTr0tV2nsqp5cB9u5Hbg 8gzwfMJpshZss2i6SKNi9GDcA2OGJUA+VqSxxqdYe/iDL7B1cvFwWjIiD6Buyvlw6MVj x5DWcWyoFCHSg0XXAl5Q2Fve6e2Din3/psdm2LlItlrqWnNEJRWLNTXmky5KqOQCS5ep PIng==
X-Gm-Message-State: AOAM533YsPqaGllgWdHmbznKIsjwShQjFCO9xXvyv2ziGjDqGjteRY2g OWpXNBwE132QfiS2xMvNiqkPkwjjlso4aqW2uUj1/w==
X-Google-Smtp-Source: ABdhPJwi1Bmrmp/ZUHXPHNmNtTlxMMHtyrPee8kaNIbc3SCbGUk45lMwhrXNdxNThyf7m3dbFeJPmnJuZzE9R2LG+QQ=
X-Received: by 2002:a5d:464e:: with SMTP id j14mr3966110wrs.361.1595508856125; Thu, 23 Jul 2020 05:54:16 -0700 (PDT)
MIME-Version: 1.0
References: <69599899-EF86-49F0-8CAB-228C8AC148CB@cs.ucla.edu> <CAOFH+OYuX0f33=3FhhVi-hiJV9-ih-z8yyQMeHjRW6B=wN-cVw@mail.gmail.com> <BN8PR07MB6370BA37F0A19F4D416D61A2B57B0@BN8PR07MB6370.namprd07.prod.outlook.com> <CAOFH+OadgvE34w2kSfMaWjUeo-+75a3K3mOPJCKXWaP+0=o1Nw@mail.gmail.com> <4801E04D-3658-43F7-B6E2-047F8B8641DA@cablelabs.com>
In-Reply-To: <4801E04D-3658-43F7-B6E2-047F8B8641DA@cablelabs.com>
From: Luca Muscariello <muscariello@ieee.org>
Date: Thu, 23 Jul 2020 14:54:05 +0200
Message-ID: <CAH8sseTh34_2_n5f2uvxVexUXzN5dat_U=-J+JH=qmbNCMXxkA@mail.gmail.com>
To: Greg White <g.white@cablelabs.com>
Cc: Junxiao Shi <shijunxiao@email.arizona.edu>, "Shannigrahi, Susmit" <sshannigrahi@tntech.edu>, "<nfd-dev@lists.cs.ucla.edu>" <nfd-dev@lists.cs.ucla.edu>, ICNRG <icnrg@irtf.org>, Lixia Zhang <lixia@cs.ucla.edu>
Content-Type: multipart/alternative; boundary="0000000000009b294605ab1b5a14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/YhhA2SmoBmG0RNL_lqK9ZgirZSQ>
Subject: Re: [icnrg] [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2020 12:54:20 -0000

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 <g.white@cablelabs.com> 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 <shijunxiao@email.arizona.edu>
> *Date: *Monday, July 20, 2020 at 9:01 PM
> *To: *"Shannigrahi, Susmit" <sshannigrahi@tntech.edu>
> *Cc: *"<nfd-dev@lists.cs.ucla.edu>" <nfd-dev@lists.cs.ucla.edu>du>, ICNRG <
> icnrg@irtf.org>gt;, Greg White <g.white@CableLabs.com>om>, Lixia Zhang <
> lixia@cs.ucla.edu>
> *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
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
>