Return-Path: 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 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 Cc: kazuhisa matsuzono , asaeda@nict.go.jp, cedric.westphal@huawei.com, icnrg , nwcrg 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 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: Subject: Re: [icnrg] [nwcrg] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 05:45:51 -0000 This is a multi-part message in MIME format. --------------D89A112D0806706ECEDCE604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> > > 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 >>> 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 >>> 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 >> https://www.irtf.org/mailman/listinfo/nwcrg > > > _______________________________________________ > nwcrg mailing list > nwcrg@irtf.org > https://www.irtf.org/mailman/listinfo/nwcrg --------------D89A112D0806706ECEDCE604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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> 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.


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
https://www.irtf.org/mailman/listinfo/nwcrg


_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg

--------------D89A112D0806706ECEDCE604--