Subject: [icnrg] Comments on draft-jhong-icnrg-nrs-requirements-00

From: Konstantinos Katsaros <[email-masked]>
Date: Mon, 19 Jun 2017 11:08:33 +0300

Hi,

I had a look at draft-jhong-icnrg-nrs-requirements-00.txt.

As I high level comment, I think more work is needed to better structure 
and position this material. Some overlaps are there,  the content of 
some sections does not fit the selected titles (and implied context) 
well, while in some cases sub-sections are not on the same level of 
detail e.g., Section 4.1.8 vs 4.2.1. Language can also be improved.

Please find some more detailed comments below.

Kind regards,
Konstantinos (Dinos) Katsaros

Section 1

- The text is somehow unclear when introducing "name resolution", " 
content request routing" and "content delivery" as three typical ICN 
"routing" steps ("ICN routing generally involves three steps:"). As 
already explained in the text, name resolution can be actually part of 
"content request routing". In such cases the definition of name 
resolution in the introduction is not valid. Perhaps a way to address 
this would be to introduce name resolution as a function that yields 
information to be used for forwarding (another function); whether this 
information is a node (output) interface, a Bloom filter or a network 
locator is something orthogonal. In general, I think the text could 
improve with a clearer separation of functions; perhaps by first not 
explicitly referring to "routing" steps.

- IMO the document should first introduce basic operations that need to 
take place in the two identified modes of name resolution / name based 
routing, before getting into the comparison. One of the first functional 
requirements is to collect and then place the name resolution(/routing) 
state. This comes before a discussion on updating the state or making 
reference to an overlay or flooding. I would not engage in this 
discussion in the introduction, but would rather only set the context 
e.g., properly define name resolution.

Section 3

- I would reduce overlap between the introduction and Section 3.1.

- The contribution of Section 3.3 to the document is a bit unclear to 
me. First, being strict :), ICN features "mobility support", not 
"mobility". Then,  I also do not understand what "namespace expansion 
into the routing/forwarding" refers to.

- References are missing e.g., to DONA (Page 5).

- Since CCN/NDN is not introduced, I would avoid references to CCN/NDN 
terminology e.g., "interest" on page 6. Can be replaced by "request".

Section 4

- It would be good, for completeness reasons at least, to support the 
scalability requirement with some figures/numbers. References to "large" 
number of contents or "frequently"  generated "small" packets is not 
informative enough to assess this requirement. Perhaps a few references 
could also help in this direction.

- Similarly, how low should the latency be? In the order of e.g., the 
current DNS resolution latencies? Lower/higher? Depends on the service 
supported? Regarding latency, getting to the (topologically) closest 
copy of some content does not guarantee ("ensure") low latency as other 
aspects are also important e.g., congestion on the path, load on the 
node serving the content, etc.

- There are noticeable differences across requirements, regarding the 
level of detail/depth of discussion e.g., 4.2.1 vs 4.1.8 or 4.2.3. Some 
more analysis would help e.g., what does deployability exactly stand for 
in this context, and what does "from the edges" practically mean? How is 
this related to name based routing approaches? Similarly, 4.3.4 on 
Privacy just says we need privacy; what are the threats we need to 
prepare for, what sort of information leaking, happening where/how?

Section 5

- I think the section should be re-positioned as what it describes is 
not exactly use-cases but rather features/aspects that affect the NRD 
design, along with existing NRS designs e.g., PURSUIT RENE, 
MobilityFirst. IMO, issues such as namespace structure and mobility, 
should be discussed earlier in the document, wrt their relation to name 
resolution.

- Then, if it is to discuss the SoA, the text should go beyond the mere, 
very high level description of existing approaches and try to identify 
key features and differences, as well as to discuss how existing 
approaches deal with requirements. I think this will work better if SoA 
is discussed in one place.

Section 8

- I do not exactly agree with the definition of NRS given (see also 
previous comment). As I see it, NRS takes you from the information name 
space to the forwarding domain. This can also lead to cached content, in 
which case name resolution does not help a client to actually reach 
a/the producer. In some environments we may even not want to reach the 
producer e.g., IoT environemts, for energy saving reasons.

Other comments

- I think it would be usefull to try to explicitly assess the importance 
of each requirement. How critical is it for example to minimize 
inter-domain traffic or to achieve low latency, how do these 
requirements' importance compare? Also, do we need a "one size fits all" 
NRS?

- Language and tone can be improved at some points e.g.,

"ICN also has been emerged" -> "ICN also has emerged",
"as the most promising technology" -> "as a promising technology",
"Requirements on security are things",
Beginning of Section 5.2

---

From: 홍정하 <[email-masked]>
Date: Tue, 20 Jun 2017 08:31:11 +0000

Dear Konstantinos (Dinos) Katsaros,

Thank you very much for reviewing the NRS requirements draft.
We are going to revise the draft according to the discussion made 
at the last meeting in Chicago. The revised one will be submitted 
before the Prague meeting. 
We will try to reflect your valuable comments.

Please see my replies in line [JH]. 

Thanks,
Jungha Hong

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Konstantinos Katsaros
Sent: Monday, June 19, 2017 5:09 PM
To: [email-masked]
Subject: [icnrg] Comments on draft-jhong-icnrg-nrs-requirements-00

Hi,

Kind regards,

Section 1

[JH]: This is a good point and I agree with you. Actually, there was a 
consensus on name resolution as a function in the Chicago meeting. 

Section 3

[JH]: According to revising the Introduction section, section 3 will be 
also revised.

[JH]: We will take care of the overlap.

[JH]: In Section 3.3, we meant that ICN has challenge to support the 
dynamism features and NRS can help it. We will make the Section 3.3 
clearer. 

[JH]: We will take care of it.

[JH]: We will take care of it.

Section 4

[JH]: I agree with you about all your comments on Section 4. Will take care of them.

Section 5

[JH]: The purpose of this document is to provide the motivation as 
well as the requirements. Section 5, use cases was actually related to the 
motivation (not to the requirements). So, we may try to re-position 
this section.

[JH]: Namespace structure and mobility issues were discussed in Section 3.2 
and 3.3, respectively. We will reflect your comments to those sections.

[JH]: This is a good point. We need some discussion among authors on how to 
deal with this comment.

Section 8

[JH]: I agree with you. Will take care of it.

Other comments

[JH]: We will try to consider this comment.

[JH]: OK. Will take care of it.

_______________________________________________
icnrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/icnrg