Re: [icnrg] ICNRG progress

"Mosko, Marc <mmosko@parc.com>" <mmosko@parc.com> Tue, 10 March 2020 01:55 UTC

Return-Path: <mmosko@parc.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 8111C3A0CC6 for <icnrg@ietfa.amsl.com>; Mon, 9 Mar 2020 18:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=parc.onmicrosoft.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 cbItHFcWRn9I for <icnrg@ietfa.amsl.com>; Mon, 9 Mar 2020 18:55:52 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770059.outbound.protection.outlook.com [40.107.77.59]) (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 E9D023A0CC5 for <icnrg@irtf.org>; Mon, 9 Mar 2020 18:55:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=atPSM1Faapd4KzHKrNxg47Eiw75A4UDkP6LLZWPbYJypC0xpcvJzu5fqRZfzadIlICYNrX5LpLG9bIV+OzrBJfatSNSzDJzKdzZcEjkA1B03l4H7ftYSkaUwXbGzlvtMidUi3yYwhXhnDVyN+Oln0otyyDu5bAMK1JRNmtH0mMThrR06qJnir1bfS2+3Ub/Hxyg4TigFgeMZijNueoDPHDUZFgrVtrbNqBaSde+jKACYGNP1/dD4nnhbVolZHwt91Mg9itcrbHs5l4lmtf0AYB6qiUu4ZbFJTLRCyxL/RRlm6NA5nXaZi/I4Nzf8aalQbNubY3B0V3UJfATruiFOtg==
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=uuR+cfQbm4svJYl2Wry6vaqVPPJIlcj2po9TJdnBooU=; b=kWqG8pQV8fsnwpxITjb+SFQhM3qWNm1ma1jHsf4iYukBNuYqQRfFDpPZ3ajVrRjLwZ8CsbH1ImA+f+b+D9mTyrb3UxlOhkx4hgiZyQ1nYaR3DO0YGNe4n5fj6GatyGcwGwBY4OgXBzF9J8P2zrwHd+wSLXrjzC+El/ZD71ZYzTogCVOK8nNWKldHberc5u5AYS/Boz2QSoEsXobALjzrMRu4lrzq6cFGWJztW8ZBTFBA8Oiw2eVnwYSrmuRCujTAZTVp5iY3prN+tTgYbQp1ogfErEbnnC8cbl68ljl0im099w6egUF/hHj/j+i/hpnXi2wLF/H0Jm/AFcRd+togbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=parc.com; dmarc=pass action=none header.from=parc.com; dkim=pass header.d=parc.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parc.onmicrosoft.com; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uuR+cfQbm4svJYl2Wry6vaqVPPJIlcj2po9TJdnBooU=; b=QmY2i5w65yeJFaIeMIUVGN5uFvsQGNdLiqb/fSHIWoRtSwecmw7y/zThTBr04bVg9+tbGT7vI2Q2reFJIdNnwa0hhKNZFt8ZxTnuOSRboy4RbM452hcmLSzzNEE3Yq5YE8WSPrJ8KZJCwWY+UacMSbGmcwmG1ODWt0HxhcJntDE=
Received: from BYAPR15MB3272.namprd15.prod.outlook.com (2603:10b6:a03:110::17) by BYAPR15MB2823.namprd15.prod.outlook.com (2603:10b6:a03:15a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Tue, 10 Mar 2020 01:55:48 +0000
Received: from BYAPR15MB3272.namprd15.prod.outlook.com ([fe80::507e:3768:eb66:1e91]) by BYAPR15MB3272.namprd15.prod.outlook.com ([fe80::507e:3768:eb66:1e91%5]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 01:55:48 +0000
From: "Mosko, Marc <mmosko@parc.com>" <mmosko@parc.com>
To: Ken Calvert <calvert@netlab.uky.edu>, "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: [icnrg] ICNRG progress
Thread-Index: AQHV9n0b6s3rpMl3hEKQe1TwUfm+26hAm7WA
Date: Tue, 10 Mar 2020 01:55:48 +0000
Message-ID: <E802242C-DB84-42C1-9C18-D69E4BB9A92D@parc.com>
References: <mailman.104.1582574416.2917.icnrg@irtf.org> <48BD9966-D362-405F-A7B1-1E5515F041AC@netlab.uky.edu>
In-Reply-To: <48BD9966-D362-405F-A7B1-1E5515F041AC@netlab.uky.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mmosko@parc.com;
x-originating-ip: [2620:0:2e80:a00b::b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 89642c0f-8d19-460d-ab3f-08d7c49627be
x-ms-traffictypediagnostic: BYAPR15MB2823:
x-microsoft-antispam-prvs: <BYAPR15MB2823AF7290636431FCD7F906ADFF0@BYAPR15MB2823.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 033857D0BD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39850400004)(136003)(396003)(366004)(376002)(189003)(199004)(5660300002)(66946007)(186003)(66476007)(64756008)(66446008)(66556008)(9686003)(6512007)(6486002)(478600001)(966005)(76116006)(3450700001)(2906002)(86362001)(36756003)(71200400001)(36542004)(8936002)(8676002)(81166006)(81156014)(2616005)(66574012)(296002)(110136005)(316002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB2823; H:BYAPR15MB3272.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1;
received-spf: None (protection.outlook.com: parc.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zRjXLUPLO7PL0VrhqEbZ+yh+pRUwLmFnf0giuwEKqzvW3Jw9V628sOW99gMKTtdZGRhsfY4Wh3I2C3supWIKLNYAmeFhCZHatqJdJE5XbWd8kYzjWY2fFn5/nITdbjoE0hS6NYhc/T3RygbF+rhj1Wj+GVDVYchsP+JCrMMg5RX+ViHZvKCRRBKoMcJktckW/iFd4olFtWF14DJ9sZySU/44zCamDnXuLkMOlum+EvY7uuRLnIq9fa0wNkt1My+zr+BIN2sIYeIthHasHpwRuI8ToUfRU6KCySdqGWCKrAjZDYrnQD7MBsDus04Pk2k0Tms1o4UwqcprI6fhPQdRLs5qvdzUoSwhPAUyN87P3C63UV7jCbJ7UEk11gdp2W9qWxrfikvyxbESNIVqByOML754PqZmSpb12y2ILyVfUPagpXIFIrX8l9O2VCELmghBgToFsngFQ2jFwdp73Ita/fm2WxCD/3PWm7oiXUCGFhlQVBv3/tAmVeIr3Ab854mUeooTK6eH5XZ7bn2clVGtGg==
x-ms-exchange-antispam-messagedata: DO/OodkP0GIX6BF9kwlywSp93pLNp01KBdmCWKi6BPsk6L6/zSZGjDoFCnTuQfy3GMuehz05EJew742KhsyNApPHBqItUY7Unx+CD3QPJ/Lyg7nm2Zg8U87KuQ4e4zvmXviNjUWbedBZnkLfhEfoqaBgOpfSN2pulSrbsk83rmY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4EEA9A043C1ACE48B95AAE784E920884@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: parc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89642c0f-8d19-460d-ab3f-08d7c49627be
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 01:55:48.4401 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ej/f90XgAm+rgOnGyuJkIwZk+BFj+hDwLFO+dTpYezMgXQSpzw36xGUF/QnLnFHB
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2823
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/UDN04uAFzklIH2WWjzO0ABSdZFg>
Subject: Re: [icnrg] ICNRG progress
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: Tue, 10 Mar 2020 01:55:57 -0000

Ken,

In ccnx or ndn, the only way to guarantee this property is to include a hash constraint (ndn name segment or ccnx field).  That ensures you get the same response (if any) for the same query over time, modulo some tiny tiny number of hash collisions.  Really, it does not guarantee that, but if the routers all behave correctly they should ensure that you get the same data or no data.  A misbehaving router could feed you incorrect content, so the consumer must always do their own check.

In CCNx, we expect that even within a given publisher, the content object that matches a name may change over time, as guided by the expiry time and recommended cache time.  In NDN, if you are using discovery, you expect that different data objects will match the query of a name prefix.  NDN expects that within a given publisher, the full name (name up to but excluding hash component) should be unique.  But that is a convention of the publisher, and is not guaranteed in any way.

Third parties could always try to publish their own objects under any name.  Without including publisher key restrictions in an interest or using namespace keys to limit publication to authorized parties, there could very well be any number of different objects with the same name and only routing would cause one over another to be fetched.

Marc

On 3/9/20, 6:42 PM, "icnrg on behalf of Ken Calvert" <icnrg-bounces@irtf.org on behalf of calvert@netlab.uky.edu> wrote:

    Dear ICNRG -
    
    I recently read the CCNx semantics RFC.  I was a bit surprised to find nothing in it about "referential transparency" - the idea that interests for the same name should always return the same (content) bits.  That (no stated position) is understandable for ICN as a whole, but I expected that specific protocols would have some kind of statement about it (I think NDN requires it, but I'm not up on the latest NDN specs or code).
    
    So, a question:  Is referential transparency a property of CCNx, or is it explicitly left up to the publisher, or what?  Or put another way, what, if anything, is a requestor entitled to assume about the result of different interests for the same name?
    
    Thanks for any help.  And apologies if this is a dumb or non-useful question.
    
    Ken
    _______________________________________________
    icnrg mailing list
    icnrg@irtf.org
    https://www.irtf.org/mailman/listinfo/icnrg