Subject: Re: [icnrg] ICNRG next steps

From: [email-masked]
Date: Tue, 10 Jul 2012 16:13:15 +0800

We have submitted a draft about ICN deployment considerations and ICN 
design for ISP's existing networks. It can be access at 
http://tools.ietf.org/html/draft-li-icnrg-icn-isp-00. Comments are 
welcome.
We'd like to ask for a time slot to present this draft. Thank you!

BR
Lichun

[email-masked] 写于 2012-06-08 16:21:40:

> I have now remodeled the ICNRG Wiki to help us in our continued work
> in the ICNRG, please see
> http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
> This page is intended to be a dynamic page where everyone is offered
> to contribute. So this page is a complement to the official homepage
> of the RG, http://irtf.org/icnrg.
> 
> We are planning to have the first official ICNRG @ IETF 84, 
> Vancouver, Canada, July 29-August 3, 2012. It is time that we start 
> to plan for what we would like to have on the agenda at that 
> meeting. We should devote some time to discuss how to best organize 
> our work and form some groups that can address the work items that 
> we choose to focus on. We also like to see some good technical 
> presentations. It is probably a good idea to try to focus those 
> around a specific topic to enable a good discussion. Proposals for 
> work items, topics for technical presentations as well as specific 
> proposals for presentations are welcome. Proposals can be send to 
> this list and/or be entered to the Wiki.
> 
> Börje
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Ashok Narayanan <[email-masked]>
Date: Tue, 24 Jul 2012 17:45:49 -0400

Hi folks,

Sorry for the late notice. The draft proposed below on BGP is uploaded to the wiki.

http://trac.tools.ietf.org/group/irtf/trac/attachment/wiki/icnrg/draft-narayanan-icnrg-bgp-uri-00.txt

-Ashok

On Jun 25, 2012, at 6/25 10:25 AM, Ashok Narayanan wrote:

> Hi Borje, all,
> 
> We'd like to start the discussion on routing protocol formats (BGP, OSPF) for carrying NDN routes. Of interest would be schemes that can carry URI-type routes which are usable by both NDN and other CDN-style architectures. At this point, defining a straw man scheme would give the community a place to build around. To start this, we would like a slot at Vancouver to present proposed BGP extensions for carrying content URI routes, which are for both NDN and other ICN/CDN schemes that are URI based. We will submit an associated draft (-00) with this.
> 
> Thanks
> -Ashok, Stefano and Brian
> 
> On Jun 8, 2012, at 6/8 4:21 AM, Börje Ohlman wrote:
> 
>> I have now remodeled the ICNRG Wiki to help us in our continued work in the ICNRG, please see
>> This page is intended to be a dynamic page where everyone is offered to contribute. So this page is a complement to the official homepage of the RG, http://irtf.org/icnrg.
>> 
>> We are planning to have the first official ICNRG @ IETF 84, Vancouver, Canada, July 29-August 3, 2012. It is time that we start to plan for what we would like to have on the agenda at that meeting. We should devote some time to discuss how to best organize our work and form some groups that can address the work items that we choose to focus on. We also like to see some good technical presentations. It is probably a good idea to try to focus those around a specific topic to enable a good discussion. Proposals for work items, topics for technical presentations as well as specific proposals for presentations are welcome. Proposals can be send to this list and/or be entered to the Wiki.
>> 
>> 	Börje
>>

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 25 Jul 2012 08:59:00 +0000

Hi Ashok,

thanks for sharing this -- good material for a discussion!

A few comments and first questions:

The draft is not yet submitted, right? In case you want to do this, please fix the following

	- s/ICNRG WG/Network Working Group/ in the first line in the boilerplate (page 1)
	- s/IRTF ICNRG working group/IRTF ICN research group/ in the first line in the intro (page 3)
	- section 4.2, paragraph starting with "A BGP speaker": last sentence ends a bit abruptly.

A comment on the intro: I think it's fair to say that most ICN approaches use names for identifying data objects (i.e., not only NDN).

A question: you mention scalability in the "Usage Scope" section. It seems like this scheme is assuming implicit aggregation (through NDN name prefixes). Assuming you have ICN names without hierarchical name structures, do you want to provide name-based routing for those, too? For example, we earlier discussed mechanisms like explicit aggregation...

Thanks,
Dirk

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ashok Narayanan
Sent: Dienstag, 24. Juli 2012 23:46
To: Börje Ohlman
Cc: [email-masked]; Stefano Previdi; Brian Field
Subject: Re: [icnrg] ICNRG next steps

Hi folks,

-Ashok

Hi Borje, all,

Thanks

	Börje

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 25 Jul 2012 10:05:32 +0100

> A comment on the intro: I think it's fair to say that most ICN approaches use names for identifying data objects (i.e., not only NDN).

DONA (the first ICN proposal) does not use names, neither does PURSUIT. I would prefer to be exact rather than fuzzy. The draft is about an approach for name-based solutions, not for ICN in general. 

Dirk

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 25 Jul 2012 12:43:25 +0100

My apologies for being incorrect myself, it is indeed hierarchical naming

Dirk

"Rimac, Ivica (Ivica)" <[email-masked]> wrote:

> I would prefer to be exact rather than fuzzy. The draft is about an
> approach for name-based solutions, not for ICN in general.

It seems to address an even more specific subgroup of solutions by assuming
and exploiting an hierarchical naming scheme (for aggregation on and BGP
announcement of name prefixes. 

-Ivica 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dirk Trossen
> Sent: Wednesday, July 25, 2012 11:06 AM
> To: Dirk Kutscher
> Cc: Ashok Narayanan; Börje Ohlman; [email-masked]; Stefano Previdi;
> Brian Field
> > A comment on the intro: I think it's fair to say that most ICN
> approaches use names for identifying data objects (i.e., not only NDN).
> 
> DONA (the first ICN proposal) does not use names, neither does PURSUIT.
> I would prefer to be exact rather than fuzzy. The draft is about an
> approach for name-based solutions, not for ICN in general.
> 
> Dirk
> 
> >
> > A question: you mention scalability in the "Usage Scope" section. It
> seems like this scheme is assuming implicit aggregation (through NDN
> name prefixes). Assuming you have ICN names without hierarchical name
> structures, do you want to provide name-based routing for those, too?
> For example, we earlier discussed mechanisms like explicit
> aggregation...
> >
> > Thanks,
> > Dirk
> >
> >
> >
> >
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Ashok Narayanan
> > We'd like to start the discussion on routing protocol formats (BGP,
> OSPF) for carrying NDN routes. Of interest would be schemes that can
> carry URI-type routes which are usable by both NDN and other CDN-style
> architectures. At this point, defining a straw man scheme would give
> the community a place to build around. To start this, we would like a
> slot at Vancouver to present proposed BGP extensions for carrying
> content URI routes, which are for both NDN and other ICN/CDN schemes
> that are URI based. We will submit an associated draft (-00) with this.
> >
> > Thanks
> to contribute. So this page is a complement to the official homepage of
> the RG, http://irtf.org/icnrg.
> >
> Vancouver, Canada, July 29-August 3, 2012. It is time that we start to
> plan for what we would like to have on the agenda at that meeting. We
> should devote some time to discuss how to best organize our work and
> form some groups that can address the work items that we choose to
> focus on. We also like to see some good technical presentations. It is
> probably a good idea to try to focus those around a specific topic to
> enable a good discussion. Proposals for work items, topics for
> technical presentations as well as specific proposals for presentations
> are welcome. Proposals can be send to this list and/or be entered to
> the Wiki.
> >
> > 	Börje
> >
> >_____________________________________________

> >_____________________________________________

> >_____________________________________________

>_____________________________________________

---

From: Ashok Narayanan <[email-masked]>
Date: Wed, 25 Jul 2012 10:41:00 -0400

Hi Dirk,

> 	- s/IRTF ICNRG working group/IRTF ICN research group/ in the first line in the intro (page 3)

Thanks, will make those changes and upload

> 	- section 4.2, paragraph starting with "A BGP speaker": last sentence ends a bit abruptly.

Oops, that looks like a typo. Sorry, that was shoddy.

> A comment on the intro: I think it's fair to say that most ICN approaches use names for identifying data objects (i.e., not only NDN).

True; will clear it up.

> 
> A question: you mention scalability in the "Usage Scope" section. It seems like this scheme is assuming implicit aggregation (through NDN name prefixes). Assuming you have ICN names without hierarchical name structures, do you want to provide name-based routing for those, too? For example, we earlier discussed mechanisms like explicit aggregation…

Yes. There was some talk on that in a previous version of this doc but I thought I would talk about it in the prezo rather than document it. Broadly, the proposal is: if there is a naming scheme that benefits from routing (and can operate with summarization) then this can fit. A good example is Bloom filter; a new namespace "ccn:bloom" can be defined where each of the routes is a Bloom filter with some well-known set of hashes, and a content name matches a route if it is in the filter. Another proposal was for a hybrid "ccn:prefix_bloom:" where there is a prefix followed by a Bloom filter, so a URI matches the route iff the prefix matches _and_ the URI is in the Bloom filter. 

If people think this is useful then I would bring this into the second version of the doc. Thoughts?

-Ashok

---

From: Ashok Narayanan <[email-masked]>
Date: Wed, 25 Jul 2012 10:44:08 -0400

> announcement of name prefixes. 

Yes, in this version of the document we are aiming at that specific target. However, there has been discussion of a (slightly) more general scheme, for naming which is not necessarily hierarchical but can still be summarized (e.g. flat names w/ routes that carry a Bloom filter; see my other email to Dirk today). The general statement in the draft that "the URN namespace/URL scheme defines the prefix matching technique" is meant to support this generalization.

-Ashok

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 25 Jul 2012 15:57:44 +0100

Ashok,

> Yes, in this version of the document we are aiming at that specific target. However, there has been discussion of a (slightly) more general scheme, for naming which is not necessarily hierarchical…

it's indeed interesting to see how a BF-based solution could work with this proposed BGP extension. I believe it could work for the inter-domain ideas that we are working on within the PURSUIT project although it is neither a prefix-matching scheme nor would one necessarily use a URN namespace (although the latter is debatable and Karen Sollins' work, presented at the ICN workshop in Helsinki, supports some very good thinking in this direction). I'm thinking of a better formulation to address the former but I'm drawing a blank here.

Dirk

---

From: "Rimac, Ivica (Ivica)" <[email-masked]>
Date: Wed, 25 Jul 2012 11:39:53 +0000

-Ivica

---

From: [email-masked]
Date: Thu, 26 Jul 2012 09:41:14 +0800

Hi Ashok,

Interesting work. I have two comments.

section 4 "Content FIB matching is done on componentized longest prefix 
match."
I think longest prefix match is wrong.
Suppose a content provider has two servers. One server (main site) stores 
all contents and publishes a route "www.example.com/", while the other 
server (mirror site) stores part of the contents and publishes a route 
"www.example.com/pics/". If a client close to the main server requests a 
file "www.example.com/pics/1.jpg", the request should be routed to the 
main server instead of the mirror server.

"6.1.  Content-URI Attributes"
As BGP for content URI controls data packet routing in an indirect way 
(via controlling interest packet routing), using MED and LOCAL_PREF to 
enforce data routing policies is different from that in original BGP. I 
think the draft may need to mention the differences.

BR
Lichun

[email-masked] 写于 2012-07-25 05:45:49:

> http://trac.tools.ietf.
org/group/irtf/trac/attachment/wiki/icnrg/draft-narayanan-icnrg-bgp-uri-00.txt
> carry URI-type routes which are usable by both NDN and other CDN-
> style architectures. At this point, defining a straw man scheme 
> would give the community a place to build around. To start this, we 
> would like a slot at Vancouver to present proposed BGP extensions 
> for carrying content URI routes, which are for both NDN and other 
> ICN/CDN schemes that are URI based. We will submit an associated 
> draft (-00) with this.
> 
> Thanks

---

From: Ashok Narayanan <[email-masked]>
Date: Wed, 25 Jul 2012 22:42:54 -0400

Hi Lichun,

Thanks for the note. Please see inline for ASHOK>

On Jul 25, 2012, at 7/25 9:41 PM, <[email-masked]> wrote:

