From christian.tschudin at unibas.ch Mon Jun 1 03:56:03 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Mon, 1 Jun 2015 12:56:03 +0200 (CEST) Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: Message-ID: Hi Junxiao, thanks for these answers. So it seems that NDNLPv2 will be an index-fragment protocol only, for the link-types mentioned in "Goals" only, and no B-E variant ever? My assumption was that NDNLP would be a "framework" that various sub-network-layer protocols would share for their task-specific headers. But it seems that this is quite wrong. What would you suggest as header structure for bringing LP variants into the type-value-space of NDN packets? A forth outer type? best, christian On Thu, 28 May 2015, Junxiao Shi wrote: > Hi Christian > NdnlpHeader wrapper > In the full plan?NDNLPv2_20150513.pptx?page 17-20, we have a header and a > trailer. The header wrapper makes it easier to define the portion covered by > HMAC signature (page 53), and permits a padding at the end of header (page > 24). > 2-octet overhead is negligible on the link types mentioned in "Goals" > section. NDNLPv2 is not designed for 20-octet MTU links; those links need a > different link adaptation layer protocol. > > B-E Fragmentation and extra fragment types > No, only NdnlpFragment type is allowed. > 3-octet overhead is negligible on the link types mentioned in "Goals" > section. NDNLPv2 is not designed for 20-octet MTU links; those links need a > different link adaptation layer protocol. > > Concatenation in single frame > NDNLPv2 is able to operation on a stream socket, so it can handle > concatenation in a single frame. > However, NDNLPv2 does not define whether concatenation is allowed, and this > is up to face implementation. > Seealso?http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.ht > ml on a related topic about WebSocket frame vs network layer packets. > > NdnlpSequence width > The width is chosen by link implementation. > Suppose EthernetFace implementation for 100Mbps link has chosen 48-bit, all > NdnlpSequence on this link must be 48-bit. > There's no negotiation. > > Unknown Fields > Excerpt from?NDNLPv2_20150513.pptx?page 27: > Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure > everyone to understand all fields. > > > Ignoring an unknown field will cause incorrect operations, see #2520 > note-11. > > A vendor-specific extension can claim a TLV-TYPE as "known field but > relevant feature is disabled". > This is not a "unknown field". > > Extension fields on first fragment only > This mainly applies to extension fields that decorate a whole network layer > packet. > For example, it's sufficient to add a Network NACK on the first fragment, > and it's unnecessary to repeat the Network NACK field on subsequent > fragments. > > Fields that do not decorate a network layer packet, such as Automated Repeat > reQuest, can be added to any fragment. > > Yours, Junxiao > > On Thu, May 28, 2015 at 7:33 AM, wrote: > Dear Junxiao, > > thanks for sharing your design plans and the possibility to > comment. > > A packet layout question: Isn't the NdnlpHeader wrapper > redundant? You can see this in the grammar where no other field > can ever follow the outer NDNLP-PACKET-TYPE and -length. > > Or are there plans for other fields coming before or instead of > the NdnlpHeader? Else I guess that this was introduced for > parsing speed reasons? But the price is considerable: at least 2 > mandatory bytes for every Ndnlp packet for carrying no > additional information. > > Regarding fragmentation, I'm wondering about plans for the B+E > style mentioned in the slides. Could additional fragment types > be forseen? > > ? fragmentBegin, fragmentMiddle, fragmendEnd and > fragmentBeginEnd > > This would bring the overhead from 2 or 3 bytes for a B+E header > extension down to 0 additional bytes. *) > > Finally some suggestions where the packet format description > could benefit from clarifications regarding operational aspects: > > - NDNLP packet stuffing (concatenation) inside the same frame: > ? ok or not? > > - mixed NDNLP/Interest/Data stuffing inside the same frame: ok > or not? > > - fixed width of sequence number field: can the sender choose > ? unilateraly or will be there a link negotiation protocol? Can > ? the sender change the width on the fly? > > - Isn't the statement that "If an incoming NdnlpPacket contains > unknown > ? fields, the receiver MUST drop the packet" evolution-hostile, > also > ? against the old principle of "be liberal in what you accept"? > > ? Or expresses this a stance against the feature interaction > problem > ? and wants to prevent vendor-specific extensions? Asked > differently: > ? Shouldn't there be a type range reserved for experimental and > ? vendor-specific extensions with an explicit semantics on how > to > ? process such packets with unknown extensions (without dropping > the > ? packet alltogether)? > > - Related: Does the statement (in the indexed fragmentation > section) > ? reading "Unless otherwise specified, header extension fields > from > ? other features shall only appear on the first fragment." mean > that > ? in general a link feature can/will squat the link for some > ? self-chosen duration? > ? For example, a hypothetical "urgent msg feature" (or signals > like > ? a fragment ack or nack feature running in the other direction) > would > ? have to wait until a fragment train has ended? > > best, christian > > > *) Looking at the "minimum Ndnlp packet fragment overhead" might > be > ? ?an interesting metric to observe in the design. Currently, it > seems > ? ?that a B+E scheme in NDNLP will vary between 12 and 7 bytes > of > ? ?overhead, depending on the final design and type allocation > choices > ? ?that will be made. In a BT low energy context with 20B MTU > this > ? ?means a change from 8 to 13 bytes payload, a 60% capacity > increase. > > > On Tue, 26 May 2015, Junxiao Shi wrote: > > > Dear folks > > I have written the protocol spec of first batch of > features in NDNLPv2, and > I need someone to review the design. > > http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2 > > If you don't know what this is about, see #2520, > #2763,andhttp://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417. > ppt > x > > I'll appreciate all review comments. > You don't have to be an expert in order to do a > design review. > > Yours, Junxiao > > > > > > From shijunxiao at email.arizona.edu Thu Jun 4 12:00:20 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 4 Jun 2015 12:00:20 -0700 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: Message-ID: Hi Christian The statement "NDNLPv2 will be an index-fragment protocol only" is wrong. B-E fragmentation is possible, but B-indicator and E-indicator need to be header fields. The NdnlpFragment type remains the same. Your assumption is not wrong. NDNLPv2 is designed to be extensible: each feature can add its own header or trailer fields. Typically, a link should not have multiple link protocols: most links should use NDNLPv2; a link with ultra low MTU (eg. NFC) should use a different link protocol (probably with a fixed header). Otherwise, it's up to the link implementation to differentiate between a NDNLPv2 packet and a packet of another link protocol. Yours, Junxiao On Mon, Jun 1, 2015 at 3:56 AM, wrote: > Hi Junxiao, > > thanks for these answers. > > So it seems that NDNLPv2 will be an index-fragment protocol only, for the > link-types mentioned in "Goals" only, and no B-E variant ever? > > My assumption was that NDNLP would be a "framework" that various > sub-network-layer protocols would share for their task-specific headers. > But it seems that this is quite wrong. > > What would you suggest as header structure for bringing LP variants into > the type-value-space of NDN packets? A forth outer type? > > best, christian > > > > On Thu, 28 May 2015, Junxiao Shi wrote: > > Hi Christian >> NdnlpHeader wrapper >> In the full plan NDNLPv2_20150513.pptx page 17-20, we have a header and a >> trailer. The header wrapper makes it easier to define the portion covered >> by >> HMAC signature (page 53), and permits a padding at the end of header (page >> 24). >> 2-octet overhead is negligible on the link types mentioned in "Goals" >> section. NDNLPv2 is not designed for 20-octet MTU links; those links need >> a >> different link adaptation layer protocol. >> >> B-E Fragmentation and extra fragment types >> No, only NdnlpFragment type is allowed. >> 3-octet overhead is negligible on the link types mentioned in "Goals" >> section. NDNLPv2 is not designed for 20-octet MTU links; those links need >> a >> different link adaptation layer protocol. >> >> Concatenation in single frame >> NDNLPv2 is able to operation on a stream socket, so it can handle >> concatenation in a single frame. >> However, NDNLPv2 does not define whether concatenation is allowed, and >> this >> is up to face implementation. >> Seealso >> http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.ht >> ml on a related topic about WebSocket frame vs network layer packets. >> >> NdnlpSequence width >> The width is chosen by link implementation. >> Suppose EthernetFace implementation for 100Mbps link has chosen 48-bit, >> all >> NdnlpSequence on this link must be 48-bit. >> There's no negotiation. >> >> Unknown Fields >> Excerpt from NDNLPv2_20150513.pptx page 27: >> Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure >> everyone to understand all fields. >> >> >> Ignoring an unknown field will cause incorrect operations, see #2520 >> note-11. >> >> A vendor-specific extension can claim a TLV-TYPE as "known field but >> relevant feature is disabled". >> This is not a "unknown field". >> >> Extension fields on first fragment only >> This mainly applies to extension fields that decorate a whole network >> layer >> packet. >> For example, it's sufficient to add a Network NACK on the first fragment, >> and it's unnecessary to repeat the Network NACK field on subsequent >> fragments. >> >> Fields that do not decorate a network layer packet, such as Automated >> Repeat >> reQuest, can be added to any fragment. >> >> Yours, Junxiao >> >> On Thu, May 28, 2015 at 7:33 AM, wrote: >> Dear Junxiao, >> >> thanks for sharing your design plans and the possibility to >> comment. >> >> A packet layout question: Isn't the NdnlpHeader wrapper >> redundant? You can see this in the grammar where no other field >> can ever follow the outer NDNLP-PACKET-TYPE and -length. >> >> Or are there plans for other fields coming before or instead of >> the NdnlpHeader? Else I guess that this was introduced for >> parsing speed reasons? But the price is considerable: at least 2 >> mandatory bytes for every Ndnlp packet for carrying no >> additional information. >> >> Regarding fragmentation, I'm wondering about plans for the B+E >> style mentioned in the slides. Could additional fragment types >> be forseen? >> >> fragmentBegin, fragmentMiddle, fragmendEnd and >> fragmentBeginEnd >> >> This would bring the overhead from 2 or 3 bytes for a B+E header >> extension down to 0 additional bytes. *) >> >> Finally some suggestions where the packet format description >> could benefit from clarifications regarding operational aspects: >> >> - NDNLP packet stuffing (concatenation) inside the same frame: >> ok or not? >> >> - mixed NDNLP/Interest/Data stuffing inside the same frame: ok >> or not? >> >> - fixed width of sequence number field: can the sender choose >> unilateraly or will be there a link negotiation protocol? Can >> the sender change the width on the fly? >> >> - Isn't the statement that "If an incoming NdnlpPacket contains >> unknown >> fields, the receiver MUST drop the packet" evolution-hostile, >> also >> against the old principle of "be liberal in what you accept"? >> >> Or expresses this a stance against the feature interaction >> problem >> and wants to prevent vendor-specific extensions? Asked >> differently: >> Shouldn't there be a type range reserved for experimental and >> vendor-specific extensions with an explicit semantics on how >> to >> process such packets with unknown extensions (without dropping >> the >> packet alltogether)? >> >> - Related: Does the statement (in the indexed fragmentation >> section) >> reading "Unless otherwise specified, header extension fields >> from >> other features shall only appear on the first fragment." mean >> that >> in general a link feature can/will squat the link for some >> self-chosen duration? >> For example, a hypothetical "urgent msg feature" (or signals >> like >> a fragment ack or nack feature running in the other direction) >> would >> have to wait until a fragment train has ended? >> >> best, christian >> >> >> *) Looking at the "minimum Ndnlp packet fragment overhead" might >> be >> an interesting metric to observe in the design. Currently, it >> seems >> that a B+E scheme in NDNLP will vary between 12 and 7 bytes >> of >> overhead, depending on the final design and type allocation >> choices >> that will be made. In a BT low energy context with 20B MTU >> this >> means a change from 8 to 13 bytes payload, a 60% capacity >> increase. >> >> >> On Tue, 26 May 2015, Junxiao Shi wrote: >> >> >> Dear folks >> >> I have written the protocol spec of first batch of >> features in NDNLPv2, and >> I need someone to review the design. >> >> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2 >> >> If you don't know what this is about, see #2520, >> #2763,andhttp:// >> redmine.named-data.net/attachments/download/301/NDNLPv2_20150417. >> ppt >> x >> >> I'll appreciate all review comments. >> You don't have to be an expert in order to do a >> design review. >> >> Yours, Junxiao >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jun 9 20:15:20 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 9 Jun 2015 20:15:20 -0700 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: Message-ID: Hi Christian 20150608 NFD call decides to take two of your suggestions. NdnlpHeader wrapper NdnlpHeader wrapper is eliminated. Instead, header fields are placed directly under LpPacket element. TLV-TYPE codes [81:99] and [800:959] are reserved for header fields, and [960:999] are reserved for trailer fields. Unknown Fields I have adopted the idea in http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-July/000282.html When an unknown header field appears, if its TLV-TYPE is within [800:959] range, the least significant bit determines whether to drop the packet or ignore the field. For [81:99] range, the only action is to drop the packet. The protocol document has been updated to reflect the above (and other) changes. http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2 Yours, Junxiao On Thu, May 28, 2015 at 2:28 PM, Junxiao Shi wrote: > > NdnlpHeader wrapper > In the full plan NDNLPv2_20150513.pptx > page > 17-20, we have a header and a trailer. The header wrapper makes it easier > to define the portion covered by HMAC signature (page 53), and permits a > padding at the end of header (page 24). > 2-octet overhead is negligible on the link types mentioned in "Goals" > section. NDNLPv2 is not designed for 20-octet MTU links; those links need a > different link adaptation layer protocol. > > Unknown Fields > Excerpt from NDNLPv2_20150513.pptx > page > 27: > > Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to > understand all fields. > > > Ignoring an unknown field will cause incorrect operations, see #2520 > note-11. > > A vendor-specific extension can claim a TLV-TYPE as "known field but > relevant feature is disabled". > This is not a "unknown field". > > On Thu, May 28, 2015 at 7:33 AM, wrote: > >> A packet layout question: Isn't the NdnlpHeader wrapper redundant? You >> can see this in the grammar where no other field can ever follow the outer >> NDNLP-PACKET-TYPE and -length. >> >> Or are there plans for other fields coming before or instead of the >> NdnlpHeader? Else I guess that this was introduced for parsing speed >> reasons? But the price is considerable: at least 2 mandatory bytes for >> every Ndnlp packet for carrying no additional information. >> >> >> - Isn't the statement that "If an incoming NdnlpPacket contains unknown >> fields, the receiver MUST drop the packet" evolution-hostile, also >> against the old principle of "be liberal in what you accept"? >> >> Or expresses this a stance against the feature interaction problem >> and wants to prevent vendor-specific extensions? Asked differently: >> Shouldn't there be a type range reserved for experimental and >> vendor-specific extensions with an explicit semantics on how to >> process such packets with unknown extensions (without dropping the >> packet alltogether)? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tschudin at unibas.ch Wed Jun 10 01:18:03 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Wed, 10 Jun 2015 10:18:03 +0200 (CEST) Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: Message-ID: Hi Junxiao, thanks, nice to see this uptake. I was (waiting for time to write this up and) thinking about another general comment on the NDNLPv2 spec: Currently it seems that the "protocol in charge" is defined implicitely through the presence or absence of some fields. For example, IndexedFragmentation could be defined as "needs Sequence plus at least one of the fields FragIndex and FragCount" If I introduce a BeginEndFragmentation protocol, the rule would be "needs the BeginEndFragBits field" and the implicit assumption that the fields present in a packet must violate the previous rules, otherwise the router is confused which protocol is in charge. (see also the note below on the "roles" that a router should adopt). My suggestion: the spec should either spell out these rules (and how new rules have to be formed), or introduce an explicit protocol demux field as is the case with SignatureType. The latter approach has the benefit that new protocols can reuse existing fields (and their type values) and that new protocols do not necessarily need a new type-value (to mark their presence). What do you think? best, christian PS: Here is a link on that question of how to organize the header space, see Bob Braden et al's "From Protocol Stacks to Protocol Heaps - Role Based Architecture" http://conferences.sigcomm.org/hotnets/2002/program.html which is exactly what TLV permits do to, namely to escape the strict encapsulation. Dropping the header container was one such step in that direction. On Wed, 10 Jun 2015, Junxiao Shi wrote: > Hi Christian > 20150608 NFD call decides to take two of your suggestions. > > NdnlpHeader wrapper > NdnlpHeader wrapper is eliminated. > Instead, header fields are placed directly under LpPacket element. > TLV-TYPE codes [81:99] and [800:959] are reserved for header fields, and > [960:999] are reserved for trailer fields. > > Unknown Fields > I have adopted the idea in > http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-July/000282.html > When an unknown header field appears, if its TLV-TYPE is within [800:959] > range, the least significant bit determines whether to drop the packet or > ignore the field. For [81:99] range, the only action is to drop the packet. > > > The protocol document has been updated to reflect the above (and other) > changes. > http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2 > > Yours, Junxiao > > On Thu, May 28, 2015 at 2:28 PM, Junxiao Shi > wrote: > > NdnlpHeader wrapper > In the full plan?NDNLPv2_20150513.pptx?page 17-20, we have a header > and a trailer. The header wrapper makes it easier to define the > portion covered by HMAC signature (page 53), and permits a padding at > the end of header (page 24). > 2-octet overhead is negligible on the link types mentioned in "Goals" > section. NDNLPv2 is not designed for 20-octet MTU links; those links > need a different link adaptation layer protocol. > > Unknown Fields > Excerpt from?NDNLPv2_20150513.pptx?page 27: > Rationale: NdnlpPacket is hop-by-hop. It's feasible to > ensure everyone to understand all fields. > > > Ignoring an unknown field will cause incorrect operations, see #2520 > note-11. > > A vendor-specific extension can claim a TLV-TYPE as "known field but > relevant feature is disabled". > This is not a "unknown field". > > On Thu, May 28, 2015 at 7:33 AM, wrote: > A packet layout question: Isn't the NdnlpHeader wrapper > redundant? You can see this in the grammar where no other > field can ever follow the outer NDNLP-PACKET-TYPE and > -length. > > Or are there plans for other fields coming before or > instead of the NdnlpHeader? Else I guess that this was > introduced for parsing speed reasons? But the price is > considerable: at least 2 mandatory bytes for every Ndnlp > packet for carrying no additional information. > > > - Isn't the statement that "If an incoming NdnlpPacket > contains unknown > ? fields, the receiver MUST drop the packet" > evolution-hostile, also > ? against the old principle of "be liberal in what you > accept"? > > ? Or expresses this a stance against the feature > interaction problem > ? and wants to prevent vendor-specific extensions? Asked > differently: > ? Shouldn't there be a type range reserved for > experimental and > ? vendor-specific extensions with an explicit semantics on > how to > ? process such packets with unknown extensions (without > dropping the > ? packet alltogether)? > > > From shijunxiao at email.arizona.edu Wed Jun 10 08:40:07 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 10 Jun 2015 08:40:07 -0700 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: Message-ID: Hi Christian protocol in charge The protocol in charge is determined by the link, not determined by every packet. Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. In the normal case, a link cannot be configured to run two fragmentation features at the same time. For example, if IndexedFragmentation is enabled on a link: The receiver will expect Sequence, FragIndex, and FragCount. When Sequence is missing, the packet is dropped. When FragIndex is missing, it implied value 0 is used. When FragCount is missing, it implied value 1 is used. When a BeginEndFragBits field is received, if the receiver understands B-E fragmentation feature but this feature is disabled on this link, B-E fragmentation feature should define what to do in this situation (typically, either drop or ignore); if the receiver does not understand B-E fragmentation feature, the unknown field procedure is used. In case some link must run two fragmentation features at the same time, one may define a new fragmentation feature that is a combination of these two. It would be "Indexed + B-E fragmentation". It can either declare a demux field, or dispatch according to what fields are present. However, such combination fragmentation feature is not recommended. It's expected for a link to choose at most one fragmentation feature. Yours, Junxiao On Wed, Jun 10, 2015 at 1:18 AM, wrote: > Hi Junxiao, > > thanks, nice to see this uptake. > > I was (waiting for time to write this up and) thinking about another > general comment on the NDNLPv2 spec: > > Currently it seems that the "protocol in charge" is defined implicitely > through the presence or absence of some fields. For example, > IndexedFragmentation could be defined as > > "needs Sequence plus at least one of the fields FragIndex and FragCount" > > If I introduce a BeginEndFragmentation protocol, the rule would be > > "needs the BeginEndFragBits field" > > and the implicit assumption that the fields present in a packet must > violate the previous rules, otherwise the router is confused which protocol > is in charge. (see also the note below on the "roles" that a router should > adopt). > > > My suggestion: the spec should either spell out these rules (and how new > rules have to be formed), or introduce an explicit protocol demux field as > is the case with SignatureType. > > The latter approach has the benefit that new protocols can reuse existing > fields (and their type values) and that new protocols do not necessarily > need a new type-value (to mark their presence). > > What do you think? > > best, christian > > > PS: Here is a link on that question of how to organize the header space, > see Bob Braden et al's "From Protocol Stacks to Protocol Heaps - Role Based > Architecture" http://conferences.sigcomm.org/hotnets/2002/program.html > > which is exactly what TLV permits do to, namely to escape the strict > encapsulation. Dropping the header container was one such step in that > direction. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Wed Jun 10 21:21:31 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 10 Jun 2015 21:21:31 -0700 Subject: [Nfd-dev] Proposed NDN spec change Message-ID: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> Dear all, The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. --- 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 jburke at remap.ucla.edu Wed Jun 10 21:27:01 2015 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Thu, 11 Jun 2015 04:27:01 +0000 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> Message-ID: <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Alex, Can you explain the motivating use case(s)? Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? Thanks, Jeff On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >Dear all, > >The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). > >This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. > >We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. > >--- >Alex > From alexander.afanasyev at ucla.edu Wed Jun 10 21:48:39 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 10 Jun 2015 21:48:39 -0700 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. --- Alex > On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: > > Alex, > > Can you explain the motivating use case(s)? > Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? > Thanks, > Jeff > > > > > On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: > >> Dear all, >> >> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >> >> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >> >> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >> >> --- >> 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 alexander.afanasyev at ucla.edu Wed Jun 10 22:19:24 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 10 Jun 2015 22:19:24 -0700 Subject: [Nfd-dev] Removal of Interest.Scope from ndn-cxx Message-ID: Just want to notify that we are removing Interest.Scope from the library. Interest.Scope was was removed from NDN specification some time ago and we never actually supported it inside NFD. No known application are using it right now. If you're using it now, please remove asap. --- 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 oran at cisco.com Thu Jun 11 04:32:57 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Thu, 11 Jun 2015 11:32:57 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: Message-ID: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> > On Jun 10, 2015, at 11:40 AM, Junxiao Shi wrote: > > Hi Christian > > protocol in charge > The protocol in charge is determined by the link, not determined by every packet. > Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. How? Not by hand on each end I hope? No initialization handshake? > In the normal case, a link cannot be configured to run two fragmentation features at the same time. > > For example, if IndexedFragmentation is enabled on a link: > The receiver will expect Sequence, FragIndex, and FragCount. > When Sequence is missing, the packet is dropped. > When FragIndex is missing, it implied value 0 is used. > When FragCount is missing, it implied value 1 is used. > > When a BeginEndFragBits field is received, > if the receiver understands B-E fragmentation feature but this feature is disabled on this link, B-E fragmentation feature should define what to do in this situation (typically, either drop or ignore); > if the receiver does not understand B-E fragmentation feature, the unknown field procedure is used. > > In case some link must run two fragmentation features at the same time, one may define a new fragmentation feature that is a combination of these two. It would be "Indexed + B-E fragmentation". It can either declare a demux field, or dispatch according to what fields are present. > However, such combination fragmentation feature is not recommended. It's expected for a link to choose at most one fragmentation feature. > > > Yours, Junxiao > > On Wed, Jun 10, 2015 at 1:18 AM, wrote: > Hi Junxiao, > > thanks, nice to see this uptake. > > I was (waiting for time to write this up and) thinking about another general comment on the NDNLPv2 spec: > > Currently it seems that the "protocol in charge" is defined implicitely through the presence or absence of some fields. For example, IndexedFragmentation could be defined as > > "needs Sequence plus at least one of the fields FragIndex and FragCount" > > If I introduce a BeginEndFragmentation protocol, the rule would be > > "needs the BeginEndFragBits field" > > and the implicit assumption that the fields present in a packet must violate the previous rules, otherwise the router is confused which protocol is in charge. (see also the note below on the "roles" that a router should adopt). > > > My suggestion: the spec should either spell out these rules (and how new rules have to be formed), or introduce an explicit protocol demux field as is the case with SignatureType. > > The latter approach has the benefit that new protocols can reuse existing fields (and their type values) and that new protocols do not necessarily need a new type-value (to mark their presence). > > What do you think? > > best, christian > > > PS: Here is a link on that question of how to organize the header space, see Bob Braden et al's "From Protocol Stacks to Protocol Heaps - Role Based Architecture" http://conferences.sigcomm.org/hotnets/2002/program.html > > which is exactly what TLV permits do to, namely to escape the strict encapsulation. Dropping the header container was one such step in that direction. > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Thu Jun 11 07:19:59 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 11 Jun 2015 07:19:59 -0700 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> Message-ID: Hi Dave Enabled features can be set at compile time, in the configuration file, or through management commands. Defaults for NFD are: - Ethernet multicast and UDP multicast: indexed fragmentation, network NACK - UDP unicast: indexed fragmentation, network NACK - TCP: network NACK - TCP local and UNIX socket: network NACK, local cache policy - turn on with management command: consumer controlled forwarding, incoming face indication There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. Yours, Junxiao On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: > > The protocol in charge is determined by the link, not determined by > every packet. > > Before an NDNLPv2 packet is processed, the receiver already knows what > features are enabled. > How? Not by hand on each end I hope? No initialization handshake? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Thu Jun 11 07:27:38 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Thu, 11 Jun 2015 14:27:38 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> Message-ID: > On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: > > Hi Dave > > Enabled features can be set at compile time, in the configuration file, or through management commands. > > Defaults for NFD are: > ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK > ? UDP unicast: indexed fragmentation, network NACK > ? TCP: network NACK > ? TCP local and UNIX socket: network NACK, local cache policy > ? turn on with management command: consumer controlled forwarding, incoming face indication > > There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. > However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? How to you ?reset? the link if it gets desynchronized due to a bad management command setting? How do you do version checking? How does a receiver tell a transmitter what is the acceptable maximum MTU? I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. > For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. > > Yours, Junxiao > > On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: > > The protocol in charge is determined by the link, not determined by every packet. > > Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. > How? Not by hand on each end I hope? No initialization handshake? From Ignacio.Solis at parc.com Thu Jun 11 11:35:31 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Thu, 11 Jun 2015 18:35:31 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> Message-ID: I?m not sure I follow. If I am a laptop, and need to connect to a WiFi router. Do I need to know in advance what the WiFi router settings are? Does the WiFi router need to send me a management command to ?remotely? set my settings? Does my laptop send a command to the router to say: "on my face, disable indexed fragmentation and enable B-E fragmentation?? Are we going to need a probing protocol that sends packets until something works? Specially if "those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped?. Which brings up the question of, does the command have to be sent under the right settings? Does the command have acknowledgements of execution? Pardon my ignorance, I?m new to this topic, maybe this is all explained in the document. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com On 6/11/15, 7:19 AM, "Junxiao Shi" > wrote: Hi Dave Enabled features can be set at compile time, in the configuration file, or through management commands. Defaults for NFD are: * Ethernet multicast and UDP multicast: indexed fragmentation, network NACK * UDP unicast: indexed fragmentation, network NACK * TCP: network NACK * TCP local and UNIX socket: network NACK, local cache policy * turn on with management command: consumer controlled forwarding, incoming face indication There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. Yours, Junxiao On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) > wrote: > The protocol in charge is determined by the link, not determined by every packet. > Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. How? Not by hand on each end I hope? No initialization handshake? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Jun 11 14:59:38 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 11 Jun 2015 14:59:38 -0700 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> Message-ID: <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> I think what we are talking here are two orthogonal issues. The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. --- Alex > On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: > >> >> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >> >> Hi Dave >> >> Enabled features can be set at compile time, in the configuration file, or through management commands. >> >> Defaults for NFD are: >> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >> ? UDP unicast: indexed fragmentation, network NACK >> ? TCP: network NACK >> ? TCP local and UNIX socket: network NACK, local cache policy >> ? turn on with management command: consumer controlled forwarding, incoming face indication >> >> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. > How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? > How to you ?reset? the link if it gets desynchronized due to a bad management command setting? > How do you do version checking? > How does a receiver tell a transmitter what is the acceptable maximum MTU? > > I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. > >> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >> >> Yours, Junxiao >> >> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>> The protocol in charge is determined by the link, not determined by every packet. >>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >> How? Not by hand on each end I hope? No initialization handshake? > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- 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 oran at cisco.com Fri Jun 12 08:57:44 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Fri, 12 Jun 2015 15:57:44 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> Message-ID: > On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: > > I think what we are talking here are two orthogonal issues. Well, we differ on that. I don?t think they are orthogonal at all. > The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. > But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. > If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). > > --- > Alex > >> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >> >>> >>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>> >>> Hi Dave >>> >>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>> >>> Defaults for NFD are: >>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>> ? UDP unicast: indexed fragmentation, network NACK >>> ? TCP: network NACK >>> ? TCP local and UNIX socket: network NACK, local cache policy >>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>> >>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >> How do you do version checking? >> How does a receiver tell a transmitter what is the acceptable maximum MTU? >> >> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >> >>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>> >>> Yours, Junxiao >>> >>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>> The protocol in charge is determined by the link, not determined by every packet. >>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>> How? Not by hand on each end I hope? No initialization handshake? >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Marc.Mosko at parc.com Fri Jun 12 13:26:03 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Fri, 12 Jun 2015 20:26:03 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> Message-ID: <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Dave, I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured. It also has some older authentication mechanisms. It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well. BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP). There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming. Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations. Marc On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: > >> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: >> >> I think what we are talking here are two orthogonal issues. > Well, we differ on that. I don?t think they are orthogonal at all. > >> The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. >> > But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: > > When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). > > I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? > > You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. > >> If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. > I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). > >> >> --- >> Alex >> >>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>> >>>> >>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>>> >>>> Hi Dave >>>> >>>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>>> >>>> Defaults for NFD are: >>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>>> ? UDP unicast: indexed fragmentation, network NACK >>>> ? TCP: network NACK >>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>>> >>>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >>> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >>> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >>> How do you do version checking? >>> How does a receiver tell a transmitter what is the acceptable maximum MTU? >>> >>> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >>> >>>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>>> >>>> Yours, Junxiao >>>> >>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>>> The protocol in charge is determined by the link, not determined by every packet. >>>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>>> How? Not by hand on each end I hope? No initialization handshake? >>> >>> >>> _______________________________________________ >>> 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 oran at cisco.com Sat Jun 13 05:42:53 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Sat, 13 Jun 2015 12:42:53 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Message-ID: > On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote: > > Dave, > > I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured. It also has some older authentication mechanisms. It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well. BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP). > Good points. I withdraw the suggestion about BFD as a model for auto-configuration, although it is definitely worth looking at as a model for how to do an adjacency maintenance protocol. > There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming. Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations. > It would be really good to work together on this (i.e. the NDN and CCN communities). We?ve done some internal work at Cisco as well, but mostly as an experimentation harness in Python to try to get the semantics right before worrying about packet formats. Maybe we could collaborate on some talks at ICNRG in Prague to try to scope the work and prevent divergence in our designs? Seems this is an area where our other design differences won?t affect things much. DaveO. > Marc > > > On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: > >> >>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: >>> >>> I think what we are talking here are two orthogonal issues. >> Well, we differ on that. I don?t think they are orthogonal at all. >> >>> The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. >>> >> But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: >> >> When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). >> >> I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? >> >> You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. >> >>> If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. >> I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). >> >>> >>> --- >>> Alex >>> >>>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>>> >>>>> >>>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>>>> >>>>> Hi Dave >>>>> >>>>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>>>> >>>>> Defaults for NFD are: >>>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>>>> ? UDP unicast: indexed fragmentation, network NACK >>>>> ? TCP: network NACK >>>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>>>> >>>>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>>>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >>>> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >>>> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >>>> How do you do version checking? >>>> How does a receiver tell a transmitter what is the acceptable maximum MTU? >>>> >>>> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >>>> >>>>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>>>> >>>>> Yours, Junxiao >>>>> >>>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>>>> The protocol in charge is determined by the link, not determined by every packet. >>>>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>>>> How? Not by hand on each end I hope? No initialization handshake? >>>> >>>> >>>> _______________________________________________ >>>> 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 christian.tschudin at unibas.ch Sat Jun 13 09:21:15 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Sat, 13 Jun 2015 18:21:15 +0200 (CEST) Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Message-ID: Hi Dave, we should extend the small workgroup we had at Dagstuhl on operational NW management. Iterating from then: NW mgmt is the killer app - if it's badly done you are dead. See you in Prague, christian On Sat, 13 Jun 2015, Dave Oran (oran) wrote: > >> On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote: >> >> Dave, >> >> I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured. It also has some older authentication mechanisms. It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well. BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP). >> > Good points. I withdraw the suggestion about BFD as a model for auto-configuration, although it is definitely worth looking at as a model for how to do an adjacency maintenance protocol. > >> There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming. Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations. >> > It would be really good to work together on this (i.e. the NDN and CCN communities). We?ve done some internal work at Cisco as well, but mostly as an experimentation harness in Python to try to get the semantics right before worrying about packet formats. > > Maybe we could collaborate on some talks at ICNRG in Prague to try to scope the work and prevent divergence in our designs? Seems this is an area where our other design differences won?t affect things much. > > DaveO. > >> Marc >> >> >> On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: >> >>> >>>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: >>>> >>>> I think what we are talking here are two orthogonal issues. >>> Well, we differ on that. I don?t think they are orthogonal at all. >>> >>>> The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. >>>> >>> But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: >>> >>> When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). >>> >>> I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? >>> >>> You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. >>> >>>> If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. >>> I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). >>> >>>> >>>> --- >>>> Alex >>>> >>>>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>>>> >>>>>> >>>>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>>>>> >>>>>> Hi Dave >>>>>> >>>>>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>>>>> >>>>>> Defaults for NFD are: >>>>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>>>>> ? UDP unicast: indexed fragmentation, network NACK >>>>>> ? TCP: network NACK >>>>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>>>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>>>>> >>>>>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>>>>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >>>>> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >>>>> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >>>>> How do you do version checking? >>>>> How does a receiver tell a transmitter what is the acceptable maximum MTU? >>>>> >>>>> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >>>>> >>>>>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>>>>> >>>>>> Yours, Junxiao >>>>>> >>>>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>>>>> The protocol in charge is determined by the link, not determined by every packet. >>>>>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>>>>> How? Not by hand on each end I hope? No initialization handshake? >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > 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 Sun Jun 14 17:05:27 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 15 Jun 2015 00:05:27 +0000 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: Thanks for the explanation. The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? (Using only a default lets us have only one of these options.) Thanks, Jeff On 6/10/15, 9:48 PM, "Alex Afanasyev" wrote: >There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). > >Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). > >All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. > >--- >Alex > >> On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: >> >> Alex, >> >> Can you explain the motivating use case(s)? >> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? >> Thanks, >> Jeff >> >> >> >> >> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >> >>> Dear all, >>> >>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >>> >>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >>> >>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >>> >>> --- >>> Alex >>> > From Ignacio.Solis at parc.com Sun Jun 14 23:22:14 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 15 Jun 2015 06:22:14 +0000 Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Message-ID: We?re in favor of discussing this in Prague. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com On 6/13/15, 5:42 AM, "Dave Oran (oran)" wrote: > >> On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote: >> >> Dave, >> >> I think BFD has some good features, but it does not itself have a >>discovery mechanism and must be configured. It also has some older >>authentication mechanisms. It also reserves point-to-multipoint for >>future use, which for router-to-router links is probably not a problem >>but if it is expected to run on every node on a LAN, I think the >>point-to-point nature of BFD would not scale well. BFD does not include >>a capabilities exchange, except for its own parameters, so we would need >>to do something beyond what it offers (without getting as far out there >>as ML-PPP). >> >Good points. I withdraw the suggestion about BFD as a model for >auto-configuration, although it is definitely worth looking at as a model >for how to do an adjacency maintenance protocol. > >> There is quite a bit of work on neighbor discovery and link >>maintenance, so I think we can put together something that would be ok >>to run on all nodes on a multiple access link without being >>overwhelming. Also, if one uses a route-reflector approach then one >>does not need to monitor a full mesh but only those in-use destinations. >> >It would be really good to work together on this (i.e. the NDN and CCN >communities). We?ve done some internal work at Cisco as well, but mostly >as an experimentation harness in Python to try to get the semantics right >before worrying about packet formats. > >Maybe we could collaborate on some talks at ICNRG in Prague to try to >scope the work and prevent divergence in our designs? Seems this is an >area where our other design differences won?t affect things much. > >DaveO. > >> Marc >> >> >> On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: >> >>> >>>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev >>>> wrote: >>>> >>>> I think what we are talking here are two orthogonal issues. >>> Well, we differ on that. I don?t think they are orthogonal at all. >>> >>>> The first priority here is to define NDNLP2 as a protocol to work as >>>>adaptation layer under an assumption that parameters of the link are >>>>known. >>>> >>> But they aren?t - the purpose of a link layer adaptation protocol is >>>to?well?adapt to the link. In some cases in fact, you need to measure >>>the link in order to know what the adaptation should be. While this is >>>an ancient example that may not be applicable now, the general >>>principle may apply: >>> >>> When we were deigning ISIS we discovered that some Ethernets would >>>pass full link-sized packets and some would not (either due to physical >>>layer errors or buggy repeaters). So, one could initialize the link and >>>even exchange small packets, but real packets would get dropped. So, we >>>made sure that the link initialization protocol padded the hello >>>packets to the maximum size. (This had some amusing second-order >>>consequences, such as what to put in the padding - different people >>>were were funny in a number of creative ways). >>> >>> I?ll also note that failing to do this caused us to have many >>>different adjacency-establishment protocols on top of the same kind of >>>link, which in turn resulted in multiplicity of link management >>>schemes, which even now is not cleaned up. At least now we have BFD, >>>which has a way to unify these separate protocols under one umbrella. >>>Maybe we should adopt BFD as the substrate to do the NDN-specific link >>>adaptation features rather than starting form scratch? >>> >>> You can of course go too far in the other direction, for example with >>>the PPP multi-layer link management stuff which got unnecessarily >>>complicated. >>> >>>> If we get to the point that we need to negotiate NDNLP features on >>>>the link, then we would need to figure out how to do this >>>>negotiations, e.g., with some interests/data handshakes or some other >>>>way. >>> I think we need to do this now - it?s to me a fundamental part of >>>defining the link adaptation protocol(s). >>> >>>> >>>> --- >>>> Alex >>>> >>>>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>>>> >>>>>> >>>>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi >>>>>> wrote: >>>>>> >>>>>> Hi Dave >>>>>> >>>>>> Enabled features can be set at compile time, in the configuration >>>>>>file, or through management commands. >>>>>> >>>>>> Defaults for NFD are: >>>>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, >>>>>>network NACK >>>>>> ? UDP unicast: indexed fragmentation, network NACK >>>>>> ? TCP: network NACK >>>>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>>>> ? turn on with management command: consumer controlled >>>>>>forwarding, incoming face indication >>>>>> >>>>>> There is no handshake because the receiver needs to know what >>>>>>NDNLPv2 features are enabled when processing the handshake packet. >>>>>> However, since NDNLPv2 features can be controlled through >>>>>>management commands, it's possible to determine an initial set of >>>>>>enabled features at compile time or in the configuration file, and >>>>>>then change the features during runtime. This has a similar effect >>>>>>of handshake, because a management command can be sent from a remote >>>>>>node. >>>>> How do you get the management command to the node if the link hasn?t >>>>>come up with NDNLP2 running yet? >>>>> How to you ?reset? the link if it gets desynchronized due to a bad >>>>>management command setting? >>>>> How do you do version checking? >>>>> How does a receiver tell a transmitter what is the acceptable >>>>>maximum MTU? >>>>> >>>>> I don?t have a problem using Interest/Data exchanges as the way to >>>>>do the initialization handshake, but I don?t see how this works >>>>>reasonably when starting from an unknown or incorrect state, and I >>>>>don?t see how the link state machine is maintained. >>>>> >>>>>> For example, an end host can send a command "on my face, disable >>>>>>indexed fragmentation and enable B-E fragmentation" to the router, >>>>>>and the next packet will use the new fragmentation feature; but >>>>>>those packets transmitted prior to the command and received >>>>>>afterwards would be processed incorrectly and likely got dropped. >>>>>> >>>>>> Yours, Junxiao >>>>>> >>>>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) >>>>>>wrote: >>>>>>> The protocol in charge is determined by the link, not determined >>>>>>>by every packet. >>>>>>> Before an NDNLPv2 packet is processed, the receiver already knows >>>>>>>what features are enabled. >>>>>> How? Not by hand on each end I hope? No initialization handshake? >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > >_______________________________________________ >Nfd-dev mailing list >Nfd-dev at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From lanwang at memphis.edu Mon Jun 15 08:44:47 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Mon, 15 Jun 2015 15:44:47 +0000 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: <0CCBD5C0-8C1E-4D5C-9C6D-F63A1E505616@memphis.edu> If there's a common application need, then I feel it's justifiable to have these special values. Could you give an example or two? Lan On Jun 14, 2015, at 7:05 PM, "Burke, Jeff" wrote: > Thanks for the explanation. The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? (Using only a default lets us have only one of these options.) > > Thanks, > Jeff > > > > > On 6/10/15, 9:48 PM, "Alex Afanasyev" wrote: > >> There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). >> >> Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). >> >> All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. >> >> --- >> Alex >> >>> On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: >>> >>> Alex, >>> >>> Can you explain the motivating use case(s)? >>> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? >>> Thanks, >>> Jeff >>> >>> >>> >>> >>> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >>> >>>> Dear all, >>>> >>>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >>>> >>>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >>>> >>>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >>>> >>>> --- >>>> Alex >>>> >> > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From lixia at CS.UCLA.EDU Mon Jun 15 08:50:18 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Mon, 15 Jun 2015 08:50:18 -0700 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: > On Jun 14, 2015, at 5:05 PM, Burke, Jeff wrote: > > Thanks for the explanation. The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? (Using only a default lets us have only one of these options.) > > Thanks, > Jeff a quick suggestion: to be able to explicitly express both: 1/ Alex suggested the absence of FreshnessPeriod = not fresh 2/ define a special FreshnessPeriod value to mean "always fresh" > On 6/10/15, 9:48 PM, "Alex Afanasyev" wrote: > >> There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). >> >> Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). >> >> All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. >> >> --- >> Alex >> >>> On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: >>> >>> Alex, >>> >>> Can you explain the motivating use case(s)? >>> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? >>> Thanks, >>> Jeff >>> >>> >>> >>> >>> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >>> >>>> Dear all, >>>> >>>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >>>> >>>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >>>> >>>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >>>> >>>> --- >>>> Alex >>>> >> > > _______________________________________________ > 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 Mon Jun 15 08:53:30 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 15 Jun 2015 15:53:30 +0000 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: I'll try to come up with a few examples per Lan's request. Is the definition of freshness entirely up to the application, or does the architecture provide some implicit definition bc of some impact on caching, for example? Jeff On 6/15/15, 8:50 AM, "Lixia Zhang" wrote: > >> On Jun 14, 2015, at 5:05 PM, Burke, Jeff wrote: >> >> Thanks for the explanation. The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? (Using only a default lets us have only one of these options.) >> >> Thanks, >> Jeff > >a quick suggestion: to be able to explicitly express both: > >1/ Alex suggested the absence of FreshnessPeriod = not fresh > >2/ define a special FreshnessPeriod value to mean "always fresh" > > > >> On 6/10/15, 9:48 PM, "Alex Afanasyev" wrote: >> >>> There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). >>> >>> Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). >>> >>> All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. >>> >>> --- >>> Alex >>> >>>> On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: >>>> >>>> Alex, >>>> >>>> Can you explain the motivating use case(s)? >>>> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? >>>> Thanks, >>>> Jeff >>>> >>>> >>>> >>>> >>>> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >>>> >>>>> Dear all, >>>>> >>>>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >>>>> >>>>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >>>>> >>>>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >>>>> >>>>> --- >>>>> Alex >>>>> >>> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From lixia at CS.UCLA.EDU Mon Jun 15 09:11:40 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Mon, 15 Jun 2015 09:11:40 -0700 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: > On Jun 15, 2015, at 8:53 AM, Burke, Jeff wrote: > > > I'll try to come up with a few examples per Lan's request. > > Is the definition of freshness entirely up to the application, or does the architecture provide some implicit definition bc of some impact on caching, for example? > > Jeff Personal opinionr: I feel that our experimentation is yet to go far and wide enough to offer meaningful a guideline here > On 6/15/15, 8:50 AM, "Lixia Zhang" wrote: > >> >>> On Jun 14, 2015, at 5:05 PM, Burke, Jeff wrote: >>> >>> Thanks for the explanation. The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? (Using only a default lets us have only one of these options.) >>> >>> Thanks, >>> Jeff >> >> a quick suggestion: to be able to explicitly express both: >> >> 1/ Alex suggested the absence of FreshnessPeriod = not fresh >> >> 2/ define a special FreshnessPeriod value to mean "always fresh" >> >> >> >>> On 6/10/15, 9:48 PM, "Alex Afanasyev" wrote: >>> >>>> There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). >>>> >>>> Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). >>>> >>>> All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. >>>> >>>> --- >>>> Alex >>>> >>>>> On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: >>>>> >>>>> Alex, >>>>> >>>>> Can you explain the motivating use case(s)? >>>>> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? >>>>> Thanks, >>>>> Jeff >>>>> >>>>> >>>>> >>>>> >>>>> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >>>>>> >>>>>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >>>>>> >>>>>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >>>>>> >>>>>> --- >>>>>> Alex >>>>>> >>>> >>> >>> _______________________________________________ >>> 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 Mon Jun 15 09:13:23 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 15 Jun 2015 16:13:23 +0000 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: <42509093-2C65-43C5-9CE0-396229F03B66@remap.ucla.edu> Ok, I looked back the spec and the applicable part seems to be: "Note that the stale data is still valid data; the expiration of FreshnessPeriod only means that the producer may have produced newer data." So, newer data means what? The same prefix? The same name? J. On 6/15/15, 8:53 AM, "Nfd-dev on behalf of Burke, Jeff" wrote: > >I'll try to come up with a few examples per Lan's request. > >Is the definition of freshness entirely up to the application, or does the architecture provide some implicit definition bc of some impact on caching, for example? > >Jeff > > > >On 6/15/15, 8:50 AM, "Lixia Zhang" wrote: > >> >>> On Jun 14, 2015, at 5:05 PM, Burke, Jeff wrote: >>> >>> Thanks for the explanation. The proposed change makes sense to me, but just wanted to ask my original question again: Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? (Using only a default lets us have only one of these options.) >>> >>> Thanks, >>> Jeff >> >>a quick suggestion: to be able to explicitly express both: >> >>1/ Alex suggested the absence of FreshnessPeriod = not fresh >> >>2/ define a special FreshnessPeriod value to mean "always fresh" >> >> >> >>> On 6/10/15, 9:48 PM, "Alex Afanasyev" wrote: >>> >>>> There are few cases that triggered this issue. The most recent for me is key retrieval (with some assumptions and ndns model): the requester sends interests for key name + must be fresh selector, omitting the version number. (Essentially, this allows certification chain to be updated (e.g., parent's key re-signed) without requiring resigning every single data packet.) The assumption here is that this interest would periodically go to "authority" that will return the latest version of the data packet and verification would proceed. Unfortunately, we didn't actually put FreshnessPeriod into certificate data packets (this will be fixed), which completely broke the assumption. The data packet now becomes forever fresh and there is no way around it (except maybe using an exclude filter, which shouldn't be the primary mechanism for this purpose). >>>> >>>> Another issue that Junxiao recently encountered with ndnfs and I think I had something similar in the past with something else (I forgot what exactly triggered the original redmine issue). >>>> >>>> All issues I mentioned are related to discovery mechanism. During discovery, only a partial name is known and there is a desire to contact "authority" for the data to get the latest knowledge. On the other had, FreshnessPeriod (semi-ambiguously) defines how often this "authority" is willing to receive such interests and how frequently information is expected to change. >>>> >>>> --- >>>> Alex >>>> >>>>> On Jun 10, 2015, at 9:27 PM, Burke, Jeff wrote: >>>>> >>>>> Alex, >>>>> >>>>> Can you explain the motivating use case(s)? >>>>> Would it make sense to provide a way to encode whether the packet should be considered "always fresh" or "always stale" explicitly? >>>>> Thanks, >>>>> Jeff >>>>> >>>>> >>>>> >>>>> >>>>> On 6/10/15, 9:21 PM, "Nfd-dev on behalf of Alex Afanasyev" wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> The current NDN spec defines that Data packets without FreshnessPeriod are considered always fresh ("data packet cannot be marked stale", http://named-data.net/doc/ndn-tlv/data.html#freshnessperiod). >>>>>> >>>>>> This creates a problem for some applications that we are currently playing with and I would like the spec (and subsequently NFD implementation) to be changed to do the opposite: when FreshnessPeriod is not specified, data packet should **never** be considered fresh. >>>>>> >>>>>> We have discussed this issue in the past (http://redmine.named-data.net/issues/2440), but haven't finalized the decision. If there are no objections, I would like to proceed with the change ASAP. >>>>>> >>>>>> --- >>>>>> Alex >>>>>> >>>> >>> >>> _______________________________________________ >>> 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 chaim.rieger at gmail.com Wed Jun 17 11:20:04 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 11:20:04 -0700 Subject: [Nfd-dev] Fresh install on Fedora issues Message-ID: <5581BA54.9060107@gmail.com> ndn-cxx is installed (latest version) on fedora 22 x64 into /usr/local/bin /usr/local/lib64 cd into the nfd ./waf configure runs fine ./waf produces the following error [118/123] Linking build/bin/nfdc tools/nfd-status.cpp.5.o: In function `ndn::Name::getPrefix(long) const': /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' collect2: error: ld returned 1 exit status tools/ndn-autoconfig-server.cpp.1.o: In function `ndn::Name::getPrefix(long) const': /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' collect2: error: ld returned 1 exit status Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' Build failed -> task in '../bin/nfd-status' failed (exit status 1): {task 139875896348496: cxxprogram nfd-status.cpp.5.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> nfd-status} ['/usr/bin/g++', 'tools/nfd-status.cpp.5.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/nfd-status', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] -> task in '../bin/ndn-autoconfig-server' failed (exit status 1): {task 139875896347216: cxxprogram ndn-autoconfig-server.cpp.1.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> ndn-autoconfig-server} ['/usr/bin/g++', 'tools/ndn-autoconfig-server.cpp.1.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/ndn-autoconfig-server', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] -- -- Chaim Rieger From alexander.afanasyev at ucla.edu Wed Jun 17 11:45:35 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 17 Jun 2015 11:45:35 -0700 Subject: [Nfd-dev] Fresh install on Fedora issues In-Reply-To: <5581BA54.9060107@gmail.com> References: <5581BA54.9060107@gmail.com> Message-ID: Can you check that you don't have the static library (libndn-cxx.a) installed somewhere? > On Jun 17, 2015, at 11:20 AM, Chaim Rieger wrote: > > ndn-cxx is installed (latest version) on fedora 22 x64 into /usr/local/bin /usr/local/lib64 > > cd into the nfd > ./waf configure runs fine > ./waf produces the following error > > [118/123] Linking build/bin/nfdc > tools/nfd-status.cpp.5.o: In function `ndn::Name::getPrefix(long) const': > /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' > collect2: error: ld returned 1 exit status > > tools/ndn-autoconfig-server.cpp.1.o: In function `ndn::Name::getPrefix(long) const': > /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' > collect2: error: ld returned 1 exit status > > Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' > Build failed > -> task in '../bin/nfd-status' failed (exit status 1): > {task 139875896348496: cxxprogram nfd-status.cpp.5.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> nfd-status} > ['/usr/bin/g++', 'tools/nfd-status.cpp.5.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/nfd-status', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] > -> task in '../bin/ndn-autoconfig-server' failed (exit status 1): > {task 139875896347216: cxxprogram ndn-autoconfig-server.cpp.1.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> ndn-autoconfig-server} > ['/usr/bin/g++', 'tools/ndn-autoconfig-server.cpp.1.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/ndn-autoconfig-server', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] > > -- > -- > Chaim Rieger > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- 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 chaim.rieger at gmail.com Wed Jun 17 11:47:48 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 11:47:48 -0700 Subject: [Nfd-dev] Fresh install on Fedora issues In-Reply-To: References: <5581BA54.9060107@gmail.com> Message-ID: <5581C0D4.9020000@gmail.com> [crieger at localhost NFD] $ locate libndn-cxx /home/crieger/ndnSIM/ndn-cxx/libndn-cxx.pc.in /home/crieger/ndnSIM/ndn-cxx/build/libndn-cxx.pc /home/crieger/ndnSIM/ndn-cxx/build/libndn-cxx.so /home/crieger/ndnSIM/ndn-cxx/build/libndn-cxx.so.0.3.2 /usr/local/lib64/libndn-cxx.so /usr/local/lib64/libndn-cxx.so.0.3.2 /usr/local/lib64/pkgconfig/libndn-cxx.pc installed into /usr/local/lib64 as shared only. On 06/17/2015 11:45 AM, Alex Afanasyev wrote: > Can you check that you don't have the static library (libndn-cxx.a) installed somewhere? > >> On Jun 17, 2015, at 11:20 AM, Chaim Rieger wrote: >> >> ndn-cxx is installed (latest version) on fedora 22 x64 into /usr/local/bin /usr/local/lib64 >> >> cd into the nfd >> ./waf configure runs fine >> ./waf produces the following error >> >> [118/123] Linking build/bin/nfdc >> tools/nfd-status.cpp.5.o: In function `ndn::Name::getPrefix(long) const': >> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >> collect2: error: ld returned 1 exit status >> >> tools/ndn-autoconfig-server.cpp.1.o: In function `ndn::Name::getPrefix(long) const': >> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >> collect2: error: ld returned 1 exit status >> >> Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' >> Build failed >> -> task in '../bin/nfd-status' failed (exit status 1): >> {task 139875896348496: cxxprogram nfd-status.cpp.5.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> nfd-status} >> ['/usr/bin/g++', 'tools/nfd-status.cpp.5.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/nfd-status', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >> -> task in '../bin/ndn-autoconfig-server' failed (exit status 1): >> {task 139875896347216: cxxprogram ndn-autoconfig-server.cpp.1.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> ndn-autoconfig-server} >> ['/usr/bin/g++', 'tools/ndn-autoconfig-server.cpp.1.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/ndn-autoconfig-server', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >> >> -- >> -- >> Chaim Rieger >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -- -- Chaim Rieger From chaim.rieger at gmail.com Wed Jun 17 11:52:14 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 11:52:14 -0700 Subject: [Nfd-dev] Fresh install on Fedora issues In-Reply-To: References: <5581BA54.9060107@gmail.com> Message-ID: <5581C1DE.7010006@gmail.com> This is getting weird I did a waf uninstall , was clean, then reinstalled successfully. when trying to run nfd-start I still get a lib error though [122/123] Linking build/bin/ndn-tlv-peek [123/123] Linking build/bin/nfd Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' 'build' finished successfully (2m22.771s) ./waf install Waf: Entering directory `/home/crieger/ndnSIM/NFD/build' + install /usr/local/share/ndn/nfd-status.xsl (from tools/nfd-status-http-server-files/nfd-status.xsl) + install /usr/local/share/ndn/reset.css (from tools/nfd-status-http-server-files/reset.css) + install /usr/local/bin/nfd-stop (from build/bin/nfd-stop) + install /usr/local/bin/nfd-start (from build/bin/nfd-start) + install /usr/local/bin/nfd-status-http-server (from build/bin/nfd-status-http-server) + install /usr/local/share/ndn/robots.txt (from tools/nfd-status-http-server-files/robots.txt) + install /usr/local/bin/nrd (from build/bin/nrd) + install /usr/local/etc/ndn/nfd.conf.sample (from build/nfd.conf.sample) + install /usr/local/share/man//man1/nfd.1 (from build/docs/manpages/nfd.1) + install /usr/local/share/ndn/style.css (from tools/nfd-status-http-server-files/style.css) + install /usr/local/share/man//man1/nrd.1 (from build/docs/manpages/nrd.1) + install /usr/local/share/man//man1/ndn-autoconfig-server.1 (from build/docs/manpages/ndn-autoconfig-server.1) + install /usr/local/share/man//man1/ndn-autoconfig.1 (from build/docs/manpages/ndn-autoconfig.1) + install /usr/local/share/ndn/text.css (from tools/nfd-status-http-server-files/text.css) + install /usr/local/share/man//man1/nfdc.1 (from build/docs/manpages/nfdc.1) + install /usr/local/share/man//man1/ndn-tlv-peek.1 (from build/docs/manpages/ndn-tlv-peek.1) + install /usr/local/share/man//man1/ndn-tlv-poke.1 (from build/docs/manpages/ndn-tlv-poke.1) + install /usr/local/share/man//man1/nfd-autoreg.1 (from build/docs/manpages/nfd-autoreg.1) + install /usr/local/share/man//man1/nfd-status-http-server.1 (from build/docs/manpages/nfd-status-http-server.1) + install /usr/local/share/man//man1/nfd-status.1 (from build/docs/manpages/nfd-status.1) + install /usr/local/bin/ndn-tlv-peek (from build/bin/ndn-tlv-peek) + install /usr/local/bin/ndn-autoconfig (from build/bin/ndn-autoconfig) + install /usr/local/bin/nfd-status (from build/bin/nfd-status) + install /usr/local/bin/nfdc (from build/bin/nfdc) + install /usr/local/bin/ndn-tlv-poke (from build/bin/ndn-tlv-poke) + install /usr/local/bin/nfd (from build/bin/nfd) + install /usr/local/bin/nfd-autoreg (from build/bin/nfd-autoreg) + install /usr/local/bin/ndn-autoconfig-server (from build/bin/ndn-autoconfig-server) Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' 'install' finished successfully (0.419s) [root at localhost NFD] # /usr/local/bin/nfd-start [root at localhost NFD] # /usr/local/bin/nfd: error while loading shared libraries: libndn-cxx.so.0.3.2: cannot open shared object file: No such file or directory [root at localhost NFD] # env | grep LD OLDPWD=/root LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64 [root at localhost NFD] # locate libndn-cxx.so.0.3.2 /home/crieger/ndnSIM/ndn-cxx/build/libndn-cxx.so.0.3.2 /usr/local/lib64/libndn-cxx.so.0.3.2 On 06/17/2015 11:45 AM, Alex Afanasyev wrote: > Can you check that you don't have the static library (libndn-cxx.a) installed somewhere? > >> On Jun 17, 2015, at 11:20 AM, Chaim Rieger wrote: >> >> ndn-cxx is installed (latest version) on fedora 22 x64 into /usr/local/bin /usr/local/lib64 >> >> cd into the nfd >> ./waf configure runs fine >> ./waf produces the following error >> >> [118/123] Linking build/bin/nfdc >> tools/nfd-status.cpp.5.o: In function `ndn::Name::getPrefix(long) const': >> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >> collect2: error: ld returned 1 exit status >> >> tools/ndn-autoconfig-server.cpp.1.o: In function `ndn::Name::getPrefix(long) const': >> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >> collect2: error: ld returned 1 exit status >> >> Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' >> Build failed >> -> task in '../bin/nfd-status' failed (exit status 1): >> {task 139875896348496: cxxprogram nfd-status.cpp.5.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> nfd-status} >> ['/usr/bin/g++', 'tools/nfd-status.cpp.5.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/nfd-status', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >> -> task in '../bin/ndn-autoconfig-server' failed (exit status 1): >> {task 139875896347216: cxxprogram ndn-autoconfig-server.cpp.1.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> ndn-autoconfig-server} >> ['/usr/bin/g++', 'tools/ndn-autoconfig-server.cpp.1.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/ndn-autoconfig-server', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >> >> -- >> -- >> Chaim Rieger >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -- -- Chaim Rieger From alexander.afanasyev at ucla.edu Wed Jun 17 13:39:14 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 17 Jun 2015 13:39:14 -0700 Subject: [Nfd-dev] Fresh install on Fedora issues In-Reply-To: <5581C1DE.7010006@gmail.com> References: <5581BA54.9060107@gmail.com> <5581C1DE.7010006@gmail.com> Message-ID: I do not confirm the problem. I just tried on my fresh Fedora 22. After installing ndn-cxx, i added echo /usr/local/lib64 | sudo tee /etc/ld.so.conf.d/usr_local_lib64.conf sudo ldconfig Afterwards, I compiled and installed NFD without issues. I used master branches for both ndn-cxx and NFD. --- Alex > On Jun 17, 2015, at 11:52 AM, Chaim Rieger wrote: > > This is getting weird > > I did a waf uninstall , was clean, then reinstalled successfully. > > when trying to run nfd-start I still get a lib error though > > [122/123] Linking build/bin/ndn-tlv-peek > [123/123] Linking build/bin/nfd > Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' > 'build' finished successfully (2m22.771s) > ./waf install > Waf: Entering directory `/home/crieger/ndnSIM/NFD/build' > + install /usr/local/share/ndn/nfd-status.xsl (from tools/nfd-status-http-server-files/nfd-status.xsl) > + install /usr/local/share/ndn/reset.css (from tools/nfd-status-http-server-files/reset.css) > + install /usr/local/bin/nfd-stop (from build/bin/nfd-stop) > + install /usr/local/bin/nfd-start (from build/bin/nfd-start) > + install /usr/local/bin/nfd-status-http-server (from build/bin/nfd-status-http-server) > + install /usr/local/share/ndn/robots.txt (from tools/nfd-status-http-server-files/robots.txt) > + install /usr/local/bin/nrd (from build/bin/nrd) > + install /usr/local/etc/ndn/nfd.conf.sample (from build/nfd.conf.sample) > + install /usr/local/share/man//man1/nfd.1 (from build/docs/manpages/nfd.1) > + install /usr/local/share/ndn/style.css (from tools/nfd-status-http-server-files/style.css) > + install /usr/local/share/man//man1/nrd.1 (from build/docs/manpages/nrd.1) > + install /usr/local/share/man//man1/ndn-autoconfig-server.1 (from build/docs/manpages/ndn-autoconfig-server.1) > + install /usr/local/share/man//man1/ndn-autoconfig.1 (from build/docs/manpages/ndn-autoconfig.1) > + install /usr/local/share/ndn/text.css (from tools/nfd-status-http-server-files/text.css) > + install /usr/local/share/man//man1/nfdc.1 (from build/docs/manpages/nfdc.1) > + install /usr/local/share/man//man1/ndn-tlv-peek.1 (from build/docs/manpages/ndn-tlv-peek.1) > + install /usr/local/share/man//man1/ndn-tlv-poke.1 (from build/docs/manpages/ndn-tlv-poke.1) > + install /usr/local/share/man//man1/nfd-autoreg.1 (from build/docs/manpages/nfd-autoreg.1) > + install /usr/local/share/man//man1/nfd-status-http-server.1 (from build/docs/manpages/nfd-status-http-server.1) > + install /usr/local/share/man//man1/nfd-status.1 (from build/docs/manpages/nfd-status.1) > + install /usr/local/bin/ndn-tlv-peek (from build/bin/ndn-tlv-peek) > + install /usr/local/bin/ndn-autoconfig (from build/bin/ndn-autoconfig) > + install /usr/local/bin/nfd-status (from build/bin/nfd-status) > + install /usr/local/bin/nfdc (from build/bin/nfdc) > + install /usr/local/bin/ndn-tlv-poke (from build/bin/ndn-tlv-poke) > + install /usr/local/bin/nfd (from build/bin/nfd) > + install /usr/local/bin/nfd-autoreg (from build/bin/nfd-autoreg) > + install /usr/local/bin/ndn-autoconfig-server (from build/bin/ndn-autoconfig-server) > Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' > 'install' finished successfully (0.419s) > [root at localhost NFD] # /usr/local/bin/nfd-start > [root at localhost NFD] # /usr/local/bin/nfd: error while loading shared libraries: libndn-cxx.so.0.3.2: cannot open shared object file: No such file or directory > > [root at localhost NFD] # env | grep LD > OLDPWD=/root > LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64 > > [root at localhost NFD] # locate libndn-cxx.so.0.3.2 > /home/crieger/ndnSIM/ndn-cxx/build/libndn-cxx.so.0.3.2 > /usr/local/lib64/libndn-cxx.so.0.3.2 > > > On 06/17/2015 11:45 AM, Alex Afanasyev wrote: >> Can you check that you don't have the static library (libndn-cxx.a) installed somewhere? >> >>> On Jun 17, 2015, at 11:20 AM, Chaim Rieger wrote: >>> >>> ndn-cxx is installed (latest version) on fedora 22 x64 into /usr/local/bin /usr/local/lib64 >>> >>> cd into the nfd >>> ./waf configure runs fine >>> ./waf produces the following error >>> >>> [118/123] Linking build/bin/nfdc >>> tools/nfd-status.cpp.5.o: In function `ndn::Name::getPrefix(long) const': >>> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >>> collect2: error: ld returned 1 exit status >>> >>> tools/ndn-autoconfig-server.cpp.1.o: In function `ndn::Name::getPrefix(long) const': >>> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >>> collect2: error: ld returned 1 exit status >>> >>> Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' >>> Build failed >>> -> task in '../bin/nfd-status' failed (exit status 1): >>> {task 139875896348496: cxxprogram nfd-status.cpp.5.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> nfd-status} >>> ['/usr/bin/g++', 'tools/nfd-status.cpp.5.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/nfd-status', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >>> -> task in '../bin/ndn-autoconfig-server' failed (exit status 1): >>> {task 139875896347216: cxxprogram ndn-autoconfig-server.cpp.1.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> ndn-autoconfig-server} >>> ['/usr/bin/g++', 'tools/ndn-autoconfig-server.cpp.1.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/ndn-autoconfig-server', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >>> >>> -- >>> -- >>> Chaim Rieger >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -- > -- > Chaim Rieger > -------------- 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 chaim.rieger at gmail.com Thu Jun 18 00:02:58 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Thu, 18 Jun 2015 00:02:58 -0700 Subject: [Nfd-dev] Fresh install on Fedora issues In-Reply-To: References: <5581BA54.9060107@gmail.com> <5581C1DE.7010006@gmail.com> Message-ID: Correct. I had a stale lib laying around. All good now. Sorry for the confusion. ? Chaim Rieger > On Jun 17, 2015, at 1:39 PM, Alex Afanasyev wrote: > > I do not confirm the problem. > > I just tried on my fresh Fedora 22. After installing ndn-cxx, i added > > echo /usr/local/lib64 | sudo tee /etc/ld.so.conf.d/usr_local_lib64.conf > sudo ldconfig > > Afterwards, I compiled and installed NFD without issues. I used master branches for both ndn-cxx and NFD. > > --- > Alex > >> On Jun 17, 2015, at 11:52 AM, Chaim Rieger wrote: >> >> This is getting weird >> >> I did a waf uninstall , was clean, then reinstalled successfully. >> >> when trying to run nfd-start I still get a lib error though >> >> [122/123] Linking build/bin/ndn-tlv-peek >> [123/123] Linking build/bin/nfd >> Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' >> 'build' finished successfully (2m22.771s) >> ./waf install >> Waf: Entering directory `/home/crieger/ndnSIM/NFD/build' >> + install /usr/local/share/ndn/nfd-status.xsl (from tools/nfd-status-http-server-files/nfd-status.xsl) >> + install /usr/local/share/ndn/reset.css (from tools/nfd-status-http-server-files/reset.css) >> + install /usr/local/bin/nfd-stop (from build/bin/nfd-stop) >> + install /usr/local/bin/nfd-start (from build/bin/nfd-start) >> + install /usr/local/bin/nfd-status-http-server (from build/bin/nfd-status-http-server) >> + install /usr/local/share/ndn/robots.txt (from tools/nfd-status-http-server-files/robots.txt) >> + install /usr/local/bin/nrd (from build/bin/nrd) >> + install /usr/local/etc/ndn/nfd.conf.sample (from build/nfd.conf.sample) >> + install /usr/local/share/man//man1/nfd.1 (from build/docs/manpages/nfd.1) >> + install /usr/local/share/ndn/style.css (from tools/nfd-status-http-server-files/style.css) >> + install /usr/local/share/man//man1/nrd.1 (from build/docs/manpages/nrd.1) >> + install /usr/local/share/man//man1/ndn-autoconfig-server.1 (from build/docs/manpages/ndn-autoconfig-server.1) >> + install /usr/local/share/man//man1/ndn-autoconfig.1 (from build/docs/manpages/ndn-autoconfig.1) >> + install /usr/local/share/ndn/text.css (from tools/nfd-status-http-server-files/text.css) >> + install /usr/local/share/man//man1/nfdc.1 (from build/docs/manpages/nfdc.1) >> + install /usr/local/share/man//man1/ndn-tlv-peek.1 (from build/docs/manpages/ndn-tlv-peek.1) >> + install /usr/local/share/man//man1/ndn-tlv-poke.1 (from build/docs/manpages/ndn-tlv-poke.1) >> + install /usr/local/share/man//man1/nfd-autoreg.1 (from build/docs/manpages/nfd-autoreg.1) >> + install /usr/local/share/man//man1/nfd-status-http-server.1 (from build/docs/manpages/nfd-status-http-server.1) >> + install /usr/local/share/man//man1/nfd-status.1 (from build/docs/manpages/nfd-status.1) >> + install /usr/local/bin/ndn-tlv-peek (from build/bin/ndn-tlv-peek) >> + install /usr/local/bin/ndn-autoconfig (from build/bin/ndn-autoconfig) >> + install /usr/local/bin/nfd-status (from build/bin/nfd-status) >> + install /usr/local/bin/nfdc (from build/bin/nfdc) >> + install /usr/local/bin/ndn-tlv-poke (from build/bin/ndn-tlv-poke) >> + install /usr/local/bin/nfd (from build/bin/nfd) >> + install /usr/local/bin/nfd-autoreg (from build/bin/nfd-autoreg) >> + install /usr/local/bin/ndn-autoconfig-server (from build/bin/ndn-autoconfig-server) >> Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' >> 'install' finished successfully (0.419s) >> [root at localhost NFD] # /usr/local/bin/nfd-start >> [root at localhost NFD] # /usr/local/bin/nfd: error while loading shared libraries: libndn-cxx.so.0.3.2: cannot open shared object file: No such file or directory >> >> [root at localhost NFD] # env | grep LD >> OLDPWD=/root >> LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64 >> >> [root at localhost NFD] # locate libndn-cxx.so.0.3.2 >> /home/crieger/ndnSIM/ndn-cxx/build/libndn-cxx.so.0.3.2 >> /usr/local/lib64/libndn-cxx.so.0.3.2 >> >> >> On 06/17/2015 11:45 AM, Alex Afanasyev wrote: >>> Can you check that you don't have the static library (libndn-cxx.a) installed somewhere? >>> >>>> On Jun 17, 2015, at 11:20 AM, Chaim Rieger wrote: >>>> >>>> ndn-cxx is installed (latest version) on fedora 22 x64 into /usr/local/bin /usr/local/lib64 >>>> >>>> cd into the nfd >>>> ./waf configure runs fine >>>> ./waf produces the following error >>>> >>>> [118/123] Linking build/bin/nfdc >>>> tools/nfd-status.cpp.5.o: In function `ndn::Name::getPrefix(long) const': >>>> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >>>> collect2: error: ld returned 1 exit status >>>> >>>> tools/ndn-autoconfig-server.cpp.1.o: In function `ndn::Name::getPrefix(long) const': >>>> /usr/local/include/ndn-cxx/name.hpp:236: undefined reference to `ndn::Name::getSubName(unsigned long, unsigned long) const' >>>> collect2: error: ld returned 1 exit status >>>> >>>> Waf: Leaving directory `/home/crieger/ndnSIM/NFD/build' >>>> Build failed >>>> -> task in '../bin/nfd-status' failed (exit status 1): >>>> {task 139875896348496: cxxprogram nfd-status.cpp.5.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> nfd-status} >>>> ['/usr/bin/g++', 'tools/nfd-status.cpp.5.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/nfd-status', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >>>> -> task in '../bin/ndn-autoconfig-server' failed (exit status 1): >>>> {task 139875896347216: cxxprogram ndn-autoconfig-server.cpp.1.o,city-hash.cpp.2.o,config-file.cpp.2.o,global-io.cpp.2.o,network-interface.cpp.2.o,network.cpp.2.o,privilege-helper.cpp.2.o,random.cpp.2.o,scheduler.cpp.2.o,logger-factory.cpp.2.o,logger.cpp.2.o -> ndn-autoconfig-server} >>>> ['/usr/bin/g++', 'tools/ndn-autoconfig-server.cpp.1.o', 'core/city-hash.cpp.2.o', 'core/config-file.cpp.2.o', 'core/global-io.cpp.2.o', 'core/network-interface.cpp.2.o', 'core/network.cpp.2.o', 'core/privilege-helper.cpp.2.o', 'core/random.cpp.2.o', 'core/scheduler.cpp.2.o', 'core/logger-factory.cpp.2.o', 'core/logger.cpp.2.o', '-o', '/home/crieger/ndnSIM/NFD/build/bin/ndn-autoconfig-server', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/usr/lib64', '-L/usr/local/lib64', '-L/usr/lib64', '-lboost_system', '-lboost_chrono', '-lboost_program_options', '-lboost_random', '-lboost_thread', '-lndn-cxx', '-lboost_system', '-lboost_filesystem', '-lboost_date_time', '-lboost_iostreams', '-lboost_regex', '-lboost_program_options', '-lboost_chrono', '-lboost_random', '-lcryptopp', '-lsqlite3', '-lrt', '-lpthread', '-lrt', '-lresolv'] >>>> >>>> -- >>>> -- >>>> Chaim Rieger >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> -- >> -- >> Chaim Rieger >> > From shijunxiao at email.arizona.edu Mon Jun 22 21:25:56 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 22 Jun 2015 21:25:56 -0700 Subject: [Nfd-dev] Proposed NDN spec change In-Reply-To: <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> References: <9B98BEA7-98A5-4F6B-A1EF-352934997FEC@ucla.edu> <000706CC-DF5D-4791-8B83-E4C2C7BC85FF@remap.ucla.edu> Message-ID: Hi Jeff FreshnessPeriod is a nonNegativeInteger, whose upper bound is 2^64-1. This upper bound value gives a FreshnessPeriod that is millions of years, which is practically "always fresh". It's unnecessary to have a special FreshnessPeriod value to indicate "always fresh". Yours, Junxiao On Wed, Jun 10, 2015 at 9:27 PM, Burke, Jeff wrote: > Would it make sense to provide a way to encode whether the packet should > be considered "always fresh" or "always stale" explicitly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Jun 24 14:37:58 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 24 Jun 2015 14:37:58 -0700 Subject: [Nfd-dev] ndn-cxx feature deprecation: signing params in CommandOptions Message-ID: Dear folks The following items are deprecated in ndn-cxx: - ndn::nfd::CommandOptions::SigningParamsKind - ndn::nfd::CommandOptions::getSigningParamsKind - ndn::nfd::CommandOptions::getSigningIdentity - ndn::nfd::CommandOptions::getSigningCertificate - ndn::nfd::CommandOptions::setSigningDefault - ndn::nfd::CommandOptions::getSigningIdentity - ndn::nfd::CommandOptions::getSigningCertificate If you have code that uses any of those features, please migrate to the new syntax as described in Doxygen. I will add DEPRECATED macro onto those items soon, but no earlier than Jul 01 12:00 UTC. This means compiler will produce a warning whenever they are used. If your project uses "-Werror" flag, this would become an error. To test your project, in management/nfd-command-option.hpp, comment out `#define NDN_MANAGEMENT_NFD_COMMAND_OPTIONS_KEEP_DEPRECATED_SIGNING_PARAMS`. Those deprecated items will be deleted in v0.5. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Jun 27 18:08:12 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 27 Jun 2015 18:08:12 -0700 Subject: [Nfd-dev] HOWTO: checkout two pending commits to local machine Message-ID: Dear folks I'm asked for how to checkout two pending commits from Gerrit to the local machine, for the purpose of preparing for a manual rebasing/merging. Here's the procedure: 1. clone the repository from Gerrit 1. see detailed procedure at http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-March/000961.html 2. on Gerrit, find the checkout command line of the first pending commit 1. navigate to the Change screen 2. click on "Download" dropdown 3. on the dropdown box, select "ssh" in the combo box at the bottom 4. copy the command line next to "Checkout" 3. execute the checkout command line on the local repository 4. create a branch from the checked out commit 1. git branch cWWWW-XX, where WWWW is the Change number, and XX is the patchset number 5. on Gerrit, find the checkout command line of the second pending commit (see step 2) 6. execute the checkout command line on the local repository 7. create a branch from the checked out commit 1. git branch cYYYY-ZZ, where YYYY is the Change number, and ZZ is the patchset number Now you have checked out two pending commits from Gerrit, and they are in branch cWWWW-XX and cYYYY-ZZ, respectively. If you find a mistake in this procedure, please reply-all to report the problem, and paste error message and screenshots. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: