From aa at CS.UCLA.EDU Mon Feb 1 09:58:58 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 1 Feb 2016 09:58:58 -0800 Subject: [Nfd-dev] NFD-android 0.2.0 (based on NFD 0.4.0) Message-ID: <03A11D37-11E9-4A02-908E-8F03BBD4A818@cs.ucla.edu> Hi all, I just want to highlight that we pushed an updated version of NFD-android to Google Play (0.2.0 based on NFD 0.4.0). It is still in alpha testing and the latest code is still under review. If you haven't yet opt-in to alpha testing, please go here: https://play.google.com/apps/testing/net.named_data.nfd. If you have opt-in before, you should have gotten the update automatically. Please let us know about any problems you found either by filing bug reports (http://redmine.named-data.net/projects/nfd-android) or by email. I would also would like to invite everybody to participate in development of the app and making it better. There are multiple directions of improvement, from pure GUI additions (e.g., settings dialog) to more complex Java-JNI-C++ fixes. Thanks, Alex -------------- 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 nfd-call-notification at mail1.yoursunny.com Tue Feb 2 07:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 2 Feb 2016 08:00:03 -0700 Subject: [Nfd-dev] NFD call 20160202 Message-ID: <201602021500.u12F03pl005577@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From bruno.ricci at uniroma2.it Tue Feb 2 07:50:52 2016 From: bruno.ricci at uniroma2.it (Bruno Ricci) Date: Tue, 2 Feb 2016 16:50:52 +0100 Subject: [Nfd-dev] Insertion in name tree Message-ID: <56B0D05C.3040909@uniroma2.it> Dear all, I have a small question regarding how insertions on name tree are made. Suppose one has a name, for instance /aaaaa/bbbbb/ccccc/ddddd/eeeee. Running nfdc register, I noticed that while the lookup operation is made on the entire prefix, the insertion operation on name-tree.cpp is made with a for loop, so that on each step we add a component: first /aaaaa, then /aaaaa/bbbbb, and so on (see the attached small log of nametree, I ran NFD, made a register and stopped NFD). The question then is: why are the insertion of "long" names treated in this way, and not directly adding the full name? Is that an optimization for further insertions? Thanks in advance. Bruno -- ---------------------------------------------------------------------- Bruno Ricci, Ph.D. Post-doc Researcher CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni Department of Electronic Engineering, University of Rome "Tor Vergata" Website: http://netgroup.uniroma2.it/bruno-ricci/ Tel.: +39 06 7259 7445 -------------- next part -------------- STARTING NFD lookup start /ndn/broadcast insert start /ndn insert end /ndn insert start /ndn/broadcast insert end /ndn/broadcast lookup end /ndn/broadcast findLongestPrefixMatch start /ndn/broadcast findLongestPrefixMatch end /ndn/broadcast findExactMatch start /ndn/broadcast findExactMatch end /ndn/broadcast fullEnumerate start fullEnumerate end lookup start /aaaaa/bbbbb/ccccc/ddddd/eeeee insert start /aaaaa insert end /aaaaa insert start /aaaaa/bbbbb insert end /aaaaa/bbbbb insert start /aaaaa/bbbbb/ccccc insert end /aaaaa/bbbbb/ccccc insert start /aaaaa/bbbbb/ccccc/ddddd insert end /aaaaa/bbbbb/ccccc/ddddd insert start /aaaaa/bbbbb/ccccc/ddddd/eeeee insert end /aaaaa/bbbbb/ccccc/ddddd/eeeee lookup end /aaaaa/bbbbb/ccccc/ddddd/eeeee STOPPING NFD From nfd-call-notification at mail1.yoursunny.com Thu Feb 4 07:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 4 Feb 2016 08:00:03 -0700 Subject: [Nfd-dev] NFD call 20160204 Message-ID: <201602041500.u14F03rF023880@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Fri Feb 5 14:33:27 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 5 Feb 2016 14:33:27 -0800 Subject: [Nfd-dev] [NDN Principles] Call Message-ID: Let us start the call to finalize the NDN principles. The first one will be today 8pm PST (Friday) on skype (join if you can). Before the call, I'll share the slide deck where I put each principle and few details about the principle that we can refine during the call. I would like also reserver slot tomorrow 8pm PST (Saturday). Depending on the progress today and tomorrow, we will schedule more calls. -- Alex -------------- 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 lixia at CS.UCLA.EDU Fri Feb 5 14:47:26 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Fri, 5 Feb 2016 14:47:26 -0800 Subject: [Nfd-dev] [NDN Principles] Call In-Reply-To: References: Message-ID: <75C1633D-39A0-40B9-9A47-1EE2A9795933@cs.ucla.edu> > On Feb 5, 2016, at 2:33 PM, Alex Afanasyev wrote: > > Let us start the call to finalize the NDN principles. The first one will be today 8pm PST (Friday) on skype (join if you can). > > Before the call, I'll share the slide deck where I put each principle and few details about the principle that we can refine during the call. > > I would like also reserver slot tomorrow 8pm PST (Saturday). Depending on the progress today and tomorrow, we will schedule more calls. > > -- > Alex my apology -- I forgot that today is UCLA's annual engineering award dinner, taht'll last till 9PM I believe. I could do a chat right after 3:30PM congestion control From aa at CS.UCLA.EDU Fri Feb 5 14:48:33 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 5 Feb 2016 14:48:33 -0800 Subject: [Nfd-dev] [NDN Principles] Call In-Reply-To: <75C1633D-39A0-40B9-9A47-1EE2A9795933@cs.ucla.edu> References: <75C1633D-39A0-40B9-9A47-1EE2A9795933@cs.ucla.edu> Message-ID: <5CA9C22D-839E-42A0-B47F-53DE8B8711EA@cs.ucla.edu> > On Feb 5, 2016, at 2:47 PM, Lixia Zhang wrote: > > >> On Feb 5, 2016, at 2:33 PM, Alex Afanasyev wrote: >> >> Let us start the call to finalize the NDN principles. The first one will be today 8pm PST (Friday) on skype (join if you can). >> >> Before the call, I'll share the slide deck where I put each principle and few details about the principle that we can refine during the call. >> >> I would like also reserver slot tomorrow 8pm PST (Saturday). Depending on the progress today and tomorrow, we will schedule more calls. >> >> -- >> Alex > > my apology -- I forgot that today is UCLA's annual engineering award dinner, taht'll last till 9PM I believe. > > I could do a chat right after 3:30PM congestion control I'm not ready yet... (moving cyclops to CSU). We can start tomorrow then. -------------- 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 aa at CS.UCLA.EDU Fri Feb 5 15:09:28 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 5 Feb 2016 15:09:28 -0800 Subject: [Nfd-dev] [NDN Principles] Call In-Reply-To: References: Message-ID: <9521951E-EE3F-4F99-8475-B4107C9B7D2D@cs.ucla.edu> My apologies for accidentally sending this email to the mailing list (Mail.app has real problems with previous recipients management). Just as a short background, we are working on an initial list of NDN design principles to kick start discussions on ndn-interest real soon. --- Alex > On Feb 5, 2016, at 2:33 PM, Alex Afanasyev wrote: > > Let us start the call to finalize the NDN principles. The first one will be today 8pm PST (Friday) on skype (join if you can). > > Before the call, I'll share the slide deck where I put each principle and few details about the principle that we can refine during the call. > > I would like also reserver slot tomorrow 8pm PST (Saturday). Depending on the progress today and tomorrow, we will schedule more calls. > > -- > Alex > -------------- 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 shijunxiao at email.arizona.edu Sun Feb 7 20:19:00 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 7 Feb 2016 21:19:00 -0700 Subject: [Nfd-dev] Fwd: Modify data packet In-Reply-To: <56B8157E.8010407@cs.arizona.edu> References: <56B8157E.8010407@cs.arizona.edu> Message-ID: ---------- Forwarded message ---------- From: "Klaus Schneider" Date: Feb 7, 2016 21:11 Subject: Modify data packet To: "Junxiao Shi" Cc: Hi Junxiao, is it possible to modify the data packet inside the call beforeSatisfyInterest(shared_ptr pitEntry, const Face& inFace, const Data& data) ? Can I for example set a new type like this: data.getMetaInfo().setType(XY); I tried it, but it doesn't seem to work for me. Best regards, Klaus -------------- next part -------------- An HTML attachment was scrubbed... URL: From bigcatlei at gmail.com Mon Feb 8 16:36:18 2016 From: bigcatlei at gmail.com (Lei Liu) Date: Mon, 8 Feb 2016 16:36:18 -0800 Subject: [Nfd-dev] How to use the client control forwarding strategy Message-ID: Hi, Can anyone help to elaborate how to enable the client control forwarding strategy in NFD? I understand that by using nfdc, we can set strategy to a name such as: nfdc set-strategy ndn:/app1/video ndn:/localhost/nfd/strategy/client-control Then, suppose we have an interest like /app1/video, how can we force it to be forwarded to a specific face? NFD developer guide mentioned a NextHopFaceId field in the interest message, but how to enable this feature and send an interest with a NextHopFaceId field? Thanks, Best regards, Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From mastorakis at CS.UCLA.EDU Mon Feb 8 16:50:04 2016 From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis) Date: Mon, 8 Feb 2016 16:50:04 -0800 Subject: [Nfd-dev] [ndnSIM] regarding block.hpp In-Reply-To: References: Message-ID: Hi Carl, since this seems to be a documentation issue of ndn-cxx, but related to ndnSIM at the same time, I would like this email to be on the nfd-dev mailing list as well. The general guidance that I could give you is (as you correctly pointed out) that in NDN we follow the TLV format (that is, Type - Length - Value). To that end, you will have to create your own methods (or extend the existing ones) to encode and decode something to/from wire format. If you could be more specific on the things that you would like to achieve, I could provide more help. In general, the Block class of ndn-cxx, provides encoders and decoders for many different types of data in order to abstract the low layer details from the developer. As far as the documentation issue is concerned, thank you for bringing this up. We will try to address it in the near future. Thank you, Spyridon (Spyros) Mastorakis Personal Website: http://cs.ucla.edu/~mastorakis/ Internet Research Laboratory Computer Science Department UCLA > On Feb 8, 2016, at 3:10 PM, Carl Zu wrote: > > I think lack of documentation is a problem... > > I wanted to write some bytes in the interest message in ndnSIM. In ns3, thanks to their documentation, one can easily understand that in order to write some bytes, he should serialize a header. > > For doing the same thing in ndnSIM, I have had the impression that I should use "block". Moreover, It looks as though an interest message is a set of TLVs (based on the explanation in the NDN project website). So probably if I like to write eight bytes as four pieces of two-byte data, I should write four TLVs. But indeed, there are many constructors in block.hpp, and it's just about looking at one code after another to understand each of them due to lack of documentation... > > Can someone please give some guidance ???. > > thanks and rgds. > C -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Mon Feb 8 17:09:47 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 8 Feb 2016 17:09:47 -0800 Subject: [Nfd-dev] Modify data packet In-Reply-To: References: <56B8157E.8010407@cs.arizona.edu> Message-ID: > On Feb 7, 2016, at 8:19 PM, Junxiao Shi wrote: > > ---------- Forwarded message ---------- > From: "Klaus Schneider" > > Date: Feb 7, 2016 21:11 > Subject: Modify data packet > To: "Junxiao Shi" > > Cc: > > Hi Junxiao, > > is it possible to modify the data packet inside the call beforeSatisfyInterest(shared_ptr pitEntry, const Face& inFace, const Data& data) ? > > Can I for example set a new type like this: > > data.getMetaInfo().setType(XY); > > I tried it, but it doesn't seem to work for me. > > Best regards, > Klaus Data packet is marked const in the method interface and it is incorrect to modify the data packet from NDN semantical view. In other words, modification of the data packet will violate immutability of data and invalidated signatures. -- Alex -------------- 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 shijunxiao at email.arizona.EDU Mon Feb 8 17:19:08 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Mon, 8 Feb 2016 18:19:08 -0700 Subject: [Nfd-dev] How to use the client control forwarding strategy In-Reply-To: References: Message-ID: Hi Liu I've used client-control in one simple app. https://github.com/yoursunny/ndn6-tools/blob/7322ea378dbcdd0014b5217cb49da6283c3f9e94/remote-register-prefix.cpp#L92-L121 (not intended as a tutorial) Yours, Junxiao On Feb 8, 2016 17:36, "Lei Liu" wrote: > Hi, > > Can anyone help to elaborate how to enable the client control forwarding > strategy in NFD? > > I understand that by using nfdc, we can set strategy to a name such as: > > nfdc set-strategy ndn:/app1/video > ndn:/localhost/nfd/strategy/client-control > > Then, suppose we have an interest like /app1/video, how can we force it to > be forwarded to a specific face? NFD developer guide mentioned a > NextHopFaceId field in the interest message, but how to enable this feature > and send an interest with a NextHopFaceId field? > > Thanks, > Best regards, > > Lei > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Mon Feb 8 17:22:40 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 8 Feb 2016 17:22:40 -0800 Subject: [Nfd-dev] How to use the client control forwarding strategy In-Reply-To: References: Message-ID: Hi Lei, To use client-control strategy you will need two pieces: enable local control feature on the face and use the corresponding NDNLP header to indicate where to forward. To enable the feature, you can refer to http://redmine.named-data.net/projects/nfd/wiki/FaceMgmt#Enable-a-LocalControlHeader-feature With ndn-cxx, you can write something like this (or follow Junxiao's example) ndn::Face **face**; ndn::KeyChain keyChain; ndn::nfd::Controller controller(**face**, keyChain); controller.start( ControlParameters() .setLocalControlFeature(ndn::nfd::LOCAL_CONTROL_FEATURE_NEXT_HOP_FACE_ID), ... callback for success ..., ... callback for failure (e.g., permission denied) ...); ... ndn::Interest x("/hello/world"); x.setTag(make_shared(m_faceId)); **face**.expressInterest(x, ...); ... --- Alex > On Feb 8, 2016, at 5:19 PM, Junxiao Shi wrote: > > Hi Liu > > I've used client-control in one simple app. > https://github.com/yoursunny/ndn6-tools/blob/7322ea378dbcdd0014b5217cb49da6283c3f9e94/remote-register-prefix.cpp#L92-L121 > (not intended as a tutorial) > > Yours, Junxiao > > On Feb 8, 2016 17:36, "Lei Liu" > wrote: > Hi, > > Can anyone help to elaborate how to enable the client control forwarding strategy in NFD? > > I understand that by using nfdc, we can set strategy to a name such as: > > nfdc set-strategy ndn:/app1/video ndn:/localhost/nfd/strategy/client-control > > Then, suppose we have an interest like /app1/video, how can we force it to be forwarded to a specific face? NFD developer guide mentioned a NextHopFaceId field in the interest message, but how to enable this feature and send an interest with a NextHopFaceId field? > > Thanks, > Best regards, > > Lei > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- 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 aa at CS.UCLA.EDU Mon Feb 8 17:34:24 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 8 Feb 2016 17:34:24 -0800 Subject: [Nfd-dev] [ndnSIM] regarding block.hpp In-Reply-To: References: Message-ID: <2EC501AC-9678-4D44-934E-EF87AEBBFE56@cs.ucla.edu> > On Feb 8, 2016, at 3:10 PM, Carl Zu wrote: > > I think lack of documentation is a problem... > > I wanted to write some bytes in the interest message in ndnSIM. In ns3, thanks to their documentation, one can easily understand that in order to write some bytes, he should serialize a header. > > For doing the same thing in ndnSIM, I have had the impression that I should use "block". Moreover, It looks as though an interest message is a set of TLVs (based on the explanation in the NDN project website). So probably if I like to write eight bytes as four pieces of two-byte data, I should write four TLVs. But indeed, there are many constructors in block.hpp, and it's just about looking at one code after another to understand each of them due to lack of documentation... Hi Carl, I think you're looking into a slightly wrong place. If you want to extend Interest, you need first define your own TLV (which type to use and specific content). For simple things you don't need to define your own class, you can simply store the actual value in some standard type, say char[8]. After doing so, the only part remain is to update serialization/deserialization methods of interest.cpp which are called wireEncode and wireDecode. I will agree that there is limited documentation, but there are many examples of this encoding. add variable to keep your data (and getter/setter methods when needed): char m_myValue[8]; Add the following to the wireEncode (note that encoding is done in reverse order): totalLength += encoder.prependByteArrayBlock(, m_myValue, 8); And the following to the wireDecode: val = m_wire.find(); if (val != m_wire.elements_end()) { memcpy(m_myValue, val->value(), val->value_size()); else memset(m_myValue, 0, 8); --- Alex > > Can someone please give some guidance ???. > > thanks and rgds. > C > _______________________________________________ > ndnSIM mailing list > ndnSIM at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim -------------- 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 carlzu8 at gmail.com Tue Feb 9 09:24:48 2016 From: carlzu8 at gmail.com (Carl Zu) Date: Tue, 9 Feb 2016 18:24:48 +0100 Subject: [Nfd-dev] [ndnSIM] regarding block.hpp In-Reply-To: <2EC501AC-9678-4D44-934E-EF87AEBBFE56@cs.ucla.edu> References: <2EC501AC-9678-4D44-934E-EF87AEBBFE56@cs.ucla.edu> Message-ID: On Tue, Feb 9, 2016 at 2:34 AM, Alex Afanasyev wrote: > > > On Feb 8, 2016, at 3:10 PM, Carl Zu wrote: > > > > I think lack of documentation is a problem... > > > > I wanted to write some bytes in the interest message in ndnSIM. In ns3, > thanks to their documentation, one can easily understand that in order to > write some bytes, he should serialize a header. > > > > For doing the same thing in ndnSIM, I have had the impression that I > should use "block". Moreover, It looks as though an interest message is a > set of TLVs (based on the explanation in the NDN project website). So > probably if I like to write eight bytes as four pieces of two-byte data, I > should write four TLVs. But indeed, there are many constructors in > block.hpp, and it's just about looking at one code after another to > understand each of them due to lack of documentation... > > Hi Carl, > > I think you're looking into a slightly wrong place. If you want to extend > Interest, you need first define your own TLV (which type to use and > specific content). For simple things you don't need to define your own > class, you can simply store the actual value in some standard type, say > char[8]. After doing so, the only part remain is to update > serialization/deserialization methods of interest.cpp which are called > wireEncode and wireDecode. > > I will agree that there is limited documentation, but there are many > examples of this encoding. > > Hi guys, thanks a lot for your replies. Alex, could you please mention more precisely to which examples you are referring? Thank you. C > add variable to keep your data (and getter/setter methods when needed): > > char m_myValue[8]; > > Add the following to the wireEncode (note that encoding is done in reverse > order): > > totalLength += encoder.prependByteArrayBlock(, m_myValue, > 8); > > And the following to the wireDecode: > > val = m_wire.find(); > if (val != m_wire.elements_end()) { > memcpy(m_myValue, val->value(), val->value_size()); > else > memset(m_myValue, 0, 8); > > --- > Alex > > > > Can someone please give some guidance ???. > > > > thanks and rgds. > > C > > _______________________________________________ > > ndnSIM mailing list > > ndnSIM at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bigcatlei at gmail.com Tue Feb 9 11:03:21 2016 From: bigcatlei at gmail.com (Lei Liu) Date: Tue, 9 Feb 2016 11:03:21 -0800 Subject: [Nfd-dev] How to use the client control forwarding strategy In-Reply-To: References: Message-ID: Hi Alex, and Junxiao, Thank you for your reply. I understand better now. To enable the local control feature, this link ( http://redmine.named-data.net/projects/nfd/wiki/FaceMgmt#Enable-a-LocalControlHeader-feature) mentioned a command like enable-local-control ControlParameters fields: - LocalControlFeature (required): 1=IncomingFaceId, 2=NextHopFaceId, 3=CachingPolicy But I am still unclear about how to run this command. Also, what is difference / relationship between this command and the command "nfdc set-strategy ndn:/app1/video ndn:/localhost/nfd/strategy/client-control"? Do we need to run both of them? Thanks for your attention, Best regards, Lei 2016-02-08 17:22 GMT-08:00 Alex Afanasyev : > Hi Lei, > > To use client-control strategy you will need two pieces: enable local > control feature on the face and use the corresponding NDNLP header to > indicate where to forward. > > To enable the feature, you can refer to > http://redmine.named-data.net/projects/nfd/wiki/FaceMgmt#Enable-a-LocalControlHeader-feature > > > With ndn-cxx, you can write something like this (or follow Junxiao's > example) > > ndn::Face **face**; > ndn::KeyChain keyChain; > ndn::nfd::Controller controller(**face**, keyChain); > > controller.start( > ControlParameters() > > .setLocalControlFeature(ndn::nfd::LOCAL_CONTROL_FEATURE_NEXT_HOP_FACE_ID), > ... callback for success ..., > ... callback for failure (e.g., permission denied) ...); > > ... > > ndn::Interest x("/hello/world"); > x.setTag(make_shared(m_faceId)); > **face**.expressInterest(x, ...); > ... > > --- > Alex > > On Feb 8, 2016, at 5:19 PM, Junxiao Shi > wrote: > > Hi Liu > > I've used client-control in one simple app. > > https://github.com/yoursunny/ndn6-tools/blob/7322ea378dbcdd0014b5217cb49da6283c3f9e94/remote-register-prefix.cpp#L92-L121 > (not intended as a tutorial) > > Yours, Junxiao > On Feb 8, 2016 17:36, "Lei Liu" wrote: > >> Hi, >> >> Can anyone help to elaborate how to enable the client control forwarding >> strategy in NFD? >> >> I understand that by using nfdc, we can set strategy to a name such as: >> >> nfdc set-strategy ndn:/app1/video >> ndn:/localhost/nfd/strategy/client-control >> >> Then, suppose we have an interest like /app1/video, how can we force it >> to be forwarded to a specific face? NFD developer guide mentioned a >> NextHopFaceId field in the interest message, but how to enable this feature >> and send an interest with a NextHopFaceId field? >> >> Thanks, >> Best regards, >> >> Lei >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bigcatlei at gmail.com Tue Feb 9 14:31:28 2016 From: bigcatlei at gmail.com (Lei Liu) Date: Tue, 9 Feb 2016 14:31:28 -0800 Subject: [Nfd-dev] How to enable a new forwarding strategy Message-ID: Hi, We developed a new forwarding strategy, but how to actually use it in NFD? nfdc command-line tool does not recognize this new forwarding strategy. NFD developer guide mentioned to modify daemon/fw/available-strategies.cpp and install the new strategy to the list of existing built-in strategies. But this file "daemon/fw/available-strategies.cpp" is no longer available in the latest NFD. Thanks, Best regards, Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Tue Feb 9 15:58:55 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Tue, 9 Feb 2016 15:58:55 -0800 Subject: [Nfd-dev] How to enable a new forwarding strategy In-Reply-To: References: Message-ID: <1AC52CE7-CAA6-46D5-BF4F-8836C630F5CB@cs.ucla.edu> > On Feb 9, 2016, at 2:31 PM, Lei Liu wrote: > > Hi, > > We developed a new forwarding strategy, but how to actually use it in NFD? nfdc command-line tool does not recognize this new forwarding strategy. > > NFD developer guide mentioned to modify daemon/fw/available-strategies.cpp and install the new strategy to the list of existing built-in strategies. But this file "daemon/fw/available-strategies.cpp" is no longer available in the latest NFD. > > Thanks, > Best regards, > > Lei In .cpp file of your strategy just add const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); NFD_REGISTER_STRATEGY(YourStrategyClass); After that you should be able to use ndn:/localhost/nfd/strategy/you-strategy-name in nfdc. --- Alex -------------- 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 bigcatlei at gmail.com Tue Feb 9 16:51:11 2016 From: bigcatlei at gmail.com (bigcatlei at gmail.com) Date: Tue, 9 Feb 2016 16:51:11 -0800 Subject: [Nfd-dev] How to enable a new forwarding strategy In-Reply-To: <1AC52CE7-CAA6-46D5-BF4F-8836C630F5CB@cs.ucla.edu> References: <1AC52CE7-CAA6-46D5-BF4F-8836C630F5CB@cs.ucla.edu> Message-ID: <50AB3822-36E7-4645-B2B1-4FD7EB1E573E@gmail.com> Hi Alex, Thanks for your reply. We did add the following into our cpp program > const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); > NFD_REGISTER_STRATEGY(YourStrategyClass); But it doesn't work. The nfdc cannot use the new strategy with the error code 504. Is there any other particular things that we need to note in order to install a new forwarding strategy? Thanks, Best regards, Lei > On Feb 9, 2016?3:58 PM?Alex Afanasyev wrote? > > >> On Feb 9, 2016, at 2:31 PM, Lei Liu wrote: >> >> Hi, >> >> We developed a new forwarding strategy, but how to actually use it in NFD? nfdc command-line tool does not recognize this new forwarding strategy. >> >> NFD developer guide mentioned to modify daemon/fw/available-strategies.cpp and install the new strategy to the list of existing built-in strategies. But this file "daemon/fw/available-strategies.cpp" is no longer available in the latest NFD. >> >> Thanks, >> Best regards, >> >> Lei > > In .cpp file of your strategy just add > > const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); > NFD_REGISTER_STRATEGY(YourStrategyClass); > > After that you should be able to use ndn:/localhost/nfd/strategy/you-strategy-name in nfdc. > > --- > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Tue Feb 9 17:30:14 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Tue, 9 Feb 2016 17:30:14 -0800 Subject: [Nfd-dev] How to enable a new forwarding strategy In-Reply-To: <50AB3822-36E7-4645-B2B1-4FD7EB1E573E@gmail.com> References: <1AC52CE7-CAA6-46D5-BF4F-8836C630F5CB@cs.ucla.edu> <50AB3822-36E7-4645-B2B1-4FD7EB1E573E@gmail.com> Message-ID: > On Feb 9, 2016, at 4:51 PM, bigcatlei at gmail.com wrote: > > Hi Alex, > > Thanks for your reply. We did add the following into our cpp program > >> const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); >> NFD_REGISTER_STRATEGY(YourStrategyClass); > > But it doesn't work. The nfdc cannot use the new strategy with the error code 504. > > Is there any other particular things that we need to note in order to install a new forwarding strategy? Hmm. It should work. I just tried to create a dummy strategy. I just added tmp.hpp and tmp.cpp files into daemon/fw folder and had invocation of NFD_REGISTER_STRATEGY macro. After I run the compiled NFD, I'm able to use nfdc to set strategy: # nfdc set-strategy /hello /localhost/nfd/strategy/tmp/%FD%00 Successfully set strategy choice: ControlParameters(Name: /hello, Strategy: /localhost/nfd/strategy/tmp/%FD%00, ) Did you added your strategy files in some other location? --- Alex > > Thanks, > Best regards, > > Lei > > > On Feb 9, 2016?3:58 PM?Alex Afanasyev > wrote? > >> >>> On Feb 9, 2016, at 2:31 PM, Lei Liu > wrote: >>> >>> Hi, >>> >>> We developed a new forwarding strategy, but how to actually use it in NFD? nfdc command-line tool does not recognize this new forwarding strategy. >>> >>> NFD developer guide mentioned to modify daemon/fw/available-strategies.cpp and install the new strategy to the list of existing built-in strategies. But this file "daemon/fw/available-strategies.cpp" is no longer available in the latest NFD. >>> >>> Thanks, >>> Best regards, >>> >>> Lei >> >> In .cpp file of your strategy just add >> >> const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); >> NFD_REGISTER_STRATEGY(YourStrategyClass); >> >> After that you should be able to use ndn:/localhost/nfd/strategy/you-strategy-name in nfdc. >> >> --- >> Alex >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: add-tmp-strategy.patch Type: application/octet-stream Size: 4283 bytes Desc: not available URL: -------------- 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 bigcatlei at gmail.com Tue Feb 9 17:36:10 2016 From: bigcatlei at gmail.com (bigcatlei at gmail.com) Date: Tue, 9 Feb 2016 17:36:10 -0800 Subject: [Nfd-dev] How to enable a new forwarding strategy In-Reply-To: References: <1AC52CE7-CAA6-46D5-BF4F-8836C630F5CB@cs.ucla.edu> <50AB3822-36E7-4645-B2B1-4FD7EB1E573E@gmail.com> Message-ID: <06190D5F-8CBA-4B9F-96B1-F5DBC514B65A@gmail.com> Hi Alex, Thanks! We also put it in daemon/fw. Maybe something is wrong in our side. We will double check carefully. Thanks, Best regards, Lei > On Feb 9, 2016?5:30 PM?Alex Afanasyev wrote: > > >> On Feb 9, 2016, at 4:51 PM, bigcatlei at gmail.com wrote: >> >> Hi Alex, >> >> Thanks for your reply. We did add the following into our cpp program >> >>> const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); >>> NFD_REGISTER_STRATEGY(YourStrategyClass); >> >> But it doesn't work. The nfdc cannot use the new strategy with the error code 504. >> >> Is there any other particular things that we need to note in order to install a new forwarding strategy? > > Hmm. It should work. I just tried to create a dummy strategy. I just added tmp.hpp and tmp.cpp files into daemon/fw folder and had invocation of NFD_REGISTER_STRATEGY macro. After I run the compiled NFD, I'm able to use nfdc to set strategy: > > # nfdc set-strategy /hello /localhost/nfd/strategy/tmp/%FD%00 > Successfully set strategy choice: ControlParameters(Name: /hello, Strategy: /localhost/nfd/strategy/tmp/%FD%00, ) > > > > Did you added your strategy files in some other location? > > --- > Alex > >> >> Thanks, >> Best regards, >> >> Lei >> >> >>> On Feb 9, 2016?3:58 PM?Alex Afanasyev wrote? >>> >>> >>>> On Feb 9, 2016, at 2:31 PM, Lei Liu wrote: >>>> >>>> Hi, >>>> >>>> We developed a new forwarding strategy, but how to actually use it in NFD? nfdc command-line tool does not recognize this new forwarding strategy. >>>> >>>> NFD developer guide mentioned to modify daemon/fw/available-strategies.cpp and install the new strategy to the list of existing built-in strategies. But this file "daemon/fw/available-strategies.cpp" is no longer available in the latest NFD. >>>> >>>> Thanks, >>>> Best regards, >>>> >>>> Lei >>> >>> In .cpp file of your strategy just add >>> >>> const Name YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); >>> NFD_REGISTER_STRATEGY(YourStrategyClass); >>> >>> After that you should be able to use ndn:/localhost/nfd/strategy/you-strategy-name in nfdc. >>> >>> --- >>> Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Feb 10 06:23:31 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 10 Feb 2016 07:23:31 -0700 Subject: [Nfd-dev] HOWTO see details of Jenkins build error Message-ID: Dear folks I'm asked how to see the details of a Jenkins build error. The procedure is: 1. From your Gerrit Change, find a link to the failed Jenkins build. It should start with http://jenkins.named.net/ . 2. Navigate to that link, and sign in with any Google Account. 3. Under "Configurations" there should be a list of operating system names. These are the systems you commit has been built on. If there's a red circle to the left of a system name, the build has failed on this system. If there's no system name showing up, something went wrong in Jenkins scheduling, and you can see the error via "Console Output" link on the left navigation bar. 4. Tap on a system name that has a red circle. 5. Tap on "View as plain text" link on left navigation bar. 6. Scroll to the end of this output, and look for signs of compilation error. 7. If the end of output looks like unit testing logs, this means there's no compilation error. Search for "error in" and "error: in" (precisely these two strings without quotes) to find out which test cases went wrong. 8. If the end of output looks like a Java stack trace, this means there's an issue with a Jenkins slave machine. 9. In case of Jenkins scheduling error (step 3) or slave error (step 8), go back to the page opened in step 2, and tap "Retrigger" on the left navigation bar. If the build still fails due to the same Jenkins scheduling/slave error, complain on nfd-dev mailing list, and include a link to the failed build in your message. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Feb 10 08:28:04 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 10 Feb 2016 16:28:04 +0000 Subject: [Nfd-dev] ndndump Message-ID: Hi, Has ndndump been updated to catch NACK packets? Lan From M.AbdollahiSabet at mail.sbu.ac.ir Wed Feb 10 09:34:08 2016 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Wed, 10 Feb 2016 21:04:08 +0330 Subject: [Nfd-dev] Automatic face removal Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29EF@m-pdc.sbu.ac.ir> Hi, Isn't permanent face(-P) supposed to live forever unless the network protocol stack goes down? I've tested nfd on 4 different nodes recently and although I created faces permanently with nfdc, but after a while(less than half an hour) I saw my created faces destroyed, so did my registered prefixes. Thus, traffic generations stopped. What's wrong with it? Thanks, Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Wed Feb 10 10:14:02 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Wed, 10 Feb 2016 10:14:02 -0800 Subject: [Nfd-dev] ndndump In-Reply-To: References: Message-ID: <839C5E1B-D875-44D1-8227-DE03CC315C88@cs.ucla.edu> Unfortunately, not yet. --- Alex P.S. I would like to take this opportunity and call for help from members of this list with adding this support to ndndump (and wireshark dissector) . You can contact me directly if you need additional details or guidance. > On Feb 10, 2016, at 8:28 AM, Lan Wang (lanwang) wrote: > > Hi, > > Has ndndump been updated to catch NACK packets? > > Lan -------------- 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 shijunxiao at email.arizona.EDU Wed Feb 10 10:12:10 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Wed, 10 Feb 2016 11:12:10 -0700 Subject: [Nfd-dev] Automatic face removal In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29EF@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29EF@m-pdc.sbu.ac.ir> Message-ID: <9523A52B-68E0-4EB8-BF94-9DE44E34DF8D@email.arizona.edu> Hi Muhammad To diagnose this problem: Run NFD with logging enabled, and log level set to DEBUG for Face, Transport, and UnicastUdpTransport. After creating a face with -P, take a note at the FaceId. After the face disappears, look for this FaceId in the NFD logs. Yours, Junxiao > On Feb 10, 2016, at 10:34 AM, Muhammad Hosain Abdollahi Sabet wrote: > > Hi, > > Isn't permanent face(-P) supposed to live forever unless the network protocol stack goes down? I've tested nfd on 4 different nodes recently and although I created faces permanently with nfdc, but after a while(less than half an hour) I saw my created faces destroyed, so did my registered prefixes. Thus, traffic generations stopped. What's wrong with it? > > Thanks, > Sabet > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Feb 10 10:17:37 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 10 Feb 2016 18:17:37 +0000 Subject: [Nfd-dev] ndndump In-Reply-To: <839C5E1B-D875-44D1-8227-DE03CC315C88@cs.ucla.edu> References: , <839C5E1B-D875-44D1-8227-DE03CC315C88@cs.ucla.edu> Message-ID: <28CBDC78-4039-4C34-9E13-1E587F6033BD@memphis.edu> Vince made some changes to capture NACKs. But I am not sure if it recognized other NDNLP packets. He can contribute his code. Lan > On Feb 10, 2016, at 12:14 PM, Alex Afanasyev wrote: > > Unfortunately, not yet. > > --- > Alex > > P.S. > I would like to take this opportunity and call for help from members of this list with adding this support to ndndump (and wireshark dissector) . You can contact me directly if you need additional details or guidance. > > >> On Feb 10, 2016, at 8:28 AM, Lan Wang (lanwang) wrote: >> >> Hi, >> >> Has ndndump been updated to catch NACK packets? >> >> Lan > > From shijunxiao at email.arizona.EDU Wed Feb 10 10:14:57 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Wed, 10 Feb 2016 11:14:57 -0700 Subject: [Nfd-dev] ndndump In-Reply-To: <839C5E1B-D875-44D1-8227-DE03CC315C88@cs.ucla.edu> References: <839C5E1B-D875-44D1-8227-DE03CC315C88@cs.ucla.edu> Message-ID: <1B14FBCE-9812-4921-A6DF-632EBEDD62A9@email.arizona.edu> Dear folks I think the decision was to focus the development effort on Wireshark dissector. Feature 3197 would add NDNLPv2 dissector including Nack. There?s no need to maintain two tools with similar function. ndndump can be replaced with tshark + Wireshark dissector. Yours, Junxiao > On Feb 10, 2016, at 11:14 AM, Alex Afanasyev wrote: > > Unfortunately, not yet. > > --- > Alex > > P.S. > I would like to take this opportunity and call for help from members of this list with adding this support to ndndump (and wireshark dissector) . You can contact me directly if you need additional details or guidance. > > >> On Feb 10, 2016, at 8:28 AM, Lan Wang (lanwang) wrote: >> >> Hi, >> >> Has ndndump been updated to catch NACK packets? >> >> Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.EDU Wed Feb 10 10:18:18 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Wed, 10 Feb 2016 11:18:18 -0700 Subject: [Nfd-dev] ndndump In-Reply-To: <28CBDC78-4039-4C34-9E13-1E587F6033BD@memphis.edu> References: <839C5E1B-D875-44D1-8227-DE03CC315C88@cs.ucla.edu> <28CBDC78-4039-4C34-9E13-1E587F6033BD@memphis.edu> Message-ID: Hi Lan I will accept this contribution. Vince may use Feature 3463 . Yours, Junxiao > On Feb 10, 2016, at 11:17 AM, Lan Wang (lanwang) wrote: > > Vince made some changes to capture NACKs. But I am not sure if it recognized other NDNLP packets. He can contribute his code. > > Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.EDU Wed Feb 10 10:22:44 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Wed, 10 Feb 2016 11:22:44 -0700 Subject: [Nfd-dev] HOWTO see details of Jenkins build error In-Reply-To: References: Message-ID: Dear folks (small correction from the last message) I'm asked how to see the details of a Jenkins build error. The procedure is: 1. From your Gerrit Change, find a link to the failed Jenkins build. It should start with http://jenkins.named-data.net/ . 2. Navigate to that link, and sign in with any Google Account. 3. Under "Configurations" there should be a list of operating system names. These are the systems you commit has been built on. If there's a red circle to the left of a system name, the build has failed on this system. If there's no system name showing up, something went wrong in Jenkins scheduling, and you can see the error via "Console Output" link on the left navigation bar. 4. Tap on a system name that has a red circle. 5. Tap on "View as plain text" link on left navigation bar. 6. Scroll to the end of this output, and look for signs of compilation error. 7. If the end of output looks like unit testing logs, this means there's no compilation error. Search for "error in" and "error: in" (precisely these two strings without quotes) to find out which test cases went wrong. 8. If the end of output looks like a Java stack trace, this means there's an issue with a Jenkins slave machine. 9. In case of Jenkins scheduling error (step 3) or slave error (step 8), go back to the page opened in step 2, and tap "Retrigger" on the left navigation bar. If the build still fails due to the same Jenkins scheduling/slave error, complain on nfd-dev mailing list, and include a link to the failed build in your message. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From bigcatlei at gmail.com Wed Feb 10 15:13:39 2016 From: bigcatlei at gmail.com (Lei Liu) Date: Wed, 10 Feb 2016 15:13:39 -0800 Subject: [Nfd-dev] How to enable a new forwarding strategy In-Reply-To: <06190D5F-8CBA-4B9F-96B1-F5DBC514B65A@gmail.com> References: <1AC52CE7-CAA6-46D5-BF4F-8836C630F5CB@cs.ucla.edu> <50AB3822-36E7-4645-B2B1-4FD7EB1E573E@gmail.com> <06190D5F-8CBA-4B9F-96B1-F5DBC514B65A@gmail.com> Message-ID: Hi Alex, We tried the tmp.hpp and tmp.cpp files provided by you, but still have the same problem when installing the new forwarding strategy. Below is our details procedures. Please take a look to see if there is any problem. 1. install ndn-cxx git clone https://github.com/named-data/ndn-cxx ./waf configure ./waf sudo ./waf install 2. install NFD git clone --recursive https://github.com/named-data/NFD added tmp.hpp and tmp.cpp files into daemon/fw folder ./waf configure ./waf sudo ./waf install 3. run NFD and enable the new forwarding strategy nfd-start nfdc set-strategy /hello /localhost/nfd/strategy/tmp/%FD%00 ERROR: Failed to set strategy choice: unsupported strategy (code:504) Other build-in forwarding strategies are working well on this machine, such as the client-control, best-route, etc. Please let me know your opinion, Thanks, Best regards, Lei 2016-02-09 17:36 GMT-08:00 bigcatlei at gmail.com : > Hi Alex, > > Thanks! > > We also put it in daemon/fw. Maybe something is wrong in our side. We > will double check carefully. > > Thanks, > Best regards, > > Lei > > > On Feb 9, 2016?5:30 PM?Alex Afanasyev wrote: > > > On Feb 9, 2016, at 4:51 PM, bigcatlei at gmail.com wrote: > > Hi Alex, > > Thanks for your reply. We did add the following into our cpp program > > const Name > YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); > NFD_REGISTER_STRATEGY(YourStrategyClass); > > > But it doesn't work. The nfdc cannot use the new strategy with the error > code 504. > > Is there any other particular things that we need to note in order to > install a new forwarding strategy? > > > Hmm. It should work. I just tried to create a dummy strategy. I just > added tmp.hpp and tmp.cpp files into daemon/fw folder and had invocation > of NFD_REGISTER_STRATEGY macro. After I run the compiled NFD, I'm able to > use nfdc to set strategy: > > # nfdc set-strategy /hello /localhost/nfd/strategy/tmp/%FD%00 > Successfully set strategy choice: ControlParameters(Name: /hello, > Strategy: /localhost/nfd/strategy/tmp/%FD%00, ) > > > > > Did you added your strategy files in some other location? > > --- > Alex > > > Thanks, > Best regards, > > Lei > > > On Feb 9, 2016?3:58 PM?Alex Afanasyev wrote? > > > On Feb 9, 2016, at 2:31 PM, Lei Liu wrote: > > > Hi, > > > We developed a new forwarding strategy, but how to actually use it in NFD? > nfdc command-line tool does not recognize this new forwarding strategy. > > > NFD developer guide mentioned to modify daemon/fw/available-strategies.cpp > and install the new strategy to the list of existing built-in strategies. > But this file "daemon/fw/available-strategies.cpp" is no longer available > in the latest NFD. > > > Thanks, > > Best regards, > > > Lei > > > In .cpp file of your strategy just add > > const Name > YourStrategyClass::STRATEGY_NAME("ndn:/localhost/nfd/strategy/you-strategy-name/%FD%00"); > NFD_REGISTER_STRATEGY(YourStrategyClass); > > After that you should be able to use > ndn:/localhost/nfd/strategy/you-strategy-name in nfdc. > > --- > Alex > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Thu Feb 11 01:28:58 2016 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Thu, 11 Feb 2016 12:58:58 +0330 Subject: [Nfd-dev] Automatic face removal References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29EF@m-pdc.sbu.ac.ir> <9523A52B-68E0-4EB8-BF94-9DE44E34DF8D@email.arizona.edu> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29F0@m-pdc.sbu.ac.ir> Hi Junxiao Did as you told. Where do NFD logs sit? Thanks, Sabet -----Original Message----- From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Wed 2/10/2016 9:42 PM To: Muhammad Hosain Abdollahi Sabet Cc: nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Automatic face removal Hi Muhammad To diagnose this problem: Run NFD with logging enabled, and log level set to DEBUG for Face, Transport, and UnicastUdpTransport. After creating a face with -P, take a note at the FaceId. After the face disappears, look for this FaceId in the NFD logs. Yours, Junxiao > On Feb 10, 2016, at 10:34 AM, Muhammad Hosain Abdollahi Sabet wrote: > > Hi, > > Isn't permanent face(-P) supposed to live forever unless the network protocol stack goes down? I've tested nfd on 4 different nodes recently and although I created faces permanently with nfdc, but after a while(less than half an hour) I saw my created faces destroyed, so did my registered prefixes. Thus, traffic generations stopped. What's wrong with it? > > Thanks, > Sabet > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Feb 11 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 11 Feb 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160211 Message-ID: <201602111500.u1BF02I6025327@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From bigcatlei at gmail.com Thu Feb 11 11:09:17 2016 From: bigcatlei at gmail.com (Lei Liu) Date: Thu, 11 Feb 2016 11:09:17 -0800 Subject: [Nfd-dev] cannot stop NFD Message-ID: Hi, I cannot stop nfd, either by using nfd-stop or directly killing nfd process. It looks like NFD is immediately restarted. Any suggestion? Thanks, Best regards, Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Thu Feb 11 11:20:39 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 11 Feb 2016 11:20:39 -0800 Subject: [Nfd-dev] cannot stop NFD In-Reply-To: References: Message-ID: With OS you're using? for Ubuntu Linux 12.04, run sudo service stop nfd For 14.04+ sudo systemctl stop nfd sudo ststemctl disable nfd For OSX with macports sudo port unload nfd For OSX with homebrew nfd-stop should have done the job. --- Alex > On Feb 11, 2016, at 11:09 AM, Lei Liu wrote: > > Hi, > > I cannot stop nfd, either by using nfd-stop or directly killing nfd process. It looks like NFD is immediately restarted. Any suggestion? > > Thanks, > Best regards, > > Lei > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From bigcatlei at gmail.com Thu Feb 11 17:18:47 2016 From: bigcatlei at gmail.com (Lei Liu) Date: Thu, 11 Feb 2016 17:18:47 -0800 Subject: [Nfd-dev] Get the full FIB table info Message-ID: Hello, NFD developers, I am just wondering in the forwarding strategy program (e.g. best-route-strategy2.cpp), can we read/get the full FIB table information? If yes, how to do that? If I understand correctly, in the current program BestRouteStrategy2::afterReceiveInterest(const Face& inFace, const Interest& interest, shared_ptr fibEntry, shared_ptr pitEntry), we only get a FIB entry which satisfies the Longest Prefix Matching for a given Interest, am I right? Please advise, Thanks, Best regards, Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Thu Feb 11 18:00:13 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 11 Feb 2016 18:00:13 -0800 Subject: [Nfd-dev] [ndnSIM] regarding block.hpp In-Reply-To: References: <2EC501AC-9678-4D44-934E-EF87AEBBFE56@cs.ucla.edu> Message-ID: > On Feb 9, 2016, at 9:24 AM, Carl Zu wrote: > > On Tue, Feb 9, 2016 at 2:34 AM, Alex Afanasyev > wrote: > > > On Feb 8, 2016, at 3:10 PM, Carl Zu > wrote: > > > > I think lack of documentation is a problem... > > > > I wanted to write some bytes in the interest message in ndnSIM. In ns3, thanks to their documentation, one can easily understand that in order to write some bytes, he should serialize a header. > > > > For doing the same thing in ndnSIM, I have had the impression that I should use "block". Moreover, It looks as though an interest message is a set of TLVs (based on the explanation in the NDN project website). So probably if I like to write eight bytes as four pieces of two-byte data, I should write four TLVs. But indeed, there are many constructors in block.hpp, and it's just about looking at one code after another to understand each of them due to lack of documentation... > > Hi Carl, > > I think you're looking into a slightly wrong place. If you want to extend Interest, you need first define your own TLV (which type to use and specific content). For simple things you don't need to define your own class, you can simply store the actual value in some standard type, say char[8]. After doing so, the only part remain is to update serialization/deserialization methods of interest.cpp which are called wireEncode and wireDecode. > > I will agree that there is limited documentation, but there are many examples of this encoding. > > Hi guys, > > thanks a lot for your replies. > > Alex, could you please mention more precisely to which examples you are referring? Hi Carl, I meant wireEncode/wireDecode methods of data structures implemented in ndn-cxx (Data, Interest, MetaInfo, etc.). -- Alex > > Thank you. > C > add variable to keep your data (and getter/setter methods when needed): > > char m_myValue[8]; > > Add the following to the wireEncode (note that encoding is done in reverse order): > > totalLength += encoder.prependByteArrayBlock(, m_myValue, 8); > > And the following to the wireDecode: > > val = m_wire.find(); > if (val != m_wire.elements_end()) { > memcpy(m_myValue, val->value(), val->value_size()); > else > memset(m_myValue, 0, 8); > > --- > Alex > > > > Can someone please give some guidance ???. > > > > thanks and rgds. > > C > > _______________________________________________ > > ndnSIM mailing list > > ndnSIM at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim -------------- 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 shijunxiao at email.arizona.edu Thu Feb 11 18:00:43 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 11 Feb 2016 19:00:43 -0700 Subject: [Nfd-dev] Get the full FIB table info In-Reply-To: References: Message-ID: This is an intentional limitation: strategy only has access to the current FIB entry. See NFD devguide "strategy API" section for more information. On Feb 11, 2016 18:19, "Lei Liu" wrote: > Hello, NFD developers, > > I am just wondering in the forwarding strategy program (e.g. > best-route-strategy2.cpp), can we read/get the full FIB table information? > If yes, how to do that? > > If I understand correctly, in the current program > > BestRouteStrategy2::afterReceiveInterest(const Face& inFace, const > Interest& interest, > shared_ptr fibEntry, shared_ptr pitEntry), > > we only get a FIB entry which satisfies the Longest Prefix Matching for a > given Interest, am I right? > > Please advise, > Thanks, > > Best regards, > Lei > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Fri Feb 12 05:52:45 2016 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Fri, 12 Feb 2016 17:22:45 +0330 Subject: [Nfd-dev] tlv-tools still in github NFD Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29F1@m-pdc.sbu.ac.ir> Hi everyone, In ndn-tlv-ping it says: ndn-tlv-ping has been deprecated. Please use ndnping and ndnpingserver from ndn-tools instead. But installing NFD from source still installs ndn-tlv-ping, ndn-tlv-peek and ndn-tlv-poke. It's nothing troublemaker for me, since I haven't been using 'tlv's these days. Just installed NFD on another node today and noticed this. Maybe it's better to update NFD github package. Needless to say that the repository package installs non-tlv tools. Thanks, Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Feb 12 06:03:46 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 12 Feb 2016 07:03:46 -0700 Subject: [Nfd-dev] tlv-tools still in github NFD In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29F1@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29F1@m-pdc.sbu.ac.ir> Message-ID: Hi Muhammad ndn-tlv-peek is unrelated to ndn-tlv-ping, but it's also deprecated and will be deleted in v0.5. Watch http://redmine.named-data.net/issues/2819 for progress. Yours, Junxiao On Feb 12, 2016 06:58, "Muhammad Hosain Abdollahi Sabet" < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Hi everyone, > > In ndn-tlv-ping it says: > > ndn-tlv-ping has been deprecated. Please use ndnping and ndnpingserver > from ndn-tools instead. > > But installing NFD from source still installs ndn-tlv-ping, ndn-tlv-peek > and ndn-tlv-poke. > It's nothing troublemaker for me, since I haven't been using 'tlv's these > days. Just installed NFD on another node today and noticed this. Maybe it's > better to update NFD github package. Needless to say that the repository > package installs non-tlv tools. > > Thanks, > Sabet > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.figueiredo at itec.ufpa.br Fri Feb 12 06:53:40 2016 From: pedro.figueiredo at itec.ufpa.br (Pedro UFPA) Date: Fri, 12 Feb 2016 06:53:40 -0800 (PST) Subject: [Nfd-dev] NFD on Home Router Message-ID: <56BDF1E9.4070103@itec.ufpa.br> Hi everyone, I am currently trying to install NFD and ndn-cxx to a router (TP-Link WR841ND) with OpenWRT, following the tutorial in http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_home_routers. However, I am having trouble using scp to transfer the binaries (due to memory size constraints). It would be very helpful to have guidance on using an USB auto-mounted or other strategies (http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001027.html), and also on running the binaries. Thanks in advance, Pedro. From gibmat at cs.arizona.EDU Fri Feb 12 08:16:07 2016 From: gibmat at cs.arizona.EDU (Mathias Gibbens) Date: Fri, 12 Feb 2016 16:16:07 +0000 Subject: [Nfd-dev] NFD on Home Router In-Reply-To: <56BDF1E9.4070103@itec.ufpa.br> References: <56BDF1E9.4070103@itec.ufpa.br> Message-ID: <1455293767.3353.13.camel@cs.arizona.edu> Hi Pedro, I'd suggest you look at these two OpwnWRT wiki pages: https://wiki.openwrt.org/doc/howto/usb.storage https://wiki.openwrt.org/doc/uci/fstab Currently I am using DD-WRT, since at the time it was easier to install on my router than OpenWRT was. In its web GUI there are options for auto-mounting USB drives. I also discovered that if I formatted my external drive with the label "jffs", it would mount at /jffs on the router. (Yes, I know that's "wrong", but it works and is also in the default search path for shared libraries so I didn't have to fiddle with LD_LIBRARY_PATH.) I don't know if there's much more advice I can give right off hand, but let me know if you have other questions. Mathias On Fri, 2016-02-12 at 07:53 -0700, Pedro UFPA wrote: > Hi everyone, > > I am currently trying to install NFD and ndn-cxx to a router (TP-Link > WR841ND) with OpenWRT, following the tutorial in > http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_home_routers. > > However, I am having trouble using scp to transfer the binaries (due to > memory size constraints). It would be very helpful to have guidance on > using an USB auto-mounted or other strategies > (http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001027.html), > and also on running the binaries. > > Thanks in advance, > > Pedro. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From susmit at cs.colostate.edu Mon Feb 15 15:33:21 2016 From: susmit at cs.colostate.edu (Susmit) Date: Mon, 15 Feb 2016 17:33:21 -0600 Subject: [Nfd-dev] 2nd NDN Hackathon Call for Hacks Message-ID: ====================================== CALL FOR HACKS The 2nd Named Data Networking (NDN) Hackathon March 20-21, UC San Diego Campus, La Jolla, CA ====================================== ------------------------------------------ IMPORTANT DATES ------------------------------------------ Submission deadline: March 6, 2016 Acceptance notification: March 13, 2016 ------------------------------------------ WEBSITE ------------------------------------------ http://2nd-ndn-hackathon.named-data.net ------------------------------------------ Call for Hacks ------------------------------------------ The NDN Team is organizing our 2nd NDN Hackathon to be held on March 20-21, 2016 at the UC San Diego Campus in La Jolla, CA. We solicit Hackathon project proposals that advance the state of NDN. Participants will have approximately **12 hours** to work on the projects. We encourage projects that: - directly address NDN research needs, - create new NDN tools or modify existing tools, - create or improve documentation and how-to guides. ------------------------------------------ SUBMISSION GUIDELINES ------------------------------------------ Proposals should be submitted via email to <2nd-ndn-hackathon at named-data.net>. Submission templates are available on the Hackathon website. The submissions should include: - 1 page description PDF, including contact information of submitter and project leader(s), problem statement, approach, contribution to NDN, planned tasks to accomplish, knowledge requirements, and what is the expected outcome by the end of the Hackathon. - 1 or 2 PPTx slides, listing the project leader(s) and summarizing the problem, contribution, tasks, required knowledge, and expected outcome. All submitted proposals will be reviewed by the Hacking Committee. If accepted, the project leader is expected to give a 5 minute ?pitch? presentation at the beginning of the Hackathon, soliciting participation from attendees. Projects will be judged by a panel for the "Best of Hackathon" prize. We hope that this hackathon will be a fun event for everyone and that projects will lead to collaborations extending beyond the Hackathon. ------------------------------------------ ORGANIZING COMMITTEE ------------------------------------------ - Alex Afanasyev (University of California, Los Angeles) - Susmit Shannigrahi (Colorado State University) ------------------------------------------ HACKING COMMITTEE ------------------------------------------ - Davide Pesavento (LIP6 / University Pierre & Marie Curie, Sorbonne University) - Vince Lenhman (University of Memphis) - Eric Newberry (University of Arizona) - Wentao Shang (University of California, Los Angeles) - Hila Ben Abraham (Washington University in St. Louis) - Peter Gusev (REMAP / University of California, Los Angeles) From nfd-call-notification at mail1.yoursunny.com Tue Feb 16 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 16 Feb 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160216 Message-ID: <201602161500.u1GF02vt017380@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.EDU Tue Feb 16 12:54:49 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Tue, 16 Feb 2016 13:54:49 -0700 Subject: [Nfd-dev] Fwd: Sample ndnlp fragmentation/reassembly code In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Susmit Date: Tue, Feb 16, 2016 at 10:10 AM Subject: Sample ndnlp fragmentation/reassembly code To: Junxiao Shi Hi Junxiao, I was wandering what's the plan for NDNLPv2. Would it be integrated with the faces by default or it's just an API that enables fragmentation and the user would integrate it with the faces when required. I was also looking for some sample code if there's any. Thanks. -- Regards, Susmit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Feb 18 07:00:01 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 18 Feb 2016 08:00:01 -0700 Subject: [Nfd-dev] NFD call 20160218 Message-ID: <201602181500.u1IF01rK013728@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Feb 18 11:14:18 2016 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 18 Feb 2016 11:14:18 -0800 Subject: [Nfd-dev] NFD call 20160218 In-Reply-To: <201602181500.u1IF01rK013728@lectura.cs.arizona.edu> References: <201602181500.u1IF01rK013728@lectura.cs.arizona.edu> Message-ID: Dear all, Sorry for the delayed notice. We are canceling today's call. The next call will be, as scheduled, on Tuesday, Feb 23rd. --- Alex > On Feb 18, 2016, at 7:00 AM, NFD call notification wrote: > > Dear folks > > This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/760263096. The current call time is every Tuesday/Thursday 13:00-14:00 Pacific Time. The current agenda includes the following issues: > > > > Retreat planning > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlzu8 at gmail.com Tue Feb 23 03:19:11 2016 From: carlzu8 at gmail.com (Carl Zu) Date: Tue, 23 Feb 2016 12:19:11 +0100 Subject: [Nfd-dev] meaning of certain nfd.Forwarder logs ? Message-ID: Hi folks, I am running ndn-simple.cpp with prefix "nfd.Forwarder", certain logs appear in the beginning of terminal that I cannot clearly understand. I copy them below and ask my questions: the first two logs: 0s -1 nfd.Forwarder:onIncomingData(): [DEBUG] onIncomingData face=1 data=/localhost/nfd/faces/events/%FE%00 0s -1 nfd.Forwarder:onDataUnsolicited(): [DEBUG] onDataUnsolicited face=1 data=/localhost/nfd/faces/events/%FE%00 cached who is node -1 ?! (I suppose it should not be a node...). One of the first and foremost claims in NDN is a "pull-based" data retrieval. Why then terminal starts with incoming data pipeline before to sending any interests ? And why it is mentioned "cached" ? Repeating the same pattern, it changes to: 0s -1 nfd.Forwarder:onIncomingData(): [DEBUG] onIncomingData face=1 data=/localhost/nfd/fib/add-nexthop/h%0C%07%00i%02%01%00j%04%7F%FF%FF%FF/%01/DF (and a lot more :-) 0s -1 nfd.Forwarder:onDataUnsolicited(): [DEBUG] onDataUnsolicited face=1 data=/localhost/nfd/fib/add-nexthop/h%0C%07%00i%02%01%00j%04%7F%FF%FF%FF/%01/DFa%82t%E8%13%C6/%164%1B%01%01%1C%2F%07-(and a lot more :-) *Is this for FIB population ? I would really like to understand this deeper...* Later it changes to: 0s -1 nfd.Forwarder:onIncomingData(): [DEBUG] onIncomingData face=1 data=/localhost/nfd/strategy-choice/set/h3%07%08%08%06prefixk%27%07%25%08%09localhost And : 0s -1 ndn.Consumer:Consumer() 0s -1 ndn.Producer:Producer() Any guidance would be highly appreciated. C -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Feb 23 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 23 Feb 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160223 Message-ID: <201602231500.u1NF02cE024000@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From jdd at wustl.EDU Tue Feb 23 13:04:35 2016 From: jdd at wustl.EDU (Dehart, John) Date: Tue, 23 Feb 2016 21:04:35 +0000 Subject: [Nfd-dev] nfd-autoreg problems on the NDN Testbed Message-ID: <5728DEE3-E36D-4885-8B2F-0DB531942959@wustl.edu> We seem to be having problems with nfd-autoreg on the NDN Testbed. When nfd is restarted, nfd-autoreg works fine. But after some period of time, it appears to stop working. Unfortunately, I don?t have any data yet on when it stops working. For instance, right now on your laptop running nfd if you register a route to the UCLA node and do an ndnping to it, the ndnping will be successful and we see the face created on the UCLA node but there are no registered routes added on the UCLA node for this new face. The same was occurring on the REMAP node. Then, I restarted nfd on the REMAP node and did the same test and it does register routes for the new face. Has anyone else seen this issue? John From jdd at wustl.EDU Tue Feb 23 13:14:29 2016 From: jdd at wustl.EDU (Dehart, John) Date: Tue, 23 Feb 2016 21:14:29 +0000 Subject: [Nfd-dev] nfd-autoreg problems on the NDN Testbed In-Reply-To: <5728DEE3-E36D-4885-8B2F-0DB531942959@wustl.edu> References: <5728DEE3-E36D-4885-8B2F-0DB531942959@wustl.edu> Message-ID: <54F51C83-D7F4-40B1-AF0B-105868938EED@wustl.edu> More information. I just tested two more nodes in the Testbed: CSU and CAIDA. On each of them nfd-autoreg is working. CSU has been up for 46 days and CAIDA for 5. So, just the passing of time does not seem to be the key. John > On Feb 23, 2016, at 3:04 PM, Dehart, John wrote: > > > We seem to be having problems with nfd-autoreg on the NDN Testbed. > When nfd is restarted, nfd-autoreg works fine. But after some period of > time, it appears to stop working. Unfortunately, I don?t have any data yet > on when it stops working. > > For instance, right now on your laptop running nfd if you register a route > to the UCLA node and do an ndnping to it, the ndnping will be successful > and we see the face created on the UCLA node but there are no registered > routes added on the UCLA node for this new face. > > The same was occurring on the REMAP node. Then, I restarted nfd > on the REMAP node and did the same test and it does register routes > for the new face. > > Has anyone else seen this issue? > > John > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From jburke at remap.UCLA.EDU Tue Feb 23 13:24:56 2016 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Tue, 23 Feb 2016 21:24:56 +0000 Subject: [Nfd-dev] What is a "region" ? Message-ID: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> Hi, Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... For example, see section 4.2 of the NFD developer's guide. http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf [cid:597A9946-58BB-4C0C-A3FA-3825AEE7390A] 1) What is a region? 2) How should they be configured at each NFD? 3) [And, who is expected to configure them, and when?] Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2016-02-23 13.18.21.png Type: image/png Size: 40099 bytes Desc: Screenshot 2016-02-23 13.18.21.png URL: From jdd at wustl.EDU Tue Feb 23 13:32:12 2016 From: jdd at wustl.EDU (Dehart, John) Date: Tue, 23 Feb 2016 21:32:12 +0000 Subject: [Nfd-dev] nfd-autoreg problems on the NDN Testbed In-Reply-To: <54F51C83-D7F4-40B1-AF0B-105868938EED@wustl.edu> References: <5728DEE3-E36D-4885-8B2F-0DB531942959@wustl.edu> <54F51C83-D7F4-40B1-AF0B-105868938EED@wustl.edu> Message-ID: <956C7DD8-AA25-4833-B0C4-EC4712F3BE98@wustl.edu> In case anyone tries this out with UCLA, I just restart nfd there in preparation for ndncon for the seminar tomorrow. John > On Feb 23, 2016, at 3:14 PM, Dehart, John wrote: > > > More information. > I just tested two more nodes in the Testbed: CSU and CAIDA. > On each of them nfd-autoreg is working. CSU has been up for 46 days and CAIDA for 5. > So, just the passing of time does not seem to be the key. > > John > >> On Feb 23, 2016, at 3:04 PM, Dehart, John wrote: >> >> >> We seem to be having problems with nfd-autoreg on the NDN Testbed. >> When nfd is restarted, nfd-autoreg works fine. But after some period of >> time, it appears to stop working. Unfortunately, I don?t have any data yet >> on when it stops working. >> >> For instance, right now on your laptop running nfd if you register a route >> to the UCLA node and do an ndnping to it, the ndnping will be successful >> and we see the face created on the UCLA node but there are no registered >> routes added on the UCLA node for this new face. >> >> The same was occurring on the REMAP node. Then, I restarted nfd >> on the REMAP node and did the same test and it does register routes >> for the new face. >> >> Has anyone else seen this issue? >> >> John >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From M.AbdollahiSabet at mail.sbu.ac.ir Tue Feb 23 13:28:56 2016 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Wed, 24 Feb 2016 00:58:56 +0330 Subject: [Nfd-dev] What is a "region" ? References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29FC@m-pdc.sbu.ac.ir> Hi Jeff, On 2, I guess they should be configured in nfd.conf. Take a look at the .conf, after "strategy_choice" section, there is: ; Declare network region names ; These are used for mobility support. An Interest carrying a Link object is ; assumed to have reached the producer region if any delegation name in the ; Link object is a prefix of any region name. network_region { ; /example/region1 ; /example/region2 } I have no idea about 3rd and am eager to know. It must have something connection with ndns. Thanks, Sabet -----Original Message----- From: Nfd-dev on behalf of Burke, Jeff Sent: Wed 2/24/2016 12:54 AM To: nfd-dev at lists.cs.ucla.edu Subject: [Nfd-dev] What is a "region" ? Hi, Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... For example, see section 4.2 of the NFD developer's guide. http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf [cid:597A9946-58BB-4C0C-A3FA-3825AEE7390A] 1) What is a region? 2) How should they be configured at each NFD? 3) [And, who is expected to configure them, and when?] Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2016-02-23 13.18.21.png Type: image/png Size: 40099 bytes Desc: Screenshot 2016-02-23 13.18.21.png URL: From lixia at CS.UCLA.EDU Tue Feb 23 15:46:50 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Tue, 23 Feb 2016 15:46:50 -0800 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> Message-ID: <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> we are in group meeting now and explained how LINK (= forwarding hint) works to Zhehao and Haitao. We also trying to figure out a solution to the function you wanted (NDNfit's original design was based on a misconception of LINK). LINK is a forwarding hint, it just carries an interest to the place where the name in the interest can be used directly for lookup. Lixia > On Feb 23, 2016, at 1:24 PM, Burke, Jeff wrote: > > Hi, > > Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... > > For example, see section 4.2 of the NFD developer's guide. > http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf > > > > 1) What is a region? > 2) How should they be configured at each NFD? > 3) [And, who is expected to configure them, and when?] > > Thanks, > Jeff > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Tue Feb 23 16:02:17 2016 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Wed, 24 Feb 2016 00:02:17 +0000 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> Message-ID: <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> Thanks... It would be great to better understand the nature of the misconception, and what a "region" is ? I can't find a definition anywhere. Jeff From: Lixia Zhang > Date: Tuesday, February 23, 2016 at 3:46 PM To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] What is a "region" ? we are in group meeting now and explained how LINK (= forwarding hint) works to Zhehao and Haitao. We also trying to figure out a solution to the function you wanted (NDNfit's original design was based on a misconception of LINK). LINK is a forwarding hint, it just carries an interest to the place where the name in the interest can be used directly for lookup. Lixia On Feb 23, 2016, at 1:24 PM, Burke, Jeff > wrote: Hi, Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... For example, see section 4.2 of the NFD developer's guide. http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf 1) What is a region? 2) How should they be configured at each NFD? 3) [And, who is expected to configure them, and when?] Thanks, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.EDU Tue Feb 23 16:27:43 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Tue, 23 Feb 2016 17:27:43 -0700 Subject: [Nfd-dev] Fwd: ndn-traffic-generator with digest signing? In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Chengyu Fan Date: Tue, Feb 23, 2016 at 3:59 PM Subject: ndn-traffic-generator with digest signing? To: Junxiao Shi Hi Junxiao, Could you tell me how to use the "digest signing" in ndn-traffic-generator? I think you are talking about SignWithSha256 in server.conf in the NFD call. But it has been replace by SigningInfo. Should I checkout the old version? Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Tue Feb 23 16:56:58 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Tue, 23 Feb 2016 16:56:58 -0800 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> Message-ID: <6C3CA1F7-041E-4631-88F9-690350F68FBC@cs.ucla.edu> > On Feb 23, 2016, at 1:24 PM, Burke, Jeff wrote: > > > Hi, > > Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... > > For example, see section 4.2 of the NFD developer's guide. > http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf > > > > 1) What is a region? I don't have a good definition for the region, I can only give an implicit definition through its usage (details are in Section 4.2.3 of dev guide). Given Interest with data name and LINK with a set of delegations (forwarding hints), the set of "network region prefixes" determines whether the router should use "best" delegation or data name to forward the interest. It is related to a prefix or a set of prefixes that have (global) reachability---can be used to direct interests towards the NDN network or an NDN router. > 2) How should they be configured at each NFD? As of right now, manually. Note that this configuration must be done only on routers that do not have "default route", i.e., only on NDN Testbed routers. NFD that has default route always uses data name to forward the interest. In other words, clients connected to testbed routers don't need to do anything. > 3) [And, who is expected to configure them, and when?] As of right now, hub operator. Need to be configured whenever reachability changes (new prefixes are announced in NLSR). In the long term, there should be a form of automation (injecting from NLSR or NLSR should announce based on centralized config). --- Alex -------------- 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 wangzhehao410305 at gmail.com Tue Feb 23 17:07:28 2016 From: wangzhehao410305 at gmail.com (Zhehao Wang) Date: Tue, 23 Feb 2016 17:07:28 -0800 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> Message-ID: Hi Jeff, It would be great to better understand the nature of the misconception The nature of the misconception, as I see it, is that link delegations are meant to be forwarding hints only, and should not carry things such as a DPU function name and parameters. (We should go over the "ndn-omh-dpu-notes-20160210b" slides discussed in Open mHealth call two weeks ago again, as the design, illustrated by an example in its slide 15, is not how link's meant to be used;) Also, I think it would be nice to update the link design document in redmine (which has, for example, misleading delegation names (that are specific data names such as "/att/user/alex/net/ndnsim")). Thanks, Zhehao On Tue, Feb 23, 2016 at 4:02 PM, Burke, Jeff wrote: > Thanks... It would be great to better understand the nature of the > misconception, and what a "region" is ? I can't find a definition anywhere. > Jeff > > From: Lixia Zhang > Date: Tuesday, February 23, 2016 at 3:46 PM > To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] What is a "region" ? > > we are in group meeting now and explained how LINK (= forwarding hint) > works to Zhehao and Haitao. We also trying to figure out a solution to the > function you wanted (NDNfit's original design was based on a misconception > of LINK). > > LINK is a forwarding hint, it just carries an interest to the place where > the name in the interest can be used directly for lookup. > > Lixia > > On Feb 23, 2016, at 1:24 PM, Burke, Jeff wrote: > > Hi, > > Even after looking at relevant sections in the NFD developer's guide, we > are blocked on finishing the NDNFit forwarding hint design by not > understanding the specific definition of what a "region" is, and how they > should be confirmed in practice... > > For example, see section 4.2 of the NFD developer's guide. > > http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf > > > > 1) What is a region? > 2) How should they be configured at each NFD? > 3) [And, who is expected to configure them, and when?] > > Thanks, > Jeff > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Tue Feb 23 18:54:38 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Tue, 23 Feb 2016 18:54:38 -0800 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> Message-ID: > On Feb 23, 2016, at 4:02 PM, Burke, Jeff wrote: > > Thanks... It would be great to better understand the nature of the misconception, and what a "region" is ? I can't find a definition anywhere. > Jeff Let me try a simple explanation: 1/ a LINK is to get an interest to the place where the name in the interest can be used directly for lookup 2/ routers do FIB lookup using LINK first (if interest carries one), until the interest reaches the place (so called "region") where its name is in the FIB, then the router will do look up using the interest name 3/ a router decides whether the LINK has finished its job by comparing LINK with its own name: if the LINK is either its prefix or an exact match to the name, then the LINK is no longer needed. Every entity in an NDN network should know its own name (how it learns the name is design/implementation question). > From: Lixia Zhang > > Date: Tuesday, February 23, 2016 at 3:46 PM > To: Jeff Burke > > Cc: "nfd-dev at lists.cs.ucla.edu " > > Subject: Re: [Nfd-dev] What is a "region" ? > >> we are in group meeting now and explained how LINK (= forwarding hint) works to Zhehao and Haitao. We also trying to figure out a solution to the function you wanted (NDNfit's original design was based on a misconception of LINK). >> >> LINK is a forwarding hint, it just carries an interest to the place where the name in the interest can be used directly for lookup. >> >> Lixia >> >>> On Feb 23, 2016, at 1:24 PM, Burke, Jeff > wrote: >>> >>> Hi, >>> >>> Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... >>> >>> For example, see section 4.2 of the NFD developer's guide. >>> http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf >>> >>> >>> >>> 1) What is a region? >>> 2) How should they be configured at each NFD? >>> 3) [And, who is expected to configure them, and when?] >>> >>> Thanks, >>> Jeff >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Feb 24 01:30:51 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 24 Feb 2016 02:30:51 -0700 Subject: [Nfd-dev] Fwd: Fwd: ndn-traffic-generator with digest signing? In-Reply-To: References: <2D0144D3-BBEF-4587-A65D-B1CDBEA1B344@cs.arizona.edu> Message-ID: ---------- Forwarded message ---------- From: Spencer Lee Date: Wed, Feb 24, 2016 at 12:19 AM Subject: Re: [Nfd-dev] Fwd: ndn-traffic-generator with digest signing? To: Beichuan Zhang Cc: Chengyu Fan , Junxiao Shi < shijunxiao at email.arizona.edu> Hi Chengyu, Do you want to use ndn-traffic-generator through configuration files? Like in the sample execution in the read.me? https://github.com/named-data/ndn-traffic-generator#3-sample-run-instructions Are you trying to use digest Sha256 signing? a simple example of a server configuration would be this: ########## Name=/test/E Content=EEEEEEEE SigningInfo=id:/localhost/identity/digest-sha256 an example procedure with some general steps to using ndn-traffic-generator can also be seen in the github issues page: https://github.com/named-data/ndn-traffic-generator/issues/6. Please let me know if that helps. Thanks, Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreylmaia at gmail.com Wed Feb 24 07:06:05 2016 From: andreylmaia at gmail.com (andrey maia) Date: Wed, 24 Feb 2016 12:06:05 -0300 Subject: [Nfd-dev] NDN for android - NDNWhiteboard Message-ID: Hi everyone, I'm trying to run the NDNWhiteboard setting the routes to my own PC (using udp://MY_PC_IP instead of udp://spurs.cs.ucla.edu) I already have an InterestFilter, based on consumer-producer API, set up to my PC (instead of /ndn/edu/ucla/remap/ping).It is working for ping, but I'm still not able to fetch any content properly from other devices. *RegisterChronoSyncTask: SYNC: /ndn/edu/ucla/...* don't even appears in my log Am I forgetting some configuration on my server? It would be very helpful, if anyone could help me on this issue. Thanks in advance, Andrey Maia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Wed Feb 24 08:16:47 2016 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Wed, 24 Feb 2016 16:16:47 +0000 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> Message-ID: <29EDA178-92A4-4699-B598-F7775CF1157A@remap.ucla.edu> Thanks for the explanation...! Let me try a simple explanation: 1/ a LINK is to get an interest to the place where the name in the interest can be used directly for lookup 2/ routers do FIB lookup using LINK first (if interest carries one), until the interest reaches the place (so called "region") where its name is in the FIB, then the router will do look up using the interest name (Just to double-check - what's the "its" here?) 3/ a router decides whether the LINK has finished its job by comparing LINK with its own name: if the LINK is either its prefix or an exact match to the name, then the LINK is no longer needed. Not sure I follow ? why should the router care whether the LINK name has anything to do with its name, shouldn't it only care if it can forward based on the Interest name or not? (And, I guess, if it is "responsible" the LINK prefix?) I think I understand the basic idea but am confused about the introduction of the router's administrative identity into forwarding decisions. Isn't the point simply that the Interest reaches a router that is 1) sufficiently "responsible" for the LINK prefix that it can ignore it and 2) capable of forwarding the Interest name itself? I guess this is the point of the regions list ? to define responsibility? (Also, if I am correct, the word 'region' seems to unnecessarily imply a perimeter / geographic boundary rather than a capability. I wonder if it is the right term.) To use a specific example: When an Interest with LINK /com/microsoft/healthvault reaches a router /com/microsoft/routers/us/west/foo/47 at the edge of its AS, that router could have a region entry for "/com/microsoft/healthvault" and directly forward "/org/openmhealth" appropriately. This doesn't meet the link prefix matching requirement but isn't unreasonable...? Or am I missing something? Every entity in an NDN network should know its own name (how it learns the name is design/implementation question). Yes, but does entity name correspond directly to forwarding responsibility? (Is this convention or requirement?) Thanks, Jeff From: Lixia Zhang > Date: Tuesday, February 23, 2016 at 3:46 PM To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] What is a "region" ? we are in group meeting now and explained how LINK (= forwarding hint) works to Zhehao and Haitao. We also trying to figure out a solution to the function you wanted (NDNfit's original design was based on a misconception of LINK). LINK is a forwarding hint, it just carries an interest to the place where the name in the interest can be used directly for lookup. Lixia On Feb 23, 2016, at 1:24 PM, Burke, Jeff > wrote: Hi, Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... For example, see section 4.2 of the NFD developer's guide. http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf 1) What is a region? 2) How should they be configured at each NFD? 3) [And, who is expected to configure them, and when?] Thanks, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Wed Feb 24 08:22:05 2016 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Wed, 24 Feb 2016 16:22:05 +0000 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <6C3CA1F7-041E-4631-88F9-690350F68FBC@cs.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> <6C3CA1F7-041E-4631-88F9-690350F68FBC@cs.ucla.edu> Message-ID: <82CA2914-12A5-4467-BA4A-96396AECED59@remap.ucla.edu> > >> On Feb 23, 2016, at 1:24 PM, Burke, Jeff wrote: >> >> >> Hi, >> >> Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... >> >> For example, see section 4.2 of the NFD developer's guide. >> http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf >> >> >> >> 1) What is a region? > >I don't have a good definition for the region, I can only give an implicit definition through its usage (details are in Section 4.2.3 of dev guide). > >Given Interest with data name and LINK with a set of delegations (forwarding hints), the set of "network region prefixes" determines whether the router should use "best" delegation or data name to forward the interest. Ok, as I mentioned in my email to Lixia, does that mean that "responsibility" for the prefix is the basic concept here? (In order to ignore the LINK?) > >It is related to a prefix or a set of prefixes that have (global) reachability---can be used to direct interests towards the NDN network or an NDN router. > >> 2) How should they be configured at each NFD? > >As of right now, manually. > >Note that this configuration must be done only on routers that do not have "default route", i.e., only on NDN Testbed routers. NFD that has default route always uses data name to forward the interest. In other words, clients connected to testbed routers don't need to do anything. Could it be done internally too, if one wanted to say, implement the ability to issue Interests with LINKs to /edu/ucla/remap/healthvault that were forwarded all the way to a node (past REMAP border node) to a host or set of hosts that handled /org/openmhealth namespace? > >> 3) [And, who is expected to configure them, and when?] > >As of right now, hub operator. Need to be configured whenever reachability changes (new prefixes are announced in NLSR). > >In the long term, there should be a form of automation (injecting from NLSR or NLSR should announce based on centralized config). > >- Thanks, Jeff >-- >Alex > From lixia at CS.UCLA.EDU Wed Feb 24 08:35:33 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 24 Feb 2016 08:35:33 -0800 Subject: [Nfd-dev] What is a "region" ? In-Reply-To: <29EDA178-92A4-4699-B598-F7775CF1157A@remap.ucla.edu> References: <3B126FA3-136F-4C43-9C13-083CB5DA3BDB@remap.ucla.edu> <2E9A4C95-4ECF-42C5-927E-EF9CD38A75CF@cs.ucla.edu> <48829FCC-32BC-4477-80E4-BC4BFC051BA0@remap.ucla.edu> <29EDA178-92A4-4699-B598-F7775CF1157A@remap.ucla.edu> Message-ID: > On Feb 24, 2016, at 8:16 AM, Burke, Jeff wrote: > > Thanks for the explanation...! > >> >> Let me try a simple explanation: >> 1/ a LINK is to get an interest to the place where the name in the interest can be used directly for lookup >> 2/ routers do FIB lookup using LINK first (if interest carries one), until the interest reaches the place (so called "region") where its name is in the FIB, then the router will do look up using the interest name > > > (Just to double-check - what's the "its" here?) its=the interest >> 3/ a router decides whether the LINK has finished its job by comparing LINK with its own name: if the LINK is either its prefix or an exact match to the name, then the LINK is no longer needed. > > > Not sure I follow ? why should the router care whether the LINK name has anything to do with its name, shouldn't it only care if it can forward based on the Interest name or not? (And, I guess, if it is "responsible" the LINK prefix?) the router should first consider LINK > I think I understand the basic idea but am confused about the introduction of the router's administrative identity into forwarding decisions. Isn't the point simply that the Interest reaches a router that is 1) sufficiently "responsible" for the LINK prefix that it can ignore it and 2) capable of forwarding the Interest name itself? I guess this is the point of the regions list ? to define responsibility? it is much less of "responsibility" per se, but the interest needs to reach a place where the name in the interest can be use used for forwarding. > (Also, if I am correct, the word 'region' seems to unnecessarily imply a perimeter / geographic boundary rather than a capability. I wonder if it is the right term.) not sure what you meant by "capability". the issue here is whether the name carried in the interest can match anything in the FIB > To use a specific example: > > When an Interest with LINK /com/microsoft/healthvault reaches a router /com/microsoft/routers/us/west/foo/47 at the edge of its AS, that router could have a region entry for "/com/microsoft/healthvault" and directly forward "/org/openmhealth" appropriately. I did not follow how the above: where is this "/org/openmhealth"? step up a level: there seems some conceptual cross talk here. Maybe best we get together with a whiteboard rather than using this ineffective email > This doesn't meet the link prefix matching requirement but isn't unreasonable...? Or am I missing something? > >> >> Every entity in an NDN network should know its own name (how it learns the name is design/implementation question). > > > Yes, but does entity name correspond directly to forwarding responsibility? (Is this convention or requirement?) > > Thanks, > Jeff > >> >> >>> From: Lixia Zhang > >>> Date: Tuesday, February 23, 2016 at 3:46 PM >>> To: Jeff Burke > >>> Cc: "nfd-dev at lists.cs.ucla.edu " > >>> Subject: Re: [Nfd-dev] What is a "region" ? >>> >>>> we are in group meeting now and explained how LINK (= forwarding hint) works to Zhehao and Haitao. We also trying to figure out a solution to the function you wanted (NDNfit's original design was based on a misconception of LINK). >>>> >>>> LINK is a forwarding hint, it just carries an interest to the place where the name in the interest can be used directly for lookup. >>>> >>>> Lixia >>>> >>>>> On Feb 23, 2016, at 1:24 PM, Burke, Jeff > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Even after looking at relevant sections in the NFD developer's guide, we are blocked on finishing the NDNFit forwarding hint design by not understanding the specific definition of what a "region" is, and how they should be confirmed in practice... >>>>> >>>>> For example, see section 4.2 of the NFD developer's guide. >>>>> http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf >>>>> >>>>> >>>>> >>>>> 1) What is a region? >>>>> 2) How should they be configured at each NFD? >>>>> 3) [And, who is expected to configure them, and when?] >>>>> >>>>> Thanks, >>>>> Jeff >>>>> >>>>> _______________________________________________ >>>>> Nfd-dev mailing list >>>>> Nfd-dev at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengy.fan at gmail.com Wed Feb 24 13:18:47 2016 From: chengy.fan at gmail.com (Chengyu Fan) Date: Wed, 24 Feb 2016 14:18:47 -0700 Subject: [Nfd-dev] Fwd: ndn-traffic-generator with digest signing? In-Reply-To: References: <2D0144D3-BBEF-4587-A65D-B1CDBEA1B344@cs.arizona.edu> Message-ID: Thanks, Spencer. It works. It would be helpful if you can put such SigningInfo examples in the server.conf. On Wed, Feb 24, 2016 at 2:30 AM, Junxiao Shi wrote: > > ---------- Forwarded message ---------- > From: Spencer Lee > Date: Wed, Feb 24, 2016 at 12:19 AM > Subject: Re: [Nfd-dev] Fwd: ndn-traffic-generator with digest signing? > To: Beichuan Zhang > Cc: Chengyu Fan , Junxiao Shi < > shijunxiao at email.arizona.edu> > > > Hi Chengyu, > > Do you want to use ndn-traffic-generator through configuration files? > > Like in the sample execution in the read.me? > https://github.com/named-data/ndn-traffic-generator#3-sample-run-instructions > > Are you trying to use digest Sha256 signing? a simple example of a server > configuration would be this: > > ########## > Name=/test/E > Content=EEEEEEEE > SigningInfo=id:/localhost/identity/digest-sha256 > > an example procedure with some general steps to using > ndn-traffic-generator can also be seen in the github issues page: > https://github.com/named-data/ndn-traffic-generator/issues/6. > > Please let me know if that helps. > > Thanks, > Spencer > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Feb 25 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 25 Feb 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160225 Message-ID: <201602251500.u1PF02xN002671@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Thu Feb 25 07:22:05 2016 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Thu, 25 Feb 2016 15:22:05 +0000 Subject: [Nfd-dev] Help with NDN-RTC measurement/troubleshooting Message-ID: <96DD520B-1C7F-4082-8134-2F14BDF53C7F@remap.ucla.edu> Forwarding a portion of this thread from the PI mailing list for consideration in the call today. (Unfortunately neither Peter or I can join the call but we can check in with Jeff Thompson about the discussion and join next week.) Jeff From: Lixia Zhang > Date: Wednesday, February 24, 2016 at 3:23 PM To: Jeff Burke > Cc: "ndn-pis at lists.cs.ucla.edu" >, "Dehart, John" >, "Gusev, Peter" > Subject: Re: [Ndn-pis] Week-by-week steps with NDN-RTC I think today's ndn-rtc trial is a great success -- although maybe just half dozen people on it, still perhaps the largest size we have tried. I fully support that we should keep doing it from now on, to tune it up. Hope we get more people on ndn-rtc next time (I will make sure that everyone in my group gets on it) I was disappointed that we only had 4 PIs on the call -- everyone stated on the doodle pool that they are available on this time slot (2PM PT Wed). Hope to see more people get on next seminar. I assume the NFD call group would follow up the specific questions you listed below. Lixia On Feb 24, 2016, at 3:14 PM, Burke, Jeff > wrote: Hi, So, I think the call quality of NDN-RTC was not so great for the seminar... but we tried it. Thanks to all that participated! I'd like to suggest that we keep using NDN-RTC each week (with WebEx as a backup) and treat its performance as an engineering problem to be collectively solved in steps week-by-week with participation from people in each group as time allows, in addition to driving bigger picture research questions. (Put another way ? I am excited that we are dealing with congestion control but the conversation seems to be not heading to make any performance impact in the next two months.) Would people be open to this approach? For example, 1) Could we hack traffic monitoring tools specific to the NDN-RTC namespace, and use them next week to understand what's happening at each node? 2) Any quick solution to audio prioritization? 3) Peter, can we turn on the "adaptive rate control" detection algorithms for next week but disable stream switching, so we can start to log whether or not the E2E approach detect congestion but not actually rely on it working? 4) Is there an immediate congestion control idea that could be tried on just a couple of (perhaps non-testbed nodes) in 5) Should we explicitly collect impressions from everyone on performance? Just brainstorming out-loud, but I'm wondering if it makes sense to try to treat this as a practical collective problem to get working ASAP... we could use the help. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Thu Feb 25 18:46:43 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Thu, 25 Feb 2016 18:46:43 -0800 Subject: [Nfd-dev] NDN for android - NDNWhiteboard In-Reply-To: References: Message-ID: <59BA907F-F5DB-4AC5-85C5-74D18E07088E@cs.ucla.edu> Hi Andrey, I copied Peter, one of the authors of the whiteboard application, on this reply. Hope he'd be able to help answer your questions Lixia > On Feb 24, 2016, at 7:06 AM, andrey maia wrote: > > Hi everyone, > > I'm trying to run the NDNWhiteboard setting the routes to my own PC > (using udp://MY_PC_IP instead of udp://spurs.cs.ucla.edu ) > > I already have an InterestFilter, based on consumer-producer API, set up to my PC (instead of /ndn/edu/ucla/remap/ping).It is working for ping, but I'm still not able to fetch any content properly from other devices. > > RegisterChronoSyncTask: SYNC: /ndn/edu/ucla/... don't even appears in my log > > Am I forgetting some configuration on my server? > It would be very helpful, if anyone could help me on this issue. > > Thanks in advance, > > Andrey Maia > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.t.bankole at gmail.com Thu Feb 25 22:17:47 2016 From: peter.t.bankole at gmail.com (Peter Bankole) Date: Thu, 25 Feb 2016 22:17:47 -0800 Subject: [Nfd-dev] NDN for android - NDNWhiteboard In-Reply-To: <59BA907F-F5DB-4AC5-85C5-74D18E07088E@cs.ucla.edu> References: <59BA907F-F5DB-4AC5-85C5-74D18E07088E@cs.ucla.edu> Message-ID: Hi Andrey, Let me make sure I understand your question correctly. Are you setting your PC as an NDN node? . There could be several reasons why its not working correctly. It could be a firewall. We never got it work with our PC. We always used the spurs.cs.ucla.edu route. Alex Afanasyev from the NDN lab is the best to answer this question. v/r Peter On Thu, Feb 25, 2016 at 6:46 PM, Lixia Zhang wrote: > Hi Andrey, > > I copied Peter, one of the authors of the whiteboard application, on this > reply. Hope he'd be able to help answer your questions > > Lixia > > > On Feb 24, 2016, at 7:06 AM, andrey maia wrote: > > Hi everyone, > > I'm trying to run the NDNWhiteboard setting the routes to my own PC > (using udp://MY_PC_IP instead of udp://spurs.cs.ucla.edu) > > I already have an InterestFilter, based on consumer-producer API, set up > to my PC (instead of /ndn/edu/ucla/remap/ping).It is working for ping, > but I'm still not able to fetch any content properly from other devices. > > *RegisterChronoSyncTask: SYNC: /ndn/edu/ucla/...* don't even appears in > my log > > Am I forgetting some configuration on my server? > It would be very helpful, if anyone could help me on this issue. > > Thanks in advance, > > Andrey Maia > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Fri Feb 26 00:20:06 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 26 Feb 2016 00:20:06 -0800 Subject: [Nfd-dev] NDN for android - NDNWhiteboard In-Reply-To: References: Message-ID: > On Feb 24, 2016, at 7:06 AM, andrey maia wrote: > > Hi everyone, > > I'm trying to run the NDNWhiteboard setting the routes to my own PC > (using udp://MY_PC_IP instead of udp://spurs.cs.ucla.edu) > > I already have an InterestFilter, based on consumer-producer API, set up to my PC (instead of /ndn/edu/ucla/remap/ping). It is working for ping, but I'm still not able to fetch any content properly from other devices. > > RegisterChronoSyncTask: SYNC: /ndn/edu/ucla/... don't even appears in my log > > Am I forgetting some configuration on my server? > It would be very helpful, if anyone could help me on this issue. > > Thanks in advance, > > Andrey Maia As I understand, the issue is that your own PC has no idea that it needs to forward interests towards the devices. There is a proper solution (automatic prefix propagation), but it not yet working with NFD-android. The current workaround is to run additional nfd-autoreg daemon on your PC. nfd-autoreg automatically creates a route for the defined prefix whenever somebody triggers creation of "on-demand" face (e.g., by sending interest over UDP face). In the simplest case, just run nfd-autoreg --prefix=/some/prefix After that you will need to update the Whiteboard app to use the same prefix. * * * Just a side note. The correct solution is for Whiteboard app to obtain (in some automatic way) key and cert that correspond to the prefix under which it can publish. Using this key, the app/NFD-android will be able to automatically register and maintain "back route" from the hub (your PC) towards the phone. There are a few components that we have developed for this, but given limited manpower it is still in progress. --- Alex -------------- 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 aa at CS.UCLA.EDU Fri Feb 26 12:17:34 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 26 Feb 2016 12:17:34 -0800 Subject: [Nfd-dev] Sample ndnlp fragmentation/reassembly code In-Reply-To: References: Message-ID: <06FBF594-9D57-47DF-AE85-F6734F8EB26C@cs.ucla.edu> Just to record the discussion we had during NFD call yesterday. Fragmentation is already enabled in NFD on all datagram faces (ethernet, unicast udp, multicast udp). However, when it kicks in depends on the "MTU" settings for the face: - for raw ethernet-based faces, NFD obtains MTU size from the network adapter - for UDP-based, "MTU" (as it is currently defined) is a maximum size for UDP datagram, i.e., around 64k bytes. --- Alex > On Feb 16, 2016, at 12:54 PM, Junxiao Shi wrote: > > ---------- Forwarded message ---------- > From: Susmit > Date: Tue, Feb 16, 2016 at 10:10 AM > Subject: Sample ndnlp fragmentation/reassembly code > To: Junxiao Shi > > > Hi Junxiao, > > I was wandering what's the plan for NDNLPv2. Would it be integrated > with the faces by default or it's just an API that enables > fragmentation and the user would integrate it with the faces when > required. > I was also looking for some sample code if there's any. > > Thanks. > > -- > Regards, > Susmit. -------------- 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 jburke at remap.ucla.edu Sun Feb 28 09:38:50 2016 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Sun, 28 Feb 2016 17:38:50 +0000 Subject: [Nfd-dev] NDN-RTC testing, next steps Message-ID: Hi folks, Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC. I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat. It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items. Please reply within the appropriate redmine issue, if possible, rather than by email. A. Next tests 1. March 2 seminar. Christos will give the next seminar on March 2. Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time? Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test? My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes. http://redmine.named-data.net/issues/3485 2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC. John is already helping with this. We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach. Who should it be? http://redmine.named-data.net/issues/3487 3. Enable ARC detectors. Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does? http://redmine.named-data.net/issues/3488 B. Remaining triage on last test 1. PIT / name-tree entries. After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate? Or, provide instrumentation to do this after the next test on this coming Wednesday? http://redmine.named-data.net/issues/3484 @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread. 2. Capture of NFD parameters during the test. John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?) This would be useful in evaluating these tests and also looking for relevant behavior during the test. Assignee: WUSTL? http://redmine.named-data.net/issues/3486 3. NDN-RTC: Summarize results of internal testing. Peter, folks need to understand better what we think should work based on the testing you and Jiachen did. Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter. Due: ASAP. http://redmine.named-data.net/issues/3483 C. Application issues 1. NDN-RTC: Bandwidth performance. Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are? Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect. Assignee: Peter Due: Before next seminar. http://redmine.named-data.net/issues/3478 2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load. (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique. This optimization should be something that can be turned on/off in the GUI.) Assignee: Peter Due: Perhaps before retreat http://redmine.named-data.net/issues/3477 D. NFD performance The previous section are performance optimizations. We can do them, but have to know our target: 1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions. Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed? http://redmine.named-data.net/issues/3482 E. More NDN-RTC evaluation tools I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first. 1. Simulation: Real app. Klaus and others would like to be able to simulate NDN-RTC traffic. Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world. http://redmine.named-data.net/issues/3479 2. Emulation. In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue? https://github.com/named-data/mini-ndn http://redmine.named-data.net/issues/3481 3. Simulation: traffic generator. If the above is not feasible, Lixia suggests a simple traffic generator could also be written. (See 2/26 17:26 message). http://redmine.named-data.net/issues/3480 F. Debugging support 1. NFD Instrumentation. Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it. Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?) http://redmine.named-data.net/issues/3476 G. Design challenges / Useful mechanisms 1. Prioritization. For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago. Can we pursue design and discussion of this? http://redmine.named-data.net/issues/3475 [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?] 2. Congestion control work continues in parallel by Klaus. Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans. Klaus, could you let us know this in the redmine issue, http://redmine.named-data.net/issues/1624 [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?] Thanks! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: