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

"David R. Oran" <daveoran@orandom.net> Mon, 13 January 2020 14:59 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 CAEC91200D6 for <icnrg@ietfa.amsl.com>; Mon, 13 Jan 2020 06:59:31 -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 NeOG4CLfIQx1 for <icnrg@ietfa.amsl.com>; Mon, 13 Jan 2020 06:59:29 -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 971A312003E for <icnrg@irtf.org>; Mon, 13 Jan 2020 06:59:29 -0800 (PST)
Received: from [] (c-71-233-150-209.hsd1.ma.comcast.net []) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 00DExQTl020903 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <icnrg@irtf.org>; Mon, 13 Jan 2020 06:59:28 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Mon, 13 Jan 2020 09:59:25 -0500
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <CE4D26DF-0DA4-4EA0-9083-6B7D9D8FCAB2@orandom.net>
References: <CAPjWiCR0feHO01tsJPdxN_isj+0_u8168MYKZ7Aa_4h=OXCHsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_98F1BEB5-3BAB-41C9-BA37-BE293A68DEA2_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[1056, 10808], "plain":[643, 9002], "uuid":"D1E4BCF9-D2A3-4888-A68E-B488A3238C0F"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/qrzhRqqHfpxb61fD_kJ8DEPtPBA>
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: Mon, 13 Jan 2020 14:59:32 -0000

We have a deadline coming up in two days to submit comments on this 
before NWCRG sends it to last call.

We will obviously have a chance to give further comments during last 
call since this is a joint RG document managed by NWCRG, but the sooner 
the better in order to have the document in the best possible shape 
coming out of RG last call.



Forwarded message:

> From: Marie-Jose Montpetit <marie@mjmontpetit.com>
> To: David R. Oran <daveoran@orandom.net>, nwcrg <nwcrg@irtf.org>, 
> icnrg <icnrg@irtf.org>
> Subject: Re: [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs
> Date: Fri, 13 Dec 2019 08:23:43 -0800
> Thank you for your comments.
> In order to push this draft to last call we will limit the further 
> comments
> to January 15 2020 to account for the upcoming Holidays.
> Marie-José/Vincent
> On December 7, 2019 at 8:55:36 AM, David R. Oran 
> (daveoran@orandom.net)
> wrote:
> With <ICNRG Chair Hat On>
> A reminder to ICNRG’ers to please review this document soon, as the 
> 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 
>    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
> 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 mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg