[icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs

"David R. Oran" <daveoran@orandom.net> Sat, 07 December 2019 13:55 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B3E241200FD; Sat, 7 Dec 2019 05:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cRwXGhWP7EXe; Sat, 7 Dec 2019 05:55:27 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (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 5F730120096; Sat, 7 Dec 2019 05:55:27 -0800 (PST)
Received: from [] ([IPv6:2601:184:407f:80ce:6d8d:2155:aa43:c372]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id xB7DtLoS011728 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Dec 2019 05:55:24 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: nwcrg <nwcrg@irtf.org>, icnrg <icnrg@irtf.org>
Date: Sat, 07 Dec 2019 08:55:16 -0500
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <5D41640A-9D13-49AD-BABD-6AADDC4724A1@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_CAD2B204-01E3-493E-8AF6-0DECFEC7ED67_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/mPyovhCZ-851pdbDQHw2t2ViaR8>
Subject: [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, 07 Dec 2019 13:55:31 -0000

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 

- 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 

- 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 

- 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