Re: [icnrg] [nwcrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs
Kazuhisa Matsuzono <matsuzono@nict.go.jp> Wed, 19 February 2020 07:49 UTC
Return-Path: <matsuzono@nict.go.jp>
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 8BC071200DE; Tue, 18 Feb 2020 23:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nict.go.jp
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 KolYFfkSrq8u; Tue, 18 Feb 2020 23:49:27 -0800 (PST)
Received: from mo-csw.securemx.jp (mo-csw1116.securemx.jp [210.130.202.158]) (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 815C61200D8; Tue, 18 Feb 2020 23:49:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nict.go.jp; h=Subject:To:Cc :References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type;i= matsuzono@nict.go.jp; s=20190225.smx; t=1582098554; x=1583308154; bh=cJk5e/Ltyo9/ r3fv0NkrnbS4R/flLQQuNWgheY0mH/E=; b=gvAYs1WD4sJ26QZBkfbha2XciXoXMERNpkTUtYJZ3m o7AKTbAuAdTFgaevCFDqHG9gKAc15lMb108lvW1ac7KY+EbvA3yDcs2uXbcGtLVig1EW1gtx536Ha +Medhkji16b6Fnntcvqt/nkE+XrhOgPj4zPDpYVfCOI/NJR5a92q7o/HFfp1I9dp6VXEQNhiQhzcd 8tjURKu16Oz1bBwAkkLjNm6SvnhVLJROorYZbQV/0ECQSFxZVBhvmHbeQgbipVcWBjZPdm0v3KBcG Y4E3ecXQk6ffMfj3j6gwfO5bl45gwG6LDyyEvReSyyCspJ0w88wL8kCWIvijVG0FRO1SA==;
Received: by mo-csw.securemx.jp (mx-mo-csw1116) id 01J7nE8M016435; Wed, 19 Feb 2020 16:49:14 +0900
X-Iguazu-Qid: 2wGrHliUwdfkMChBDA
X-Iguazu-QSIG: v=2; s=0; t=1582098553; q=2wGrHliUwdfkMChBDA; m=NTkPXw8VP2TFr8LH22BN+97jGdBKBOmrzax5uoJEVHg=
Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by relay.securemx.jp (mx-mr1112) id 01J7nAUr018096 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 19 Feb 2020 16:49:11 +0900
Received: from [133.243.146.168] (5gou2f-dhcp08.nict.go.jp [133.243.146.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPSA id 9E48630F5F; Wed, 19 Feb 2020 16:49:10 +0900 (JST)
To: Vincent Roca <vincent.roca@inria.fr>, asaeda@nict.go.jp, cedric.westphal@huawei.com
Cc: nwcrg <nwcrg@irtf.org>, icnrg <icnrg@irtf.org>
References: <5D41640A-9D13-49AD-BABD-6AADDC4724A1@orandom.net> <88d270bf-619c-d1ce-7b30-2b9a3371069c@sfc.wide.ad.jp> <882B9F95-ED00-49DE-A55E-4D6409646D68@inria.fr>
From: Kazuhisa Matsuzono <matsuzono@nict.go.jp>
Message-ID: <57ace330-89ab-3cea-64c7-2982e5179413@nict.go.jp>
Date: Wed, 19 Feb 2020 16:48:29 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <882B9F95-ED00-49DE-A55E-4D6409646D68@inria.fr>
Content-Type: multipart/alternative; boundary="------------C30D60EB56B29EDBB1C5C581"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/G3DXs7-OLpgqnLni-1JtObORtDo>
Subject: Re: [icnrg] [nwcrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs
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, 19 Feb 2020 07:49:30 -0000
Dear Vincent, Sorry for our delay, but we need a bit more time to revise this draft. We'll post the revised draft as soon as possible. Please wait for a while. Thank you very much for your coordination. Regards, Kazuhisa On 2020/02/19 1:38, Vincent Roca wrote: > Dear Kazuhisa et al., > > Could you please update your document, taking into account the > comments received so far. > I need to give a careful look at it too, which should preferably be > done once all of this is cleared. > Thank you. > > Cheers, Vincent > >> Le 14 déc. 2019 à 04:12, kazuhisa matsuzono >> <kazuhisa=40sfc.wide.ad.jp@dmarc.ietf.org >> <mailto:kazuhisa=40sfc.wide.ad.jp@dmarc.ietf.org>> a écrit : >> >> Hello, Dave-san, >> >> Thank you for your constructive comments. >> As Marie-José-san said, >> we'll wait for the further comments by Jan. 15, and then, upload a >> corrected version. >> >> Thanks, >> Kazuhisa >> >> On 2019/12/07 21:55, David R. Oran wrote: >>> >>> With <ICNRG Chair Hat On> >>> A reminder to ICNRG’ers to please review this document soon, as the >>> NWCRG would like to progress to last call in the near future. >>> >>> With <ICNRG Chair Hat Off> >>> Here are my comments as individual on draft-irtf-nwcrg-nwc-ccn-reqs. >>> They are divided into general, technical, and editorial/nits. >>> >>> >>> General Comments >>> >>> * >>> >>> The document contains a lot of thought-provoking material, and >>> is technically sound in terms of its discussion of the issues >>> and tradeoffs. Therefore, I think it’s appropriate to advance it >>> now as it can form the basis to guide future research work and >>> experimentation with the combination of ICN and NWC. >>> >>> * >>> >>> While not a pre-condition to advancing this to RG last call in >>> NWCRG, the writing does need a fair amount of work on clarity of >>> English language exposition, grammar and usage. It would be very >>> helpful if this could be done before sending it to IRSG review, >>> as IRSG members are neither NWC nor ICN experts, and could very >>> easily be left scratching their heads in a number of places. >>> >>> * >>> >>> The introductory tutorial material on ICN is appropriate to >>> level-set for the NWC community, but there’s a need for an >>> equivalent tutorial section on NWC to level set for the ICN >>> community. Concepts like “degrees of freedom”, “innovative >>> packets”, “RLNC”, don’t appear in the (terse) terminology list >>> in the Definitions section. It might be good to expand this with >>> more tutorial text. >>> >>> * >>> >>> There are a number of places where the document confounds >>> security with privacy; these need to be clearly separated and >>> the considerations articulated. >>> >>> * >>> >>> A pass needs to be done to align the text here with the current >>> RFC status of CCNx. I have some specific comments on this in the >>> technical comments below, but I may have missed some places so >>> an overall scrub ought to be done, either now, or during RG last >>> call. >>> >>> >>> Technical Comments >>> >>> * >>> >>> In the second paragraph on page 8, you discuss the interaction >>> of the naming scheme choices with forwarding, but don’t address >>> which, if any, of the characteristics would necessitate a change >>> to the semantic-free matching currently done by CCNs and NDN, >>> and/or the prefix match semantics of NDN versus exact match of >>> CCNx. Instead you concentrate on the size of the TLV headers, >>> which doesn’t seem to be a first-order problem. >>> >>> * >>> >>> Material touching on in-network recoding is scattered around in >>> various places and probably ought to be consolidated or >>> alternatively summarized in a section near the end to pull >>> things together. One approach you don’t consider (but probably >>> ought to) is exploiting multi-signature capability some signing >>> schemes that would work with CCNx. This way you can use >>> different signing keys for the original and coded packets, >>> allowing the entities responsible for coding to be different >>> from the authors of the original content. This way in-network >>> recoding could be allowed by giving the signing keys for coded >>> packets to routers - this would not require them to be trusted >>> to maintain the integrity of the original data since they would >>> not have the original signing keys. >>> >>> * >>> >>> In section 4.2.2 you bring up video streaming, and seem to have >>> an assumption that your network code is systematic rather than >>> non-systematic (aside: another thing probably needing some >>> material in the introductory section), further asserting that >>> sequential delivery is important, and hence there’s some >>> disadvantage to fetching coded packets first. I had a somewhat >>> hard time following this, and unless I’m misreading your logic, >>> I think it’s actually wrong since today’s streaming decoders >>> don’t care at all about packet arrival order and need enough >>> computing capacity to decode NWC packets within the playout >>> deadline in order to work decently anyway. >>> >>> * >>> >>> In the second paragraph of 4.3, you seem to be unaware that CCNx >>> has exactly the feature you want for packets you don’t want to >>> cache. The producer just sets the RCT (Recommended Cache Time) >>> to zero. >>> >>> * >>> >>> The discussion about whether routers need to decode and validate >>> coded packets is a bit confused and I think actually wrong in >>> some places. There are two issues. First, the text confounds >>> cache pollution with cache poisoning; these are separate >>> phenomena that need different mitigation/avoidance approaches. >>> Second, while you probably ought to discuss both, cache >>> poisoning is pretty thoroughly addressed in the current CCNx >>> design (less so in NDN) in a way that does /not/ require routers >>> to validate signatures on packets, or in the case of NWC, decode >>> them. >>> >>> * >>> >>> I didn’t get the use of the term “virtual logical link” when >>> talking about fetching content from multiple producer sites. >>> None of the transport or congestion control schemes I’m familiar >>> with for ICN use this term, and in fact I’m not sure the concept >>> is at all useful in the context of multi-path/multi-destination >>> forwarding in CCNx o NDN. Instead you might just reference >>> existing work on multi-path/multi-destination congestion control >>> and transport. >>> >>> * >>> >>> As the first sentence of a security considerations section, >>> saying “This document does not impact the security of the >>> Internet” is a big red flag in front of a bull. Get rid of it >>> (see may editorial suggestion to consolidate all of the security >>> and privacy material see rather than a separate section earlier). >>> >>> >>> Editorial Comments & Nits >>> >>> * >>> >>> Need to do a global replace of CCN with CCNx. >>> >>> * >>> >>> Get rid of the first paragraph of section 2 and the normative >>> reference, since this document doesn’t use any of the RFC2119 >>> terminology. >>> >>> * >>> >>> Everywhere you say “seamless mobility” it needs to say “seamless >>> /consumer/ mobility”. >>> >>> * >>> >>> the second paragraph on page 7 (which begins “the CCN/NDN core >>> abstraction”) is really hard to follow. There’s also a >>> confounding between what NDN cals the “Strategy layer” and >>> “specific…transport” since in NDN forwarding strategy does not >>> provide what are classically considered to be transport functions. >>> >>> * >>> >>> Section 4 probably should not be called “requirements” since >>> (a)this document is not an appropriate vehicle for expressing >>> NWC/ICN integration requirements, and (b)it doesn’t really state >>> requirements, but rather some general technical considerations. >>> >>> * >>> >>> the first paragraph of section 4.1 is under naming, but talks >>> mostly about fragmentation. Some re-organization might help by >>> moving the fragmentation issues to the end of 4.1 rather than >>> the beginning. >>> >>> * >>> >>> page 8, second paragraph s/not be able to obtain degrees of >>> freedom/not be able top obtain sufficient degrees of freedom/ >>> >>> * >>> >>> Page 11, Section 4.3 Caching is *not* essential for improving >>> throughput and latency. It’s useful, but not essential. >>> >>> * >>> >>> Given the paucity of material in section 4.5 on security and >>> privacy, it might be better to just move this (and hopefully >>> expand it a bit) to section 6 as a conventional security >>> considerations section. >>> >>> [End of Comments] >>> >>> On 21 Nov 2019, at 0:47, David Oran wrote: >>> >>> This is joint work of NWCRG and ICNRG, managed out of NWCRG. It >>> has needed serious review from the ICNRG participants for quite >>> some time, and at this point our review is what is holding up >>> its last call and progression. >>> >>> You can find the current version at >>> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ >>> >>> PLEASE review this and send comments to both the ICNRG and NWCRG >>> mailing lists. >>> >>> I would like to set a deadline of three weeks (December 13) >>> after which if no comments that need to be addressed prior to >>> further advancement are received, I’ll advise the NWCRG chairs >>> to proceed with RG Last call in NWCRG. >>> >>> Thanks, and have a good trip home for those of you who joined us >>> in Singapore. >>> >>> DaveO (for Dirk and Börje), ICNRG co-chairs. >>> >>> >>> ___________________________ >>> iDevice - please excuse typos. >>> >>> _______________________________________________ >>> icnrg mailing list >>> icnrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/icnrg >>> >>> DaveO >>> >>> >>> _______________________________________________ >>> icnrg mailing list >>> icnrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/icnrg >> >> _______________________________________________ >> nwcrg mailing list >> nwcrg@irtf.org <mailto:nwcrg@irtf.org> >> https://www.irtf.org/mailman/listinfo/nwcrg >
- [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs David R. Oran
- Re: [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-re… Marie-Jose Montpetit
- Re: [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-re… kazuhisa matsuzono
- [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs David R. Oran
- Re: [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-re… Vera Li
- Re: [icnrg] [nwcrg] Review of draft-irtf-nwcrg-nw… Vincent Roca
- Re: [icnrg] [nwcrg] Review of draft-irtf-nwcrg-nw… Kazuhisa Matsuzono
- Re: [icnrg] [nwcrg] Review of draft-irtf-nwcrg-nw… kazuhisa matsuzono