From zeynalvand at ce.sharif.edu Tue Jan 6 09:32:25 2015 From: zeynalvand at ce.sharif.edu (L.Zeynalvand) Date: Tue, 06 Jan 2015 21:02:25 +0330 Subject: [Ndn-interest] NFD Development - Content Store In-Reply-To: References: Message-ID: <651747ff438e191ebe85214633034d69@ce.sharif.edu> Is there a way to make the Content Store persistent? By persistent I don't mean no cache replacement, what I mean is that if for any reason we power off the router and then power back on, whatever there was in content store remain intact. (consider the router is an end user wifi router) Regards, -- Leonid Zeynalvand M.Sc Information Technology Sharif University of Technology From chaim.rieger at gmail.com Wed Jan 7 09:09:08 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 07 Jan 2015 09:09:08 -0800 Subject: [Ndn-interest] Concept of ports Message-ID: <54AD6834.5020600@gmail.com> Hi all, am new here, searched the archives as well as the available information yet did not find a definitive answer. Does the concept of ports go away with NDN ? Being that a port is a logical flag in a tcp stream, and ND has each packet flagged by application/device, does it need or allow port information within its packet structure ? From shijunxiao at email.arizona.edu Wed Jan 7 12:38:07 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 7 Jan 2015 13:38:07 -0700 Subject: [Ndn-interest] Concept of ports In-Reply-To: <54AD6834.5020600@gmail.com> References: <54AD6834.5020600@gmail.com> Message-ID: Hi Chaim A TCP or UDP endpoint is identified by IP address and port number. IP address is used for forwarding between nodes, and port number is used for demultiplexing within a node. An NDN endpoint (application) is identified by Name prefix. The Name prefix is used both for forwarding between nodes and demultiplexing within a node. Thus, a Name prefix that appears in the RIB of an end host roughly equals IP address plus port number. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc at caida.org Mon Jan 12 22:25:20 2015 From: kc at caida.org (k claffy) Date: Mon, 12 Jan 2015 22:25:20 -0800 Subject: [Ndn-interest] NDNcomm2014 report draft published Message-ID: <20150113062520.GA95407@caida.org> the attached pdf will be posted on named-data.net and linked from http://www.caida.org/workshops/ndn/1409/ tomorrow. comments welcome, we have submitted to ccr for april publication we hope thanks, k -------------- next part -------------- A non-text attachment was scrubbed... Name: ndncomm2014-report.pdf Type: application/octet-stream Size: 138687 bytes Desc: not available URL: From schwannden at gmail.com Thu Jan 15 18:52:41 2015 From: schwannden at gmail.com (AnChe Kuo) Date: Fri, 16 Jan 2015 10:52:41 +0800 Subject: [Ndn-interest] How is scalability done globally given current name structure Message-ID: Dear Sir or Madam I am an intern at Academia Sinica and a student at NCTU, Taiwan, and I have been studying NDN for a few month now. If I wrote an application and call it "Foo", then can I simply register "Foo" into the global NDN network? Given current architecture, each router administrator is allowed to register only names satisfying certain pattern that is assigned to them, right? So if Academia Sinica now joins NDN network, we might get a prefix "ndn/tw/sinica", which means I can only register my application as "ndn/tw/sinica/Foo". But this present a problem. If some one in UCLA decided that she loves this application, and also runs a producer there, she would have to register it as "/ndn/edu/ucla/Foo". Now how can a client in China get the content that is closest to him if he only knows the application name "Foo"? If he sends an interest named "Foo", then longest prefix match won't find anything. If he has to know the full name "/ndn/edu/ucla/Foo", then we have lost the benefit of NDN architecture, because it is almost equivalent to an exact source, not just a content name. So how does NDN intend to solve the problem? 1. If NDN only focus on a small network, with applications for IoT or M2M can register their names freely, then what are the benefits of NDN other then its more natural architecture for related application? If we look at efficiency, then TCP/IP is probably enough for a small area network, will NDN offer the improvement that is necessary? 2. If we release the top level namespace for all applications to register, so that we may register "Foo" into global routers, with these top level namespace managed by some organization (similar to ICANN), then will we suffer from routing table explosion? Because now we have each unique URLs, and millions of different applications registered at the top level to serve the global users. So far these are my concerns. I understand I might be having the wrong question, because it might no be the intended use of NDN or the current objective of the whole NDN project. But either way I would love to hear from your feedback, or any critique on my question is welcomed. -- Best Wishes, ??? Kuo, AnChe(Schwannden) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.detti at uniroma2.it Fri Jan 16 01:16:18 2015 From: andrea.detti at uniroma2.it (Andrea Detti) Date: Fri, 16 Jan 2015 10:16:18 +0100 Subject: [Ndn-interest] How is scalability done globally given current name structure In-Reply-To: References: Message-ID: <54B8D6E2.4070903@uniroma2.it> Dear Kuo, this seems to me again the plain old scalability problem of NDN/CCN that I (re)-observed in the mailing list some days ago (see my mails or Locator hints, updated cisco packet format draft). I proposed the introduction of a ContentLocator TLV field (aka locator hint, routing info, forwarding alias, etc. ) which contains a set of names used to help routing in those contexts where pure routing by object name practically does not scale. ContentLocator is used by an NDN/CCN router when FIB is unable to forward on (Object) name. Thus in your case the Interest fields would be: (Object) Name : Foo ContentLocator : {ndn/tw/sinica/Foo; ndn/edu/ucla/Foo} The NDN strategy layer chooses which is the better serving location between ndn/tw/sinica/Foo and ndn/edu/ucla/Foo Only ndn/tw/sinica/ and ndn/edu/ucla/ are advertized on the global routing plane, thus reducing the FIB entries to the (e.g.) number of Autonomous Systems. Plain old locator identifier split approach proposed by several researchers before me. Clearly, you need a secure, reliable and scalable resolution system (as properly observed by DaveO) to obtain the ContentLocator field at the communication session start. And also a name management system that authorizes you tho name an object as Foo. I guess that sooner or later people mostly involved in defining the NDN/CCN protocol will face this old scalability problem (I apologize if you already solved this scalability issue and I miss some information) . Conversely, as now it seems to me, this technology can be used only in small closed environments, that however could be an interesting use-case too, albeit with a little bit smaller impact with respect to the original global scope: "Information-centric networking (ICN) is an approach to evolve the Internet infrastructure" (citing ICNRG home page) Andrea On 01/16/2015 03:52 AM, AnChe Kuo wrote: > Dear Sir or Madam > > I am an intern at Academia Sinica and a student at NCTU, Taiwan, > and I have been studying NDN for a few month now. > > If I wrote an application and call it "Foo", then can I simply > register "Foo" into the global NDN network? Given current > architecture, each router administrator is allowed to register only > names satisfying certain pattern that is assigned to them, right? So > if Academia Sinica now joins NDN network, we might get a prefix > "ndn/tw/sinica", which means I can only register my application as > "ndn/tw/sinica/Foo". > > But this present a problem. If some one in UCLA decided that she loves > this application, and also runs a producer there, she would have to > register it as "/ndn/edu/ucla/Foo". Now how can a client in China get > the content that is closest to him if he only knows the application > name "Foo"? If he sends an interest named "Foo", then longest prefix > match won't find anything. If he has to know the full name > "/ndn/edu/ucla/Foo", then we have lost the benefit of > NDN architecture, because it is almost equivalent to an exact source, > not just a content name. > > So how does NDN intend to solve the problem? > 1. If NDN only focus on a small network, with applications for IoT or > M2M can register their names freely, then what are the benefits of NDN > other then its more natural architecture for related application? If > we look at efficiency, then TCP/IP is probably enough for a small area > network, will NDN offer the improvement that is necessary? > 2. If we release the top level namespace for all applications to > register, so that we may register "Foo" into global routers, with > these top level namespace managed by some organization (similar to > ICANN), then will we suffer from routing table explosion? Because now > we have each unique URLs, and millions of different applications > registered at the top level to serve the global users. > > So far these are my concerns. I understand I might be having the wrong > question, because it might no be the intended use of NDN or the > current objective of the whole NDN project. But either way I would > love to hear from your feedback, or any critique on my question is > welcomed. > > > -- > Best Wishes, > ??? > Kuo, AnChe(Schwannden) > > > _______________________________________________ > 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 chaim.rieger at gmail.com Fri Jan 16 19:15:30 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Fri, 16 Jan 2015 19:15:30 -0800 Subject: [Ndn-interest] How is scalability done globally given current name structure In-Reply-To: <54B8D6E2.4070903@uniroma2.it> References: <54B8D6E2.4070903@uniroma2.it> Message-ID: <54B9D3D2.4060204@gmail.com> On 1/16/2015 1:16 AM, Andrea Detti wrote: > Dear Kuo, > this seems to me again the plain old scalability problem of NDN/CCN > that I (re)-observed in the mailing list some days ago (see my mails > or Locator hints, updated cisco packet format draft). > > I proposed the introduction of a ContentLocator TLV field (aka locator > hint, routing info, forwarding alias, etc. ) which contains a set of > names used to help routing in those contexts where pure routing by > object name practically does not scale. ContentLocator is used by an > NDN/CCN router when FIB is unable to forward on (Object) name. > > Thus in your case the Interest fields would be: > > (Object) Name : Foo > ContentLocator : {ndn/tw/sinica/Foo; ndn/edu/ucla/Foo} > > The NDN strategy layer chooses which is the better serving location > between ndn/tw/sinica/Foo and ndn/edu/ucla/Foo > > Only ndn/tw/sinica/ and ndn/edu/ucla/ are advertized on the global > routing plane, thus reducing the FIB entries to the (e.g.) number of > Autonomous Systems. Plain old locator identifier split approach > proposed by several researchers before me. > > Clearly, you need a secure, reliable and scalable resolution system > (as properly observed by DaveO) to obtain the ContentLocator field at > the communication session start. And also a name management system > that authorizes you tho name an object as Foo. > > I guess that sooner or later people mostly involved in defining the > NDN/CCN protocol will face this old scalability problem (I apologize > if you already solved this scalability issue and I miss some > information) . > > Conversely, as now it seems to me, this technology can be used only in > small closed environments, that however could be an interesting > use-case too, albeit with a little bit smaller impact with respect to > the original global scope: "Information-centric networking (ICN) is an > approach to evolve the Internet infrastructure" (citing ICNRG home page) > > Andrea Why can this naming convention only be used on small scale, why not take the philosophy of the DNS convention and apply it as follows. Each name that must be publicly routable is advertised to the world Only top level domain should be advertised within each top level domain all the subdomain (or sub data) are/is only routable within the self domain This will allow (for example) UCLA to control and allocate names to all data within the UCLA network, and not have to advertise routing for it. Why not let each entity control their own naming convention, which will in turn also place the responsibility for routing within self on said entity and not on the rest of the world keeping the public routing tables very small. Correct me if I am completely out out line please. From tailinchu at gmail.com Fri Jan 16 22:27:07 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 16 Jan 2015 22:27:07 -0800 Subject: [Ndn-interest] How is scalability done globally given current name structure In-Reply-To: <54B9D3D2.4060204@gmail.com> References: <54B8D6E2.4070903@uniroma2.it> <54B9D3D2.4060204@gmail.com> Message-ID: Chaim Rieger's idea is what ndn is going now. On Fri, Jan 16, 2015 at 7:15 PM, Chaim Rieger wrote: > On 1/16/2015 1:16 AM, Andrea Detti wrote: >> Dear Kuo, >> this seems to me again the plain old scalability problem of NDN/CCN >> that I (re)-observed in the mailing list some days ago (see my mails >> or Locator hints, updated cisco packet format draft). >> >> I proposed the introduction of a ContentLocator TLV field (aka locator >> hint, routing info, forwarding alias, etc. ) which contains a set of >> names used to help routing in those contexts where pure routing by >> object name practically does not scale. ContentLocator is used by an >> NDN/CCN router when FIB is unable to forward on (Object) name. >> >> Thus in your case the Interest fields would be: >> >> (Object) Name : Foo >> ContentLocator : {ndn/tw/sinica/Foo; ndn/edu/ucla/Foo} >> >> The NDN strategy layer chooses which is the better serving location >> between ndn/tw/sinica/Foo and ndn/edu/ucla/Foo >> >> Only ndn/tw/sinica/ and ndn/edu/ucla/ are advertized on the global >> routing plane, thus reducing the FIB entries to the (e.g.) number of >> Autonomous Systems. Plain old locator identifier split approach >> proposed by several researchers before me. >> >> Clearly, you need a secure, reliable and scalable resolution system >> (as properly observed by DaveO) to obtain the ContentLocator field at >> the communication session start. And also a name management system >> that authorizes you tho name an object as Foo. >> >> I guess that sooner or later people mostly involved in defining the >> NDN/CCN protocol will face this old scalability problem (I apologize >> if you already solved this scalability issue and I miss some >> information) . >> >> Conversely, as now it seems to me, this technology can be used only in >> small closed environments, that however could be an interesting >> use-case too, albeit with a little bit smaller impact with respect to >> the original global scope: "Information-centric networking (ICN) is an >> approach to evolve the Internet infrastructure" (citing ICNRG home page) >> >> Andrea > > Why can this naming convention only be used on small scale, why not take > the philosophy of the DNS convention and apply it as follows. > > Each name that must be publicly routable is advertised to the world > Only top level domain should be advertised > within each top level domain all the subdomain (or sub data) are/is only > routable within the self domain > > This will allow (for example) UCLA to control and allocate names to all > data within the UCLA network, and not have to advertise routing for it. > > Why not let each entity control their own naming convention, which will > in turn also place the responsibility for routing within self on said > entity and not on the rest of the world keeping the public routing > tables very small. > > Correct me if I am completely out out line please. > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From andrea.detti at uniroma2.it Mon Jan 19 00:38:41 2015 From: andrea.detti at uniroma2.it (Andrea Detti) Date: Mon, 19 Jan 2015 09:38:41 +0100 Subject: [Ndn-interest] How is scalability done globally given current name structure In-Reply-To: <54B9D3D2.4060204@gmail.com> References: <54B8D6E2.4070903@uniroma2.it> <54B9D3D2.4060204@gmail.com> Message-ID: <54BCC291.60206@uniroma2.it> On 01/17/2015 04:15 AM, Chaim Rieger wrote: > On 1/16/2015 1:16 AM, Andrea Detti wrote: >> Dear Kuo, >> this seems to me again the plain old scalability problem of NDN/CCN >> that I (re)-observed in the mailing list some days ago (see my mails >> or Locator hints, updated cisco packet format draft). >> >> I proposed the introduction of a ContentLocator TLV field (aka locator >> hint, routing info, forwarding alias, etc. ) which contains a set of >> names used to help routing in those contexts where pure routing by >> object name practically does not scale. ContentLocator is used by an >> NDN/CCN router when FIB is unable to forward on (Object) name. >> >> Thus in your case the Interest fields would be: >> >> (Object) Name : Foo >> ContentLocator : {ndn/tw/sinica/Foo; ndn/edu/ucla/Foo} >> >> The NDN strategy layer chooses which is the better serving location >> between ndn/tw/sinica/Foo and ndn/edu/ucla/Foo >> >> Only ndn/tw/sinica/ and ndn/edu/ucla/ are advertized on the global >> routing plane, thus reducing the FIB entries to the (e.g.) number of >> Autonomous Systems. Plain old locator identifier split approach >> proposed by several researchers before me. >> >> Clearly, you need a secure, reliable and scalable resolution system >> (as properly observed by DaveO) to obtain the ContentLocator field at >> the communication session start. And also a name management system >> that authorizes you tho name an object as Foo. >> >> I guess that sooner or later people mostly involved in defining the >> NDN/CCN protocol will face this old scalability problem (I apologize >> if you already solved this scalability issue and I miss some >> information) . >> >> Conversely, as now it seems to me, this technology can be used only in >> small closed environments, that however could be an interesting >> use-case too, albeit with a little bit smaller impact with respect to >> the original global scope: "Information-centric networking (ICN) is an >> approach to evolve the Internet infrastructure" (citing ICNRG home page) >> >> Andrea > Why can this naming convention only be used on small scale, why not take > the philosophy of the DNS convention and apply it as follows. > > Each name that must be publicly routable is advertised to the world > Only top level domain should be advertised > within each top level domain all the subdomain (or sub data) are/is only > routable within the self domain > > This will allow (for example) UCLA to control and allocate names to all > data within the UCLA network, and not have to advertise routing for it. > > Why not let each entity control their own naming convention, which will > in turn also place the responsibility for routing within self on said > entity and not on the rest of the world keeping the public routing > tables very small. > > Correct me if I am completely out out line please. In doing so, if you have a same content foo.mp4 on youtube and on vimeo, the content would have two different names: youtube.com/foo.mp4 and vimeo,com/foo.mp4. And this prevents the exploitation of multi-sources in a NDN, that is a relevant regression in my point of view. This is exactly the practical issue raised by Kuo in the initial mail of the thread. Including in a name a prefix that is actually a routing locator (domain, AS, or whatever else) in my opinion is in contrast with respect to the initial NDN philosophy of binding communication sessions on "what" rather than on "where". Moreover, in case of mobility it is well know that including a locator in the name may be a serious problem. Andrea > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From ooofreedom at gmail.com Tue Jan 20 13:33:58 2015 From: ooofreedom at gmail.com (Lijing Wang) Date: Tue, 20 Jan 2015 13:33:58 -0800 Subject: [Ndn-interest] seeking for a girl to share a room during 5th NDN Retreat 2015 Message-ID: Hi, everyone. I?m a PhD student studying in UCLA NDN group. Now I?m seeking for a girl to share a room with me during 5th NDN Retreat 2015 in San Diego, cause I?m the only girl of our group who decided to join the meeting. If you?re interested, please mail me. Thanks! Lijing From chenatu2006 at gmail.com Tue Jan 20 19:22:37 2015 From: chenatu2006 at gmail.com (Shuo Chen) Date: Wed, 21 Jan 2015 11:22:37 +0800 Subject: [Ndn-interest] Should segmentation be supported by NDN underlying protocol? Message-ID: Hi all, This question comes from the size of interest. Data packet could be appended with segment number or version number. But how to deal with interest whose size exceeds the network packet payload size limit? Should it be segmented by underlying protocol? ---- Shuo Chen Tsinghua University -------------- next part -------------- An HTML attachment was scrubbed... URL: From gts at ics.uci.EDU Tue Jan 20 20:27:19 2015 From: gts at ics.uci.EDU (GTS) Date: Tue, 20 Jan 2015 20:27:19 -0800 Subject: [Ndn-interest] Should segmentation be supported by NDN underlying protocol? In-Reply-To: References: Message-ID: <54BF2AA7.2090400@ics.uci.edu> Hi Shuo, we (at UCI) in collaboration with folks at CISCO have considered this issue and its security implications. You can have a look at: http://arxiv.org/abs/1405.2861 (Section IV.A talks about interests). A newer version of the same work is attached to this email. Regards, Gene ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 1/20/15 7:22 PM, Shuo Chen wrote: > Hi all, > > This question comes from the size of interest. Data packet could be > appended with segment number or version number. But how to deal with > interest whose size exceeds the network packet payload size limit? > Should it be segmented by underlying protocol? > > > ---- > Shuo Chen > Tsinghua University > > > _______________________________________________ > 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: frag.pdf Type: application/x-download Size: 579829 bytes Desc: not available URL: From qnick at qnick.ru Wed Jan 21 05:40:09 2015 From: qnick at qnick.ru (qnick at qnick.ru) Date: Wed, 21 Jan 2015 16:40:09 +0300 Subject: [Ndn-interest] Ndn-interest Digest, Vol 10, Issue 3 In-Reply-To: References: Message-ID: <2464221421847609@web21j.yandex.ru> Hello, I'm new here and have some dumb questions after installing NFD on several pcs: - What should I do to view the full FIB table? smth like "nfdc print" - Is it possible to create one shared namespace for number of pcs? Like that: nfdc register /ndn/test udp://pc1 nfdc register /ndn/test udp://pc2 nfdc register /ndn/test udp://pc3 Thank you. Nikita. PS: NFD package for Debian jessie/wheezy reqested =) From dibenede at cs.colostate.edu Wed Jan 21 05:52:33 2015 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Wed, 21 Jan 2015 06:52:33 -0700 Subject: [Ndn-interest] Ndn-interest Digest, Vol 10, Issue 3 In-Reply-To: <2464221421847609@web21j.yandex.ru> References: <2464221421847609@web21j.yandex.ru> Message-ID: On Wed, Jan 21, 2015 at 6:40 AM, wrote: > Hello, > I'm new here and have some dumb questions after installing NFD on several > pcs: > - What should I do to view the full FIB table? smth like "nfdc print" > You can use nfd-status -b . Omitting the option dumps the FIB and more. > - Is it possible to create one shared namespace for number of pcs? Like > that: > nfdc register /ndn/test udp://pc1 > nfdc register /ndn/test udp://pc2 > nfdc register /ndn/test udp://pc3 > Yes, but I think the default forwarding strategy is BestRoute, so all Interest traffic for the prefix will be sent to one machine. You can check the active strategy with nfd-status -s and change it with nfdc set-strategy /ndn/test . Other strategy options are Broadcast and NCC: /localhost/nfd/strategy/broadcast /localhost/nfd/strategy/ncc > > Thank you. > > Nikita. > > PS: NFD package for Debian jessie/wheezy reqested =) > _______________________________________________ > 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 kosalase at gmail.com Wed Jan 21 22:14:48 2015 From: kosalase at gmail.com (Kosala Senevirathna) Date: Thu, 22 Jan 2015 17:14:48 +1100 Subject: [Ndn-interest] Security issues Message-ID: Hi, I am searching on security issues on NDN which are currently discussing. I noted few cases but wish to know a list of identified issues. Can anyone give me some info. pls. Regards, Kos -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Jan 22 15:59:55 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 22 Jan 2015 16:59:55 -0700 Subject: [Ndn-interest] Security issues In-Reply-To: References: Message-ID: Hi Kos Please watch ndn-cxx Task 2123 for discussion about NDN certificate design. Please subscribe to ndn-sec mailing list < http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-sec> for security issues in NDN architecture. Yours, Junxiao On Wed, Jan 21, 2015 at 11:14 PM, Kosala Senevirathna wrote: > > Hi, > > I am searching on security issues on NDN which are currently discussing. > I noted few cases but wish to know a list of identified issues. > > Can anyone give me some info. pls. > > > Regards, > > Kos > > _______________________________________________ > 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 jburke at remap.UCLA.EDU Thu Jan 29 10:39:45 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Thu, 29 Jan 2015 18:39:45 +0000 Subject: [Ndn-interest] NDN Video FAQ 5 posted on vehicular networking Message-ID: Video FAQ #5 from Giovanni Pau on vehicular networking has been posted here: https://vimeo.com/117022616 Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: