From NourElHouda.BenYoussef at oxia-group.com Thu Dec 3 03:13:43 2015 From: NourElHouda.BenYoussef at oxia-group.com (Nour El Houda Ben Youssef) Date: Thu, 3 Dec 2015 11:13:43 +0000 Subject: [Ndn-interest] CalculateRoutes In-Reply-To: <505FD4B9-96EF-4EC0-8227-3C397E2A8125@ucla.edu> References: <712FE4E7257849499414892DD92704BC5FC71FA3@INFRAEX01.oxia.corp> <0DBC83D9-593C-466A-8AA7-2B80DF021BBC@ucla.edu> <712FE4E7257849499414892DD92704BC5FC72FCB@INFRAEX01.oxia.corp> <703EF5C8-C54C-40CF-AF7A-B4910CBF29EB@ucla.edu> <712FE4E7257849499414892DD92704BC5FC74025@INFRAEX01.oxia.corp> <712FE4E7257849499414892DD92704BC5FC740A8@INFRAEX01.oxia.corp> <505FD4B9-96EF-4EC0-8227-3C397E2A8125@ucla.edu> Message-ID: <712FE4E7257849499414892DD92704BC73233BFE@INFRAEX02.oxia.corp> Dear Alex I'm planning on comparing different forwarding strategies in a PLC topology built using the ns-3 PLC module To do so I change the forwarding strategy in each scenario and then run the simulation and collect delay using ndnSim application tracers If I work with defaultroutes does this mean that I'm not using the forwording starategy ? I doubted this because I'm having the same results with all the forwarding strategies ! I tried to use calculate routes to populate the FIB's but all the nodes are unreachable!!! Does this mean that there is a problem with the PLC_channel ?! Please help De : Alexander Afanasyev [mailto:cawka1 at gmail.com] De la part de Alex Afanasyev Envoy? : jeudi 17 juillet 2014 20:43 ? : Nour El Houda Ben Youssef Objet : Re: Using AddNetDeviceFaceCreateCallback Somehow, plc network device or channel don't support working with multiple protocols. If you check NetDeviceFace::Send, you'll see that Send operation specifies "L3Protocol::ETHERNET_FRAME_TYPE" as a protocol number. During registering ndn protocol, NetDeviceFace::RegisterProtocolHandlers, the same protocol was specified. Somehow, inside PLC module when packet arrives, it does not carry the proper protocol number and without the hack I suggested, NS-3 cannot properly dispatch packets to ndnSIM. --- Alex On Jul 17, 2014, at 12:56 AM, Nour El Houda Ben Youssef > wrote: Dear Alex I'm really thankful, I don't know by which miracle but the maneuver worked just fine I would like thought to understand what was the meaning of the changes that you recommended Best regards De : Alexander Afanasyev [mailto:cawka1 at gmail.com] De la part de Alex Afanasyev Envoy? : mercredi 16 juillet 2014 06:13 ? : Nour El Houda Ben Youssef Objet : Re: Using AddNetDeviceFaceCreateCallback You can try to replace L3Protocol::ETHERNET_FRAME_TYPE with 0 in ndn-net-device-face.cc (you may also set promisc mode to false). Two days ago I was observing a similar behavior as you described with lr-wpan module and the hack solved the problem. --- Alex On Jul 15, 2014, at 8:21 PM, Nour El Houda Ben Youssef > wrote: Well frankly it wasn't without difficulties especially that I'm new with ns3, but using this link was very helpful :https://github.com/jvaubourg/plc There was also need to disable python bindings before building the module and then I regenerated, using the semi-automatic way, all python bindings for plc Unfortunately I thought this was the hardest part but then I wasn't able to deploy ndn over a PLC topology :( After running few examples I noticed that interests are being sent then received at PLC_netdevice level but not reaching higher layers I think perhaps the problem is caused by PLC_mac I hope you build PLC module and then figure out the problem ! Best regards De : Alexander Afanasyev [mailto:cawka1 at gmail.com] De la part de Alex Afanasyev Envoy? : mardi 15 juillet 2014 18:33 ? : Nour El Houda Ben Youssef Objet : Re: Using AddNetDeviceFaceCreateCallback Ehm.. How did you manage to compile plc module in the first place? It seem to me that it works only with older version (ns-3.16), while the current ndnSIM was just rebased on top of ns-3.20... Even after I fixed the problems with wscript, I still cannot build the code due to some errors... --- Alex On Jul 15, 2014, at 12:33 AM, Nour El Houda Ben Youssef > wrote: Thank you for your quick answer Actually I do not need a particular initialization but ndn did not work over a PLC netdevice. I'm sure PLC netdevice works fine since I used it with Internet stack but when I try to deploy ndn stack over it interests are being sent but not received :( So I guessed it should need a customized callback The PLC module that I'm using can be found in: https://github.com/ns3-plc-module You can also find attached my script deploying ndn avec PLC Your help is really appreciated Best regards De : Alexander Afanasyev [mailto:cawka1 at gmail.com] De la part de Alex Afanasyev Envoy? : lundi 14 juillet 2014 18:39 ? : Nour El Houda Ben Youssef Objet : Re: Using AddNetDeviceFaceCreateCallback Hi, Technically, there is a default callback that should work with any class based on NetDevice. The callback is needed when you need to do custom initialization of the face (=creating custom version of ndn::Face for the netdevice). The example I have is here: https://github.com/cawka/ndnSIM-nom-rapid-car2car/blob/master/scenarios/car-relay.cc#L44 --- Alex On Jul 14, 2014, at 3:23 AM, Nour El Houda Ben Youssef > wrote: Dear Alexander I'm having trouble using ndnSim over a power line communication netdevice I would like to ask if there is any example showing me how to define a new NetDeviceFace Callback Best regards Nour El Houda Ben Youssef Koubaa Doctorante Mobidoc - OXIA/SAGE Mast?re nouvelle g?n?ration des syst?mes d'informations - FST Ing?nieur G?nie Logiciel - INSAT > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Fri Dec 4 11:50:07 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 4 Dec 2015 11:50:07 -0800 Subject: [Ndn-interest] go-ndn 1.2 Message-ID: This release is not possible without some individual contributors. Major Feature: - experimental "send/push" semantics: A data sender sends interests with name "/ACK/" to ensure that a specific node receives a specific data packet. This is implemented with `mux.Notifier` and `mux.Listener`. Feel free to share how you achieve send or push in NDN. - go-ndn/health: instrument your ndn application easily. It stores per-minute stats like interest request count and response time on disk, and presents on a nice web interface. All web interface assets are directly compiled into application and are available offline. (See https://github.com/go-ndn/health) Tutorial: - Generate Data Before Interest: Discuss two common design patterns to publish data "before" interests, and show how "self-generated/fake interests" can achieve this. https://github.com/go-ndn/example/blob/master/before-interest.md Contributer: - Oli Gavin - qhsong - Mahyuddin Husairi More details: https://github.com/go-ndn/example#news From m.faran.majeed at gmail.com Fri Dec 4 22:55:40 2015 From: m.faran.majeed at gmail.com (Muhammad Faran) Date: Sat, 5 Dec 2015 13:55:40 +0700 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. Message-ID: Hi! So far, I have been viewing NDN architecture working as pull-based mechanism. Is there any possibility to incorporate "Push" mechanism in it? Because for some environments, (vehicular/MANET), pull-based mechanism may not work properly. Scenario: In a highly dynamic environment, the producer moving quickly among content routers, capturing and publishing video. So, producer can not wait for an interest and want to push the video content in-network before its local storage is full. Kind regards, Faran, AIT, Thailand -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.h.ahmed at ieee.org Fri Dec 4 23:12:42 2015 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Sat, 5 Dec 2015 16:12:42 +0900 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. In-Reply-To: References: Message-ID: Dear Faran, Experts may response in this regards, however, here is my answer: In Vehicular NDN research, mostly authors assume that content routers are installed in each vehicle, especially, when we say that no infrastructure support is there such as RSU. So my point is that almost every node/vehicle is performing as a content router + provider + consumer role at different instances under the given circumstances. Now, if we talk about "Push" based communications, then we might have a look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to the specific type of data, then they don't need to send interest(s) every time. On the other hands, the producers start "pushing" the data into the network. However, in naive NDN, this approach may have its own consequences. Because, when you push, then it will cost extra cost in terms of overhead and additional copies of the packets and there might be a case, that all the neighboring nodes do not want to have that video content so why they pay the cost of channel utilization for receiving the data, they don't want or have any interest. I am not sure, that did I give you the required answer. Good Luck~~ Kind Regards, ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ *Syed Hassan Ahmed* ??? ?? ???? PhD Research Scholar, MoNeT Wireless Lab, Kyungpook National University, Daegu City, Republic of Korea. Cell: +82-10-9883-0786 https://sites.google.com/site/shahmedknu/ On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran wrote: > Hi! > > So far, I have been viewing NDN architecture working as pull-based > mechanism. Is there any possibility to incorporate "Push" mechanism in it? > Because for some environments, (vehicular/MANET), pull-based mechanism may > not work properly. > > Scenario: In a highly dynamic environment, the producer moving quickly > among content routers, capturing and publishing video. So, producer can not > wait for an interest and want to push the video content in-network before > its local storage is full. > > > Kind regards, > > Faran, > AIT, Thailand > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.faran.majeed at gmail.com Sat Dec 5 00:12:08 2015 From: m.faran.majeed at gmail.com (Muhammad Faran) Date: Sat, 5 Dec 2015 15:12:08 +0700 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. In-Reply-To: References: Message-ID: Dear Hassan, Thank you for prompt response. Actually, I can define the scenario in following two points: 1. As per application perspective, the producer needs to send content whether it is needed or not by consumers. Or there can be archiving of the content later after its production. 2. Due to requirements of the application, the network has to adapt to push-based mechanism and might not be limited to only pull-based mechanism where an interest MUST be issued to retrieve content. What I've understood from your reply: 1. In vehicular environment, every node is performing as all in all. So do every node does in normal environment to be content router, producer and consumer, nothing different. But even in vehicular applications such as monitoring, a producer that wants to use the network to just accommodate its content may need to just push content. 2. According to my sense, channel utilization is the task of layers below the "strategy layer" of NDN. Even for channel utilization, if content routers are aware of the application needs then they have to accommodate the content. Kind regards, Faran AIT, Thailand On Sat, Dec 5, 2015 at 2:12 PM, Syed Hassan Ahmed wrote: > Dear Faran, > > Experts may response in this regards, however, here is my answer: > > In Vehicular NDN research, mostly authors assume that content routers are > installed in each vehicle, especially, when we say that no infrastructure > support is there such as RSU. So my point is that almost every node/vehicle > is performing as a content router + provider + consumer role at different > instances under the given circumstances. > > Now, if we talk about "Push" based communications, then we might have a > look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to > the specific type of data, then they don't need to send interest(s) every > time. On the other hands, the producers start "pushing" the data into the > network. However, in naive NDN, this approach may have its own > consequences. Because, when you push, then it will cost extra cost in terms > of overhead and additional copies of the packets and there might be a case, > that all the neighboring nodes do not want to have that video content so > why they pay the cost of channel utilization for receiving the data, they > don't want or have any interest. > > I am not sure, that did I give you the required answer. > Good Luck~~ > > Kind Regards, > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > *Syed Hassan Ahmed* > ??? ?? ???? > > PhD Research Scholar, > MoNeT Wireless Lab, > Kyungpook National University, > Daegu City, Republic of Korea. > Cell: +82-10-9883-0786 > https://sites.google.com/site/shahmedknu/ > > On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran > wrote: > >> Hi! >> >> So far, I have been viewing NDN architecture working as pull-based >> mechanism. Is there any possibility to incorporate "Push" mechanism in it? >> Because for some environments, (vehicular/MANET), pull-based mechanism may >> not work properly. >> >> Scenario: In a highly dynamic environment, the producer moving quickly >> among content routers, capturing and publishing video. So, producer can not >> wait for an interest and want to push the video content in-network before >> its local storage is full. >> >> >> Kind regards, >> >> Faran, >> AIT, Thailand >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From setori88 at gmail.com Sat Dec 5 00:22:11 2015 From: setori88 at gmail.com (stewart mackenzie) Date: Sat, 5 Dec 2015 16:22:11 +0800 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. In-Reply-To: References: Message-ID: Your "push" producer could issue an interest that contains a "request for interest", when the push target gets the interest in responds with an ack. Then the push target immediately issues an interest for the data as detailed in the "request for interest" interest. 2cw /sjm From m.faran.majeed at gmail.com Sat Dec 5 00:44:51 2015 From: m.faran.majeed at gmail.com (Muhammad Faran) Date: Sat, 5 Dec 2015 15:44:51 +0700 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network Message-ID: Dear Stewart, Thank you for your reply. From your reply I understood the following: 1. There is no intrinsic push-based mechanism support in NDN architecture. 2. If a producer wants to take initiative for pushing content before it is requested, it will have to use "request for interest" interest. According to second point, we'll have to explicitly set producer to perform "request for interest" functionality to do pushing of content. Am I right? Kind regards, Faran AIT, Thailand On Sat, Dec 5, 2015 at 3:22 PM, wrote: > Send Ndn-interest mailing list submissions to > ndn-interest at lists.cs.ucla.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > or, via email, send a message with subject or body 'help' to > ndn-interest-request at lists.cs.ucla.edu > > You can reach the person managing the list at > ndn-interest-owner at lists.cs.ucla.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ndn-interest digest..." > > > Today's Topics: > > 1. go-ndn 1.2 (Tai-Lin Chu) > 2. Producer taking initiative to "Push" content to network. > (Muhammad Faran) > 3. Re: Producer taking initiative to "Push" content to network. > (Syed Hassan Ahmed) > 4. Re: Producer taking initiative to "Push" content to network. > (Muhammad Faran) > 5. Re: Producer taking initiative to "Push" content to network. > (stewart mackenzie) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 4 Dec 2015 11:50:07 -0800 > From: Tai-Lin Chu > To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] go-ndn 1.2 > Message-ID: > 0-OPT4E5PdkoaTBsaxdxwVos9zHo3v7ng at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > This release is not possible without some individual contributors. > > Major Feature: > > - experimental "send/push" semantics: A data sender sends interests > with name "/ACK/" to ensure that a specific node > receives a specific data packet. This is implemented with > `mux.Notifier` and `mux.Listener`. Feel free to share how you achieve > send or push in NDN. > > - go-ndn/health: instrument your ndn application easily. It stores > per-minute stats like interest request count and response time on > disk, and presents on a nice web interface. All web interface assets > are directly compiled into application and are available offline. (See > https://github.com/go-ndn/health) > > Tutorial: > > - Generate Data Before Interest: Discuss two common design patterns to > publish data "before" interests, and show how "self-generated/fake > interests" can achieve this. > > https://github.com/go-ndn/example/blob/master/before-interest.md > > > Contributer: > - Oli Gavin > - qhsong > - Mahyuddin Husairi > > More details: https://github.com/go-ndn/example#news > > > ------------------------------ > > Message: 2 > Date: Sat, 5 Dec 2015 13:55:40 +0700 > From: Muhammad Faran > To: ndn-interest at lists.cs.ucla.edu > Subject: [Ndn-interest] Producer taking initiative to "Push" content > to network. > Message-ID: > 5WSvYBa8SOphT5NQmE2xrRCuZ639w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi! > > So far, I have been viewing NDN architecture working as pull-based > mechanism. Is there any possibility to incorporate "Push" mechanism in it? > Because for some environments, (vehicular/MANET), pull-based mechanism may > not work properly. > > Scenario: In a highly dynamic environment, the producer moving quickly > among content routers, capturing and publishing video. So, producer can not > wait for an interest and want to push the video content in-network before > its local storage is full. > > > Kind regards, > > Faran, > AIT, Thailand > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20151205/ce47c02b/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Sat, 5 Dec 2015 16:12:42 +0900 > From: Syed Hassan Ahmed > To: Muhammad Faran > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Producer taking initiative to "Push" > content to network. > Message-ID: > < > CAJeX4qfbnp2wgcAB5LWT5iOW4JdkwUc_QTyBdCC+hp++-qLCnA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Faran, > > Experts may response in this regards, however, here is my answer: > > In Vehicular NDN research, mostly authors assume that content routers are > installed in each vehicle, especially, when we say that no infrastructure > support is there such as RSU. So my point is that almost every node/vehicle > is performing as a content router + provider + consumer role at different > instances under the given circumstances. > > Now, if we talk about "Push" based communications, then we might have a > look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to > the specific type of data, then they don't need to send interest(s) every > time. On the other hands, the producers start "pushing" the data into the > network. However, in naive NDN, this approach may have its own > consequences. Because, when you push, then it will cost extra cost in terms > of overhead and additional copies of the packets and there might be a case, > that all the neighboring nodes do not want to have that video content so > why they pay the cost of channel utilization for receiving the data, they > don't want or have any interest. > > I am not sure, that did I give you the required answer. > Good Luck~~ > > Kind Regards, > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > *Syed Hassan Ahmed* > ??? ?? ???? > > PhD Research Scholar, > MoNeT Wireless Lab, > Kyungpook National University, > Daegu City, Republic of Korea. > Cell: +82-10-9883-0786 > https://sites.google.com/site/shahmedknu/ > > On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran > wrote: > > > Hi! > > > > So far, I have been viewing NDN architecture working as pull-based > > mechanism. Is there any possibility to incorporate "Push" mechanism in > it? > > Because for some environments, (vehicular/MANET), pull-based mechanism > may > > not work properly. > > > > Scenario: In a highly dynamic environment, the producer moving quickly > > among content routers, capturing and publishing video. So, producer can > not > > wait for an interest and want to push the video content in-network before > > its local storage is full. > > > > > > Kind regards, > > > > Faran, > > AIT, Thailand > > > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20151205/d6f441c9/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Sat, 5 Dec 2015 15:12:08 +0700 > From: Muhammad Faran > To: Syed Hassan Ahmed > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Producer taking initiative to "Push" > content to network. > Message-ID: > < > CAFMc_X95z3ruk2Nm95raq389xHxCs3bf-YkHQw+kUJhOgEoOAQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Hassan, > > Thank you for prompt response. Actually, I can define the scenario in > following two points: > > 1. As per application perspective, the producer needs to send content > whether it is needed or not by consumers. Or there can be archiving of the > content later after its production. > 2. Due to requirements of the application, the network has to adapt to > push-based mechanism and might not be limited to only pull-based mechanism > where an interest MUST be issued to retrieve content. > > What I've understood from your reply: > > 1. In vehicular environment, every node is performing as all in all. So do > every node does in normal environment to be content router, producer and > consumer, nothing different. But even in vehicular applications such as > monitoring, a producer that wants to use the network to just accommodate > its content may need to just push content. > 2. According to my sense, channel utilization is the task of layers below > the "strategy layer" of NDN. Even for channel utilization, if content > routers are aware of the application needs then they have to accommodate > the content. > > Kind regards, > > Faran > AIT, Thailand > > On Sat, Dec 5, 2015 at 2:12 PM, Syed Hassan Ahmed > wrote: > > > Dear Faran, > > > > Experts may response in this regards, however, here is my answer: > > > > In Vehicular NDN research, mostly authors assume that content routers are > > installed in each vehicle, especially, when we say that no infrastructure > > support is there such as RSU. So my point is that almost every > node/vehicle > > is performing as a content router + provider + consumer role at different > > instances under the given circumstances. > > > > Now, if we talk about "Push" based communications, then we might have a > > look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to > > the specific type of data, then they don't need to send interest(s) every > > time. On the other hands, the producers start "pushing" the data into the > > network. However, in naive NDN, this approach may have its own > > consequences. Because, when you push, then it will cost extra cost in > terms > > of overhead and additional copies of the packets and there might be a > case, > > that all the neighboring nodes do not want to have that video content so > > why they pay the cost of channel utilization for receiving the data, they > > don't want or have any interest. > > > > I am not sure, that did I give you the required answer. > > Good Luck~~ > > > > Kind Regards, > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > > *Syed Hassan Ahmed* > > ??? ?? ???? > > > > PhD Research Scholar, > > MoNeT Wireless Lab, > > Kyungpook National University, > > Daegu City, Republic of Korea. > > Cell: +82-10-9883-0786 > > https://sites.google.com/site/shahmedknu/ > > > > On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran > > > wrote: > > > >> Hi! > >> > >> So far, I have been viewing NDN architecture working as pull-based > >> mechanism. Is there any possibility to incorporate "Push" mechanism in > it? > >> Because for some environments, (vehicular/MANET), pull-based mechanism > may > >> not work properly. > >> > >> Scenario: In a highly dynamic environment, the producer moving quickly > >> among content routers, capturing and publishing video. So, producer can > not > >> wait for an interest and want to push the video content in-network > before > >> its local storage is full. > >> > >> > >> Kind regards, > >> > >> Faran, > >> AIT, Thailand > >> > >> _______________________________________________ > >> Ndn-interest mailing list > >> Ndn-interest at lists.cs.ucla.edu > >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >> > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20151205/6d89c50c/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Sat, 5 Dec 2015 16:22:11 +0800 > From: stewart mackenzie > To: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Producer taking initiative to "Push" > content to network. > Message-ID: > n2kFZYAzHEdOtSFTJbbK5TYcgwhkQgky54mkaTptAN3uA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Your "push" producer could issue an interest that contains a "request > for interest", when the push target gets the interest in responds with > an ack. > Then the push target immediately issues an interest for the data as > detailed in the "request for interest" interest. > > 2cw > > /sjm > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > ------------------------------ > > End of Ndn-interest Digest, Vol 21, Issue 2 > ******************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From setori88 at gmail.com Sat Dec 5 00:52:45 2015 From: setori88 at gmail.com (stewart mackenzie) Date: Sat, 5 Dec 2015 16:52:45 +0800 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network In-Reply-To: References: Message-ID: On Sat, Dec 5, 2015 at 4:44 PM, Muhammad Faran wrote: > According to second point, we'll have to explicitly set producer to perform > "request for interest" functionality to do pushing of content. Am I right? This is how I understand it yup :-) You could also take a look at this paper: http://conferences.sigcomm.org/sigcomm/2011/papers/icn/p62.pdf From s.h.ahmed at ieee.org Sat Dec 5 01:49:58 2015 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Sat, 5 Dec 2015 18:49:58 +0900 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. In-Reply-To: References: Message-ID: Dear Faran, Stewart mentioned a very valid point and by sending "request for interest" is also a pull based mechanism. So by default it will be a conventional one. However, "interest" structure needs to be defined. :) For the community and your kind self, I am sharing few papers regarding Vehicular ICN papers: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392 http://www.sciencedirect.com/science/article/pii/S0140366415003552 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7182541 http://dl.acm.org/citation.cfm?id=2811411.2811539&coll=DL&dl=ACM http://dl.acm.org/citation.cfm?doid=2695664.2695844 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7297653 Kind Regards, Syed Hassan Ahmed. (??) PhD Scholar @ KNU, Daegu, Republic of Korea. https://sites.google.com/site/shahmedknu/ > On Dec 5, 2015, at 5:12 PM, Muhammad Faran wrote: > > Dear Hassan, > > Thank you for prompt response. Actually, I can define the scenario in following two points: > > 1. As per application perspective, the producer needs to send content whether it is needed or not by consumers. Or there can be archiving of the content later after its production. > 2. Due to requirements of the application, the network has to adapt to push-based mechanism and might not be limited to only pull-based mechanism where an interest MUST be issued to retrieve content. > > What I've understood from your reply: > > 1. In vehicular environment, every node is performing as all in all. So do every node does in normal environment to be content router, producer and consumer, nothing different. But even in vehicular applications such as monitoring, a producer that wants to use the network to just accommodate its content may need to just push content. > 2. According to my sense, channel utilization is the task of layers below the "strategy layer" of NDN. Even for channel utilization, if content routers are aware of the application needs then they have to accommodate the content. > > Kind regards, > > Faran > AIT, Thailand > >> On Sat, Dec 5, 2015 at 2:12 PM, Syed Hassan Ahmed wrote: >> Dear Faran, >> >> Experts may response in this regards, however, here is my answer: >> >> In Vehicular NDN research, mostly authors assume that content routers are installed in each vehicle, especially, when we say that no infrastructure support is there such as RSU. So my point is that almost every node/vehicle is performing as a content router + provider + consumer role at different instances under the given circumstances. >> >> Now, if we talk about "Push" based communications, then we might have a look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to the specific type of data, then they don't need to send interest(s) every time. On the other hands, the producers start "pushing" the data into the network. However, in naive NDN, this approach may have its own consequences. Because, when you push, then it will cost extra cost in terms of overhead and additional copies of the packets and there might be a case, that all the neighboring nodes do not want to have that video content so why they pay the cost of channel utilization for receiving the data, they don't want or have any interest. >> >> I am not sure, that did I give you the required answer. >> Good Luck~~ >> >> Kind Regards, >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Syed Hassan Ahmed >> ??? ?? ???? >> >> PhD Research Scholar, >> MoNeT Wireless Lab, >> Kyungpook National University, >> Daegu City, Republic of Korea. >> Cell: +82-10-9883-0786 >> https://sites.google.com/site/shahmedknu/ >> >>> On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran wrote: >>> Hi! >>> >>> So far, I have been viewing NDN architecture working as pull-based mechanism. Is there any possibility to incorporate "Push" mechanism in it? Because for some environments, (vehicular/MANET), pull-based mechanism may not work properly. >>> >>> Scenario: In a highly dynamic environment, the producer moving quickly among content routers, capturing and publishing video. So, producer can not wait for an interest and want to push the video content in-network before its local storage is full. >>> >>> >>> Kind regards, >>> >>> Faran, >>> AIT, Thailand >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From gts at ics.uci.EDU Sat Dec 5 06:00:56 2015 From: gts at ics.uci.EDU (GTS) Date: Sat, 5 Dec 2015 06:00:56 -0800 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. In-Reply-To: References: Message-ID: <5662EE18.9040705@ics.uci.edu> Push-based communication in NDN (and its security implications) was also explored in the context of sensing and actuation. See these two papers: J. Burke, P. Gasti, N. Nathan and G. Tsudik, Secure Sensing over Named Data Networking , /13th International Symposium on Network Computing and Applications (NCA)/, Cambridge, MA, 2014. and J. Burke, P. Gasti, N. Nathan and G. Tsudik, Securing Instrumented Environments over Content-Centric Networking: the Case of Lighting Control , /the 2nd IEEE International Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN)/, Italy, 2013. Cheers, Gene ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 12/5/15 1:49 AM, Syed Hassan Ahmed wrote: > Dear Faran, > > Stewart mentioned a very valid point and by sending "request for > interest" is also a pull based mechanism. So by default it will be a > conventional one. > > However, "interest" structure needs to be defined. :) > > For the community and your kind self, I am sharing few papers > regarding Vehicular ICN papers: > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392 > > http://www.sciencedirect.com/science/article/pii/S0140366415003552 > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7182541 > > http://dl.acm.org/citation.cfm?id=2811411.2811539&coll=DL&dl=ACM > > http://dl.acm.org/citation.cfm?doid=2695664.2695844 > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7297653 > > > Kind Regards, > Syed Hassan Ahmed. (??) > PhD Scholar @ KNU, > Daegu, Republic of Korea. > https://sites.google.com/site/shahmedknu/ > > > > On Dec 5, 2015, at 5:12 PM, Muhammad Faran > wrote: > >> Dear Hassan, >> >> Thank you for prompt response. Actually, I can define the scenario in >> following two points: >> >> 1. As per application perspective, the producer needs to send content >> whether it is needed or not by consumers. Or there can be archiving >> of the content later after its production. >> 2. Due to requirements of the application, the network has to adapt >> to push-based mechanism and might not be limited to only pull-based >> mechanism where an interest MUST be issued to retrieve content. >> >> What I've understood from your reply: >> >> 1. In vehicular environment, every node is performing as all in all. >> So do every node does in normal environment to be content router, >> producer and consumer, nothing different. But even in vehicular >> applications such as monitoring, a producer that wants to use the >> network to just accommodate its content may need to just push content. >> 2. According to my sense, channel utilization is the task of layers >> below the "strategy layer" of NDN. Even for channel utilization, if >> content routers are aware of the application needs then they have to >> accommodate the content. >> >> Kind regards, >> >> Faran >> AIT, Thailand >> >> On Sat, Dec 5, 2015 at 2:12 PM, Syed Hassan Ahmed > > wrote: >> >> Dear Faran, >> >> Experts may response in this regards, however, here is my answer: >> >> In Vehicular NDN research, mostly authors assume that content >> routers are installed in each vehicle, especially, when we say >> that no infrastructure support is there such as RSU. So my point >> is that almost every node/vehicle is performing as a content >> router + provider + consumer role at different instances under >> the given circumstances. >> >> Now, if we talk about "Push" based communications, then we might >> have a look at Pub/Sub mechanisms. If the vehicles in any area >> are subscribed to the specific type of data, then they don't need >> to send interest(s) every time. On the other hands, the producers >> start "pushing" the data into the network. However, in naive NDN, >> this approach may have its own consequences. Because, when you >> push, then it will cost extra cost in terms of overhead and >> additional copies of the packets and there might be a case, that >> all the neighboring nodes do not want to have that video content >> so why they pay the cost of channel utilization for receiving the >> data, they don't want or have any interest. >> >> I am not sure, that did I give you the required answer. >> Good Luck~~ >> >> Kind Regards, >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> *Syed Hassan Ahmed* >> ??? ?? ???? >> >> PhD Research Scholar, >> MoNeT Wireless Lab, >> Kyungpook National University, >> Daegu City, Republic of Korea. >> Cell: +82-10-9883-0786 >> https://sites.google.com/site/shahmedknu/ >> >> On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran >> > wrote: >> >> Hi! >> >> So far, I have been viewing NDN architecture working as >> pull-based mechanism. Is there any possibility to incorporate >> "Push" mechanism in it? Because for some environments, >> (vehicular/MANET), pull-based mechanism may not work properly. >> >> Scenario: In a highly dynamic environment, the producer >> moving quickly among content routers, capturing and >> publishing video. So, producer can not wait for an interest >> and want to push the video content in-network before its >> local storage is full. >> >> >> Kind regards, >> >> Faran, >> AIT, Thailand >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Sat Dec 5 15:08:54 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Sat, 5 Dec 2015 15:08:54 -0800 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network. In-Reply-To: <5662EE18.9040705@ics.uci.edu> References: <5662EE18.9040705@ics.uci.edu> Message-ID: I love those papers from Tsudik. Although I did not read those papers before, go-ndn uses a very similar mechanism (notification) for "send/push". 1. Sender issues interest /receiver/ACK/data (it notifies receiver that data is available) 2. Receiver decides whether it issues interest /data to fetch data 3. Receiver answers /receiver/ACK/data In general, a receiving node can have more listening channels for notifications. This is one of the simplest/generic implementation of send/push in current NDN stack. At high level, push "synchronizes" consumer-producer communication; a producer can ensure whether a specific consumer gets data within a time frame. This feature is not available for pure pub/sub. Using send as a primitive, we can start to build distributed consensus algorithm that can give stronger consistency. On Sat, Dec 5, 2015 at 6:00 AM, GTS wrote: > Push-based communication in NDN (and its security implications) was also > explored in the context of sensing and actuation. See these two papers: > > J. Burke, P. Gasti, N. Nathan and G. Tsudik, Secure Sensing over Named Data > Networking, 13th International Symposium on Network Computing and > Applications (NCA), Cambridge, MA, 2014. > > and > > J. Burke, P. Gasti, N. Nathan and G. Tsudik, Securing Instrumented > Environments over Content-Centric Networking: the Case of Lighting Control, > the 2nd IEEE International Workshop on Emerging Design Choices in > Name-Oriented Networking (NOMEN), Italy, 2013. > > Cheers, > Gene > > ====================== > Gene Tsudik > Chancellor's Professor of Computer Science > University of California, Irvine > > On 12/5/15 1:49 AM, Syed Hassan Ahmed wrote: > > Dear Faran, > > Stewart mentioned a very valid point and by sending "request for interest" > is also a pull based mechanism. So by default it will be a conventional one. > > However, "interest" structure needs to be defined. :) > > For the community and your kind self, I am sharing few papers regarding > Vehicular ICN papers: > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7145392 > > http://www.sciencedirect.com/science/article/pii/S0140366415003552 > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7182541 > > http://dl.acm.org/citation.cfm?id=2811411.2811539&coll=DL&dl=ACM > > http://dl.acm.org/citation.cfm?doid=2695664.2695844 > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7297653 > > > Kind Regards, > Syed Hassan Ahmed. (??) > PhD Scholar @ KNU, > Daegu, Republic of Korea. > https://sites.google.com/site/shahmedknu/ > > > > On Dec 5, 2015, at 5:12 PM, Muhammad Faran wrote: > > Dear Hassan, > > Thank you for prompt response. Actually, I can define the scenario in > following two points: > > 1. As per application perspective, the producer needs to send content > whether it is needed or not by consumers. Or there can be archiving of the > content later after its production. > 2. Due to requirements of the application, the network has to adapt to > push-based mechanism and might not be limited to only pull-based mechanism > where an interest MUST be issued to retrieve content. > > What I've understood from your reply: > > 1. In vehicular environment, every node is performing as all in all. So do > every node does in normal environment to be content router, producer and > consumer, nothing different. But even in vehicular applications such as > monitoring, a producer that wants to use the network to just accommodate its > content may need to just push content. > 2. According to my sense, channel utilization is the task of layers below > the "strategy layer" of NDN. Even for channel utilization, if content > routers are aware of the application needs then they have to accommodate the > content. > > Kind regards, > > Faran > AIT, Thailand > > On Sat, Dec 5, 2015 at 2:12 PM, Syed Hassan Ahmed > wrote: >> >> Dear Faran, >> >> Experts may response in this regards, however, here is my answer: >> >> In Vehicular NDN research, mostly authors assume that content routers are >> installed in each vehicle, especially, when we say that no infrastructure >> support is there such as RSU. So my point is that almost every node/vehicle >> is performing as a content router + provider + consumer role at different >> instances under the given circumstances. >> >> Now, if we talk about "Push" based communications, then we might have a >> look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to >> the specific type of data, then they don't need to send interest(s) every >> time. On the other hands, the producers start "pushing" the data into the >> network. However, in naive NDN, this approach may have its own consequences. >> Because, when you push, then it will cost extra cost in terms of overhead >> and additional copies of the packets and there might be a case, that all the >> neighboring nodes do not want to have that video content so why they pay the >> cost of channel utilization for receiving the data, they don't want or have >> any interest. >> >> I am not sure, that did I give you the required answer. >> Good Luck~~ >> >> Kind Regards, >> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ >> Syed Hassan Ahmed >> ??? ?? ???? >> >> PhD Research Scholar, >> MoNeT Wireless Lab, >> Kyungpook National University, >> Daegu City, Republic of Korea. >> Cell: +82-10-9883-0786 >> https://sites.google.com/site/shahmedknu/ >> >> On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran >> wrote: >>> >>> Hi! >>> >>> So far, I have been viewing NDN architecture working as pull-based >>> mechanism. Is there any possibility to incorporate "Push" mechanism in it? >>> Because for some environments, (vehicular/MANET), pull-based mechanism may >>> not work properly. >>> >>> Scenario: In a highly dynamic environment, the producer moving quickly >>> among content routers, capturing and publishing video. So, producer can not >>> wait for an interest and want to push the video content in-network before >>> its local storage is full. >>> >>> >>> Kind regards, >>> >>> Faran, >>> AIT, Thailand >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> >> > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From Marc.Mosko at parc.com Mon Dec 7 10:08:11 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Mon, 7 Dec 2015 18:08:11 +0000 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network In-Reply-To: References: Message-ID: One can always pack up small amounts of data inside an Interest. In the NDN architecture, this is usually done by making a name component with data and possibly signing it. There?s a tech report on the NDN site about signed interests for doing stage lighting or building control or something like that, though informally the method dates back to the very early days of CCNx. In the CCNx architecture, it specifically allows for a payload field in an interest along with a name component that identifies the payload (for proper multiplexing of interests with different payloads). It?s about the same effect as putting payload in the name, but for larger payloads reduces the burden on the PIT or other things that need to process the name. Whichever method is used, putting data in an Interest has a few problems. First, it?s (like all network messages) unreliable so you need to use Data object ACKs. Also, you don?t know if any two interests would go to the same destinations because forwarding strategy might spread them across instances of the name (unless you have a multicast strategy in which case it would try to go to all) or you know you are working specifically with instance names not anycast names. Pushing unacknowledged (no Data object) data in Interests will leave junk in the PIT tables. So, you need to use a very short Interest lifetime if you know there will be no response. this might run afoul of some congestion control algorithms that will penalize Interest sources with unresponsive Data objects. If you want the data to go to many subscribers, then this will not scale well if each subscriber is giving its own name. It would be like sending unicast UDP traffic. Unless all the subscribers can listen to the same name, you won?t get multicast benefits like this. Pushing large amounts of data in Interests is not the right thing to do. It is very slow forwarding (you are doing multiple table lookups for the PIT, CS, and FIB at each hop), there?s no congestion control or flow control or ARQ unless you build your own, and if you use Data object as ACKs you need to make sure your naming and caching policies avoid two pushers using the same name or accepting a Data ACK for one pusher at a second (unintended) pusher. Marc > On Dec 5, 2015, at 12:52 AM, stewart mackenzie wrote: > > On Sat, Dec 5, 2015 at 4:44 PM, Muhammad Faran wrote: >> According to second point, we'll have to explicitly set producer to perform >> "request for interest" functionality to do pushing of content. Am I right? > > This is how I understand it yup :-) You could also take a look at this > paper: http://conferences.sigcomm.org/sigcomm/2011/papers/icn/p62.pdf > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From ravi.ravindran at gmail.com Mon Dec 7 10:25:12 2015 From: ravi.ravindran at gmail.com (Ravi Ravindran) Date: Mon, 7 Dec 2015 10:25:12 -0800 Subject: [Ndn-interest] Producer taking initiative to "Push" content to network In-Reply-To: References: Message-ID: This is a draft we had proposed in the context of CCN a few ICNRGs back, titled "Support for Notifications in CCN" https://tools.ietf.org/html/draft-ravi-ccn-notification-00 Regards Ravi On Mon, Dec 7, 2015 at 10:08 AM, wrote: > One can always pack up small amounts of data inside an Interest. In the > NDN architecture, this is usually done by making a name component with data > and possibly signing it. There?s a tech report on the NDN site about > signed interests for doing stage lighting or building control or something > like that, though informally the method dates back to the very early days > of CCNx. > > In the CCNx architecture, it specifically allows for a payload field in an > interest along with a name component that identifies the payload (for > proper multiplexing of interests with different payloads). It?s about the > same effect as putting payload in the name, but for larger payloads reduces > the burden on the PIT or other things that need to process the name. > > Whichever method is used, putting data in an Interest has a few problems. > > First, it?s (like all network messages) unreliable so you need to use Data > object ACKs. Also, you don?t know if any two interests would go to the > same destinations because forwarding strategy might spread them across > instances of the name (unless you have a multicast strategy in which case > it would try to go to all) or you know you are working specifically with > instance names not anycast names. > > Pushing unacknowledged (no Data object) data in Interests will leave junk > in the PIT tables. So, you need to use a very short Interest lifetime if > you know there will be no response. this might run afoul of some > congestion control algorithms that will penalize Interest sources with > unresponsive Data objects. > > If you want the data to go to many subscribers, then this will not scale > well if each subscriber is giving its own name. It would be like sending > unicast UDP traffic. Unless all the subscribers can listen to the same > name, you won?t get multicast benefits like this. > > Pushing large amounts of data in Interests is not the right thing to do. > It is very slow forwarding (you are doing multiple table lookups for the > PIT, CS, and FIB at each hop), there?s no congestion control or flow > control or ARQ unless you build your own, and if you use Data object as > ACKs you need to make sure your naming and caching policies avoid two > pushers using the same name or accepting a Data ACK for one pusher at a > second (unintended) pusher. > > Marc > > > On Dec 5, 2015, at 12:52 AM, stewart mackenzie > wrote: > > > > On Sat, Dec 5, 2015 at 4:44 PM, Muhammad Faran > wrote: > >> According to second point, we'll have to explicitly set producer to > perform > >> "request for interest" functionality to do pushing of content. Am I > right? > > > > This is how I understand it yup :-) You could also take a look at this > > paper: http://conferences.sigcomm.org/sigcomm/2011/papers/icn/p62.pdf > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From setori88 at gmail.com Tue Dec 8 03:44:11 2015 From: setori88 at gmail.com (stewart mackenzie) Date: Tue, 8 Dec 2015 19:44:11 +0800 Subject: [Ndn-interest] unintentional unmatched interests Message-ID: Hi all, Say an unmatchable Interest of 100 bytes is flooded randomly from any ndn router in a network of 6 billion ndn routers every 1 minute . This is normal user behaviour equivalent to navigating to a 404 url unintentionally, this is not an attack. What will happen? /sjm From shijunxiao at email.arizona.EDU Tue Dec 8 12:47:36 2015 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Tue, 8 Dec 2015 13:47:36 -0700 Subject: [Ndn-interest] unintentional unmatched interests In-Reply-To: References: Message-ID: Hi Stewart If a user is capable of flooding 6 billion NDN routers once a minute, and there are many such users, those Interests would fill up the PIT of NDN routers across the entire Internet. That's why global Internet needs routing, and cannot rely on flooding. Yours, Junxiao On Tue, Dec 8, 2015 at 4:44 AM, stewart mackenzie wrote: > Hi all, > > Say an unmatchable Interest of 100 bytes is flooded randomly from any > ndn router in a network of 6 billion ndn routers every 1 minute . This > is normal user behaviour equivalent to navigating to a 404 url > unintentionally, this is not an attack. > > What will happen? > > /sjm > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmurray at verisign.com Wed Dec 16 15:09:32 2015 From: cmurray at verisign.com (Murray, Craig) Date: Wed, 16 Dec 2015 23:09:32 +0000 Subject: [Ndn-interest] reaching NDN testbed from behind a firewall Message-ID: Hi all, I am trying to use NdnCom to connect with others on the testbed, but I am behind a firewall and port 6363 is not open. I thought I might be able to tunnel using ssh, but this does not work (below is more detail on what I tried). Does anyone have experience and/or suggestions that would help me? My guess is this is obvious to someone who knows more than I. My apologies if so. Thanks in advance for any help, Craig --------------------------------- Detail: I have three machines running NFD inside the firewall. First I tested that ndnping works between machines inside: On machine B I do the following: ndnpingserver /ndn/internal/B On machine A I do the following: nfdc register /ndn/internal udp:// ndnping /ndn/internal/B Of course this works. Next I remove entries from NFD tables On machine A I do the following: nfdc unregister /ndn/internal Next I ssh from machine A to machine B, forwarding a port On machine A I do the following: ssh -L 4000:localhost:6363 nfdc register /ndn/internal udp://localhost:4000 ndnping /ndn/internal/B This does not work. Packets time out. I have also tried the following: On machine C I do: nfdc register /ndn/internal udp:// ndnping /ndn/internal/B This works so then I try tunneling form A to C: First I end the ssh running between A and B. Then on machine A: ssh -L 5000::6363 nfdc unregister /ndn/internal nfdc register /ndn/internal udp://localhost:5000 ndnping /ndn/internal/B Of course, this does not work either. I have not tried the same thing with ssh from a machine inside the firewall to a machine outside the firewall (also running NFD) but if it does not work without a firewall in between machines, it certainly won?t work with the firewall added. Thanks for any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Wed Dec 16 15:16:29 2015 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Wed, 16 Dec 2015 15:16:29 -0800 Subject: [Ndn-interest] reaching NDN testbed from behind a firewall In-Reply-To: References: Message-ID: <2E283F1E-6562-4060-B40C-FEDD2E25A1FE@cs.ucla.edu> Hi Craig, ssh tunnels TCP port, so it is understandable why you have failed. You can try workarounds discussed here: http://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel or use tcp-based face when using the tunnel (tcp://localhost:5000) --- Alex > On Dec 16, 2015, at 3:09 PM, Murray, Craig wrote: > > Hi all, > > I am trying to use NdnCom to connect with others on the testbed, but I am behind a firewall and port 6363 is not open. I thought I might be able to tunnel using ssh, but this does not work (below is more detail on what I tried). Does anyone have experience and/or suggestions that would help me? My guess is this is obvious to someone who knows more than I. My apologies if so. > > Thanks in advance for any help, > Craig > > --------------------------------- > Detail: > I have three machines running NFD inside the firewall. > First I tested that ndnping works between machines inside: > On machine B I do the following: > ndnpingserver /ndn/internal/B > On machine A I do the following: > nfdc register /ndn/internal udp:// > ndnping /ndn/internal/B > Of course this works. Next I remove entries from NFD tables > On machine A I do the following: > nfdc unregister /ndn/internal > Next I ssh from machine A to machine B, forwarding a port > On machine A I do the following: > ssh -L 4000:localhost:6363 > nfdc register /ndn/internal udp://localhost:4000 > ndnping /ndn/internal/B > This does not work. Packets time out. > > I have also tried the following: > On machine C I do: > nfdc register /ndn/internal udp:// > ndnping /ndn/internal/B > This works so then I try tunneling form A to C: > First I end the ssh running between A and B. > Then on machine A: > ssh -L 5000::6363 > nfdc unregister /ndn/internal > nfdc register /ndn/internal udp://localhost:5000 > ndnping /ndn/internal/B > Of course, this does not work either. I have not tried the same thing with ssh from a machine inside the firewall to a machine outside the firewall (also running NFD) but if it does not work without a firewall in between machines, it certainly won?t work with the firewall added. Thanks for any help. > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From davide.pesavento at lip6.fr Wed Dec 16 16:05:45 2015 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Thu, 17 Dec 2015 01:05:45 +0100 Subject: [Ndn-interest] reaching NDN testbed from behind a firewall In-Reply-To: <2E283F1E-6562-4060-B40C-FEDD2E25A1FE@cs.ucla.edu> References: <2E283F1E-6562-4060-B40C-FEDD2E25A1FE@cs.ucla.edu> Message-ID: On Thu, Dec 17, 2015 at 12:16 AM, Alex Afanasyev wrote: > Hi Craig, > > ssh tunnels TCP port, so it is understandable why you have failed. > > You can try workarounds discussed here: > http://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel or use The first answer in that thread is simply wrong in my opinion. There's no guarantee that the TCP tunnel and the FIFO will preserve UDP datagram boundaries, thus breaking any higher-layer protocols that rely on them. The second answer (using the -w option of openssh) should work, but requires superuser privileges at both ends of the tunnel. > tcp-based face when using the tunnel (tcp://localhost:5000) This is probably the easiest workaround. Also, it may be worth pointing out that, since version 6.7, openssh supports forwarding of Unix domain sockets over the ssh tunnel, just like TCP sockets. I've never tried this technique with NFD but it should work fine. Unfortunately it's not a solution for the testbed nodes (yet), since they don't have a recent enough version of openssh installed. Best, Davide > --- > Alex > > On Dec 16, 2015, at 3:09 PM, Murray, Craig wrote: > > Hi all, > > I am trying to use NdnCom to connect with others on the testbed, but I am > behind a firewall and port 6363 is not open. I thought I might be able to > tunnel using ssh, but this does not work (below is more detail on what I > tried). Does anyone have experience and/or suggestions that would help me? > My guess is this is obvious to someone who knows more than I. My apologies > if so. > > Thanks in advance for any help, > Craig > > --------------------------------- > Detail: > I have three machines running NFD inside the firewall. > First I tested that ndnping works between machines inside: > On machine B I do the following: > ndnpingserver /ndn/internal/B > On machine A I do the following: > nfdc register /ndn/internal udp:// > ndnping /ndn/internal/B > Of course this works. Next I remove entries from NFD tables > On machine A I do the following: > nfdc unregister /ndn/internal > Next I ssh from machine A to machine B, forwarding a port > On machine A I do the following: > ssh -L 4000:localhost:6363 > nfdc register /ndn/internal udp://localhost:4000 > ndnping /ndn/internal/B > This does not work. Packets time out. > > I have also tried the following: > On machine C I do: > nfdc register /ndn/internal udp:// > ndnping /ndn/internal/B > This works so then I try tunneling form A to C: > First I end the ssh running between A and B. > Then on machine A: > ssh -L 5000::6363 > nfdc unregister /ndn/internal > nfdc register /ndn/internal udp://localhost:5000 > ndnping /ndn/internal/B > Of course, this does not work either. I have not tried the same thing with > ssh from a machine inside the firewall to a machine outside the firewall > (also running NFD) but if it does not work without a firewall in between > machines, it certainly won?t work with the firewall added. Thanks for any > help. > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From josh at caida.org Wed Dec 16 17:12:14 2015 From: josh at caida.org (Josh Polterock) Date: Wed, 16 Dec 2015 17:12:14 -0800 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for November/December 2015 Message-ID: <20151217011214.GB64232@caida.org> Named Data Networking (NDN) Project Holiday Newsletter for November/December 2015 The NDN project team compiles and publishes this newsletter monthly to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog. COMMUNITY OUTREACH * We published the "The Second Named Data Networking Community Meeting (NDNcomm 2015)", a brief summary of the second NDN Community Meeting held at UCLA in Los Angeles, California on September 28-29, 2015. The meeting provided a platform for the attendees from 49 institutions across 13 countries to exchange their recent NDN research and development results, to debate existing and proposed functionality in NDN forwarding, routing, and security, and to provide feedback to the NDN architecture design evolution. http://named-data.net/publications/second_ndncomm/ * The NDN project team has submitted a Letter of Intent to the NSF Industry/University Cooperative Research (I/UCRC) program, to explore this as a potential evolutionary path for the NDN consortium, as discussed at the last consortium meeting. According to the RFP, this program develops long-term partnerships among industry, academe, and government. "The Centers are catalyzed by an investment from the [NSF] and are primarily supported by industry Center members, with NSF taking a supporting role in the development and evolution of the Center." For more information on the program, see: http://www.nsf.gov/pubs/2016/nsf16504/nsf16504.htm. The project team plans to submit a planning grant to the July 11, 2016 deadline and encourages current and prospective members to contact us with any questions, concerns, ideas and expressions of interest about the program. We have received positive feedback from NSF to encourage the planning proposal submission. TECHNICAL NEWS * The NDN Testbed has grown to 28 Nodes with 66 links. Since our last newsletter, two new countries connected to the NDN Testbed. We added nodes at COPELABS (Cognition and People Centric Computing) at University of Lusofona in Portugal and at the University of Indonesia, Depok Indonesia. The NDN Testbed now spans 11 countries: USA, Switzerland, China, France, Indonesia, Italy, Japan, South Korea, Norway, Portugal, and Spain. To see the latest map with bandwidth usage see http://ndnmap.arl.wustl.edu/. * We announced the release of Mini-NDN v0.1.1. Mini-NDN is a lightweight networking emulation tool that enables testing, experimentation, and research on the NDN platform. Mini-NDN uses the NDN libraries, NFD, NLSR, and tools released by the NDN project to emulate an NDN network on a single system. Detailed release notes with new features, changes, and bug fixes can be found at: https://github.com/named-data/mini-ndn/blob/master/docs/RELEASE-NOTES.md More information about Mini-NDN, tutorials, installation and configuration guides, and documentation are available at the Mini-NDN Github repository: https://github.com/named-data/mini-ndn NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * Alexander Afanasyev, Yingdi Yu, Lixia Zhang, Jeff Burke, kc claffy, Joshua Polterock, "The Second Named Data Networking Community Meeting (NDNcomm 2015)" to appear in the Jan'16 issue of ACM SIGCOMM Computer Communication Review (CCR). http://named-data.net/publications/second_ndncomm/ * Susmit Shannigrahi of Colorado State presented the paper at the Fifth International Workshop on Network-Aware Data Management (NDM '15) titled "Managing scientific data with named data networking." This is a collaborative work by many authors: Chengyu Fan, Susmit Shannigrahi, Steve Dibendetto, Catherine Olschanowsky, Christos Papadopoulos, Harvey Newman, Edmund Yeh, Jean-Roch Vlimant, Azher Amin, Dorian Kcira, Iosif Legrand, Ramiro Voicu, David Randall, Kelley Wittmeyer, Mark Branson and Don Dazlich. Using ndn-atmos, an application built on NDN for managing scientific data, we demonstrated NDN's novel features such as intelligent data retrieval strategies, name discovery, data subsetting and publication protocol. The screencasts developed for this demo can be found here: http://www.cs.colostate.edu/~susmit/ndn_screencasts/ http://dx.doi.org/10.1145/2832099.2832100 * PI Lixia Zhang and Alex Afanasyev attended ICNRG meetings at IETF 94 in Yokohama, participated in discussions and presented "Shaping a New Architecture by Architectural Principles." https://www.ietf.org/proceedings/interim/2015/11/01/icnrg/slides/slides-interim-2015-icnrg-5-0.pdf * We posted revision 1 of the technical report "Name-Based Access Control." The report presents the design of Name-based Access Control (NAC), a model that encrypts content at the time of production and stores it in the network. We demonstrate how to make use of naming conventions to convey access control policy and distribute access control keys. The results suggests NAC is suitable for large-scale distributed data production and consumption. http://named-data.net/publications/techreports/ndn-0034-nac/ * We posted revision 5 of the technical report NDN-0021, "NFD Developer's Guide." NDN Forwarding Daemon (NFD) is a network forwarder that implements the Named Data Networking (NDN) protocol. NFD is designed with modularity and extensibility in mind to enable easy experiments with new protocol features, algorithms, and applications for NDN. To help developers extend and improve NFD, this document explains NFD's internals including the overall design, major modules, their implementations, and their interactions. http://named-data.net/publications/techreports/ndn-0021-5-nfd-developer-guide/ * We posted revision 1 of the technical report NDN-0035 "Creating A Secure, Integrated Home Network of Things with Named Data Networking." In this paper, we design a simple smart home network protocol to demonstrate the ways in which the Named Data Networking (NDN) internet layer protocol provides better support for these aspects of network protocol design than the traditional Internet Protocol (IP). We refer to this simple NDN-based protocol as the Named Data Network of Things (NDNoT). http://named-data.net/publications/techreports/ndn-0035-1-creating_secure_integrated/ NDN SEMINARS * Our NDN Seminar series continued during October. The NDN seminars are internally focused. We usually hold these seminars on Wednesday from 2-3p (PST). So, if you would like to be included in the NDN Seminars, please contact Jongdeog Lee for the most up-to-date information regarding upcoming seminars. - October 28th Jongdeog Lee (UIUC) InfoMax-An Information Maximizing Transport Layer Protocol for Named Data Networks - December 2nd Rodrigo Aldecoa (Northeastern University) Hyperbolic Routing (Theory) - December 16th Vince Lehman (University of Memphis) Hyperbolic Routing (Implementation) For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/. From cmurray at verisign.com Thu Dec 17 06:19:57 2015 From: cmurray at verisign.com (Murray, Craig) Date: Thu, 17 Dec 2015 14:19:57 +0000 Subject: [Ndn-interest] reaching NDN testbed from behind a firewall In-Reply-To: References: <2E283F1E-6562-4060-B40C-FEDD2E25A1FE@cs.ucla.edu> Message-ID: Thanks all! I have it working through ssh tunnel with using tcp. I will pursue better options also. Many thanks for the advice. ? Craig On 12/16/15, 7:05 PM, "Davide Pesavento" wrote: >On Thu, Dec 17, 2015 at 12:16 AM, Alex Afanasyev wrote: >> Hi Craig, >> >> ssh tunnels TCP port, so it is understandable why you have failed. >> >> You can try workarounds discussed here: >> http://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel or >>use > >The first answer in that thread is simply wrong in my opinion. There's >no guarantee that the TCP tunnel and the FIFO will preserve UDP >datagram boundaries, thus breaking any higher-layer protocols that >rely on them. > >The second answer (using the -w option of openssh) should work, but >requires superuser privileges at both ends of the tunnel. > >> tcp-based face when using the tunnel (tcp://localhost:5000) > >This is probably the easiest workaround. > >Also, it may be worth pointing out that, since version 6.7, openssh >supports forwarding of Unix domain sockets over the ssh tunnel, just >like TCP sockets. I've never tried this technique with NFD but it >should work fine. Unfortunately it's not a solution for the testbed >nodes (yet), since they don't have a recent enough version of openssh >installed. > >Best, >Davide > >> --- >> Alex >> >> On Dec 16, 2015, at 3:09 PM, Murray, Craig wrote: >> >> Hi all, >> >> I am trying to use NdnCom to connect with others on the testbed, but I >>am >> behind a firewall and port 6363 is not open. I thought I might be able >>to >> tunnel using ssh, but this does not work (below is more detail on what I >> tried). Does anyone have experience and/or suggestions that would help >>me? >> My guess is this is obvious to someone who knows more than I. My >>apologies >> if so. >> >> Thanks in advance for any help, >> Craig >> >> --------------------------------- >> Detail: >> I have three machines running NFD inside the firewall. >> First I tested that ndnping works between machines inside: >> On machine B I do the following: >> ndnpingserver /ndn/internal/B >> On machine A I do the following: >> nfdc register /ndn/internal udp:// >> ndnping /ndn/internal/B >> Of course this works. Next I remove entries from NFD tables >> On machine A I do the following: >> nfdc unregister /ndn/internal >> Next I ssh from machine A to machine B, forwarding a port >> On machine A I do the following: >> ssh -L 4000:localhost:6363 >> nfdc register /ndn/internal udp://localhost:4000 >> ndnping /ndn/internal/B >> This does not work. Packets time out. >> >> I have also tried the following: >> On machine C I do: >> nfdc register /ndn/internal udp:// >> ndnping /ndn/internal/B >> This works so then I try tunneling form A to C: >> First I end the ssh running between A and B. >> Then on machine A: >> ssh -L 5000::6363 >> nfdc unregister /ndn/internal >> nfdc register /ndn/internal udp://localhost:5000 >> ndnping /ndn/internal/B >> Of course, this does not work either. I have not tried the same thing >>with >> ssh from a machine inside the firewall to a machine outside the firewall >> (also running NFD) but if it does not work without a firewall in between >> machines, it certainly won?t work with the firewall added. Thanks for >>any >> help. >> >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> From jburke at remap.ucla.edu Wed Dec 23 12:35:59 2015 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Wed, 23 Dec 2015 20:35:59 +0000 Subject: [Ndn-interest] ACM ICN 2016 CFP Posted Message-ID: <1C619C3D-6871-4F83-B1D3-64B0FB984BC6@remap.ucla.edu> http://conferences2.sigcomm.org/acm-icn/2016/cfp.php Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Thu Dec 31 11:09:24 2015 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 31 Dec 2015 11:09:24 -0800 Subject: [Ndn-interest] NFD/ndn-cxx release 0.4.0 Message-ID: <7932B802-830E-4196-9082-B73E31BE3044@cs.ucla.edu> Dear all, Happy New Year to everybody! We are also pleased to announce the release of version 0.4.0 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. The detailed notes for the releases: - for NFD: http://named-data.net/doc/NFD/0.4.0/RELEASE_NOTES.html - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.4.0/RELEASE_NOTES.html *** Please note that this release contains several breaking changes to face system and configuration files. See more details in the release notes. *** Source code, instruction how to install NFD on Ubuntu Linux (12.04, 14.04, and 15.10) and OS X (10.9, 10.10, 10.11), tutorials, HOWTOs, a FAQ and other useful resources are available on official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.4.0/ - http://named-data.net/doc/ndn-cxx/0.4.0/ We also have updated the NFD developer's guide to revision 5 (more updates coming before the next release): - http://named-data.net/techreport/ndn-0021-5-nfd-developer-guide.pdf. * * * The NDN/NFD Team: Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko, Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon Mastorakis, Yi Huang, Jerald Paul Abraham, Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide Pesavento, Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila Ben Abraham, Patrick Crowley, Syed Obaid Amin, Vince Lehman, Lan Wang, Eric Newberry, Yukai Tu, Muktadir Chowdhury, and others (http://named-data.net/project/participants/) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: