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