> section 4 "Content FIB matching is done on componentized longest prefix match." 
> Suppose a content provider has two servers. One server (main site) stores all contents and publishes a route "www.example.com/", while the other server (mirror site) stores part of the contents and publishes a route "www.example.com/pics/". If a client close to the main server requests a file "www.example.com/pics/1.jpg", the request should be routed to the main server instead of the mirror server. 

ASHOK> That's an interesting idea. I would mention that the typical use of longer prefix routes is specifically to select them over shorter prefix routes. As you know, this is commonly done in IP for traffic engineering and Comcast (co-authors) would like to use this technique for CDN engineering as well.

Having said that, in point of fact I cannot think of a strong reason off the top of my head why your proposal is not a better idea for ICN than it is for IP; most of the usual IP arguments don't actually apply in this case. If you are @ Vancouver maybe we can talk about this a little more.  

> As BGP for content URI controls data packet routing in an indirect way (via controlling interest packet routing), using MED and LOCAL_PREF to enforce data routing policies is different from that in original BGP. I think the draft may need to mention the differences.

ASHOK> I'm not totally sure about this one. Use of MED/LOCAL_PREF will result in interests exiting the AS over particular paths towards the content; the data will flow back over that same path to the receiver (as opposed to being asymmetrically routed). Are you suggesting that we simply clarify that this applies only to interests and not to data packets? Or do you have some other, different, behavior in mind?

Thanks
-Ashok

---

From: [email-masked]
Date: Thu, 26 Jul 2012 14:21:48 +0800

Hi Ashok,

Please see inline.

BR
Lichun

[email-masked] 写于 2012-07-26 10:42:54:

> Suppose a content provider has two servers. One server (main site) 
> stores all contents and publishes a route "www.example.com/", while 
> the other server (mirror site) stores part of the contents and 
> publishes a route "www.example.com/pics/". If a client close to the 
> main server requests a file "www.example.com/pics/1.jpg", the 
> request should be routed to the main server instead of the mirror 
server. 
> 
> ASHOK> That's an interesting idea. I would mention that the typical 
> use of longer prefix routes is specifically to select them over 
> shorter prefix routes. As you know, this is commonly done in IP for 
> traffic engineering and Comcast (co-authors) would like to use this 
> technique for CDN engineering as well.
> 
> Having said that, in point of fact I cannot think of a strong reason
> off the top of my head why your proposal is not a better idea for 
> ICN than it is for IP; most of the usual IP arguments don't actually
> apply in this case. If you are @ Vancouver maybe we can talk about 
> this a little more. 
>

Lichun> IP routing can use longest prefix match because a destination host 
is located at only one place.
In contrast, a content may has several copies in different locations.
I think name-based content routing should select the 
shortest-path/lowest-cost route from all prefix-matched routes.
We may call it "closest prefix match" or "shortest-path prefix match".
I will attend the coming meeting. We can talk more on this in Vancouver.

> As BGP for content URI controls data packet routing in an indirect 
> way (via controlling interest packet routing), using MED and 
> LOCAL_PREF to enforce data routing policies is different from that 
> in original BGP. I think the draft may need to mention the differences.
> 
> ASHOK> I'm not totally sure about this one. Use of MED/LOCAL_PREF 
> will result in interests exiting the AS over particular paths 
> towards the content; the data will flow back over that same path to 
> the receiver (as opposed to being asymmetrically routed). Are you 
> suggesting that we simply clarify that this applies only to 
> interests and not to data packets? Or do you have some other, 
> different, behavior in mind?
> 
> Thanks
> -Ashok
>

Lichun> On second thought, I think there is no need to clarify.
Data traffic is much higher than interest traffic. Considering factors 
like bandwidth utilization, transit fee and QoS, ISPs may concern more on 
the routing policies of data traffic.
The way to enforce data routing policies may be different, but I think 
there is no need to discuss routing policies in this draft.

> ZTE Information Security Notice: The information contained in this 
> mail (and any attachment transmitted herewith) is privileged and 
> confidential and is intended for the exclusive use of the 
> addressee(s).  If you are not an intended recipient, any disclosure,
> reproduction, distribution or other dissemination or use of the 
> information contained is strictly prohibited.  If you have received 
> this mail in error, please delete it and notify us immediately.
>