Re: [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs
kazuhisa matsuzono <kazuhisa@sfc.wide.ad.jp> Sat, 14 December 2019 03:12 UTC
Return-Path: <kazuhisa@sfc.wide.ad.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 4DF7912012E; Fri, 13 Dec 2019 19:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sfc.wide.ad.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 Mk0PMEM4fOp8; Fri, 13 Dec 2019 19:12:46 -0800 (PST)
Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:133]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E2D12012C; Fri, 13 Dec 2019 19:12:46 -0800 (PST)
Received: from MyMac.local (unknown [133.69.36.79]) (Authenticated sender: kazuhisa) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id C6A2E2EFB; Sat, 14 Dec 2019 12:12:44 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1576293164; bh=RTgRIHk91RcUiarnfyieE4Fn4W8w20a+sMIukyhhcb0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Impfl944V376dCT6oxDzaMmqxI4ycAKkKIs+6Zt5M7kAWxp4uq+gWKWE4qyIyEGDj +rYFpuStt32Mg653u7c/UKinFmhFVkYqRIOZw5G19tPngOdjeNILIQXWowXU+gtqPG z9ggtdNpYmbLzzAGZxkuiLWFNvABXnjQGCgjbZMQwMfZyfaAlz3exZrccATKJe3B3j uT7OiaOafsX4DR+Y5SFTkHhHAV50UDclhCJCBDtMQFiGRIG8AqjYPhYyKuK+ib+AfH Lu/souVbqvOOam36ukS2YqftCwly0VIhLN6/yO+DvZEWDdjkgeZ4JDn2lWo9hv89oh V7X1I8IWteegQ==
To: "David R. Oran" <daveoran@orandom.net>, nwcrg <nwcrg@irtf.org>, icnrg <icnrg@irtf.org>
References: <5D41640A-9D13-49AD-BABD-6AADDC4724A1@orandom.net>
From: kazuhisa matsuzono <kazuhisa@sfc.wide.ad.jp>
Message-ID: <88d270bf-619c-d1ce-7b30-2b9a3371069c@sfc.wide.ad.jp>
Date: Sat, 14 Dec 2019 12:12:41 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5D41640A-9D13-49AD-BABD-6AADDC4724A1@orandom.net>
Content-Type: multipart/alternative; boundary="------------D01AC6B96509365B81890C58"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/gmAxCuD2Crb0QLqk9WegG9AZvKs>
Subject: Re: [icnrg] 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: Sat, 14 Dec 2019 03:12:49 -0000
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
- [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