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

[Cedric Adjih <[e-mail]>]

  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.

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.

* 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? 


   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).


   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


   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?).


   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. 


   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?


   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?


   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?

   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


* 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"

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

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

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

   331	   CCN/NDN itself, however, **cannot provide reliable and robust content
[CA] "does not, by default,"?
   332	   dissemination.  This requires some specific CCN/NDN transport (i.e.,

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

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

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

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


best regards,
-- Cedric

----- Mail original -----
> De: "kazuhisa matsuzono" <[e-mail]>
> À: "nwcrg" <[e-mail]>
> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg
> 
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg