Re: [nwcrg] I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-01.txt

Cedric Westphal <Cedric.Westphal@huawei.com> Thu, 04 April 2019 18:31 UTC

Return-Path: <Cedric.Westphal@huawei.com>
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 3FDA3120135 for <nwcrg@ietfa.amsl.com>; Thu, 4 Apr 2019 11:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0ocMnuyBEpn1 for <nwcrg@ietfa.amsl.com>; Thu, 4 Apr 2019 11:31:30 -0700 (PDT)
Received: from huawei.com (dfwrgout.huawei.com [206.16.17.72]) (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 9C663120134 for <nwcrg@irtf.org>; Thu, 4 Apr 2019 11:31:30 -0700 (PDT)
Received: from dfweml701-cah.china.huawei.com (unknown [172.18.9.222]) by Forcepoint Email with ESMTP id 24CA411017A28; Thu, 4 Apr 2019 13:31:28 -0500 (CDT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by dfweml701-cah.china.huawei.com (10.193.5.175) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Apr 2019 11:31:28 -0700
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.52]) by SJCEML701-CHM.china.huawei.com ([169.254.3.61]) with mapi id 14.03.0439.000; Thu, 4 Apr 2019 11:31:27 -0700
From: Cedric Westphal <Cedric.Westphal@huawei.com>
To: Cedric Adjih <cedric.adjih@inria.fr>, kazuhisa matsuzono <kazuhisa@sfc.wide.ad.jp>
CC: nwcrg <nwcrg@irtf.org>
Thread-Topic: I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-01.txt
Thread-Index: AQHU5PX8vacORxGoIUexqCsl43wavaYsWjag
Date: Thu, 4 Apr 2019 18:31:27 +0000
Message-ID: <369480A01F73974DAC423D05A977B4F23103F6A7@sjceml521-mbs.china.huawei.com>
References: <155234405845.23054.9002975309364086619@ietfa.amsl.com> <37f72b89-6c62-39f8-6ef8-c4e3f3796603@sfc.wide.ad.jp> <342052133.7458618.1553729801094.JavaMail.zimbra@inria.fr>
In-Reply-To: <342052133.7458618.1553729801094.JavaMail.zimbra@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.209.216.168]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/ghvvSPjV2s5jSUw5XMCZwC0Fvlo>
Subject: Re: [nwcrg] I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-01.txt
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: Thu, 04 Apr 2019 18:31:34 -0000

Hi Cedric,

I haven't seen a response to your email yet. I'm going to take a stab at it!
Comments below, starting with [cw]...


-----Original Message-----
From: nwcrg [mailto:nwcrg-bounces@irtf.org] On Behalf Of Cedric Adjih
Sent: Wednesday, March 27, 2019 4:37 PM
To: kazuhisa matsuzono
Cc: nwcrg
Subject: Re: [nwcrg] Fwd: I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-01.txt

  Hello Kazuhisa, hello all,

Thank you for the updated version of the draft. 

* We are a group of people (with H. Malik, M. Kieffer, C. Weidman) working on the topic, and so my/our first comment is that the document effectively achieves its goals of identifying challenges and choices needed/available in applying NC to ICN, and is very useful and informative. Also it is in good shape.

[cw]: thank you!

Then to possibly improve it, I would have suggestions below:

* The most general one is the one the division between requirements and challenges.

Maybe some of the discussion occurring in Requirements can be mirrored to "5. Challenges", if it is possible to do so without duplicating. 
For instance: discussions related to naming, or to ensuring efficient distributed network coding operation (get linearly independent content). 
I believe there are still unsolved challenges in this area.
Also I believe that the recurrent questions of interest forwarding strategies, and of filling the FIBs are a challenge, even more so with network coding, when trying to obtain gains through multipath.

[cw]: would it be possible to point out other instances? Do you want to take a stab at this split?

* Some more comments prefixed by "[CA]" below, with draft extracts prefixed the line numbers (obtained by "cat -n <the draft>"), mostly clarifications:

   264	   an "interest" message, that carries the name of the data.  On
   265	   difference to note here in CCN and NDN is that in later versions of
   266	   CCN, the interest must carry a full name, while in NDN it may carry a
   267	   name prefix (and receive in return any data with a name matching this
   268	   prefix).
[CA] Q: should draft-irtf-icnrg-ccnxmessages-09 be considered? Maybe a reference for each protocol CCN(x) / NDN can useful? 

[cw]: good idea. References are good. I believe the CCNx draft is in last call, so maybe a reference to the RFC when it's out would be good. 

   375	4.1.  Content Naming
[CA] I wonder if it is not possible to group here all the naming considerations that appear later (4.2.2, 4.2.3), in this section (maybe with separate parts for what is differing between interest and content).

[cw]: yes, all naming considerations could be listed here. Or at the least, a pointer to the other section should be included. 


   517	   interests for coded packets as well as original packets.  Moreover,
   518	   in order to decode as necessary, nodes need to know the coding vector
   519-526 [...]
   527	   packet size.  It may be useful to use compression techniques for
   528	   coding vectors [20] [21].
[CA] this kind of discussion might be moved in the naming section

[cw]: not sure I understand here, are you saying the coding vector is a naming convention?


   533	   generate useful coded packets for consumers.  Assuming that the size
   534	   of the Finite Field in use is not relatively small, re-encoding using
   535	   enough cached packets has a strong probability of making independent
   536	   coded packets [24].  If router does not have enough cached packets to
[CA] Notice the issue of linearly independent content is more complicated, if content reach one same consumer from different paths. Maybe this should be in challenges (as well?).

[cw]: you're right, it is definitely not solved!


   359	   However, it requires a fully adjustable and specific name-based
   360	   routing mechanism for CCN/NDN, and an intense computational task for
   361	   central coordination.  In the case of non-coherent NC that often
   362	   utilizes RLC, it is not required to know either network topology nor
   363	   intermediate coding operations [25].  Since non-coherent NC works in
   364	   a completely independent and decentralized manner, this approach is
   365	   more feasible especially in the large scale use cases that are
   366	   intended with CCN/NDN.  This document thus focuses on non-coherent NC
   367	   with RLC.
[CA] Maybe the difference can go beyond the binary split between "coherent" and "non-coherent", e.g. you can operate network coding in the ideal version as in [24], or with more or less control/knowledge/determinism in the network. 

[cw]: Maybe you can specify how this would be reflected in the text?


   586	   additional NC operations need after receiving interests.  According
   587	   to application requirement for latency, such NC operation strategy
   588	   should be considered.
[CA] In this discussion, is it assumed that the routers don't recode?

[cw]: first, I would suggest changing the first sentence of this paragraph to: "The procedure for splitting an overall content into small content objects is the responsibility of the original publisher." You are right that in this case, it is assumed the encoding is e2e, with no re-encoding at the intermediate router. This allows for, say, signature on the packets that can be verified throughout. However, if you feel that it is a wrong assumption, please feel free to suggest how to deal with it!

   596	   alongside regular network operations.  A network coding framework
   597	   should be compatible with a regular framework, so as to allow
   598	   backward compatibility and smooth migration from one framework to the
   599	   other.
[CA] "should" -> is backward compatibility a requirement or a design goal?

[cw]: to me, it is a requirement. What are you thinking?

   679	   on either interface.  From this point of view, an effective interest
   680	   forwarding strategy with a rate adaptation mechanism should be
[CA] rate adaptation is useful here, but maybe it is not directly linked to mobility scenarios, but in most ICN scenario?

[cw]: you are right, we can remove the "rate adaptation" comment here, since the subsection pertains to seamless mobility. The mention of rate adaptation stemmed from the fact that the multiple paths that the network coded packets follow (dynamically) add up to create a logical link and that rate adaption should be performed on the aggregate capacity of this link. Maybe it can be split up somewhere else.

   636	   attacks.  Without having all the packets in a generation, the cache
   637	   cannot decode the packets to check if it is authenticated.  Caching
[CA] this is security consideration additional to the line 436-439 -> maybe refer to the security section at the end

[cw]: good point. 

* at "**", maybe check the wording below:

   128	   NC **aggregates multiple packets with parts of the same content
[CA] "aggregates" -> ambiguity with concatenation, maybe "mixes multiple packets together"

[cw]: this paragraph explicitly assumes in-network recoding... You are right, your suggestion is clearer.

   131	   specific server, as they may have **evolved within the network.  Since
[CA] "evolved" -> "been mixed" or "progressed"?

[cw]: yes, evolved is a bit too fuzzy. "been mixed" is better. 

   298	   requester(s) using the trail of PIT entries; intermediate **node remove
[CA] "intermediate nodes"

[cw]: yes.

   316	3.  **Advantage given by NC and CCN/NDN
[CA] "Advantages provided"?

[cw]: yes. 

   331	   CCN/NDN itself, however, **cannot provide reliable and robust content
[CA] "does not, by default,"?

[cw]: yes.

   332	   dissemination.  This requires some specific CCN/NDN transport (i.e.,

[cw]: no comment here?

   465	   It should be discussed whether the network can **update data packets
[CA] "update" -> "modify"/"mix" ?

[cw]: recode?

   572	   **The procedure for splitting an overall content into small content
   573	   objects **is responsible for the original publisher.  When applying N

[cw]: see above. 

   651	   In this context, network coding **provide a mechanism to ensure that


[cw]: provides...

   660	   This naturally applies to mobility **event, where the consumer may

[cw]: events...

[cw]: Thanks!

[cw]: C. 


best regards,
-- Cedric

----- Mail original -----
> De: "kazuhisa matsuzono" <kazuhisa@sfc.wide.ad.jp>
> À: "nwcrg" <nwcrg@irtf.org>
> Envoyé: Mardi 12 Mars 2019 00:42:48
> Objet: [nwcrg] Fwd:  I-D Action: draft-irtf-nwcrg-nwc-ccn-reqs-01.txt

> Dear all,
> 
> We have updated this draft especially regarding Sec. 5.3 security, and
> made some minor changes throughout.
> Any comments to this updated draft are very welcome.
> 
> Thank you.
> Kazuhisa
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Coding for efficient NetWork
> Communications Research Group RG of the IRTF.
> 
> Title : Network Coding for Content-Centric Networking / Named Data
> Networking: Requirements and Challenges
> Authors : Kazuhisa Matsuzono
> Hitoshi Asaeda
> Cedric Westphal
> Filename : draft-irtf-nwcrg-nwc-ccn-reqs-01.txt
> Pages : 19
> Date : 2019-03-11
> 
> Abstract:
> This document describes the current research outcomes regarding
> Network Coding (NC) for Content-Centric Networking (CCN) / Named Data
> Networking (NDN), and clarifies the requirements and challenges for
> applying NC into CCN/NDN.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-nwcrg-nwc-ccn-reqs-01
> https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-nwc-ccn-reqs-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-nwc-ccn-reqs-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> 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

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