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

Greg White <g.white@CableLabs.com> Wed, 22 July 2020 22:58 UTC

Return-Path: <g.white@CableLabs.com>
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 6A55A3A08EC for <icnrg@ietfa.amsl.com>; Wed, 22 Jul 2020 15:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cablelabs.com
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 7mFqNkCXaRoL for <icnrg@ietfa.amsl.com>; Wed, 22 Jul 2020 15:58:05 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2092.outbound.protection.outlook.com [40.107.243.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67573A08E9 for <icnrg@irtf.org>; Wed, 22 Jul 2020 15:58:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W3bmjjjTcVa6ktdGMFmfURxnwf5vZRblWm3wf1DftuiTzBvz++BPmKf9Ldn7T3qfZnz4iuTjNwsvrT6X+Q4dbYdPrtVAzi7nFLp1JwbulBFIxt9kagFVj5GoKtKjNjpp6evn+jZCr50z5hAvBndwT1OFJn8klsozqOkDZjxnCKWJHrbn832sEfl6EL1uriZqeC0YF/87BsNp/LQ5uZ8QblkIa2HYdKD49l9wFKZaTkS5u+XQJadWSQbbLzE9iS3jHCsOe9f+qE6jbAwf55PsONjr28nL4KGtfQI+Xd7uMwlhZjTzQbhfFTscklB5nvaC//MKV7oSXV1YOql9YhjxGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=syzt2jSenqO34x2n2ATvZAqpyg+7KzY31hmB7mNhRKE=; b=lwhvUTYw/uYSga8cteeR7PZaVDrt5bp3IQ2r4Qrd/YOtojkh02GW8Wz6I4tZrSg7pnHaUDORGd4sDHyYhtYRRrlQ+k6Lhrd+YAu3FXACnRCSAue83+yyLgI7j1PITbBVdBlaqEizebwrmXemsNWCShU80I2/I0hI54RyvUMBuFrRc05H8k2sFmj3dAcrHKo/B5zset+fLddkJYA0LUpczI9Ffq75E85jY44/kBL83iIoyF/h+CZonHNaJsBO1HXVuFbe2fSdenxfSWe/msHWDvr/OEyI0/wlY1iW309XAfK9fC5RlZVk6EvIbigvqnZuxBRGD/5wQ/jvffjY/7sxWA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=syzt2jSenqO34x2n2ATvZAqpyg+7KzY31hmB7mNhRKE=; b=FRLfzheeRA9d2kkgu11oIau9GASOfTIW8zIIRiyO+r+WYSpvIwOsAcpik3xHukFSTrl4kvJRIHe8/f4LSnEsw6HKykQ7oRUrRETJFsJZKqGgtWikkXo3nZMMof04/GZb9icBIiJUS+RgrlZFA00HIOwA/UtZSFAatMLMiF+/RjML3DQbZNc7kDrx68Ye0+uJDmggJVSuN47lyAdbnUdBta0vj5ZC3uS076r95Kz5VFsbYq9LLFV+FAh8COMzhdGKEPcoLh6ITM1+u0fr0APZQ/2kxwVv5Wa97FvHUNfEp3K+ZlB6xj/poCqErIeehjG39MrGdeoQavgLreOkj8zZcA==
Received: from CY4PR0601MB3713.namprd06.prod.outlook.com (2603:10b6:910:92::10) by CY4PR0601MB3620.namprd06.prod.outlook.com (2603:10b6:910:8f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Wed, 22 Jul 2020 22:57:58 +0000
Received: from CY4PR0601MB3713.namprd06.prod.outlook.com ([fe80::1da2:c5c:55de:c096]) by CY4PR0601MB3713.namprd06.prod.outlook.com ([fe80::1da2:c5c:55de:c096%4]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 22:57:58 +0000
From: Greg White <g.white@CableLabs.com>
To: Junxiao Shi <shijunxiao@email.arizona.edu>, "Shannigrahi, Susmit" <sshannigrahi@tntech.edu>
CC: "<nfd-dev@lists.cs.ucla.edu>" <nfd-dev@lists.cs.ucla.edu>, ICNRG <icnrg@irtf.org>, Lixia Zhang <lixia@cs.ucla.edu>
Thread-Topic: [EXT][Nfd-dev] about draft-irtf-icnrg-IPOC
Thread-Index: AQHWXtjMce+ERe3hhkO1m41oeMGPMKkRWJ2AgAJ8MIA=
Date: Wed, 22 Jul 2020 22:57:58 +0000
Message-ID: <4801E04D-3658-43F7-B6E2-047F8B8641DA@cablelabs.com>
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>
In-Reply-To: <CAOFH+OadgvE34w2kSfMaWjUeo-+75a3K3mOPJCKXWaP+0=o1Nw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: email.arizona.edu; dkim=none (message not signed) header.d=none;email.arizona.edu; dmarc=none action=none header.from=CableLabs.com;
x-originating-ip: [98.245.82.7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5f738cca-7813-4030-92af-08d82e92ad8d
x-ms-traffictypediagnostic: CY4PR0601MB3620:
x-microsoft-antispam-prvs: <CY4PR0601MB3620290503ECCCF80F1EA1C6EE790@CY4PR0601MB3620.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nWAuTTvdm895LNtqhHSNUPK+78OnEVSzDCwMvMXir4HJ8gnkjUf4OJrcsHOCWvzpubUUX5tD8JaQeozm11ug3Se29r1rsPwrpxKh+t2ZCGzm8gM6bNcdJmQn2S/MpOjhMl/ZOOVl2tnwpNf3KQ35bfr5sNimIk6C5hVBaTlRM83M7kHtHLk16bIxakqisOb7wwqpU+b28eXhIWxHByRjhO9haviJ5a8zGPUrBheUT+XzUStmgaRSmFigBeMUQAVhcbDexTuDWeZo+LBnfu/meJ4K8Yxs+BHmdwUFC+YpRvtYfIu8hNtl9sEDf1ddmQYKV1AV6sC8iQfp7abdplBfa2KOtVCDpTAq1hwS1DuFyRcyuavG2cd3JEjcO7BJXz47r5NS5vc1wePGSL0X6R5Xbg8SkAfHYShChNh6TmZl9mDUaUFEfX2RmfRJ2gJa5KTUKnKH7LNdjr4uo5klT084gg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR0601MB3713.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(136003)(376002)(39840400004)(366004)(396003)(6506007)(6486002)(53546011)(83380400001)(2616005)(5660300002)(110136005)(8936002)(8676002)(71200400001)(4326008)(6512007)(316002)(33656002)(36756003)(166002)(86362001)(66946007)(186003)(64756008)(76116006)(66556008)(66476007)(966005)(2906002)(478600001)(26005)(66446008)(85282002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: jkqQxeVrRiU2f4wDeed7368CxX9KpUU7o6YXvwNYu+kiA1BRYkBKfTsY8FHmDs35MZUbzEDVAi/OJlSk5LoNuB/aYCxeAQjTVZ2zCmBiEQBx2Ub7rIykRNWkwIQs/4d7tU/C4XYx7vQurvm9wNFybFOb5n+s0gaMd1xZ6+f0CgCXUojCTL+PhsHHmBX1bX2gn0r03b5h8CQz7a3EJEX698HvB7tizE/edzECbaAh1IJcNJ8om1o7yv/mtjGlmNPOVF7ITcPEv60K9Nj2LVzKlfiBse77xH4jYF0kpfVzPa35Ig1jZy5tpYHTfHDzVmHHreb651o/uR4emhCLYYReXNd2BNbDc1tZIGxLbQAO+powZJikXYRoUyDT8zWbN1JoystaHkkIGBUDt2SythhQ1m26qbNm5dkkxi2pYk67XfaiItd+arFriKJTJSfKGjlVc0HapNmKo3+NGjleGIXfBEqMvBoZDJ3Zd2mYKnejgKU=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_4801E04D365843F7B6E2047F8B8641DAcablelabscom_"
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR0601MB3713.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f738cca-7813-4030-92af-08d82e92ad8d
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 22:57:58.4324 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NXUppkC/GXCZgHyMwkQP/x9lpats94YGGnl/hspPrIp4Qaa6PDt5AYOAUIvDBoirNk5xsCrCXlrb+j4lRgVGMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0601MB3620
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/3B05aXthZ1enxWjSgCyODCcxHMg>
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: Wed, 22 Jul 2020 22:58:07 -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 <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>rg>, 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