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

kazuhisa matsuzono <kazuhisa@sfc.wide.ad.jp> Mon, 02 March 2020 05:45 UTC

Return-Path: <kazuhisa@sfc.wide.ad.jp>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54153A0C82; Sun, 1 Mar 2020 21:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 rxo_n8_wU185; Sun, 1 Mar 2020 21:45:45 -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 B24813A0C77; Sun, 1 Mar 2020 21:45:44 -0800 (PST)
Received: from MyMac.local (unknown [133.69.36.79]) (Authenticated sender: kazuhisa) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id 48CAD718B; Mon, 2 Mar 2020 14:45:42 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1583127942; bh=uiMXYjVfCa3Ika5fxZSIqoq+ZKfxv+hhLI+aIU94qVk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JjgIAVXA2vGkDwZw1iL8gwCrvgiV/kNTkeSLrpdO9bv/yjfd+aFw7C8imur6MO1X6 8mFJ9GICEPq1BJVYZAmbgN6dtR5lVnF11VM7mTzh/EtU2Wc0KD+awYqUqNIkdLm05V cKLx7cT4yYDubEgogwRnOyWi8EsyHSoz5JrPBYZZIRZSsPemeOe4KcAAb9OYXAu43M +ofQNg3N3vvDT9Nsld5bb4H9FVitvtmoFMWLw7D4toLByBvtzcRQtxBI42RPqTspl4 RROK3IujT39Dq4bArWg4GCQHmRUWaAJTay0VseSCJI5OspK0ch+kHYxBp8NGVgbZ7/ 0aBLdXAM4LOcQ==
To: Vincent Roca <vincent.roca@inria.fr>
Cc: kazuhisa matsuzono <matsuzono@nict.go.jp>, asaeda@nict.go.jp, cedric.westphal@huawei.com, icnrg <icnrg@irtf.org>, nwcrg <nwcrg@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 <kazuhisa@sfc.wide.ad.jp>
Message-ID: <7d9aa2ea-8067-f15d-6fdc-9980637225df@sfc.wide.ad.jp>
Date: Mon, 2 Mar 2020 14:45:39 +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: <882B9F95-ED00-49DE-A55E-4D6409646D68@inria.fr>
Content-Type: multipart/alternative; boundary="------------D89A112D0806706ECEDCE604"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/o-nuJT8gepq1Y2j3QGV8S1MhANQ>
Subject: Re: [nwcrg] [icnrg] Review of draft-irtf-nwcrg-nwc-ccn-reqs
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 05:45:51 -0000

Dear, Vincent,  NWCRG and ICNRG team,

We’ve updated and uploaded our NWC-for-ICN draft.
It addresses the comments received so far (thanks, Dave-san and Vera-san).
Sorry for my late response.

Name: draft-irtf-nwcrg-nwc-ccn-reqs
Revision: 03
URL: 
https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-nwc-ccn-reqs-03.txt
Status: https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/
Htmlized: https://tools.ietf.org/html/draft-irtf-nwcrg-nwc-ccn-reqs-03
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-nwc-ccn-reqs
Diff: https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-nwc-ccn-reqs-03

Regards,
Kazuhisa.

On 2020/02/19 0: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
>
>
> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg