Subject: [icnrg] B-NRS adoption as a RG work item

From: 홍정하 <[email-masked]>
Date: Tue, 10 Nov 2015 05:51:05 +0000

Dear all,

We presented the updated bloom filter based flat name resolution system (B-NRS) for ICN at IETF-94 last week and proposed it for adoption as a RG work item.

NRS is required for lookup-by-name scheme in ICN. Especially when flat name is assumed, NRS is quite necessary.
NRS is also stated as one of the ICN challenges for IoT.
So, we think that NRS is suitable for a RG work item and our draft on B-NRS for ICN is mature enough for adoption as a RG work item.

We would like to get some feedback from communities on adopting this document (or general NRS) as a RG work item by the mailing list.
Please show your interests of working on it.
Also, we would welcome any comments or contribution at any time.

Thanks,
Jungha Hong

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 10 Nov 2015 06:08:42 -0500

Since there was some discussion on the list about name resolution as well as another draft from City U/Huawei maybe the topic is interesting for the group? But do we need 2 drafts or should they be combined?

Marie-José
> On Nov 10, 2015, at 12:51 AM, 홍정하 <[email-masked]> wrote:
> 
> Dear all,
>  
> <draft-hong-icnrg-bloomfilterbased-name-resolution-05.pdf>_______________________________________________
> icnrg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>

---

From: <[email-masked]>
Date: Tue, 10 Nov 2015 16:43:25 +0000

While functionally the Huawei and B-NRS proposals are very different, perhaps there could be distilled an NRS requirements or overview draft that we could then compare each of Huawei and B-NRS against.  The requirements draft would discuss, architecturally, why one needs NRS and what services it should provide without going in to details about how it works.  Hopefully, this requirements draft would come largely from the existing motivational material in B-NRS and Huawei drafts.

B-NRS is explicitly a flat-name resolver and the Huawei protocol works on hierarchical names.  I think that’s something that should be talked about in the requirements document.  Is the job of an NRS to resolve only flat names?  Would B-NRS be restricted to ICN’s that only use flat names?

If B-NRS and Huawei’s NRS apply to different namespaces (flat vs hierarchical), then I don’t see how we could merge them.

Marc

On Nov 10, 2015, at 3:08 AM, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

Marie-José
On Nov 10, 2015, at 12:51 AM, 홍정하 <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Thanks,
Jungha Hong
<draft-hong-icnrg-bloomfilterbased-name-resolution-05.pdf>_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

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

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 10 Nov 2015 11:55:05 -0500

I think the idea of the requirement draft is a good idea. 

> On Nov 10, 2015, at 11:43 AM, <[email-masked]> <[email-masked]> wrote:
> 
>> On Nov 10, 2015, at 3:08 AM, Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Nov 10, 2015, at 12:51 AM, 홍정하 <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Dear all,
>>>

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 10 Nov 2015 17:08:38 +0000

Hi,

so, what I think could be useful is to figure out whether there are common invariants, independent of the particular approach, that are important enough to document.

For that, probably an architecture discussion about how NRS would fit into our current ICN models would be good to have. This should be backed up by people’s use cases and requirements.

In the spirit of our IETF-Sunday Interim, how about to plan for having a dedicated discussion among interested partners in the near/mid term? This could be done at the next interim, but also earlier, e.g., on an online call.

Without precluding anything, one of the questions could be whether it makes sense for us to describe potential interfaces to NRSs, independent on the type of names they resolve.

Best regards,
Dirk

From: icnrg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Dienstag, 10. November 2015 17:43
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Marc

Marie-José

Dear all,

Thanks,
Jungha Hong

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 10 Nov 2015 18:33:36 +0000

Instead of focusing on a specific NRS design, it is important to provide the feature in the protocol to carry locator names explicitly. The mapping itself can be handled many ways, specifically with CCN, as we are dealing with aggregateable and semantic names, these can be SDN driven or follow decentralized name resolution systems, this shall open area for further exploration.

Regards,
Ravi

Sent: Tuesday, November 10, 2015 8:43 AM

Marc

Marie-José

Dear all,

Thanks,
Jungha Hong

---

From: David Oran <[email-masked]>
Date: Tue, 10 Nov 2015 14:53:14 -0500

<Chair hat off>
I’m not enthusiastic about ICNRG taking up work on an explicit Name Resolution Service until it’s demonstrated we need one. So far, I am of the view that the case has not been made. It substantially complicates any ICN architecture, especially from a security perspective, as you now have two domains of values to secure plus securing the function mapping between them. You also have the tricky architecture decision about whether the mappings are invertible. In the IP world, being unclear about this caused a number of really horrible hacks like in-addr.arpa.

In the same vein, I am also rather allergic to enshrining any static architectural properties to names versus identifiers versus locators, and in fact would rather we didn’t use the terms “identifier” or “locator” to infer anything other than a role a name plays as opposed to either a separate domain of values from a name, or any syntactically visible way to tell the difference.

I would also like to defer a decision on the Bloom Filter work to give the proponents a chance to respond to the results in the ICN 2015 paper http://conferences.sigcomm.org/acm-icn/2015/proceedings/p39-katsaros.pdf. The way I read the results, it seems no matter how you set the Bloom filter parameters, they are going to be wrong for all but a very carefully traffic engineered matrix and specific known interdomain topology. If true, the theoretical advantages of Bloom filters for name-based routing are not going to be realized in practice.

<reminder: this was with chair hat off>

DaveO.

> On Nov 10, 2015, at 1:33 PM, Ravi Ravindran <[email-masked]> wrote:
> 
> On Nov 10, 2015, at 3:08 AM, Marie-Jose Montpetit <[email-masked]> wrote:
>  
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 11 Nov 2015 01:00:08 +0000

Agree that we need to make the case for NRS and consider the mentioned problems.

That plus a discussion with corresponding results on how such work could be framed (invariants, interfaces vs. specific NRS systems/mechanisms) should be done before we decide on further steps in the RG.

Having said that, if a group of folks want to kick this discussion and analysis, that would IMO be useful.

Side note: we also only have the intuition about how non-NRS routing would work -- there is just as much work and open questions there.

But in general, an ICN research group should be the right place to study all of this (without premature enshrinement...).

Best regards,
Dirk

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of David Oran
Sent: Dienstag, 10. November 2015 20:53
To: Ravi Ravindran
Cc: Marie-Jose Montpetit; [email-masked]; [email-masked]; Mark Mosko
Subject: Re: [icnrg] B-NRS adoption as a RG work item

<Chair hat off>

DaveO.

---

From: 홍정하 <[email-masked]>
Date: Wed, 11 Nov 2015 08:34:24 +0000

Thanks for all comments.

I agree that for now it would be better to have the NRS requirements documented than to have a specific NRS mechanism.
So, I would like to have a dedicated discussion on what would be on the document if it is decided to be documented.
We can keep this discussion through the mailing list and continue to the next meeting.
Please give me any comments or suggestions on it.

BTW, in B-NRS, basically a flat name is assumed and the bloom filter is used to find the server where the information of a given flat name is stored. B-NRS can be also applied with a hierarchical name if the hierarchical name is stored in a server independent of the name hierarchy. However, any NRS mechanism assuming a hierarchical name where the hierarchy is used in a certain way in the NRS cannot be applied with a flat name.

I don’t think that there is a way for a flat name to be routed without NRS. NRS is to provide a routing hints for a given name whether it is flat or hierarchical. In B-NRS, we defined the routing hint as a locator. Once you get the routing hint, interest packet can be forwarded.
I know that there are a lot of works on non-NRS routing but they all assume a hierarchical name.
So, NRS is a requirement especially for flat names. Do we need to demonstrate more why NRS is needed? Is there any way of non-NRS routing with flat names?

Thanks,
Jungha Hong

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Wednesday, November 11, 2015 10:00 AM
To: David Oran <[email-masked]>; Ravi Ravindran <[email-masked]>
Cc: Marie-Jose Montpetit <[email-masked]>; [email-masked]; Mark Mosko <[email-masked]>; 홍정하 <[email-masked]>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Best regards,
Dirk

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of David Oran
Sent: Dienstag, 10. November 2015 20:53
To: Ravi Ravindran
Cc: Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mark Mosko
Subject: Re: [icnrg] B-NRS adoption as a RG work item

<Chair hat off>

DaveO.

> On Nov 10, 2015, at 1:33 PM, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:
>
> From: icnrg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Börje Ohlman <[email-masked]>
Date: Wed, 11 Nov 2015 10:17:26 +0000

HI All,

Good discussion.

First, with <chair hat off>,
I think it is a very good idea to write a requirements and use case draft for the role of an NRS in ICN. What roles it can play for hierarchical vs. flat names. How it can be used to support publisher mobility, network mobility and possibly interworking with legacy networking. It should also pay special attention to security implications of allowing for indirection in the routing system.

Second, with <chair hat on>,
I see no reason why ICNRG should not work on such a requirements draft for NRS. While we do that I suggest that specific implementation proposals stay as individual drafts until the requirements draft is done and/or the group decides otherwise.

Börje

On 11 nov 2015, at 09:34, 홍정하 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for all comments.

Thanks,
Jungha Hong

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Wednesday, November 11, 2015 10:00 AM
To: David Oran <[email-masked]<mailto:[email-masked]>>; Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Cc: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mark Mosko <[email-masked]<mailto:[email-masked]>>; 홍정하 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Best regards,
Dirk

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of David Oran
Sent: Dienstag, 10. November 2015 20:53
To: Ravi Ravindran
Cc: Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mark Mosko
Subject: Re: [icnrg] B-NRS adoption as a RG work item

<Chair hat off>

DaveO.

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 11 Nov 2015 15:03:36 -0500

Then I would suggest that the requirements are not done by any team pushing for a solution.

Marie-Jose
> On Nov 11, 2015, at 5:17 AM, Börje Ohlman <[email-masked]> wrote:
> 
> HI All,
> 
> Good discussion.
> 
>> On 11 nov 2015, at 09:34, 홍정하 <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Thanks for all comments.
>>  
>> From: icnrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Dirk Kutscher
>> To: David Oran <[email-masked] <mailto:[email-masked]>>; Ravi Ravindran <[email-masked] <mailto:[email-masked]>>
>> Cc: Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Mark Mosko <[email-masked] <mailto:[email-masked]>>; 홍정하 <[email-masked] <mailto:[email-masked]>>
>> From: icnrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of David Oran
>> Cc: Marie-Jose Montpetit; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Mark Mosko
>> I would also like to defer a decision on the Bloom Filter work to give the proponents a chance to respond to the results in the ICN 2015 paper http://conferences.sigcomm.org/acm-icn/2015/proceedings/p39-katsaros.pdf <http://conferences.sigcomm.org/acm-icn/2015/proceedings/p39-katsaros.pdf>. The way I read the results, it seems no matter how you set the Bloom filter parameters, they are going to be wrong for all but a very carefully traffic engineered matrix and specific known interdomain topology. If true, the theoretical advantages of Bloom filters for name-based routing are not going to be realized in practice.
>>  
>> > On Nov 10, 2015, at 1:33 PM, Ravi Ravindran <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > From: icnrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
>> > To: [email-masked] <mailto:[email-masked]>
>> > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: 홍정하 <[email-masked]>
Date: Thu, 12 Nov 2015 07:55:14 +0000

Sure, we will keep our solution as an individual draft and see how ICNRG is driven.

Now then, could you show me your interests of writing a requirements draft for NRS?
I would like to initiate it and certainly, I would be happy to work with any of you who are interested in writing it.
Also, any comments or suggestions on the NRS requirements are welcomed at any time.
I would like to get some feedback especially from those of you who need NRS in their own drafts/solutions.

Thanks,
Jungha Hong

From: Marie-Jose Montpetit [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 5:04 AM
To: Börje Ohlman <[email-masked]>
Cc: 홍정하 <[email-masked]>; Dirk Kutscher <[email-masked]>; David R Oran <[email-masked]>; Ravi Ravindran <[email-masked]>; icnrg <[email-masked]>; Marc Mosko <[email-masked]>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Marie-Jose
On Nov 11, 2015, at 5:17 AM, Börje Ohlman <[email-masked]<mailto:[email-masked]>> wrote:

HI All,

Good discussion.

Börje

Thanks for all comments.

Thanks,
Jungha Hong

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Wednesday, November 11, 2015 10:00 AM
To: David Oran <[email-masked]<mailto:[email-masked]>>; Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Cc: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mark Mosko <[email-masked]<mailto:[email-masked]>>; 홍정하 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Best regards,
Dirk

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of David Oran
Sent: Dienstag, 10. November 2015 20:53
To: Ravi Ravindran
Cc: Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mark Mosko
Subject: Re: [icnrg] B-NRS adoption as a RG work item

<Chair hat off>

DaveO.

---

From: 홍정하 <[email-masked]>
Date: Fri, 13 Nov 2015 05:12:04 +0000

Thanks for your interest in contributing to a requirements draft for NRS?
Besides you, I have gotten a couple of contacts more in person.
I appreciate all of your supports and interests in working on it.
I will try to contact you shortly (who have shown their interests to me) regarding on how to start/work/discuss together.

Again, thanks for all your supports.
I believe that this work will be good for ICNRG.

Jungha Hong

From: Chai, Wei Koong [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 6:45 PM
To: 홍정하 <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; Börje Ohlman <[email-masked]>
Cc: Ravi Ravindran <[email-masked]>; icnrg <[email-masked]>; David R Oran <[email-masked]>; Marc Mosko <[email-masked]>; Dirk Kutscher <[email-masked]>; Katsaros, Konstantinos <[email-masked]>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Hi Jungha and all,

As we have already done a feasibility study in this topic (see http://conferences2.sigcomm.org/acm-icn/2015/proceedings/p39-katsaros.pdf), we would like to express our interest in contributing to such requirements draft for NRS.

Thank you.

best regards,

-Wei & Konstantinos (Dinos)

**************************************************
Dr. Wei Koong CHAI
Department of Electronic & Electrical Engineering,
University College London,
37 Fitzroy Square
London W1T 6EY
http://www.ee.ucl.ac.uk/~wchai/
**************************************************

________________________________
From: icnrg <[email-masked]<mailto:[email-masked]>> on behalf of 홍정하 <[email-masked]<mailto:[email-masked]>>
Sent: 12 November 2015 07:55
To: Marie-Jose Montpetit; Börje Ohlman
Cc: Ravi Ravindran; icnrg; David R Oran; Marc Mosko; Dirk Kutscher
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Thanks,

Jungha Hong

From: Marie-Jose Montpetit [mailto:[email-masked]]
Sent: Thursday, November 12, 2015 5:04 AM
To: Börje Ohlman <[email-masked]<mailto:[email-masked]>>
Cc: 홍정하 <[email-masked]<mailto:[email-masked]>>; Dirk Kutscher <[email-masked]<mailto:[email-masked]>>; David R Oran <[email-masked]<mailto:[email-masked]>>; Ravi Ravindran <[email-masked]<mailto:[email-masked]>>; icnrg <[email-masked]<mailto:[email-masked]>>; Marc Mosko <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Marie-Jose

HI All,

Good discussion.

Börje

Thanks for all comments.

Thanks,

Jungha Hong

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Wednesday, November 11, 2015 10:00 AM
To: David Oran <[email-masked]<mailto:[email-masked]>>; Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Cc: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mark Mosko <[email-masked]<mailto:[email-masked]>>; 홍정하 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] B-NRS adoption as a RG work item

Best regards,

Dirk

-----Original Message-----

To: Ravi Ravindran

<Chair hat off>

DaveO.

icnrg mailing list

icnrg mailing list