From nfd-call-notification at mail1.yoursunny.com  Tue Mar  1 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 1 Mar 2016 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20160301
Message-ID: <201603011500.u21F028D020848@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160301/fdeab148/attachment.html>

From iliamo at mailbox.org  Tue Mar  1 11:36:53 2016
From: iliamo at mailbox.org (Ilya Moiseenko)
Date: Tue, 1 Mar 2016 20:36:53 +0100 (CET)
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
Message-ID: <920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>

Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and
Table 1 of Mininet paper
http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good
choice for experiments that depend on precise timing.


Ilya  

>     On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu>
> wrote:
> 
>     Hi folks,
> 
>     Below I summarize what I think are all of the issues and ideas raised last
> week about continuing the process of debugging NDN-RTC.   I've created redmine
> issues for each to aid tracking and am hoping to hand over to Peter the
> coordination process of checking in on all of these in the time between now
> and the retreat.   It would be great to get feedback from the NFD team on what
> they can help with - especially on the first few more immediate items. 
> 
>     Please reply within the appropriate redmine issue, if possible, rather
> than by email. 
> 
>     A. Next tests
> 
>     1. March 2 seminar. Christos will give the next seminar on March 2.
>  Anyone at ColoState that might be able to provide support to him in running
> both NDN-RTC and WebEx at the same time?  Peter, can you follow up with
> Christos and Steve as a starting point, and try to push a new version of
> NDN-RTC with any things that we want to test?  My suggestion is also to
> provide only one bandwidth option for each stream, so we see uniform requests
> across all nodes.   http://redmine.named-data.net/issues/3485
> 
>     2. Test plan. Peter proposes to put together a methodical testing
> strategy, using the seminars and other regular meetings as tests of NDN-RTC.
>  John is already helping with this.  We would like a single point of contact
> from the NFD team to act as a liaison for this, and help get questions answers
> / design an approach.  Who should it be?
>    http://redmine.named-data.net/issues/3487
> 
>     3. Enable ARC detectors.  Peter, I know that we are not ready for
> incorporating ARC support, and it's not likely to solve current problems, but
> I'm wondering if we could include the congestion detection mechanism and log
> its behavior, just to see how it does?
>   http://redmine.named-data.net/issues/3488
> 
>     B. Remaining triage on last test
> 
>     1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node
> contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us
> figure out what they are / what caused them so we can try to mitigate?  Or,
> provide instrumentation to do this after the next test on this coming
> Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us
> know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in
> the redmine thread. 
> 
>     2. Capture of NFD parameters during the test.  John, is it possible to do
> periodic capture of stats like the above ? perhaps every few seconds per node?
> (Or do you already do that?)   This would be useful in evaluating these tests
> and also looking for relevant behavior during the test.  Assignee: WUSTL?
>  http://redmine.named-data.net/issues/3486
> 
>     3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to
> understand better what we think should work based on the testing you and
> Jiachen did.  Perhaps summarize in bullet-point format what we've learned /
> observed so far, and where we think there are issues. Assignee: Peter.  Due:
> ASAP.  http://redmine.named-data.net/issues/3483 
> 
>     C. Application issues
> 
>     1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than
> expected was observed during the test, and higher than I remember from
> previous versions. Peter, can you let us know to expect for a given stream (in
> both directions), and breakdown in percentages with its major contributions
> are?  Also, you may wish to change the menu options to reflect both the media
> bitrate and the estimated total network traffic so people know what to expect.
>  Assignee: Peter  Due: Before next seminar.
>  http://redmine.named-data.net/issues/3478
> 
>     2. NDN-RTC: Silence suppression. Several people noted that silence
> suppression should be incorporate so that audio fetching from silent
> participants is reduced/eliminated, potentially reducing PIT and CPU load.
>  (We have discussed this before. Though this is an optimization, we should
> consider fixing it to remove this critique.  This optimization should be
> something that can be turned on/off in the GUI.)   Assignee: Peter  Due:
> Perhaps before retreat  http://redmine.named-data.net/issues/3477
> 
>     D. NFD performance
> 
>     The previous section are performance optimizations.  We can do them, but
> have to know our target: 
> 
>     1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in
> the application, the nominal bandwidths that were observed (~100-500
> kbyte/sec) should be reasonable on the university networks and nodes in
> questions.  Given that we are being advised to optimize the app, can someone
> please advise on what are appropriate target bandwidths for the current NFDs
> running on the current testbed?  http://redmine.named-data.net/issues/3482
> 
>     E. More NDN-RTC evaluation tools
> 
>     I really hope that we don't have to wait to the hackathon to make
> progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with
> the simulation/emulation environment desired by the NFD team, just let us know
> which of these should be targeted first. 
> 
>     1. Simulation: Real app.  Klaus and others would like to be able to
> simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external
> traffic. I'm not sure if this is what Junxiao was referring to, but here's a
> HOWTO -
> https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world
> https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world .
>     http://redmine.named-data.net/issues/3479
> 
>     2. Emulation.  In addition, it was discussed that NDN-RTC could be run
> with the Mini-NDN emulation environment. This seems feasible. Does someone
> from the NFD team want to try, this perhaps in the context of figuring out NFD
> PIT growth issue?    https://github.com/named-data/mini-ndn
>   http://redmine.named-data.net/issues/3481
> 
>     3. Simulation: traffic generator.  If the above is not feasible, Lixia
> suggests a simple traffic generator could also be written.  (See 2/26 17:26
> message).   http://redmine.named-data.net/issues/3480
> 
>     F. Debugging support
> 
>     1. NFD Instrumentation.  Though it might take time to add, perhaps we can
> brainstorm about what instrumentation for NFD would help with debugging these
> types of applications, and perhaps come up with short-term ways to achieve it.
>  Could the NFD team contribute ideas to this and Peter, can you add notes to
> this on an ongoing basses about what might be useful for NDN-RTC?)
>   http://redmine.named-data.net/issues/3476
> 
>     G. Design challenges / Useful mechanisms
> 
>     1. Prioritization.  For both audio and eventually scalable video traffic,
> NDN-RTC could make use of the type of one-hop priority mechanism discussed
> briefly with Van a year or so ago.  Can we pursue design and discussion of
> this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in
> the next few weeks, could a trial implementation be a hackathon project?]
> 
>     2. Congestion control work continues in parallel by Klaus.  Lixia suggests
> that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a
> schedule of the work that he plans.  Klaus, could you let us know this in the
> redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is
> sketched in the next few weeks, could a trial implementation be a hackathon
> project?]
> 
> 
>     Thanks!
>     Jeff
> 
> 
> 
>      
> 


 

> _______________________________________________
>     Nfd-dev mailing list
>     Nfd-dev at lists.cs.ucla.edu
>     http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160301/5be215ca/attachment.html>

From lanwang at memphis.edu  Tue Mar  1 11:45:47 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 1 Mar 2016 19:45:47 +0000
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
Message-ID: <FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>

Ilya,

Can you elaborate a little what you mean by experiments that depend on precise timing?

Lan

On Mar 1, 2016, at 1:36 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and Table 1 of Mininet paper http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good choice for experiments that depend on precise timing.


Ilya

On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC.   I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat.   It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items.

Please reply within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

B. Remaining triage on last test

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

E. More NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]


Thanks!
Jeff







_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160301/d1b7eb54/attachment.html>

From iliamo at mailbox.org  Tue Mar  1 12:22:26 2016
From: iliamo at mailbox.org (Ilya Moiseenko)
Date: Tue, 1 Mar 2016 21:22:26 +0100 (CET)
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>
Message-ID: <2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>

For example, in Mininet, it is possible to see >150ms delays on 10 ms links,
because either the host or guest operating system has decided that it was a good
time to switch to another process.

In addition to that, Table 1 says that peak performance of Mininet with just 1
switch is ~500mbits, but NDN forwarder is much much slower than IP switch, and I
guess you would like to have at least 3-5 nodes in the topology. I think that
Mininet is good for testing chat applications, maybe routing protocols, but not
for relatively high throughput apps.     

>     On March 1, 2016 at 8:45 PM "Lan Wang (lanwang)" <lanwang at memphis.edu>
> wrote:
> 
>     Ilya,
> 
>     Can you elaborate a little what you mean by experiments that depend on
> precise timing?
> 
>     Lan
> 
>     On Mar 1, 2016, at 1:36 PM, Ilya Moiseenko <iliamo at mailbox.org
> mailto:iliamo at mailbox.org > wrote:
> 
> 
>         > > 
> >         Hi Jeff,
> > 
> >         Before anyone puts efforts in Mininet emulation, I suggest to read
> > section 5 and Table 1 of Mininet paper
> > http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf
> > 
> >         Mininet is a good tool for achieving protocol correctness, but it's
> > not a good choice for experiments that depend on precise timing.
> > 
> > 
> >         Ilya  
> > 
> >             > > >             On February 28, 2016 at 6:38 PM "Burke, Jeff"
> >             > > > <jburke at remap.ucla.edu mailto:jburke at remap.ucla.edu >
> >             > > > wrote:
> > > 
> > >             Hi folks,
> > > 
> > >             Below I summarize what I think are all of the issues and ideas
> > > raised last week about continuing the process of debugging NDN-RTC.   I've
> > > created redmine issues for each to aid tracking and am hoping to hand over
> > > to Peter the coordination process of checking in on all of these in the
> > > time between now and the retreat.   It would be great to get feedback from
> > > the NFD team on what they can help with - especially on the first few more
> > > immediate items. 
> > > 
> > >             Please reply within the appropriate redmine issue, if
> > > possible, rather than by email. 
> > > 
> > >             A. Next tests
> > > 
> > >             1. March 2 seminar. Christos will give the next seminar on
> > > March 2.  Anyone at ColoState that might be able to provide support to him
> > > in running both NDN-RTC and WebEx at the same time?  Peter, can you follow
> > > up with Christos and Steve as a starting point, and try to push a new
> > > version of NDN-RTC with any things that we want to test?  My suggestion is
> > > also to provide only one bandwidth option for each stream, so we see
> > > uniform requests across all nodes.
> > >   http://redmine.named-data.net/issues/3485
> > > 
> > >             2. Test plan. Peter proposes to put together a methodical
> > > testing strategy, using the seminars and other regular meetings as tests
> > > of NDN-RTC.  John is already helping with this.  We would like a single
> > > point of contact from the NFD team to act as a liaison for this, and help
> > > get questions answers / design an approach.  Who should it be?
> > >    http://redmine.named-data.net/issues/3487
> > > 
> > >             3. Enable ARC detectors.  Peter, I know that we are not ready
> > > for incorporating ARC support, and it's not likely to solve current
> > > problems, but I'm wondering if we could include the congestion detection
> > > mechanism and log its behavior, just to see how it does?
> > >   http://redmine.named-data.net/issues/3488
> > > 
> > >             B. Remaining triage on last test
> > > 
> > >             1. PIT / name-tree entries.  After the test on Wednesday, the
> > > REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can
> > > someone help us figure out what they are / what caused them so we can try
> > > to mitigate?  Or, provide instrumentation to do this after the next test
> > > on this coming Wednesday?    http://redmine.named-data.net/issues/3484
> > >  @Peter, please let us know what the maximum Interest Lifetime is in
> > > NDN-RTC packets ASAP; respond in the redmine thread. 
> > > 
> > >             2. Capture of NFD parameters during the test.  John, is it
> > > possible to do periodic capture of stats like the above ? perhaps every
> > > few seconds per node? (Or do you already do that?)   This would be useful
> > > in evaluating these tests and also looking for relevant behavior during
> > > the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486
> > > 
> > >             3. NDN-RTC: Summarize results of internal testing.  Peter,
> > > folks need to understand better what we think should work based on the
> > > testing you and Jiachen did.  Perhaps summarize in bullet-point format
> > > what we've learned / observed so far, and where we think there are issues.
> > > Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483 
> > > 
> > >             C. Application issues
> > > 
> > >             1. NDN-RTC: Bandwidth performance.  Significantly higher
> > > bandwidth than expected was observed during the test, and higher than I
> > > remember from previous versions. Peter, can you let us know to expect for
> > > a given stream (in both directions), and breakdown in percentages with its
> > > major contributions are?  Also, you may wish to change the menu options to
> > > reflect both the media bitrate and the estimated total network traffic so
> > > people know what to expect.  Assignee: Peter  Due: Before next seminar.
> > >  http://redmine.named-data.net/issues/3478
> > > 
> > >             2. NDN-RTC: Silence suppression. Several people noted that
> > > silence suppression should be incorporate so that audio fetching from
> > > silent participants is reduced/eliminated, potentially reducing PIT and
> > > CPU load.  (We have discussed this before. Though this is an optimization,
> > > we should consider fixing it to remove this critique.  This optimization
> > > should be something that can be turned on/off in the GUI.)   Assignee:
> > > Peter  Due: Perhaps before retreat
> > >  http://redmine.named-data.net/issues/3477
> > > 
> > >             D. NFD performance
> > > 
> > >             The previous section are performance optimizations.  We can do
> > > them, but have to know our target: 
> > > 
> > >             1. NFD/Testbed ? Acceptable target bandwidth. Even with
> > > inefficiencies in the application, the nominal bandwidths that were
> > > observed (~100-500 kbyte/sec) should be reasonable on the university
> > > networks and nodes in questions.  Given that we are being advised to
> > > optimize the app, can someone please advise on what are appropriate target
> > > bandwidths for the current NFDs running on the current testbed?
> > >  http://redmine.named-data.net/issues/3482
> > > 
> > >             E. More NDN-RTC evaluation tools
> > > 
> > >             I really hope that we don't have to wait to the hackathon to
> > > make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC
> > > running with the simulation/emulation environment desired by the NFD team,
> > > just let us know which of these should be targeted first. 
> > > 
> > >             1. Simulation: Real app.  Klaus and others would like to be
> > > able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support
> > > external traffic. I'm not sure if this is what Junxiao was referring to,
> > > but here's a HOWTO -
> > > https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world
> > > https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world .
> > >     http://redmine.named-data.net/issues/3479
> > > 
> > >             2. Emulation.  In addition, it was discussed that NDN-RTC
> > > could be run with the Mini-NDN emulation environment. This seems feasible.
> > > Does someone from the NFD team want to try, this perhaps in the context of
> > > figuring out NFD PIT growth issue?
> > >    https://github.com/named-data/mini-ndn
> > >   http://redmine.named-data.net/issues/3481
> > > 
> > >             3. Simulation: traffic generator.  If the above is not
> > > feasible, Lixia suggests a simple traffic generator could also be written.
> > >  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480
> > > 
> > >             F. Debugging support
> > > 
> > >             1. NFD Instrumentation.  Though it might take time to add,
> > > perhaps we can brainstorm about what instrumentation for NFD would help
> > > with debugging these types of applications, and perhaps come up with
> > > short-term ways to achieve it.  Could the NFD team contribute ideas to
> > > this and Peter, can you add notes to this on an ongoing basses about what
> > > might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476
> > > 
> > >             G. Design challenges / Useful mechanisms
> > > 
> > >             1. Prioritization.  For both audio and eventually scalable
> > > video traffic, NDN-RTC could make use of the type of one-hop priority
> > > mechanism discussed briefly with Van a year or so ago.  Can we pursue
> > > design and discussion of this?  http://redmine.named-data.net/issues/3475
> > >  [If a design is sketched in the next few weeks, could a trial
> > > implementation be a hackathon project?]
> > > 
> > >             2. Congestion control work continues in parallel by Klaus.
> > >  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and
> > > asked Klaus for a schedule of the work that he plans.  Klaus, could you
> > > let us know this in the redmine issue,
> > >  http://redmine.named-data.net/issues/1624  [If a design is sketched in
> > > the next few weeks, could a trial implementation be a hackathon project?]
> > > 
> > > 
> > >             Thanks!
> > >             Jeff
> > > 
> > > 
> > > 
> > >              
> > > 
> > >         > > 
> > 
> >          
> > 
> >             > > > _______________________________________________
> > >             Nfd-dev mailing list
> > >             Nfd-dev at lists.cs.ucla.edu mailto: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 mailto:Nfd-dev at lists.cs.ucla.edu
> >         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> > 
> >     > 
> 


 

> _______________________________________________
>     Nfd-dev mailing list
>     Nfd-dev at lists.cs.ucla.edu
>     http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160301/2031e0d5/attachment.html>

From peter at remap.ucla.edu  Tue Mar  1 14:18:08 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Tue, 1 Mar 2016 22:18:08 +0000
Subject: [Nfd-dev] ndncon test producers
Message-ID: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>

Hi dev team,

There are two test ndncon producers that should be available 24/7:

/ndn/edu/ucla/remap/freeculture
- 1 audio stream
- 1 stream 1000-bytes segments:
- 700 kbps
- 1000 kbps
- 3000 kbps
- 1 stream 8000-bytes segments:
- 700 kbps
- 1000 kbps
- 3000 kbps
and

/ndn/edu/ucla/remap/test
- 1 audio stream (pandora radio)
- 1 stream webcam
- 200 kbps
- 1000 kbps
- 3000 kbps
- 1 stream desktop
- 500 kbps
- 700 kbps
- 1100 kbps

If you can?t see them in ndncon?s ?Active users? list, let me know, I?ll check the issue.

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160301/d2f553ff/attachment.html>

From lanwang at memphis.edu  Wed Mar  2 13:18:32 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 2 Mar 2016 21:18:32 +0000
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>
	<2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
Message-ID: <C014EAFE-A831-45D2-9E1A-9F584618DB4F@memphis.edu>

Vince told me that this is not the latest paper and recent versions of mininet may have better fidelity with real networks.  He's still reading the latest mininet paper and will send a more detailed response.

Lan

On Mar 1, 2016, at 2:22 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


For example, in Mininet, it is possible to see >150ms delays on 10 ms links, because either the host or guest operating system has decided that it was a good time to switch to another process.

In addition to that, Table 1 says that peak performance of Mininet with just 1 switch is ~500mbits, but NDN forwarder is much much slower than IP switch, and I guess you would like to have at least 3-5 nodes in the topology. I think that Mininet is good for testing chat applications, maybe routing protocols, but not for relatively high throughput apps.

On March 1, 2016 at 8:45 PM "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Ilya,

Can you elaborate a little what you mean by experiments that depend on precise timing?

Lan

On Mar 1, 2016, at 1:36 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and Table 1 of Mininet paper http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good choice for experiments that depend on precise timing.


Ilya

On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC.   I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat.   It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items.

Please reply within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

B. Remaining triage on last test

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

E. More NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]


Thanks!
Jeff







_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto: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<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160302/50712b9e/attachment.html>

From peter at remap.UCLA.EDU  Wed Mar  2 16:14:19 2016
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Thu, 3 Mar 2016 00:14:19 +0000
Subject: [Nfd-dev] ndncon test producers
In-Reply-To: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
References: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
Message-ID: <B7C059F0-E5B5-453E-8F9B-74FEAC27EEEF@remap.ucla.edu>

Hi dev team,

First of all, thanks for trying ndncon today.

I?d like to give a brief summary on today?s test, present results I have gathered and my thoughts/ideas for the next week.

comments:
? Susmit didn?t present through ndncon today as was planned; the reason for that - CSU hub he supposed to be using stopped creating backroutes and we had very little time to fix it before seminar; he resorted to WebEX eventually
? even though Susmit was using WebEX, I still set up a conference bridge which published WebEX video using ndncon so that ndncon users could fetch it
? I counted about 5 active users today (maybe +1 is Josh was fetching) fetching audio+video from confbridge.
? not all of them were publishing their streams though; in fact just me and occasionally Alex, so these streams were also fetched by confbridge user (thus contributed to overall traffic) and audio was passed on to WebEX (when I talked today, it was through ndncon)

summary:
? I was connected to REMAP hub and in the beginning, audio was quite choppy. video was ok, but it?s mainly due to its? static nature (slides) - i didn?t miss any slides nevertheless.
? few users on UCLA hub reported choppy audio as well (Haitao and Alex)
? JeffT (WU) was experiencing choppy audio often; @JeffT, please share your experience if you?d like
? once Alex dropped (around 10-15min from the beginning of the seminar) , Haitao reported much better audio for him; I noticed that audio improved for me as well
? till the rest of the seminar, I experienced few short audio interruptions (once in 1-2min for 0.5-1sec long); it didn?t prevent me from understanding the content
? here is the gathered CPU and memory usage for the users participating in ndncon test - http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/seminar-3-2-2016-overview (use login: guest, pw: ndnguest if needed); feel free to explore.
? one can see that Alex was experiencing raging NFD CPU usage during his first 10-15min until he restarted NFD; ndncon CPU usage wasn?t that high though;
? NFD resident memory tends to be around 700-900Mb for all users
? one can notice ndncon memory grows slowly over time (~20Mb per hour); we?ll look at that (though priority isn?t high for now)
? average ndncon CPU usage for fetching 1 audio and 1 video stream is around 40% (but depends on the machine of course)

 next seminar:
? I?ll continue improving monitoring tool as my time allows (see real-time statistics here<http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/resources-monitor-last-30min>, login:guest pw:ndnguest) and will think of adding some internal core metrics for NDN-RTC (like number of streams fetched, chasing times, number of rebufferings, etc.)
? we should clarify for ourselves few things (please add any):
? why NFD CPU usage was raging or spiked sometimes (especially for Alex?s machine)?
? JeffT may have experienced problems due to changes in traffic routes (@JeffT, please confirm), should we test/confirm that?
? is there a correlation b/w degraded ndncon experience and metrics gathered by John DeHart?

These updates are submitted to the ticket<http://redmine.named-data.net/issues/3485#note-8>.

Thanks,


[cid:9453FAEE-071D-4288-A492-3D34CD3754FF][cid:78AB15BB-C85D-4970-B4BC-5CE12EAE6AD9]


--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 1, 2016, at 2:18 PM, Peter Gusev <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi dev team,

There are two test ndncon producers that should be available 24/7:

/ndn/edu/ucla/remap/freeculture
- 1 audio stream
- 1 stream 1000-bytes segments:
- 700 kbps
- 1000 kbps
- 3000 kbps
- 1 stream 8000-bytes segments:
- 700 kbps
- 1000 kbps
- 3000 kbps
and

/ndn/edu/ucla/remap/test
- 1 audio stream (pandora radio)
- 1 stream webcam
- 200 kbps
- 1000 kbps
- 3000 kbps
- 1 stream desktop
- 500 kbps
- 700 kbps
- 1100 kbps

If you can?t see them in ndncon?s ?Active users? list, let me know, I?ll check the issue.

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/8dd7409a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scr.png
Type: image/png
Size: 64748 bytes
Desc: scr.png
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/8dd7409a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BD6DD4D1-01C4-4A46-8E59-47A7A82D1B33.jpeg
Type: image/jpeg
Size: 11655 bytes
Desc: BD6DD4D1-01C4-4A46-8E59-47A7A82D1B33.jpeg
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/8dd7409a/attachment.jpeg>

From jburke at remap.ucla.edu  Wed Mar  2 20:10:10 2016
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Thu, 3 Mar 2016 04:10:10 +0000
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
Message-ID: <4DCBF237-AFBE-415A-B37F-2BB872F15709@remap.ucla.edu>

Hi Ilya,
Thanks for pointing this out. I think it might be interesting still to try on a beefy machine with simple topologies (where we are still seeing issues) but will let Peter & others respond ...
Jeff

From: Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>>
Reply-To: Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>>
Date: Tuesday, March 1, 2016 at 11:36 AM
To: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC testing, next steps


Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and Table 1 of Mininet paper http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good choice for experiments that depend on precise timing.


Ilya

On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC.   I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat.   It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items.

Please reply within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

B. Remaining triage on last test

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

E. More NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]


Thanks!
Jeff







_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/401bbec2/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Mar  3 07:00:03 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 3 Mar 2016 08:00:03 -0700
Subject: [Nfd-dev] NFD call 20160303
Message-ID: <201603031500.u23F03qv020123@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/003a69f0/attachment.html>

From vslehman at memphis.edu  Thu Mar  3 08:40:17 2016
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Thu, 3 Mar 2016 16:40:17 +0000
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>
	<2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
Message-ID: <0F9B0549-2A03-46A5-BCB7-77CE235EC0EF@memphis.edu>

Hi Ilya,

Many of the concerns mentioned in section 5 of the Mininet paper about scheduling and performance are addressed in this paper: https://stacks.stanford.edu/file/druid:zk853sv3422/heller_thesis-augmented.pdf, and have been implemented in Mininet. But, the paper does recommend smaller experiments with lower bandwidth links in order to help guarantee accurate performance.

I?m unsure of the bandwidth requirements of NDN-RTC, but based on the paper, it would be best to limit the topology size in emulation as much as possible.

--
Vince Lehman

On Mar 1, 2016, at 2:22 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


For example, in Mininet, it is possible to see >150ms delays on 10 ms links, because either the host or guest operating system has decided that it was a good time to switch to another process.

In addition to that, Table 1 says that peak performance of Mininet with just 1 switch is ~500mbits, but NDN forwarder is much much slower than IP switch, and I guess you would like to have at least 3-5 nodes in the topology. I think that Mininet is good for testing chat applications, maybe routing protocols, but not for relatively high throughput apps.

On March 1, 2016 at 8:45 PM "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Ilya,

Can you elaborate a little what you mean by experiments that depend on precise timing?

Lan

On Mar 1, 2016, at 1:36 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and Table 1 of Mininet paper http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good choice for experiments that depend on precise timing.


Ilya

On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC.   I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat.   It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items.

Please reply within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

B. Remaining triage on last test

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

E. More NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]


Thanks!
Jeff







_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto: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<mailto: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<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/b11a459f/attachment.html>

From peter at remap.UCLA.EDU  Thu Mar  3 10:17:57 2016
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Thu, 3 Mar 2016 18:17:57 +0000
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <0F9B0549-2A03-46A5-BCB7-77CE235EC0EF@memphis.edu>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>
	<2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<0F9B0549-2A03-46A5-BCB7-77CE235EC0EF@memphis.edu>
Message-ID: <2061536A-5D37-482D-B243-35CE3C1DC7A0@remap.ucla.edu>

Hi Vince,


I?m unsure of the bandwidth requirements of NDN-RTC, but based on the paper, it would be best to limit the topology size in emulation as much as possible.


generally, one can generate as much traffic as she wants with NDN-RTC by configuring codecs for higher bitrates and/or having multiple streams.
though, the minimum requirement (calculated from fetching 1 audio stream) would be <http://redmine.named-data.net/issues/3478>  around 250 Kbit/s  (~40 Kbps interests and ~210 Kbps incoming audio stream).

--
Vince Lehman

On Mar 1, 2016, at 2:22 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


For example, in Mininet, it is possible to see >150ms delays on 10 ms links, because either the host or guest operating system has decided that it was a good time to switch to another process.

In addition to that, Table 1 says that peak performance of Mininet with just 1 switch is ~500mbits, but NDN forwarder is much much slower than IP switch, and I guess you would like to have at least 3-5 nodes in the topology. I think that Mininet is good for testing chat applications, maybe routing protocols, but not for relatively high throughput apps.

On March 1, 2016 at 8:45 PM "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Ilya,

Can you elaborate a little what you mean by experiments that depend on precise timing?

Lan

On Mar 1, 2016, at 1:36 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and Table 1 of Mininet paper http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good choice for experiments that depend on precise timing.


Ilya

On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC.   I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat.   It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items.

Please reply within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

B. Remaining triage on last test

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

E. More NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]


Thanks!
Jeff







_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/a1424808/attachment.html>

From lanwang at memphis.edu  Thu Mar  3 12:36:45 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 3 Mar 2016 20:36:45 +0000
Subject: [Nfd-dev] NDN-RTC testing, next steps
In-Reply-To: <2061536A-5D37-482D-B243-35CE3C1DC7A0@remap.ucla.edu>
References: <C3EBED33-C932-40D9-A2CC-3D244F7AEEA4@remap.ucla.edu>
	<920524554.1896.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<FC221BD8-3269-4DAF-B148-86AD6F12358B@memphis.edu>
	<2096085414.2005.1ac9714c-cc35-4a64-8e78-dfc8248549cc.open-xchange@office.mailbox.org>
	<0F9B0549-2A03-46A5-BCB7-77CE235EC0EF@memphis.edu>
	<2061536A-5D37-482D-B243-35CE3C1DC7A0@remap.ucla.edu>
Message-ID: <5CD6062A-B968-4794-8B7F-3241DC110A80@memphis.edu>



On Mar 3, 2016, at 12:17 PM, "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi Vince,


I?m unsure of the bandwidth requirements of NDN-RTC, but based on the paper, it would be best to limit the topology size in emulation as much as possible.


generally, one can generate as much traffic as she wants with NDN-RTC by configuring codecs for higher bitrates and/or having multiple streams.
though, the minimum requirement (calculated from fetching 1 audio stream) would be <http://redmine.named-data.net/issues/3478>  around 250 Kbit/s  (~40 Kbps interests and ~210 Kbps incoming audio stream).

The largest experiment we have run so far is on a 99-node topology, each node pinging 10 other nodes at 1pps with one different node failing every 180 seconds.  The ping traffic is 1900 ping packets/second (ping interest and data).  Assuming each path is 3 hops on average, that's about 5700 packets/second in total.  The failures generated about 4500 NLSR packets/second.  Together this is about 9200 packets/second for the experiment.

The spec of the machine: 32 cores ( 4 old AMD opteron 6136s 2.4GHz, iirc) with 64GB memory and virtually no disk space ( 50ish GB SSD ).

Lan

--
Vince Lehman

On Mar 1, 2016, at 2:22 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


For example, in Mininet, it is possible to see >150ms delays on 10 ms links, because either the host or guest operating system has decided that it was a good time to switch to another process.

In addition to that, Table 1 says that peak performance of Mininet with just 1 switch is ~500mbits, but NDN forwarder is much much slower than IP switch, and I guess you would like to have at least 3-5 nodes in the topology. I think that Mininet is good for testing chat applications, maybe routing protocols, but not for relatively high throughput apps.

On March 1, 2016 at 8:45 PM "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Ilya,

Can you elaborate a little what you mean by experiments that depend on precise timing?

Lan

On Mar 1, 2016, at 1:36 PM, Ilya Moiseenko <iliamo at mailbox.org<mailto:iliamo at mailbox.org>> wrote:


Hi Jeff,

Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and Table 1 of Mininet paper http://conferences.sigcomm.org/hotnets/2010/papers/a19-lantz.pdf

Mininet is a good tool for achieving protocol correctness, but it's not a good choice for experiments that depend on precise timing.


Ilya

On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

Below I summarize what I think are all of the issues and ideas raised last week about continuing the process of debugging NDN-RTC.   I've created redmine issues for each to aid tracking and am hoping to hand over to Peter the coordination process of checking in on all of these in the time between now and the retreat.   It would be great to get feedback from the NFD team on what they can help with - especially on the first few more immediate items.

Please reply within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

B. Remaining triage on last test

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

E. More NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]


Thanks!
Jeff







_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160303/7218bee6/attachment.html>

From jburke at remap.ucla.edu  Fri Mar  4 16:49:25 2016
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sat, 5 Mar 2016 00:49:25 +0000
Subject: [Nfd-dev] NDN-RTC testing roll-up for this week
Message-ID: <4FC918D7-17B1-48F3-B98B-65B7972E147F@remap.ucla.edu>


Hi folks,

Here are updates (in red) on NDN-RTC testing progress, as reported by Peter and John, and summarized to the best of my ability.

Thanks to everyone that has been working on this!!

Please correct inline or directly in the associated redmine issue.

Note that there are three existing issues with NFD/related tools which were recently identified as impacting NDN-RTC performance on the testbed. See B-4,5,6 below.

Thanks,
Jeff


Please add information within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

3/4 update:  March 9 test. Please review the redmine issue above and items below for some results and discussion since last week. As next week's seminar will be rescheduled, Peter will give an ndncon usage Q&A to generate traffic for the test.   Plans and results for this upcoming seminar will be tracked here: http://redmine.named-data.net/issues/3512  Peter requests 6 participants for now; please help... (I guess 5 plus Peter.)


2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3/4 update:  Junxiao and Alex will be the POCs.  Junxiao has requested access to REMAP test boxes, we are working on this.


3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

3/4 update:  Postponed until March 9.  Peter, can you please confirm that this is target for this? (I'm hoping we can keep moving on ARC support in parallel to other testing, without disturbing it.)


4. Testing ndncon sync behavior (added 3/4).  We are running tests to chase down and fix (prior to March 9) a potential issue with Chronosync use in ndncon that leads to high CPU load. See http://redmine.named-data.net/issues/3508.  "Given the current implementation, a problematic case could be when sync broadcast interest brings back data that does not result in digest root update (though this, by design, should not happen), and the same interest would be sent again, bringing back the same data thus causing the same interest to be sent again with no interval, and quickly flooding (only) the local NFD."


B. Triage on last tests

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  @Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

3/4 update: Progress on this issue is discussed in #3484<http://redmine.named-data.net/issues/3484>, and is described as a "design problem introduced with Dead Nonce List"  @Alex or @Junxiao, can you confirm any plan to resolve this?


2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3/4 update A: Example live stats capture by John: http://ndndemo.arl.wustl.edu/cacti/ (guest:ndnTest)

3/4 update B: Example of live stats capture by Peter here:
For the seminar-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/seminar-3-2-2016-overview
(guest:ndnguest)
Live for current ndn-rtc test streams-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/resources-monitor
(guest:ndnguest)
Next week will include outgoing Interest rate, incoming segments rate, incoming bitrate, consumer?s state (Chasing, Fetching, Adjusting, etc.), chasing time. Please contact Peter to add other stats.


3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

3/4 update: Completed. @Lixia or others from NFD team, let us know if you need more information.


As of 3/4, three new issues to triage:

4. Autoregistration / Backroute creation problem. There is a problem that causes backroutes to not be added reliably to the FIB when connecting a new client to the testbed. Please see this issue: http://redmine.named-data.net/issues/1968  and proposed solution: http://redmine.named-data.net/issues/2182   NFD folks, these tasks are unassigned ? can they be assigned? Is the release target of v0.5 correct? We need to do regular restarts of testbed hosts in the meantime to achieve proper functionality.

5. Access strategy assumptions fail for NDN-RTC traffic. Access strategy seems to flood NDN-RTC producers with interests for other producers  if they are connected to the same hub.  Please see issue http://redmine.named-data.net/issues/3219    This issue has been identified for five months and likely impacts NDN-RTC performance on the testbed, can it please be assigned and a release target given?

6. Best route strategy may still cause retransmissions by NDN-RTC.  The behavior similar to that documented in issue http://redmine.named-data.net/issues/3230 was being observed, visually on the testbed map, during the March 9 test, independently by two participants.  (See #3485 notes #9 and #13. http://redmine.named-data.net/issues/3485)   NFD team, please advise on how to test or resolve this in issue #3485, and/or reopen #3230 if necessary.)


C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

3/4 Update:  Updated with estimates by Peter. Please review.  Peter, please also comment on whether similar bandwidth was observed on March 2 and/or measure on March 9.


2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

3/4 Update:  Issue updated to describe design challenges. We will start design discussion next week.


3. Sync behavior.  High CPU load / local interest transmission may be caused sometimes by sync usage in ndncon.  See A-4 above.


D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

3/4 Update:  No response to issue; can NFD team consider it?


E. NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

3/4 Update:  Planned as a potential Hackathon project by Klaus (thanks!). (Preferred to #3) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3/4 Update: Ashlesh will take this on.  (Thanks!) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

3/4 Update:  Considered as a potential Hackathon project.


F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

3/4 Update: Some suggestions in redmine. No assignee yet.


G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

3/4 Update: Several people have asked for motivation for this.  I'll try to document/describe the motivation next week.


2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624

3/4 Update: Short-term approach planned as a hackathon project.



Thanks!
Jeff



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160305/24c1371a/attachment.html>

From shijunxiao at email.arizona.edu  Sun Mar  6 08:24:33 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 6 Mar 2016 09:24:33 -0700
Subject: [Nfd-dev] HOWTO reply to a review comment on Gerrit
Message-ID: <CAOFH+OZy0bewPfeDzvKBsfXj+A6FCKqMj4EJQOuETJ7_px3NBg@mail.gmail.com>

Dear folks

I'm asked for how to reply to a review comment on Gerrit, and here's the
procedure.

   1. Go to your Gerrit Change. The URI should look like
   http://gerrit.named-data.net/#/c/NN/ where NN is the Change number.
   2. Under "History" pane, tap "Expand All" button.
   3. Find the comment you want to reply to, and tap the line number to the
   left of that comment. This should display the file along with all comments.
   4. Find the comment, tap on the comment to expand it.
   5. Tap "Reply" button.
   6. In the multi-line textbox, enter your reply.
   7. Tap "Save" button. You can see that your reply is labelled "Draft",
   and at this moment only you can see it.
   8. Tap the up arrow on top-right corner under your name and photo. This
   takes you back to the Change.
   9. Repeat steps 2-8 if you need to reply to other comments.
   10. Tap "Reply..." button on top-center of the screen. A popup appears
   with a multi-line textbox on the top, and the list of your replies in the
   middle. Look through your replies and verify they are all accurate and
   display correctly. If you need to correct a mistake, tap the line number to
   the left of your reply, and repeat steps 4-10. If you need to delete a
   reply, tap "Discard" button instead of "Save" in step 7.
   11. If you want to write something that is applicable to the entire
   Change but not a specific file, you may write it on the multi-line textbox
   under "Reply..." button.
   12. After reviewing all your replies, tap "Post" button. Your replies
   are visible to other users only after "Post".

Many developers make the mistake of stopping at step 7, and thus their
replies aren't visible to others.

Gerrit comments do not use Markdown syntax, and I don't have a good
documentation on what's the syntax.
Some common structures can be written as:

   - To embed code in your comment, put two spaces in front of each line,
   and put a blank line before and after the code block.
   - To create an unordered list, put a "*" in front of each line, and put
   a blank line before and after the list.
   - Gerrit syntax does not seem to support ordered lists. To create an
   ordered list, use the unordered list structure, and put the number inside
   the list. In other words, the first item should start with "* 1.", the
   second item should start with "* 2.", etc.

Gerrit discussion should focus on the code itself. If you need to discuss
design, post such discussions to Redmine, where every post gets a "note-N"
link so it can be referenced easily.

This article is part of "HOWTOs for n00b" series. You may find other
articles in this series on NFD wiki
<http://redmine.named-data.net/projects/nfd/wiki> under developer resources.
Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160306/630e3e44/attachment.html>

From jburke at remap.UCLA.EDU  Sun Mar  6 08:46:02 2016
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sun, 6 Mar 2016 16:46:02 +0000
Subject: [Nfd-dev] NDN-RTC testing roll-up for this week (update 3/6)
Message-ID: <95378A1C-0717-4C44-B179-172C9DD2B6F3@remap.ucla.edu>


Hi folks,
Sorry for sending this again so soon, but this update includes an important issue related to the testbed certs.  All sites and users should update expired certificates.  Updates for today, below, are in red.
Thanks,
Jeff


Please add information within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

3/4 update:  March 9 test. Please review the redmine issue above and items below for some results and discussion since last week. As next week's seminar will be rescheduled, Peter will give an ndncon usage Q&A to generate traffic for the test.   Plans and results for this upcoming seminar will be tracked here: http://redmine.named-data.net/issues/3512 Peter requests 6 participants for now; please help... (I guess 5 plus Peter.)

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3/4 update:  Junxiao and Alex will be the POCs.  Junxiao has requested access to REMAP test boxes, we are working on this.


3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

3/4 update:  Postponed until March 9.  Peter, can you please confirm that this is target for this? (I'm hoping we can keep moving on ARC support in parallel to other testing, without disturbing it.)


4. Testing ndncon sync behavior.  We are running tests to chase down and fix (prior to March 9) a potential issue with Chronosync use in ndncon that leads to high CPU load. See http://redmine.named-data.net/issues/3508.  "Given the current implementation, a problematic case could be when sync broadcast interest brings back data that does not result in digest root update (though this, by design, should not happen), and the same interest would be sent again, bringing back the same data thus causing the same interest to be sent again with no interval, and quickly flooding (only) the local NFD."

5. Always available NDN-RTC test producers.   The following test producers should always be available, should anyone want to test ndn-rtc:  /ndn/edu/ucla/remap/freeculture and /ndn/edu/ucla/remap/test.  See   http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-March/001598.html for details.


B. Triage on last tests

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

3/4 update: Progress on this issue is discussed in #3484<http://redmine.named-data.net/issues/3484>, and is described as a "design problem introduced with Dead Nonce List"

3/6 update: According to Thursday's NFD call, Junxiao plans to fix in next release (v0.5).  Given the ongoing ndn-rtc testing, any chance we can push this and other NFD bug fixes to the testbed sooner than the retreat?


2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3/4 update A: Example live stats capture by John: http://ndndemo.arl.wustl.edu/cacti/ (guest:ndnTest)

3/4 update B: Example of live stats capture by Peter here:
For the seminar-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/seminar-3-2-2016-overview
(guest:ndnguest)
Live for current ndn-rtc test streams-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/resources-monitor
(guest:ndnguest)
Next week will include outgoing Interest rate, incoming segments rate, incoming bitrate, consumer?s state (Chasing, Fetching, Adjusting, etc.), chasing time. Please contact Peter to add other stats.


3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

3/4 update: Completed. @Lixia or others from NFD team, let us know if you need more information.


As of 3/4, three new issues to triage:

4. Autoregistration / Backroute creation problem. There is a problem that causes backroutes to not be added reliably to the FIB when connecting a new client to the testbed. Please see this issue: http://redmine.named-data.net/issues/1968  and proposed solution: http://redmine.named-data.net/issues/2182   NFD folks, these tasks are unassigned ? can they be assigned? Is the release target of v0.5 correct? We need to do regular restarts of testbed hosts in the meantime to achieve proper functionality.

3/6 update: Blocked by http://redmine.named-data.net/issues/3274, which Yingdi is now working on.  Can a due date for this be set?  Can it be issued as a bug fix prior to v0.5 release and used on the testbed?

5. Access strategy assumptions fail for NDN-RTC traffic. Access strategy seems to flood NDN-RTC producers with interests for other producers  if they are connected to the same hub.  Please see issue http://redmine.named-data.net/issues/3219    This issue has been identified for five months and likely impacts NDN-RTC performance on the testbed, can it please be assigned and a release target given?

3/6 update:  In #3513, a solution is proposed to revise the application to use "auto prefix propagation", but this depends on 1) each user having a valid cert (which may require new cert requests, see B-7 below), 2) an application namespace change (C-4), and 3) availability of auto prefix propagation, which is described in a currently unpublished memo, uploaded to the issue.  (Can someone confirm deployment status?) http://redmine.named-data.net/issues/3513

6. Best route strategy may still cause retransmissions by NDN-RTC. The behavior similar to that documented in issue http://redmine.named-data.net/issues/3230 was being observed, visually on the testbed map, during the March 9 test, independently by two participants.  (See #3485 notes #9 and #13. http://redmine.named-data.net/issues/3485)   NFD team, please advise on how to test or resolve this in issue #3485, and/or reopen #3230 if necessary.)

7. Need everyone to update expired site and user certs.  Though not yet a dependency of NDN-RTC, current user and testbed  site certificates are needed for the proposed solution to B-5 above, and generally part of the plan for security experimentation on the testbed.  Opened http://redmine.named-data.net/issues/3515  to track.   See Operators list threads "site key expiring<http://lists.named-data.net/mailman/private/operators/2016-January/000996.html>" - site signing mechanisms are ready and John will be updating them.  Peter can include instructions for user cert updates in next ndncon application prep.


C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

3/4 Update:  Updated with estimates by Peter. Please review.  Peter, please also comment on whether similar bandwidth was observed on March 2 and/or measure on March 9.


2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

3/4 Update:  Issue updated to describe design challenges. We will start design discussion next week.

3/6 Update: Should this be a hackathon project?

3. Sync behavior.  High CPU load / local interest transmission may be caused sometimes by sync usage in ndncon.  See A-4 above.

4. Update application namespace.  To work around access strategy problem (B-5), the NDN-RTC prefix should be changed from /site/ndnrtc/user to /site/user/ndnrtc.  http://redmine.named-data.net/issues/3513   Multicast conference discovery traffic will still happen in /ndn/broadcast or equivalent, I assume.  Peter, can we change this before the test on Wednesday?

5. Decrease delay.   Beichuan notes in the 3/1 NFD call that there is "more of a delay" than WebEx. This is a known issue.  Peter, we discussed some of the causes of additional delay in Osaka.  As time allows amidst other testing, we should expose parameters that make it easy to tune the pipeline size, retransmission, FEC, etc. to achieve lower delay.  Tracked in http://redmine.named-data.net/issues/3516


D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

3/4 Update:  No response to issue; can NFD team consider it?


E. NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

3/4 Update:  Planned as a potential Hackathon project by Klaus (thanks!). (Preferred to #3) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3/4 Update: Ashlesh will take this on.  (Thanks!) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

3/4 Update:  Considered as a potential Hackathon project.


F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

3/4 Update: Some suggestions in redmine. No assignee yet.


G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

3/4 Update: Several people have asked for motivation for this.  I'll try to document/describe the motivation next week.


2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624

3/4 Update: Short-term approach planned as a hackathon project.

3/6 Update: Klaus asks for input on his congestion control proposal. Now attached to issue #1624.



Thanks!
Jeff



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160306/60d233f4/attachment.html>

From jdd at wustl.EDU  Sun Mar  6 12:15:23 2016
From: jdd at wustl.EDU (Dehart, John)
Date: Sun, 6 Mar 2016 20:15:23 +0000
Subject: [Nfd-dev] NDN-RTC testing roll-up for this week (update 3/6)
In-Reply-To: <95378A1C-0717-4C44-B179-172C9DD2B6F3@remap.ucla.edu>
References: <95378A1C-0717-4C44-B179-172C9DD2B6F3@remap.ucla.edu>
Message-ID: <371E9531-3410-466A-9121-808CCC87E0FC@wustl.edu>


All:

I will be working through updating the site certificates and then will alert everyone
that it is time to update the user certs.

John

On Mar 6, 2016, at 10:46 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi folks,
Sorry for sending this again so soon, but this update includes an important issue related to the testbed certs.  All sites and users should update expired certificates.  Updates for today, below, are in red.
Thanks,
Jeff


Please add information within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. March 2 seminar. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

3/4 update:  March 9 test. Please review the redmine issue above and items below for some results and discussion since last week. As next week's seminar will be rescheduled, Peter will give an ndncon usage Q&A to generate traffic for the test.   Plans and results for this upcoming seminar will be tracked here: http://redmine.named-data.net/issues/3512 Peter requests 6 participants for now; please help... (I guess 5 plus Peter.)

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3/4 update:  Junxiao and Alex will be the POCs.  Junxiao has requested access to REMAP test boxes, we are working on this.


3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

3/4 update:  Postponed until March 9.  Peter, can you please confirm that this is target for this? (I'm hoping we can keep moving on ARC support in parallel to other testing, without disturbing it.)


4. Testing ndncon sync behavior.  We are running tests to chase down and fix (prior to March 9) a potential issue with Chronosync use in ndncon that leads to high CPU load. See http://redmine.named-data.net/issues/3508.  "Given the current implementation, a problematic case could be when sync broadcast interest brings back data that does not result in digest root update (though this, by design, should not happen), and the same interest would be sent again, bringing back the same data thus causing the same interest to be sent again with no interval, and quickly flooding (only) the local NFD."

5. Always available NDN-RTC test producers.   The following test producers should always be available, should anyone want to test ndn-rtc:  /ndn/edu/ucla/remap/freeculture and /ndn/edu/ucla/remap/test.  See   http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-March/001598.html for details.


B. Triage on last tests

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

3/4 update: Progress on this issue is discussed in #3484<http://redmine.named-data.net/issues/3484>, and is described as a "design problem introduced with Dead Nonce List"

3/6 update: According to Thursday's NFD call, Junxiao plans to fix in next release (v0.5).  Given the ongoing ndn-rtc testing, any chance we can push this and other NFD bug fixes to the testbed sooner than the retreat?


2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3/4 update A: Example live stats capture by John: http://ndndemo.arl.wustl.edu/cacti/ (guest:ndnTest)

3/4 update B: Example of live stats capture by Peter here:
For the seminar-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/seminar-3-2-2016-overview
(guest:ndnguest)
Live for current ndn-rtc test streams-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/resources-monitor
(guest:ndnguest)
Next week will include outgoing Interest rate, incoming segments rate, incoming bitrate, consumer?s state (Chasing, Fetching, Adjusting, etc.), chasing time. Please contact Peter to add other stats.


3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

3/4 update: Completed. @Lixia or others from NFD team, let us know if you need more information.


As of 3/4, three new issues to triage:

4. Autoregistration / Backroute creation problem. There is a problem that causes backroutes to not be added reliably to the FIB when connecting a new client to the testbed. Please see this issue: http://redmine.named-data.net/issues/1968  and proposed solution: http://redmine.named-data.net/issues/2182   NFD folks, these tasks are unassigned ? can they be assigned? Is the release target of v0.5 correct? We need to do regular restarts of testbed hosts in the meantime to achieve proper functionality.

3/6 update: Blocked by http://redmine.named-data.net/issues/3274, which Yingdi is now working on.  Can a due date for this be set?  Can it be issued as a bug fix prior to v0.5 release and used on the testbed?

5. Access strategy assumptions fail for NDN-RTC traffic. Access strategy seems to flood NDN-RTC producers with interests for other producers  if they are connected to the same hub.  Please see issue http://redmine.named-data.net/issues/3219    This issue has been identified for five months and likely impacts NDN-RTC performance on the testbed, can it please be assigned and a release target given?

3/6 update:  In #3513, a solution is proposed to revise the application to use "auto prefix propagation", but this depends on 1) each user having a valid cert (which may require new cert requests, see B-7 below), 2) an application namespace change (C-4), and 3) availability of auto prefix propagation, which is described in a currently unpublished memo, uploaded to the issue.  (Can someone confirm deployment status?) http://redmine.named-data.net/issues/3513

6. Best route strategy may still cause retransmissions by NDN-RTC. The behavior similar to that documented in issue http://redmine.named-data.net/issues/3230 was being observed, visually on the testbed map, during the March 9 test, independently by two participants.  (See #3485 notes #9 and #13. http://redmine.named-data.net/issues/3485)   NFD team, please advise on how to test or resolve this in issue #3485, and/or reopen #3230 if necessary.)

7. Need everyone to update expired site and user certs.  Though not yet a dependency of NDN-RTC, current user and testbed  site certificates are needed for the proposed solution to B-5 above, and generally part of the plan for security experimentation on the testbed.  Opened http://redmine.named-data.net/issues/3515  to track.   See Operators list threads "site key expiring<http://lists.named-data.net/mailman/private/operators/2016-January/000996.html>" - site signing mechanisms are ready and John will be updating them.  Peter can include instructions for user cert updates in next ndncon application prep.


C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

3/4 Update:  Updated with estimates by Peter. Please review.  Peter, please also comment on whether similar bandwidth was observed on March 2 and/or measure on March 9.


2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

3/4 Update:  Issue updated to describe design challenges. We will start design discussion next week.

3/6 Update: Should this be a hackathon project?

3. Sync behavior.  High CPU load / local interest transmission may be caused sometimes by sync usage in ndncon.  See A-4 above.

4. Update application namespace.  To work around access strategy problem (B-5), the NDN-RTC prefix should be changed from /site/ndnrtc/user to /site/user/ndnrtc.  http://redmine.named-data.net/issues/3513   Multicast conference discovery traffic will still happen in /ndn/broadcast or equivalent, I assume.  Peter, can we change this before the test on Wednesday?

5. Decrease delay.   Beichuan notes in the 3/1 NFD call that there is "more of a delay" than WebEx. This is a known issue.  Peter, we discussed some of the causes of additional delay in Osaka.  As time allows amidst other testing, we should expose parameters that make it easy to tune the pipeline size, retransmission, FEC, etc. to achieve lower delay.  Tracked in http://redmine.named-data.net/issues/3516


D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

3/4 Update:  No response to issue; can NFD team consider it?


E. NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

3/4 Update:  Planned as a potential Hackathon project by Klaus (thanks!). (Preferred to #3) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3/4 Update: Ashlesh will take this on.  (Thanks!) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

3/4 Update:  Considered as a potential Hackathon project.


F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

3/4 Update: Some suggestions in redmine. No assignee yet.


G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

3/4 Update: Several people have asked for motivation for this.  I'll try to document/describe the motivation next week.


2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624

3/4 Update: Short-term approach planned as a hackathon project.

3/6 Update: Klaus asks for input on his congestion control proposal. Now attached to issue #1624.



Thanks!
Jeff



_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160306/9ee571fe/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Mar  8 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 8 Mar 2016 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20160308
Message-ID: <201603081500.u28F02s7010711@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160308/b998c4c9/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Mar 10 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 10 Mar 2016 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20160310
Message-ID: <201603101500.u2AF02VC009318@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160310/75c79f70/attachment.html>

From zhuhongchen at bit.edu.cn  Thu Mar 10 19:26:31 2016
From: zhuhongchen at bit.edu.cn (zhuhongchen)
Date: Fri, 11 Mar 2016 11:26:31 +0800
Subject: [Nfd-dev] something about ndn-tools on github
Message-ID: <160311112631042469003355@bit.edu.cn>

Hi,
Recently, I downloaded codes for ndn-tools on GitHub, however something went wrong when compiling, may someone can fix it please.
ps :The code I used is downloaded is the newest one which updated 5 hours ago.



Best
zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160311/a10df543/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.png
Type: image/png
Size: 162196 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160311/a10df543/attachment.png>

From aa at CS.UCLA.EDU  Thu Mar 10 19:57:46 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 10 Mar 2016 19:57:46 -0800
Subject: [Nfd-dev] something about ndn-tools on github
In-Reply-To: <160311112631042469003355@bit.edu.cn>
References: <160311112631042469003355@bit.edu.cn>
Message-ID: <29363D76-A952-4A0E-8281-506638D73D8A@cs.ucla.edu>

Dear Zhu,

I think you're using a rather old version of ndn-cxx library (before the latest release).  To compile master branch of ndn-tools, it is better to use the master branch of ndn-cxx library.

--
Alex

> On Mar 10, 2016, at 7:26 PM, zhuhongchen <zhuhongchen at bit.edu.cn> wrote:
> 
> Hi,
> Recently, I downloaded codes for ndn-tools on GitHub, however something went wrong when compiling, may someone can fix it please.
> ps :The code I used is downloaded is the newest one which updated 5 hours ago.
> <error.png>
> 
> 
> Best
> zhu_______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160310/660beca0/attachment.bin>

From zhuhongchen at bit.edu.cn  Fri Mar 11 04:59:39 2016
From: zhuhongchen at bit.edu.cn (zhuhongchen)
Date: Fri, 11 Mar 2016 20:59:39 +0800
Subject: [Nfd-dev] something about ndn-tools on github
In-Reply-To: <29363D76-A952-4A0E-8281-506638D73D8A@cs.ucla.edu>
References: <160311112631042469003355@bit.edu.cn>
	<29363D76-A952-4A0E-8281-506638D73D8A@cs.ucla.edu>
Message-ID: <160311205939356614007108@bit.edu.cn>

Dear Alex,

Yes, it works. Thank you for this help

Zhu
----------------
  

---------- Origin message ----------
>From?"Alex Afanasyev" <aa at cs.ucla.edu>
>To?"zhuhongchen" <zhuhongchen at bit.edu.cn>
>Subject?Re: [Nfd-dev] something about ndn-tools on github
>Date?2016-03-11 11:57:46
 Dear Zhu,

I think you're using a rather old version of ndn-cxx library (before the latest release). To compile master branch of ndn-tools, it is better to use the master branch of ndn-cxx library.

--
Alex

> On Mar 10, 2016, at 7:26 PM, zhuhongchen <zhuhongchen at bit.edu.cn> wrote:
>
> Hi,
> Recently, I downloaded codes for ndn-tools on GitHub, however something went wrong when compiling, may someone can fix it please.
> ps :The code I used is downloaded is the newest one which updated 5 hours ago.
> <error.png>
>
>
> Best
> zhu_______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160311/25bd99ef/attachment.html>

From jburke at remap.UCLA.edu  Sun Mar 13 17:45:33 2016
From: jburke at remap.UCLA.edu (Burke, Jeff)
Date: Mon, 14 Mar 2016 00:45:33 +0000
Subject: [Nfd-dev] NDN-RTC testing roll-up for this week (update 3/13)
Message-ID: <DE1EF3D4-F6CD-43B9-B6C2-41EFC4557863@remap.ucla.edu>


Hi folks,

Here's the roll-up of ongoing activity related to NDN-RTC.  Please take a look and update / correct anything omitted here or in the related redmine issues.

We will do another test during the seminar. Peter and John may be in touch to recruit help. In general, please make sure to update your version of NdnCon before participating in any tests and, as site / user certificates have expired and rollover is not yet in place, please get your new user certificate here: http://ndncert.named-data.net/  and install prior to using NdnCon again.

Thanks!
Jeff

--

Please add information within the appropriate redmine issue, if possible, rather than by email.

A. Next tests

1. Seminar tests.

March 2 test. Christos will give the next seminar on March 2.  Anyone at ColoState that might be able to provide support to him in running both NDN-RTC and WebEx at the same time?  Peter, can you follow up with Christos and Steve as a starting point, and try to push a new version of NDN-RTC with any things that we want to test?  My suggestion is also to provide only one bandwidth option for each stream, so we see uniform requests across all nodes.   http://redmine.named-data.net/issues/3485

3/4 update:  March 9 test. Please review the redmine issue above and items below for some results and discussion since last week. As next week's seminar will be rescheduled, Peter will give an ndncon usage Q&A to generate traffic for the test.   Plans and results for this upcoming seminar will be tracked here: http://redmine.named-data.net/issues/3512 Peter requests 6 participants for now; please help... (I guess 5 plus Peter.)

3/13 update: March 9 performance was not good (see #3512) ? choppy audio, with two probable causes: CPU load of the producer and impact of multiple consumers of the same stream (perhaps strategy issue).  Subsequent tests with a smaller number of consumers (http://redmine.named-data.net/issues/3526) did not replicate the problem; plan is to continue isolated tests in addition to seminar tests.

3/13 update:  We will test again during the March 16 seminar, with continued bugfixes and updates
(#3538<http://redmine.named-data.net/issues/3538>, #3536<http://redmine.named-data.net/issues/3536>, #3535<http://redmine.named-data.net/issues/3535>, #3532<http://redmine.named-data.net/issues/3532>, #3531<http://redmine.named-data.net/issues/3531>) in the meantime.   Tracked here: http://redmine.named-data.net/issues/3549

2. Test plan. Peter proposes to put together a methodical testing strategy, using the seminars and other regular meetings as tests of NDN-RTC.  John is already helping with this.  We would like a single point of contact from the NFD team to act as a liaison for this, and help get questions answers / design an approach.  Who should it be?    http://redmine.named-data.net/issues/3487

3/4 update:  Junxiao and Alex will be the POCs.  Junxiao has requested access to REMAP test boxes, we are working on this.

3. Enable ARC detectors.  Peter, I know that we are not ready for incorporating ARC support, and it's not likely to solve current problems, but I'm wondering if we could include the congestion detection mechanism and log its behavior, just to see how it does?   http://redmine.named-data.net/issues/3488

3/4 update:  Postponed until March 9.  Peter, can you please confirm that this is target for this? (I'm hoping we can keep moving on ARC support in parallel to other testing, without disturbing it.)

3/13 update:  Still postponed until other issues addressed.

4. Testing ndncon sync behavior.  We are running tests to chase down and fix (prior to March 9) a potential issue with Chronosync use in ndncon that leads to high CPU load. See http://redmine.named-data.net/issues/3508.  "Given the current implementation, a problematic case could be when sync broadcast interest brings back data that does not result in digest root update (though this, by design, should not happen), and the same interest would be sent again, bringing back the same data thus causing the same interest to be sent again with no interval, and quickly flooding (only) the local NFD."

3/13 update: Fixed. http://redmine.named-data.net/issues/3508  Please make sure to update your version of NdnCon before participating in any tests.

5. Always available NDN-RTC test producers.   The following test producers should always be available, should anyone want to test ndn-rtc:  /ndn/edu/ucla/remap/freeculture and /ndn/edu/ucla/remap/test.  See   http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-March/001598.html for details.


B. Triage on last tests

1. PIT / name-tree entries.  After the test on Wednesday, the REMAP node contained nNameTreeEntries=96278, nPitEntries=52185. Can someone help us figure out what they are / what caused them so we can try to mitigate?  Or, provide instrumentation to do this after the next test on this coming Wednesday?    http://redmine.named-data.net/issues/3484  Peter, please let us know what the maximum Interest Lifetime is in NDN-RTC packets ASAP; respond in the redmine thread.

3/4 update: Progress on this issue is discussed in #3484<http://redmine.named-data.net/issues/3484>, and is described as a "design problem introduced with Dead Nonce List"

3/6 update: According to Thursday's NFD call, Junxiao plans to fix in next release (v0.5).  Given the ongoing ndn-rtc testing, any chance we can push this and other NFD bug fixes to the testbed sooner than the retreat?

3/13 update. Fix merged per http://redmine.named-data.net/issues/3484.  @John / Peter, any reason to update REMAP node or any other test nodes to check?

2. Capture of NFD parameters during the test.  John, is it possible to do periodic capture of stats like the above ? perhaps every few seconds per node? (Or do you already do that?)   This would be useful in evaluating these tests and also looking for relevant behavior during the test.  Assignee: WUSTL?  http://redmine.named-data.net/issues/3486

3/4 update A: Example live stats capture by John: http://ndndemo.arl.wustl.edu/cacti/ (guest:ndnTest)

3/4 update B: Example of live stats capture by Peter here:
For the seminar-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/seminar-3-2-2016-overview
(guest:ndnguest)
Live for current ndn-rtc test streams-
http://ec2-52-91-190-26.compute-1.amazonaws.com:3000/dashboard/db/resources-monitor
(guest:ndnguest)
Next week will include outgoing Interest rate, incoming segments rate, incoming bitrate, consumer?s state (Chasing, Fetching, Adjusting, etc.), chasing time. Please contact Peter to add other stats.

3/13 update: Stats now tracked in related redmine issues, live links available as well.  @John ? Peter asks if it might be possible to log NFD statistics into the same DB he is using for NDN stats.  He'll contact you about this.

3. NDN-RTC: Summarize results of internal testing.  Peter, folks need to understand better what we think should work based on the testing you and Jiachen did.  Perhaps summarize in bullet-point format what we've learned / observed so far, and where we think there are issues. Assignee: Peter.  Due: ASAP.  http://redmine.named-data.net/issues/3483

3/4 update: Completed. @Lixia or others from NFD team, let us know if you need more information.

4. Autoregistration / Backroute creation problem. There is a problem that causes backroutes to not be added reliably to the FIB when connecting a new client to the testbed. Please see this issue: http://redmine.named-data.net/issues/1968  and proposed solution: http://redmine.named-data.net/issues/2182   NFD folks, these tasks are unassigned ? can they be assigned? Is the release target of v0.5 correct? We need to do regular restarts of testbed hosts in the meantime to achieve proper functionality.

3/6 update: Blocked by http://redmine.named-data.net/issues/3274, which Yingdi is now working on.  Can a due date for this be set?  Can it be issued as a bug fix prior to v0.5 release and used on the testbed?

3/13 update:  Prerequisites completed, #2182<http://redmine.named-data.net/issues/2182> is now in code review with active discussion.

5. Access strategy assumptions fail for NDN-RTC traffic. Access strategy seems to flood NDN-RTC producers with interests for other producers  if they are connected to the same hub.  Please see issue http://redmine.named-data.net/issues/3219    This issue has been identified for five months and likely impacts NDN-RTC performance on the testbed, can it please be assigned and a release target given?

3/6 update:  In #3513, a solution is proposed to revise the application to use "auto prefix propagation", but this depends on 1) each user having a valid cert (which may require new cert requests, see B-7 below), 2) an application namespace change (C-4), and 3) availability of auto prefix propagation, which is described in a currently unpublished memo, uploaded to the issue.  (Can someone confirm deployment status?) http://redmine.named-data.net/issues/3513

3/13 update: Peter still needs to to update app namespace (#3513<http://redmine.named-data.net/issues/3513>). He'll look at it first thing on Monday and see if it can be completed for Wednesday test.  (Headless consumer/producer is top priority.)

6. Best route strategy may still cause retransmissions by NDN-RTC. The behavior similar to that documented in issue http://redmine.named-data.net/issues/3230 was being observed, visually on the testbed map, during the March 9 test, independently by two participants.  (See #3485 notes #9 and #13. http://redmine.named-data.net/issues/3485)   NFD team, please advise on how to test or resolve this in issue #3485, and/or reopen #3230 if necessary.)

3/13 update:  Junxiao indicates in #3230<http://redmine.named-data.net/issues/3230> that if this is indeed an issue and we need to alter suppression timing, it should come after NDNLP2 improvements to link reliability to be completed in ~4 months.  @Peter, for now, perhaps we can try to verify that this is indeed causing problems ? tracked here  http://redmine.named-data.net/issues/3551

7. Need everyone to update expired site and user certs.  Though not yet a dependency of NDN-RTC, current user and testbed  site certificates are needed for the proposed solution to B-5 above, and generally part of the plan for security experimentation on the testbed.  Opened http://redmine.named-data.net/issues/3515  to track.   See Operators list threads "site key expiring<http://lists.named-data.net/mailman/private/operators/2016-January/000996.html>" - site signing mechanisms are ready and John will be updating them.  Peter can include instructions for user cert updates in next ndncon application prep.

3/13 update:  Site certs have been reissued, per John DeHart's recent email to the operators list. http://redmine.named-data.net/issues/3515  has been closed. Users should re-request certs and install prior to continued use of NdnCon.  http://ndncert.named-data.net/


C. Application issues

1. NDN-RTC: Bandwidth performance.  Significantly higher bandwidth than expected was observed during the test, and higher than I remember from previous versions. Peter, can you let us know to expect for a given stream (in both directions), and breakdown in percentages with its major contributions are?  Also, you may wish to change the menu options to reflect both the media bitrate and the estimated total network traffic so people know what to expect.  Assignee: Peter  Due: Before next seminar.  http://redmine.named-data.net/issues/3478

3/4 Update:  Updated with estimates by Peter. Please review.  Peter, please also comment on whether similar bandwidth was observed on March 2 and/or measure on March 9.


2. NDN-RTC: Silence suppression. Several people noted that silence suppression should be incorporate so that audio fetching from silent participants is reduced/eliminated, potentially reducing PIT and CPU load.  (We have discussed this before. Though this is an optimization, we should consider fixing it to remove this critique.  This optimization should be something that can be turned on/off in the GUI.)   Assignee: Peter  Due: Perhaps before retreat  http://redmine.named-data.net/issues/3477

3/4 Update:  Issue updated to describe design challenges. We will start design discussion next week.

3/6 Update: Should this be a hackathon project?

3/13 Update: Elected not to submit as hackathon project ? focus on simulation/emulation support.  However, Peter will sketch out a design to discuss at the retreat, this week.

3. Sync behavior.  High CPU load / local interest transmission may be caused sometimes by sync usage in ndncon.  See A-4 above.

4. Update application namespace.  To work around access strategy problem (B-5), the NDN-RTC prefix should be changed from /site/ndnrtc/user to /site/user/ndnrtc.  http://redmine.named-data.net/issues/3513   Multicast conference discovery traffic will still happen in /ndn/broadcast or equivalent, I assume.  Peter, can we change this before the test on Wednesday?

3/13 Update: Targeting completion for this week's demo, if possible, though headless producer/consumer is priority.

5. Decrease delay.   Beichuan notes in the 3/1 NFD call that there is "more of a delay" than WebEx. This is a known issue.  Peter, we discussed some of the causes of additional delay in Osaka.  As time allows amidst other testing, we should expose parameters that make it easy to tune the pipeline size, retransmission, FEC, etc. to achieve lower delay.  Tracked in http://redmine.named-data.net/issues/3516


D. NFD performance

The previous section are performance optimizations.  We can do them, but have to know our target:

1. NFD/Testbed ? Acceptable target bandwidth. Even with inefficiencies in the application, the nominal bandwidths that were observed (~100-500 kbyte/sec) should be reasonable on the university networks and nodes in questions.  Given that we are being advised to optimize the app, can someone please advise on what are appropriate target bandwidths for the current NFDs running on the current testbed?  http://redmine.named-data.net/issues/3482

3/4 Update:  No response to issue; can NFD team consider it?


E. NDN-RTC evaluation tools

I really hope that we don't have to wait to the hackathon to make progress. Peter (and perhaps Zhehao or Jeff) can help get NDN-RTC running with the simulation/emulation environment desired by the NFD team, just let us know which of these should be targeted first.

1. Simulation: Real app.  Klaus and others would like to be able to simulate NDN-RTC traffic.  Junxiao suggests that ns3 can support external traffic. I'm not sure if this is what Junxiao was referring to, but here's a HOWTO - https://www.nsnam.org/wiki/HOWTO_make_ns?3_interact_with_the_real_world<https://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world>.     http://redmine.named-data.net/issues/3479

3/4 Update:  Planned as a potential Hackathon project by Klaus (thanks!). (Preferred to #3) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


2. Emulation.  In addition, it was discussed that NDN-RTC could be run with the Mini-NDN emulation environment. This seems feasible. Does someone from the NFD team want to try, this perhaps in the context of figuring out NFD PIT growth issue?    https://github.com/named-data/mini-ndn   http://redmine.named-data.net/issues/3481

3/4 Update: Ashlesh will take this on.  (Thanks!) Dependent on completion of NDN-RTC headless producer/consumer, targeted for next week, tracked in http://redmine.named-data.net/issues/3509.


3. Simulation: traffic generator.  If the above is not feasible, Lixia suggests a simple traffic generator could also be written.  (See 2/26 17:26 message).   http://redmine.named-data.net/issues/3480

3/4 Update:  Considered as a potential Hackathon project.

3/13 Update:  Apparently this was not submitted as a hackathon project, given that we're pursuing the other two options.

F. Debugging support

1. NFD Instrumentation.  Though it might take time to add, perhaps we can brainstorm about what instrumentation for NFD would help with debugging these types of applications, and perhaps come up with short-term ways to achieve it.  Could the NFD team contribute ideas to this and Peter, can you add notes to this on an ongoing basses about what might be useful for NDN-RTC?)   http://redmine.named-data.net/issues/3476

3/4 Update: Some suggestions in redmine. No assignee yet.


G. Design challenges / Useful mechanisms

1. Prioritization.  For both audio and eventually scalable video traffic, NDN-RTC could make use of the type of one-hop priority mechanism discussed briefly with Van a year or so ago.  Can we pursue design and discussion of this?  http://redmine.named-data.net/issues/3475  [If a design is sketched in the next few weeks, could a trial implementation be a hackathon project?]

3/4 Update: Several people have asked for motivation for this.  I'll try to document/describe the motivation next week.

3/13 Update:  Aim to discuss at retreat.

2. Congestion control work continues in parallel by Klaus.  Lixia suggests that NDN-RTC specific CC mechanisms are not needed, and asked Klaus for a schedule of the work that he plans.  Klaus, could you let us know this in the redmine issue,  http://redmine.named-data.net/issues/1624

3/4 Update: Short-term approach planned as a hackathon project.

3/6 Update: Klaus asks for input on his congestion control proposal. Now attached to issue #1624.

3/13 Update: Klaus asks for input...

Thanks!
Jeff



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160314/f33dc9f5/attachment.html>

From 121049189 at qq.com  Sun Mar 13 19:43:09 2016
From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=)
Date: Mon, 14 Mar 2016 10:43:09 +0800
Subject: [Nfd-dev] file transger
Message-ID: <tencent_761458725F64AFB159B0B68E@qq.com>

Dear all,
    I've been running NFD, nfd-start successfully, and could nfdc register /ndn udp://www.bupt.edu.cn   
     as your order, I could apps, but I don't know what to do with  https://github.com/named-data/ndn-tools/tree/master/tools/chunks
how could I run in ubuntu12.04


------------------
----------------------------------------------------
???
?????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160314/feb602ec/attachment.html>

From aa at CS.UCLA.EDU  Sun Mar 13 21:40:55 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Sun, 13 Mar 2016 21:40:55 -0700
Subject: [Nfd-dev] file transger
In-Reply-To: <tencent_761458725F64AFB159B0B68E@qq.com>
References: <tencent_761458725F64AFB159B0B68E@qq.com>
Message-ID: <A1FB8D85-92C4-4E1D-8A51-100308B09BE1@cs.ucla.edu>


> On Mar 13, 2016, at 7:43 PM, ??? <121049189 at qq.com> wrote:
> 
>> Dear all,
>>     I've been running NFD, nfd-start successfully, and could nfdc register /ndn udp://www.bupt.edu.cn
>>      as your order, I could apps, but I don't know what to do with  https://github.com/named-data/ndn-tools/tree/master/tools/chunks
>> how could I run in ubuntu12.04

What exactly you want to achieve and what the problem you're facing?  You don't have the tool installed or don't know how to use it?

---
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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160313/159be6a4/attachment.bin>

From urs.schnurrenberger at unibas.ch  Mon Mar 14 03:59:01 2016
From: urs.schnurrenberger at unibas.ch (Urs Schnurrenberger)
Date: Mon, 14 Mar 2016 10:59:01 +0000
Subject: [Nfd-dev] NFD on Ubuntu 15.10?
Message-ID: <4DE5E8A1E5827142BA60833545E63269848A3875@urz-mbx-1.urz.unibas.ch>

Dear all,

I followed the steps on http://named-data.net/doc/NFD/current/INSTALL.html#install-nfd-using-the-ndn-ppa-repository-on-ubuntu-linux and ended up here:

~$ sudo apt-get update
[...]
W: Failed to fetch http://ppa.launchpad.net/named-data/ppa/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found
W: Failed to fetch http://ppa.launchpad.net/named-data/ppa/ubuntu/dists/wily/main/binary-i386/Packages  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.

Will NFD installation using NDN PPA repository soon support Ubuntu 15.10 or do I have to go back on 14.10? I really liked that way of installing NFD. (And yes, installing from source still works.)

Best,
Urs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160314/579879c4/attachment.html>

From shijunxiao at email.arizona.edu  Mon Mar 14 04:42:08 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 14 Mar 2016 04:42:08 -0700
Subject: [Nfd-dev] NFD on Ubuntu 15.10?
In-Reply-To: <4DE5E8A1E5827142BA60833545E63269848A3875@urz-mbx-1.urz.unibas.ch>
References: <4DE5E8A1E5827142BA60833545E63269848A3875@urz-mbx-1.urz.unibas.ch>
Message-ID: <CAOFH+Oa4nS1gAjNR0UtWhMd=KedS6uQvUGj71KKL32EPCXpsCw@mail.gmail.com>

Hi URS

I can't comment on PPA availability for 15.10.

Per platform policy
http://named-data.net/codebase/platform/documentation/ndn-platform-development-guidelines/#Build_support
, 14.10 is no longer supported, and 15.10 support will be dropped as soon
as 16.04 is released.

I suggest sticking with 14.04 LTS, which shall be supported until 18.04
release that is still 2 years away.

Yours, Junxiao
On Mar 14, 2016 03:59, "Urs Schnurrenberger" <urs.schnurrenberger at unibas.ch>
wrote:

> Dear all,
>
>
>
> I followed the steps on
> http://named-data.net/doc/NFD/current/INSTALL.html#install-nfd-using-the-ndn-ppa-repository-on-ubuntu-linux
> and ended up here:
>
>
>
> ~$ sudo apt-get update
>
> [?]
>
> W: Failed to fetch
> http://ppa.launchpad.net/named-data/ppa/ubuntu/dists/wily/main/binary-amd64/Packages
> 404  Not Found
>
> W: Failed to fetch
> http://ppa.launchpad.net/named-data/ppa/ubuntu/dists/wily/main/binary-i386/Packages
> 404  Not Found
>
> E: Some index files failed to download. They have been ignored, or old
> ones used instead.
>
>
>
> Will NFD installation using NDN PPA repository soon support Ubuntu 15.10
> or do I have to go back on 14.10? I really liked that way of installing
> NFD. (And yes, installing from source still works.)
>
>
>
> Best,
>
> Urs
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160314/165cce7f/attachment.html>

From 121049189 at qq.com  Tue Mar 15 01:22:39 2016
From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=)
Date: Tue, 15 Mar 2016 16:22:39 +0800
Subject: [Nfd-dev] ERROR SOLVE
Message-ID: <tencent_7C2776F47D3847C533423141@qq.com>

Dear all,
    I'm quite new to NDN, but I'm interested in it. Now I use to host one is 192.168.110.128, another is 192.168.110.129.
as follows https://github.com/zhao7611050/ndn-tools/tree/master/tools/chunks
 in 192.168.110.129 I can't get file what I transfer in 192.168.110.128
ERROR: Reached the maximum number of timeout retries (3) while retrieving data for /localhost/demo/gpl3/%FD%00%00%01SyU%08B

What can I do. thx
------------------
----------------------------------------------------
???
?????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160315/cc7c238f/attachment.html>

From urs.schnurrenberger at unibas.ch  Tue Mar 15 01:27:19 2016
From: urs.schnurrenberger at unibas.ch (Urs Schnurrenberger)
Date: Tue, 15 Mar 2016 08:27:19 +0000
Subject: [Nfd-dev] NFD on Ubuntu 15.10?
In-Reply-To: <CAOFH+Oa4nS1gAjNR0UtWhMd=KedS6uQvUGj71KKL32EPCXpsCw@mail.gmail.com>
References: <4DE5E8A1E5827142BA60833545E63269848A3875@urz-mbx-1.urz.unibas.ch>
	<CAOFH+Oa4nS1gAjNR0UtWhMd=KedS6uQvUGj71KKL32EPCXpsCw@mail.gmail.com>
Message-ID: <4DE5E8A1E5827142BA60833545E63269848A3A23@urz-mbx-1.urz.unibas.ch>

Hi Junxiao,

thank you for the prompt reply and the link. I was not aware of that one. Definitely good to know!

Cheers,
Urs

Von: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Gesendet: Montag, 14. M?rz 2016 12:42
An: Urs Schnurrenberger <urs.schnurrenberger at unibas.ch>
Cc: <nfd-dev at lists.cs.ucla.edu> <nfd-dev at lists.cs.ucla.edu>
Betreff: Re: [Nfd-dev] NFD on Ubuntu 15.10?


Hi URS

I can't comment on PPA availability for 15.10.

Per platform policy http://named-data.net/codebase/platform/documentation/ndn-platform-development-guidelines/#Build_support , 14.10 is no longer supported, and 15.10 support will be dropped as soon as 16.04 is released.

I suggest sticking with 14.04 LTS, which shall be supported until 18.04 release that is still 2 years away.

Yours, Junxiao
On Mar 14, 2016 03:59, "Urs Schnurrenberger" <urs.schnurrenberger at unibas.ch<mailto:urs.schnurrenberger at unibas.ch>> wrote:
Dear all,

I followed the steps on http://named-data.net/doc/NFD/current/INSTALL.html#install-nfd-using-the-ndn-ppa-repository-on-ubuntu-linux and ended up here:

~$ sudo apt-get update
[?]
W: Failed to fetch http://ppa.launchpad.net/named-data/ppa/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found
W: Failed to fetch http://ppa.launchpad.net/named-data/ppa/ubuntu/dists/wily/main/binary-i386/Packages  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.

Will NFD installation using NDN PPA repository soon support Ubuntu 15.10 or do I have to go back on 14.10? I really liked that way of installing NFD. (And yes, installing from source still works.)

Best,
Urs

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160315/b87aa6e0/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Mar 15 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 15 Mar 2016 07:00:02 -0700
Subject: [Nfd-dev] NFD call 20160315
Message-ID: <201603151400.u2FE02DM002936@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160315/5c3ed272/attachment.html>

From bastiaan.wissingh at tno.nl  Thu Mar 17 02:47:37 2016
From: bastiaan.wissingh at tno.nl (Wissingh, B.F. (Bastiaan))
Date: Thu, 17 Mar 2016 09:47:37 +0000
Subject: [Nfd-dev] Clarification on usage of ChildSelector in Content Store
Message-ID: <A9C53D7C-4A74-4139-9A31-ACC73124D941@tno.nl>

Hi,

I?m currently trying to figure out how exactly NFD matches an Interest on a Content Store object by looking through the nfd code. So far I understand the process, the function Cs::find seems to be the ?general entry? used by the forwarder to request the Content Store to find a match for an Interest it received, however it is not really clear to me how the ChildSelector parameter of an Interest is used here. Based on the value, it will either try to find a LeftMost or RightMost match.

I found some explanatory documentation on (http://named-data.net/doc/ndn-tlv/interest.html#childselector), however with the example given there I?m still not quite sure what the purpose is and how it works.

Could some of you provide me with a more extensive example on this?

Thank you,
Bastiaan Wissingh
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/25f8dd6e/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Mar 17 07:00:03 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 17 Mar 2016 07:00:03 -0700
Subject: [Nfd-dev] NFD call 20160317
Message-ID: <201603171400.u2HE03Ta009287@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/5d1dc06a/attachment.html>

From lixia at CS.UCLA.EDU  Thu Mar 17 20:59:00 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Thu, 17 Mar 2016 20:59:00 -0700
Subject: [Nfd-dev] does NDN router verify packets retrieved by using full
 name?
Message-ID: <8272EC96-279A-4272-A523-C9956E642437@cs.ucla.edu>

if an interest carries implicit digest and retrieves a data packet back, does the router compute the digest to verify?





From shijunxiao at email.arizona.edu  Thu Mar 17 21:00:37 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 17 Mar 2016 21:00:37 -0700
Subject: [Nfd-dev] does NDN router verify packets retrieved by using
 full name?
In-Reply-To: <8272EC96-279A-4272-A523-C9956E642437@cs.ucla.edu>
References: <8272EC96-279A-4272-A523-C9956E642437@cs.ucla.edu>
Message-ID: <CAOFH+ObwZXdvrd__i-YEfjdY4y6ArBcv00M5AjMqyyfb-GmVXA@mail.gmail.com>

Hi Lixia

Yes. Implicit digest is always computed when the last component of Interest
name is ImplicitSha256DigestComponent.

Yours, Junxiao

On Thu, Mar 17, 2016 at 8:59 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

> if an interest carries implicit digest and retrieves a data packet back,
> does the router compute the digest to verify?
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/19fe12ea/attachment.html>

From alexander.afanasyev at ucla.edu  Thu Mar 17 21:02:32 2016
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 17 Mar 2016 21:02:32 -0700
Subject: [Nfd-dev] does NDN router verify packets retrieved by using
 full name?
In-Reply-To: <8272EC96-279A-4272-A523-C9956E642437@cs.ucla.edu>
References: <8272EC96-279A-4272-A523-C9956E642437@cs.ucla.edu>
Message-ID: <87BCD7D2-8CF7-4000-80AE-C4D1EC9AD640@ucla.edu>

It is implicitly verified, because otherwise the data packet would not match the PIT entry.

---
Alex

> On Mar 17, 2016, at 8:59 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
> 
> if an interest carries implicit digest and retrieves a data packet back, does the router compute the digest to verify?
> 
> 



From shijunxiao at email.arizona.edu  Thu Mar 17 21:09:07 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 17 Mar 2016 21:09:07 -0700
Subject: [Nfd-dev] Clarification on usage of ChildSelector in Content
 Store
In-Reply-To: <A9C53D7C-4A74-4139-9A31-ACC73124D941@tno.nl>
References: <A9C53D7C-4A74-4139-9A31-ACC73124D941@tno.nl>
Message-ID: <CAOFH+Ob2mE118W-9sP3dck05rCG74Pea76pPiwQgLgVAELRvoA@mail.gmail.com>

Hi Bastiaan

The two attachments on #1706 <http://redmine.named-data.net/issues/1706> is
worth a read. These are the main design documents of CS lookup procedure,
although one of them are originally designed for the repo.

Yours, Junxiao

On Thu, Mar 17, 2016 at 2:47 AM, Wissingh, B.F. (Bastiaan) <
bastiaan.wissingh at tno.nl> wrote:

> Hi,
>
> I?m currently trying to figure out how exactly NFD matches an Interest on
> a Content Store object by looking through the nfd code. So far I understand
> the process, the function Cs::find seems to be the ?general entry? used by
> the forwarder to request the Content Store to find a match for an Interest
> it received, however it is not really clear to me how the ChildSelector
> parameter of an Interest is used here. Based on the value, it will either
> try to find a LeftMost or RightMost match.
>
> I found some explanatory documentation on (
> http://named-data.net/doc/ndn-tlv/interest.html#childselector), however
> with the example given there I?m still not quite sure what the purpose is
> and how it works.
>
> Could some of you provide me with a more extensive example on this?
>
> Thank you,
> Bastiaan Wissingh
>
>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/26d01121/attachment.html>

From shijunxiao at email.arizona.edu  Thu Mar 17 22:27:26 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 17 Mar 2016 22:27:26 -0700
Subject: [Nfd-dev] FW: How to test in ndn development
In-Reply-To: <CA+LWhLva909P+vfscmbMkcYpTiBHS_=Ne3w7m0M7pWJ0Givy4Q@mail.gmail.com>
References: <CA+LWhLva909P+vfscmbMkcYpTiBHS_=Ne3w7m0M7pWJ0Givy4Q@mail.gmail.com>
Message-ID: <56eb91b7.0b57620a.ba920.1156@mx.google.com>





From: Teng Liang
Sent: Thursday, March 17, 2016 22:23
To: Junxiao Shi
Subject: How to test in ndn development

Hi Junxiao,

?Is there any thread that solves the problem?

I compiled ndn-cxx with tests and tried the following command to run a test.

./unit-tests --log_level=test_suite --run_test=<example>

Here is the error message:

Test setup error: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<ndn::SecTpmOsx::Error> >: No default keychain, please create one first

Thanks,
Teng

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/cd1518cf/attachment.html>

From yuyingdi at gmail.com  Thu Mar 17 23:21:55 2016
From: yuyingdi at gmail.com (Yingdi Yu)
Date: Thu, 17 Mar 2016 23:21:55 -0700
Subject: [Nfd-dev] FW: How to test in ndn development
In-Reply-To: <56eb91b7.0b57620a.ba920.1156@mx.google.com>
References: <CA+LWhLva909P+vfscmbMkcYpTiBHS_=Ne3w7m0M7pWJ0Givy4Q@mail.gmail.com>
	<56eb91b7.0b57620a.ba920.1156@mx.google.com>
Message-ID: <5F59335A-A78E-4542-94A1-1C30DF57D176@gmail.com>

Hi Teng,

Could you check if your default keychain is set? you can open "Keychain Access? to check that. If you are in the terminal mode, you can use security commands, e.g., following command will show you all the keychain you have:

$ security list-keychains 

and a command below will help you to display/set default keychain

$ security default-keychain

Best Regards,

Yingdi 

> On Mar 17, 2016, at 10:27 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
>  
>  
>  
>  
> From: Teng Liang <mailto:philoliang2011 at gmail.com>
> Sent: Thursday, March 17, 2016 22:23
> To: Junxiao Shi <mailto:shijunxiao at email.arizona.edu>
> Subject: How to test in ndn development
>  
> Hi Junxiao,
>  
>  Is there any thread that solves the problem?
>  
> I compiled ndn-cxx with tests and tried the following command to run a test.
>  
> ./unit-tests --log_level=test_suite --run_test=<example>
>  
> Here is the error message:
>  
> Test setup error: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<ndn::SecTpmOsx::Error> >: No default keychain, please create one first
>  
> Thanks,
> Teng
>  
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/564c0686/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160317/564c0686/attachment.bin>

From bastiaan.wissingh at tno.nl  Fri Mar 18 04:01:31 2016
From: bastiaan.wissingh at tno.nl (Wissingh, B.F. (Bastiaan))
Date: Fri, 18 Mar 2016 11:01:31 +0000
Subject: [Nfd-dev] Clarification on usage of ChildSelector in Content
 Store
In-Reply-To: <CAOFH+Ob2mE118W-9sP3dck05rCG74Pea76pPiwQgLgVAELRvoA@mail.gmail.com>
References: <A9C53D7C-4A74-4139-9A31-ACC73124D941@tno.nl>
	<CAOFH+Ob2mE118W-9sP3dck05rCG74Pea76pPiwQgLgVAELRvoA@mail.gmail.com>
Message-ID: <640A99E7-D2D2-47BE-B208-95E1296F8A13@tno.nl>

Hi Junxiao,

Thanks for the reference, that was exactly what I was looking for! I think I grasp the idea now, so just to confirm, looking at sheet 14 of the ?tables-concept-cs_20140117? document, as the ChildSelector ?rightmost? matches on "/example/C/r/1" should the ChildSelector ?leftmost? match on "/example/C/p/1" ?

Thanks,
Bastiaan

Van: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Datum: vrijdag 18 maart 2016 05:09
Aan: Bastiaan Wissingh <bastiaan.wissingh at tno.nl<mailto:bastiaan.wissingh at tno.nl>>
CC: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Onderwerp: Re: [Nfd-dev] Clarification on usage of ChildSelector in Content Store

Hi Bastiaan

The two attachments on #1706<http://redmine.named-data.net/issues/1706> is worth a read. These are the main design documents of CS lookup procedure, although one of them are originally designed for the repo.

Yours, Junxiao

On Thu, Mar 17, 2016 at 2:47 AM, Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl<mailto:bastiaan.wissingh at tno.nl>> wrote:
Hi,

I?m currently trying to figure out how exactly NFD matches an Interest on a Content Store object by looking through the nfd code. So far I understand the process, the function Cs::find seems to be the ?general entry? used by the forwarder to request the Content Store to find a match for an Interest it received, however it is not really clear to me how the ChildSelector parameter of an Interest is used here. Based on the value, it will either try to find a LeftMost or RightMost match.

I found some explanatory documentation on (http://named-data.net/doc/ndn-tlv/interest.html#childselector), however with the example given there I?m still not quite sure what the purpose is and how it works.

Could some of you provide me with a more extensive example on this?

Thank you,
Bastiaan Wissingh

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160318/8e23f4fd/attachment.html>

From shijunxiao at email.arizona.edu  Fri Mar 18 06:13:18 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 18 Mar 2016 06:13:18 -0700
Subject: [Nfd-dev] Clarification on usage of ChildSelector in
 ContentStore
In-Reply-To: <640A99E7-D2D2-47BE-B208-95E1296F8A13@tno.nl>
References: <A9C53D7C-4A74-4139-9A31-ACC73124D941@tno.nl>
	<CAOFH+Ob2mE118W-9sP3dck05rCG74Pea76pPiwQgLgVAELRvoA@mail.gmail.com>
	<640A99E7-D2D2-47BE-B208-95E1296F8A13@tno.nl>
Message-ID: <56ebfee8.21f8420a.f3e35.fffff3ca@mx.google.com>

Yes, /example/C/p/1 would be the correct leftmost match for /example/C among Data names { /example/B, /example/C/p/1, /example/C/p/2, /example/C/q/1, /example/C/q/2, /example/C/r/1, /example/C/r/2, /example/D }, if it does not violate other Selectors on the Interest.


From: Wissingh, B.F. (Bastiaan)
Sent: Friday, March 18, 2016 04:01
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Clarification on usage of ChildSelector in ContentStore

Hi Junxiao,

Thanks for the reference, that was exactly what I was looking for! I think I grasp the idea now, so just to confirm, looking at sheet 14 of the ?tables-concept-cs_20140117? document, as the ChildSelector ?rightmost? matches on "/example/C/r/1" should the ChildSelector ?leftmost? match on "/example/C/p/1" ?

Thanks,
Bastiaan?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160318/db4186e7/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Mar 22 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 22 Mar 2016 07:00:02 -0700
Subject: [Nfd-dev] NFD call 20160322
Message-ID: <201603221400.u2ME021a010980@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160322/fe33b6f5/attachment.html>

From aa at CS.UCLA.EDU  Tue Mar 22 09:04:13 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 22 Mar 2016 09:04:13 -0700
Subject: [Nfd-dev] NFD call 20160322
In-Reply-To: <201603221400.u2ME021a010980@lectura.cs.arizona.edu>
References: <201603221400.u2ME021a010980@lectura.cs.arizona.edu>
Message-ID: <9ABA3683-B8A8-4012-9258-D194CCFFF35E@cs.ucla.edu>

Today's call is actually cancelled.

---
Alex

> On Mar 22, 2016, at 7:00 AM, NFD call notification <nfd-call-notification at mail1.yoursunny.com> wrote:
> 
> Dear folks
> 
> This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/760263096 <https://bluejeans.com/760263096>. The current call time is every Tuesday/Thursday 13:00-14:00 Pacific Time. The current agenda includes the following issues:
> 
> 
> 
> http://redmine.named-data.net/issues/3474 <https://www.google.com/url?q=http://redmine.named-data.net/issues/3474&sa=D&ust=1458658802379000&usg=AFQjCNG-bqbS1CMqkuEreWfBou6Xk6o9ow>
> Discuss definition of ???region??? used by NFD to process links.
> 
> Needed by Haitao, Zhehao, JeffB.
> 
> 
> http://redmine.named-data.net/issues/3546 <https://www.google.com/url?q=http://redmine.named-data.net/issues/3546&sa=D&ust=1458658802381000&usg=AFQjCNFaNeBVfVgwazML67CJCR5zJhrkrA>
> PIT entry: move away forwarding semantics, design review
> 
> need: Junxiao, Alex
> 
> 
> http://redmine.named-data.net/issues/3545 <https://www.google.com/url?q=http://redmine.named-data.net/issues/3545&sa=D&ust=1458658802382000&usg=AFQjCNG_bjw-zb522xBVqrYaiyG53jZpMw>
> pit::Entry::hasUnexpiredOutRecords does not consider Nack, design review
> 
> need: Junxiao, Alex, Beichuan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160322/018a5697/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160322/018a5697/attachment.bin>

From kc at caida.org  Wed Mar 23 11:57:41 2016
From: kc at caida.org (k claffy)
Date: Wed, 23 Mar 2016 11:57:41 -0700
Subject: [Nfd-dev] two relevant papers from jj
Message-ID: <20160323185741.GA89952@caida.org>

Title: Enabling Correct Interest Forwarding and Retransmissions in a Content
  Centric Network
Authors: J.J. Garcia-Luna-Aceves, Maziar Mirzazad-Barijough
Categories: cs.NI
\\
  We show that the mechanisms used in the name data networking (NDN) and the
original content centric networking (CCN) architectures may not detect Interest
loops, even if the network in which they operate is static and no faults occur.
Furthermore, we show that no correct Interest forwarding strategy can be
defined that allows Interest aggregation and attempts to detect Interest
looping by identifying Interests uniquely. We introduce SIFAH (Strategy for
Interest Forwarding and Aggregation with Hop-Counts), the first Interest
forwarding strategy shown to be correct under any operational conditions of a
content centric network. SIFAH operates by having forwarding information bases
(FIBs) store the next hops and number of hops to named content, and by having
each Interest state the name of the requested content and the hop count from
the router forwarding an Interest to the content. We present the results of
simulation experiments using the ndnSIM simulator comparing CCN and NDN with
SIFAH. The results of these experiments illustrate the negative impact of
undetected Interest looping when Interests are aggregated in CCN and NDN, and
the performance advantages of using SIFAH.
\\ ( http://arxiv.org/abs/1603.06012 ,  657kb)
------------------------------------------------------------------------------
\\
arXiv:1603.06044
Date: Sat, 19 Mar 2016 04:03:01 GMT   (4155kb,D)

Title: A Light-Weight Forwarding Plane for Content-Centric Networks
Authors: J.J. Garcia-Luna-Aceves, Maziar Mirzazad-Barijough
Categories: cs.NI
\\
  We present CCN-DART, a more efficient forwarding approach for content-centric
networking (CCN) than named data networking (NDN) that substitutes Pending
Interest Tables (PIT) with Data Answer Routing Tables (DART) and uses a novel
approach to eliminate forwarding loops. The forwarding state required at each
router using CCN-DART consists of segments of the routes between consumers and
content providers that traverse a content router, rather than the Interests
that the router forwards towards content providers. Accordingly, the size of a
DART is proportional to the number of routes used by Interests traversing a
router, rather than the number of Interests traversing a router. We show that
CCN-DART avoids forwarding loops by comparing distances to name prefixes
reported by neighbors, even when routing loops exist. Results of simulation
experiments comparing CCN-DART with NDN using the ndnSIM simulation tool show
that CCN-DART incurs 10 to 20 times less storage overhead.
\\ ( http://arxiv.org/abs/1603.06044 ,  4155kb)


From nfd-call-notification at mail1.yoursunny.com  Thu Mar 24 07:00:03 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 24 Mar 2016 07:00:03 -0700
Subject: [Nfd-dev] NFD call 20160324
Message-ID: <201603241400.u2OE0329015631@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/6b01a5f0/attachment.html>

From shijunxiao at email.arizona.edu  Thu Mar 24 14:37:16 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 24 Mar 2016 14:37:16 -0700
Subject: [Nfd-dev] ndncon test producers
In-Reply-To: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
References: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
Message-ID: <CAOFH+ObH4Bh9gsukcmeK3TvqcCtZjpQv1kJTWALFY6i7wCRdOg@mail.gmail.com>

Hi Peter

One of the producers are down as of 20160324 2130 UTC.

[image: Inline image 1]

Yours, Junxiao

On Tue, Mar 1, 2016 at 3:18 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

> Hi dev team,
>
> There are two test *ndncon* producers that should be available 24/7:
>
> */ndn/edu/ucla/remap/freeculture*
> - 1 audio stream
> - 1 stream 1000-bytes segments:
> - 700 kbps
> - 1000 kbps
> - 3000 kbps
> - 1 stream 8000-bytes segments:
> - 700 kbps
> - 1000 kbps
> - 3000 kbps
> and
>
> */ndn/edu/ucla/remap/test*
> - 1 audio stream (pandora radio)
> - 1 stream webcam
> - 200 kbps
> - 1000 kbps
> - 3000 kbps
> - 1 stream desktop
> - 500 kbps
> - 700 kbps
> - 1100 kbps
>
> If you can?t see them in *ndncon*?s ?Active users? list, let me know,
> I?ll check the issue.
>
> Thanks,
>
> --
> Peter Gusev
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
> Software Engineer/Programmer Analyst @ REMAP UCLA
>
> Video streaming/ICN networks/Creative Development
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/e184172c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.PNG
Type: image/png
Size: 39830 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/e184172c/attachment.png>

From peter at remap.UCLA.edu  Thu Mar 24 15:08:32 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Thu, 24 Mar 2016 22:08:32 +0000
Subject: [Nfd-dev] ndncon test producers
In-Reply-To: <CAOFH+ObH4Bh9gsukcmeK3TvqcCtZjpQv1kJTWALFY6i7wCRdOg@mail.gmail.com>
References: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
	<CAOFH+ObH4Bh9gsukcmeK3TvqcCtZjpQv1kJTWALFY6i7wCRdOg@mail.gmail.com>
Message-ID: <370E41BE-623F-4BC9-BF8E-89C6D78D7EB7@remap.ucla.edu>

hi Junxiao,

Thanks, it?s backroute problem on REMAP.
need to restart it. will talk with operator.


--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 24, 2016, at 2:37 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

One of the producers are down as of 20160324 2130 UTC.

<Capture.PNG>

Yours, Junxiao

On Tue, Mar 1, 2016 at 3:18 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi dev team,

There are two test ndncon producers that should be available 24/7:

/ndn/edu/ucla/remap/freeculture
- 1 audio stream
- 1 stream 1000-bytes segments:
- 700 kbps
- 1000 kbps
- 3000 kbps
- 1 stream 8000-bytes segments:
- 700 kbps
- 1000 kbps
- 3000 kbps
and

/ndn/edu/ucla/remap/test
- 1 audio stream (pandora radio)
- 1 stream webcam
- 200 kbps
- 1000 kbps
- 3000 kbps
- 1 stream desktop
- 500 kbps
- 700 kbps
- 1100 kbps

If you can?t see them in ndncon?s ?Active users? list, let me know, I?ll check the issue.

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/6b888271/attachment.html>

From peter at remap.ucla.edu  Thu Mar 24 18:37:17 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Fri, 25 Mar 2016 01:37:17 +0000
Subject: [Nfd-dev] Autoconfig for local WiFi network
Message-ID: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>

Hi dev team,

Once we tested NDN over Ethernet on our local ?testbed? - three laptops with NFD connected to the same network - after creating ethernet faces, ndncon instances running on each machine ?magically? discovered each other and were able to communicate via chat/audio/video.

However, I?m curious about feasibility of getting similar effect on the local WiFi networks (and whether autoconfig can help with that or such discovery should become a part of autoconfig):

Say, I have three laptops with NFD connected to the same WiFi network with no Internet access. If I run autoconfig on all three laptops - will they ?magically? discover each other and create routes? If so, which routes will be created?
If no, what precludes from implementing such ?local autodiscovery"?

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/17d514ac/attachment.html>

From shijunxiao at email.arizona.edu  Thu Mar 24 19:01:18 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 24 Mar 2016 19:01:18 -0700
Subject: [Nfd-dev] ndncon test producers
In-Reply-To: <beae7166-8d0a-42eb-ae06-1faab4563a90@emhub4.ad.ucla.edu>
References: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
	<CAOFH+ObH4Bh9gsukcmeK3TvqcCtZjpQv1kJTWALFY6i7wCRdOg@mail.gmail.com>
	<beae7166-8d0a-42eb-ae06-1faab4563a90@emhub4.ad.ucla.edu>
Message-ID: <CAOFH+OY-4_0vKcjufCV_Ky4qy02us2MGFJAO7fG4YAtdu7XhGA@mail.gmail.com>

Hi Peter

So this test producer is suffering from autoreg problem again.
Can you try the workaround in
http://redmine.named-data.net/issues/3513#note-19 and use automatic prefix
propagation? This should be more reliable than autoreg.

Yours, Junxiao

On Mar 24, 2016 15:08, "Gusev, Peter" <peter at remap.ucla.edu> wrote:
>
> hi Junxiao,
>
> Thanks, it?s backroute problem on REMAP.
> need to restart it. will talk with operator.
>
>
> --
> Peter Gusev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/fd1ceb75/attachment.html>

From pedrofigueiredoc at gmail.com  Thu Mar 24 19:01:32 2016
From: pedrofigueiredoc at gmail.com (Pedro Figueiredo)
Date: Thu, 24 Mar 2016 23:01:32 -0300
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
Message-ID: <CA+ud=jvqJDKQj+AbHYqTXi+wYHwXNMdGb5HA=1SQOi92uFnPuA@mail.gmail.com>

Hi Peter,

Yes autoconfig will help you do that, you can start the
ndn-autoconfig-server application on the server (using the faceURI as
argument
http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig-server.html)
and then run ndn-autoconfig on the consumers.

This procedure will cause the consumers to search for the hub in your
network by 1st Multicast, 2nd DNS query, if any of them had success than
two prefixes are automatically created /ndn and /localhop/nfd (
http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig.html#ndn-autoconfig
).

We also worked for this functionality on Android at the 2nd Hackathon. The
code will be available very soon and folks can test and run also on
NFD-Android.

Hope this can help,

2016-03-24 22:37 GMT-03:00 Gusev, Peter <peter at remap.ucla.edu>:

> Hi dev team,
>
> Once we tested NDN over Ethernet on our local ?testbed? - three laptops
> with NFD connected to the same network - after creating ethernet faces, *ndncon
> *instances running on each machine ?magically? discovered each other and
> were able to communicate via chat/audio/video.
>
> However, I?m curious about feasibility of getting similar effect on the
> local WiFi networks (and whether autoconfig can help with that or such
> discovery should become a part of autoconfig):
>
> Say, I have three laptops with NFD connected to the same WiFi network with
> no Internet access. If I run autoconfig on all three laptops - will they
> ?magically? discover each other and create routes? If so, which routes will
> be created?
> If no, what precludes from implementing such ?local autodiscovery"?
>
> Thanks,
>
> --
> Peter Gusev
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
> Software Engineer/Programmer Analyst @ REMAP UCLA
>
> Video streaming/ICN networks/Creative Development
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>


-- 
------------------------------------------
*Pedro Cavalcanti Figueiredo*
Computer Engineering - UFPA (ITEC/FCT)
Laboratory of Signal Processing - LaPS
pedro.figueiredo at itec.ufpa.br | p.h.c at ieee.org
-------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/b2686d4e/attachment.html>

From peter at remap.ucla.edu  Thu Mar 24 19:05:51 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Fri, 25 Mar 2016 02:05:51 +0000
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <CA+ud=jvqJDKQj+AbHYqTXi+wYHwXNMdGb5HA=1SQOi92uFnPuA@mail.gmail.com>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>,
	<CA+ud=jvqJDKQj+AbHYqTXi+wYHwXNMdGb5HA=1SQOi92uFnPuA@mail.gmail.com>
Message-ID: <F8D3056B-0DA9-4104-88BD-A212C3A4803D@remap.ucla.edu>

Hi Pedro,

Thanks, this is interesting, I'll take a look.
Though, this means everyone connects to the server. is there a way to do it without a server?

example usecase: we open our laptops during hackathon, setup wifi network and want to use ndncon for text chat.

--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:+1%20213%205872748>
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 24, 2016, at 7:01 PM, Pedro Figueiredo <pedrofigueiredoc at gmail.com<mailto:pedrofigueiredoc at gmail.com>> wrote:

Hi Peter,

Yes autoconfig will help you do that, you can start the ndn-autoconfig-server application on the server (using the faceURI as argument http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig-server.html) and then run ndn-autoconfig on the consumers.

This procedure will cause the consumers to search for the hub in your network by 1st Multicast, 2nd DNS query, if any of them had success than two prefixes are automatically created /ndn and /localhop/nfd (http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig.html#ndn-autoconfig).

We also worked for this functionality on Android at the 2nd Hackathon. The code will be available very soon and folks can test and run also on NFD-Android.

Hope this can help,

2016-03-24 22:37 GMT-03:00 Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>:
Hi dev team,

Once we tested NDN over Ethernet on our local ?testbed? - three laptops with NFD connected to the same network - after creating ethernet faces, ndncon instances running on each machine ?magically? discovered each other and were able to communicate via chat/audio/video.

However, I?m curious about feasibility of getting similar effect on the local WiFi networks (and whether autoconfig can help with that or such discovery should become a part of autoconfig):

Say, I have three laptops with NFD connected to the same WiFi network with no Internet access. If I run autoconfig on all three laptops - will they ?magically? discover each other and create routes? If so, which routes will be created?
If no, what precludes from implementing such ?local autodiscovery"?

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




--
------------------------------------------
Pedro Cavalcanti Figueiredo
Computer Engineering - UFPA (ITEC/FCT)
Laboratory of Signal Processing - LaPS
pedro.figueiredo at itec.ufpa.br<mailto:pedro.figueiredo at itec.ufpa.br> | p.h.c at ieee.org<mailto:p.h.c at ieee.org>
-------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/6d4a8207/attachment.html>

From pedrofigueiredoc at gmail.com  Thu Mar 24 19:12:01 2016
From: pedrofigueiredoc at gmail.com (Pedro Figueiredo)
Date: Thu, 24 Mar 2016 23:12:01 -0300
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <43d61b53-2e74-45aa-b6c6-9d6ac18ce0e9@EMHUB6.ad.ucla.edu>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
	<CA+ud=jvqJDKQj+AbHYqTXi+wYHwXNMdGb5HA=1SQOi92uFnPuA@mail.gmail.com>
	<43d61b53-2e74-45aa-b6c6-9d6ac18ce0e9@EMHUB6.ad.ucla.edu>
Message-ID: <CA+ud=jv2TToQmnHR8HMgR2bm58_h4k9WOvGUbgo26GeuXH=rag@mail.gmail.com>

Hi Peter,

I think that is, if you take a look at the 3rd option of ndn-autoconfig you
can try to connect to a "home router" (or in this case any local hub). As
far as I understood, this process is authenticated by a certificate using
ndncert by converting your identity into the DNS format and performing DNS
query.

Best Regards,

------------------------------------------
*Pedro Cavalcanti Figueiredo*
Computer Engineering - UFPA (ITEC/FCT)
Laboratory of Signal Processing - LaPS
pedro.figueiredo at itec.ufpa.br | p.h.c at ieee.org
-------------------------------------------

2016-03-24 23:05 GMT-03:00 Gusev, Peter <peter at remap.ucla.edu>:

> Hi Pedro,
>
> Thanks, this is interesting, I'll take a look.
> Though, this means everyone connects to the server. is there a way to do
> it without a server?
>
> example usecase: we open our laptops during hackathon, setup wifi network
> and want to use ndncon for text chat.
>
> --
> Peter Gusev
> peter at remap.ucla.edu
> *+1 213 5872748 <+1%20213%205872748>*
> *peetonn_ (skype)*
>
> Software Engineer/Programmer Analyst @ REMAP UCLA
>
> Video streaming/ICN networks/Creative Development
>
> On Mar 24, 2016, at 7:01 PM, Pedro Figueiredo <pedrofigueiredoc at gmail.com>
> wrote:
>
> Hi Peter,
>
> Yes autoconfig will help you do that, you can start the
> ndn-autoconfig-server application on the server (using the faceURI as
> argument
> http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig-server.html)
> and then run ndn-autoconfig on the consumers.
>
> This procedure will cause the consumers to search for the hub in your
> network by 1st Multicast, 2nd DNS query, if any of them had success than
> two prefixes are automatically created /ndn and /localhop/nfd (
> http://named-data.net/doc/NFD/current/manpages/ndn-autoconfig.html#ndn-autoconfig
> ).
>
> We also worked for this functionality on Android at the 2nd Hackathon. The
> code will be available very soon and folks can test and run also on
> NFD-Android.
>
> Hope this can help,
>
> 2016-03-24 22:37 GMT-03:00 Gusev, Peter <peter at remap.ucla.edu>:
>
>> Hi dev team,
>>
>> Once we tested NDN over Ethernet on our local ?testbed? - three laptops
>> with NFD connected to the same network - after creating ethernet faces, *ndncon
>> *instances running on each machine ?magically? discovered each other and
>> were able to communicate via chat/audio/video.
>>
>> However, I?m curious about feasibility of getting similar effect on the
>> local WiFi networks (and whether autoconfig can help with that or such
>> discovery should become a part of autoconfig):
>>
>> Say, I have three laptops with NFD connected to the same WiFi network
>> with no Internet access. If I run autoconfig on all three laptops - will
>> they ?magically? discover each other and create routes? If so, which routes
>> will be created?
>> If no, what precludes from implementing such ?local autodiscovery"?
>>
>> Thanks,
>>
>> --
>> Peter Gusev
>>
>> peter at remap.ucla.edu
>> +1 213 5872748
>> peetonn_ (skype)
>>
>> Software Engineer/Programmer Analyst @ REMAP UCLA
>>
>> Video streaming/ICN networks/Creative Development
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>
>
> --
> ------------------------------------------
> *Pedro Cavalcanti Figueiredo*
> Computer Engineering - UFPA (ITEC/FCT)
> Laboratory of Signal Processing - LaPS
> pedro.figueiredo at itec.ufpa.br | p.h.c at ieee.org
> -------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/45e79ab3/attachment.html>

From shijunxiao at email.arizona.edu  Thu Mar 24 20:27:10 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 24 Mar 2016 20:27:10 -0700
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
Message-ID: <A6B9CCB5-6DF1-4EDD-BB1F-8CA366BC9554@email.arizona.edu>

Hi Peter

I don?t understand why NdnCon instances can ?magically? discover each other.
A standard NFD installation should create a multi-access Ethernet face on every multicast-capable network interface. However, it will not register any prefix onto these Ethernet faces, so these faces will not be used for communication.
Does your setup have another program that registers a prefix onto the Ethernet faces?

From NFD point of view, there?s no difference between wired Ethernet and WiFi, because Ethernet runs over WiFi.
However, some access points will block multicast traffic transmitted by a wireless stations, or even block all traffic between wireless stations.
You?ll need to configure your access point to permit multicast traffic among wireless stations.

Yours, Junxiao

> On Mar 24, 2016, at 6:37 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> 
> Hi dev team,
> 
> Once we tested NDN over Ethernet on our local ?testbed? - three laptops with NFD connected to the same network - after creating ethernet faces, ndncon instances running on each machine ?magically? discovered each other and were able to communicate via chat/audio/video.
> 
> However, I?m curious about feasibility of getting similar effect on the local WiFi networks (and whether autoconfig can help with that or such discovery should become a part of autoconfig):
> 
> Say, I have three laptops with NFD connected to the same WiFi network with no Internet access. If I run autoconfig on all three laptops - will they ?magically? discover each other and create routes? If so, which routes will be created?
> If no, what precludes from implementing such ?local autodiscovery"?
> 
> Thanks, 
> 
> -- 
> Peter Gusev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160324/78196da4/attachment.html>

From peter at remap.UCLA.edu  Thu Mar 24 20:57:41 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Fri, 25 Mar 2016 03:57:41 +0000
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <A6B9CCB5-6DF1-4EDD-BB1F-8CA366BC9554@email.arizona.edu>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
	<A6B9CCB5-6DF1-4EDD-BB1F-8CA366BC9554@email.arizona.edu>
Message-ID: <4B94A54D-DF7B-40F8-946F-1420C40AFC78@remap.ucla.edu>

Hi Junxiao,

My bad, I forgot mentioning that we registered a prefix (it was something simple as ?nfdc register / <face-id>?).

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 24, 2016, at 8:27 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

I don?t understand why NdnCon instances can ?magically? discover each other.
A standard NFD installation should create a multi-access Ethernet face on every multicast-capable network interface. However, it will not register any prefix onto these Ethernet faces, so these faces will not be used for communication.
Does your setup have another program that registers a prefix onto the Ethernet faces?

From NFD point of view, there?s no difference between wired Ethernet and WiFi, because Ethernet runs over WiFi.
However, some access points will block multicast traffic transmitted by a wireless stations, or even block all traffic between wireless stations.
You?ll need to configure your access point to permit multicast traffic among wireless stations.

Yours, Junxiao

On Mar 24, 2016, at 6:37 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi dev team,

Once we tested NDN over Ethernet on our local ?testbed? - three laptops with NFD connected to the same network - after creating ethernet faces, ndncon instances running on each machine ?magically? discovered each other and were able to communicate via chat/audio/video.

However, I?m curious about feasibility of getting similar effect on the local WiFi networks (and whether autoconfig can help with that or such discovery should become a part of autoconfig):

Say, I have three laptops with NFD connected to the same WiFi network with no Internet access. If I run autoconfig on all three laptops - will they ?magically? discover each other and create routes? If so, which routes will be created?
If no, what precludes from implementing such ?local autodiscovery"?

Thanks,

--
Peter Gusev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/c72cf6b5/attachment.html>

From shijunxiao at email.arizona.edu  Fri Mar 25 04:35:12 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 25 Mar 2016 04:35:12 -0700
Subject: [Nfd-dev] two relevant papers from jj
In-Reply-To: <20160323185741.GA89952@caida.org>
References: <20160323185741.GA89952@caida.org>
Message-ID: <CAOFH+OabMHdF3C6kka6BSi9NMKOGuS0-w5k5gX+1YK1duPFiFQ@mail.gmail.com>

Hi kc

I guess "relevant" means they are relevant to
http://redmine.named-data.net/issues/1966 ?

Yours, Junxiao
On Mar 23, 2016 11:58 AM, "k claffy" <kc at caida.org> wrote:

> Title: Enabling Correct Interest Forwarding and Retransmissions in a
> Content
>   Centric Network
> Authors: J.J. Garcia-Luna-Aceves, Maziar Mirzazad-Barijough
> Categories: cs.NI
> \\
>   We show that the mechanisms used in the name data networking (NDN) and
> the
> original content centric networking (CCN) architectures may not detect
> Interest
> loops, even if the network in which they operate is static and no faults
> occur.
> Furthermore, we show that no correct Interest forwarding strategy can be
> defined that allows Interest aggregation and attempts to detect Interest
> looping by identifying Interests uniquely. We introduce SIFAH (Strategy for
> Interest Forwarding and Aggregation with Hop-Counts), the first Interest
> forwarding strategy shown to be correct under any operational conditions
> of a
> content centric network. SIFAH operates by having forwarding information
> bases
> (FIBs) store the next hops and number of hops to named content, and by
> having
> each Interest state the name of the requested content and the hop count
> from
> the router forwarding an Interest to the content. We present the results of
> simulation experiments using the ndnSIM simulator comparing CCN and NDN
> with
> SIFAH. The results of these experiments illustrate the negative impact of
> undetected Interest looping when Interests are aggregated in CCN and NDN,
> and
> the performance advantages of using SIFAH.
> \\ ( http://arxiv.org/abs/1603.06012 ,  657kb)
>
> ------------------------------------------------------------------------------
> \\
> arXiv:1603.06044
> Date: Sat, 19 Mar 2016 04:03:01 GMT   (4155kb,D)
>
> Title: A Light-Weight Forwarding Plane for Content-Centric Networks
> Authors: J.J. Garcia-Luna-Aceves, Maziar Mirzazad-Barijough
> Categories: cs.NI
> \\
>   We present CCN-DART, a more efficient forwarding approach for
> content-centric
> networking (CCN) than named data networking (NDN) that substitutes Pending
> Interest Tables (PIT) with Data Answer Routing Tables (DART) and uses a
> novel
> approach to eliminate forwarding loops. The forwarding state required at
> each
> router using CCN-DART consists of segments of the routes between consumers
> and
> content providers that traverse a content router, rather than the Interests
> that the router forwards towards content providers. Accordingly, the size
> of a
> DART is proportional to the number of routes used by Interests traversing a
> router, rather than the number of Interests traversing a router. We show
> that
> CCN-DART avoids forwarding loops by comparing distances to name prefixes
> reported by neighbors, even when routing loops exist. Results of simulation
> experiments comparing CCN-DART with NDN using the ndnSIM simulation tool
> show
> that CCN-DART incurs 10 to 20 times less storage overhead.
> \\ ( http://arxiv.org/abs/1603.06044 ,  4155kb)
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/8414f728/attachment.html>

From jburke at remap.UCLA.edu  Fri Mar 25 09:19:19 2016
From: jburke at remap.UCLA.edu (Burke, Jeff)
Date: Fri, 25 Mar 2016 16:19:19 +0000
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <4B94A54D-DF7B-40F8-946F-1420C40AFC78@remap.ucla.edu>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
	<A6B9CCB5-6DF1-4EDD-BB1F-8CA366BC9554@email.arizona.edu>
	<4B94A54D-DF7B-40F8-946F-1420C40AFC78@remap.ucla.edu>
Message-ID: <72D29B26-F843-4D13-8815-618625B77BE3@remap.ucla.edu>


"You?ll need to configure your access point to permit multicast traffic among wireless stations."

I mentioned to Peter that I thought this was the case.  I think the concern here is that in "real life", where Peter is hoping to experiment with NDN-RTC more and more, we can't always control infrastructure in this way.

So what Peter is asking is whether there is (or could be) a way to automatically bootstrap local communication between NFDs on different devices connected to the same not-necessarily-internet-connected access point without requiring any configuration on the AP.
(Peter please correct me if I'm wrong)

Jeff



From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of "Gusev, Peter" <peter at remap.UCLA.edu<mailto:peter at remap.UCLA.edu>>
Date: Thursday, March 24, 2016 at 8:57 PM
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Autoconfig for local WiFi network

Hi Junxiao,

My bad, I forgot mentioning that we registered a prefix (it was something simple as ?nfdc register / <face-id>?).

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 24, 2016, at 8:27 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

I don?t understand why NdnCon instances can ?magically? discover each other.
A standard NFD installation should create a multi-access Ethernet face on every multicast-capable network interface. However, it will not register any prefix onto these Ethernet faces, so these faces will not be used for communication.
Does your setup have another program that registers a prefix onto the Ethernet faces?

From NFD point of view, there?s no difference between wired Ethernet and WiFi, because Ethernet runs over WiFi.
However, some access points will block multicast traffic transmitted by a wireless stations, or even block all traffic between wireless stations.
You?ll need to configure your access point to permit multicast traffic among wireless stations.

Yours, Junxiao

On Mar 24, 2016, at 6:37 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi dev team,

Once we tested NDN over Ethernet on our local ?testbed? - three laptops with NFD connected to the same network - after creating ethernet faces, ndncon instances running on each machine ?magically? discovered each other and were able to communicate via chat/audio/video.

However, I?m curious about feasibility of getting similar effect on the local WiFi networks (and whether autoconfig can help with that or such discovery should become a part of autoconfig):

Say, I have three laptops with NFD connected to the same WiFi network with no Internet access. If I run autoconfig on all three laptops - will they ?magically? discover each other and create routes? If so, which routes will be created?
If no, what precludes from implementing such ?local autodiscovery"?

Thanks,

--
Peter Gusev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/c12ba3b2/attachment.html>

From shijunxiao at email.arizona.edu  Fri Mar 25 10:56:47 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 25 Mar 2016 10:56:47 -0700
Subject: [Nfd-dev] Autoconfig for local WiFi network
In-Reply-To: <e32f7359-d5e8-4440-80bd-8720217a0629@EMHUB5.ad.ucla.edu>
References: <D9BCDAD8-DDE5-486B-A304-891C416ADD7C@remap.ucla.edu>
	<A6B9CCB5-6DF1-4EDD-BB1F-8CA366BC9554@email.arizona.edu>
	<4B94A54D-DF7B-40F8-946F-1420C40AFC78@remap.ucla.edu>
	<e32f7359-d5e8-4440-80bd-8720217a0629@EMHUB5.ad.ucla.edu>
Message-ID: <CAOFH+OYvDfKKoSy7dA26+05LF7ONhWGoS2t2x1z07OSXi=QX=A@mail.gmail.com>

Hi Jeff

Generally, it's impossible to support every AP configuration. The AP in my
apartment is configured to disallow any communication between wireless
stations (unicast or multicast). In other words, a wireless station can
only connect to the Internet.

Many commercial APs are configured to disallow multicast from wireless
stations, but allow unicast between wireless stations.
In this case, it's theoretically possible to enumerate the unicast address
space (assuming it's not too large) to find if there's another NDN-enabled
system, but this not only cannot scale, but also look like port scanning
and get blocked.

A much better situation is an AP that allows certain multicast protocols
between wireless stations, such as Apple Bonjour which is used by iMacs to
discover each other.
It's theoretically possible to implement a multicast transport using one of
the allowed protocols (transmit NDN packets over Apple Bonjour), but that
would increase the overhead of non-NDN systems in the network.
NFD Feature 3465 <http://redmine.named-data.net/issues/3465> explores
running autoconfig over an allowed multicast protocol. The expected outcome
of this feature is that one laptop can be designated as the router by
running `ndn-autoconfig-server`, and other laptops can run `ndn-autoconfig`
to find the router.
Ideally, it's possible to discover the unicast addresses of all NDN-enabled
systems over an allowed multicast protocol, to eliminate the need of
designating a router. But we are not there yet.

Yours, Junxiao

On Fri, Mar 25, 2016 at 9:19 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
> *"You?ll need to configure your access point to permit multicast traffic
> among wireless stations."*
>
> I mentioned to Peter that I thought this was the case.  I think the
> concern here is that in "real life", where Peter is hoping to experiment
> with NDN-RTC more and more, we can't always control infrastructure in this
> way.
>
> So what Peter is asking is whether there is (or could be) a way to
> automatically bootstrap local communication between NFDs on different
> devices connected to the same not-necessarily-internet-connected access
> point without requiring any configuration on the AP.
> (Peter please correct me if I'm wrong)
>
> Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/b3c116ee/attachment.html>

From aa at CS.UCLA.EDU  Fri Mar 25 15:49:21 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Fri, 25 Mar 2016 15:49:21 -0700
Subject: [Nfd-dev] NFD version 0.4.1 release
Message-ID: <0D9BEB85-4A1A-4A57-83F5-A0B0E70FDC0D@cs.ucla.edu>

Dear all,

We are also pleased to announce the release of version 0.4.1 of Named Data Networking
Forwarding Daemon (NFD).

The detailed notes for the release:
  http://named-data.net/doc/NFD/0.4.1/RELEASE_NOTES.html

Source code, instruction how to install NFD on Ubuntu Linux (12.04, 14.04, and 15.10) and
OS X (10.9, 10.10, 10.11), tutorials, HOWTOs, a FAQ and other useful resources are
available on the official NFD website:
  http://named-data.net/doc/NFD/0.4.1/

* * *

Other related updates:

- ndn-cxx library to version 0.4.1
  http://named-data.net/doc/ndn-cxx/0.4.1/RELEASE_NOTES.html

- NFD Developer's Guide to revision 6:
  http://named-data.net/publications/techreports/ndn-0021-6-nfd-developer-guide/

- NDN Essential Tools to version 0.3:
  https://github.com/named-data/ndn-tools

* * *

A special welcome to new contributors: Susmit Shannigrahi, Jos? Quevedo, Weiwei Liu,
Spencer Lee.

* * *

The NDN/NFD Team:
  Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko,
  Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon Mastorakis, Yi Huang, Jerald Paul
  Abraham, Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide Pesavento,
  Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila Ben Abraham,
  Patrick Crowley, Syed Obaid Amin, Vince Lehman, Lan Wang, Eric Newberry, Yukai Tu,
  Muktadir Chowdhury, and others (http://named-data.net/project/participants/)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160325/91a1ad76/attachment.bin>

From lanwang at memphis.edu  Mon Mar 28 08:41:22 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 28 Mar 2016 15:41:22 +0000
Subject: [Nfd-dev] two relevant papers from jj
In-Reply-To: <CAOFH+OabMHdF3C6kka6BSi9NMKOGuS0-w5k5gX+1YK1duPFiFQ@mail.gmail.com>
References: <20160323185741.GA89952@caida.org>
	<CAOFH+OabMHdF3C6kka6BSi9NMKOGuS0-w5k5gX+1YK1duPFiFQ@mail.gmail.com>
Message-ID: <D23E574C-E60D-48E8-85F9-E5B5AEA48CD8@memphis.edu>

The first paper is probably relevant to the redmine issue, but I have not read the paper yet.  Wonder if it makes sense to have a number of NDN seminars or NFD calls on these papers (and JJ?s various other papers).  Even though some of his ideas do not look good, it would be nice if we have a clear understanding of the merits and problems.  We need to solicit a few students to read each of these papers.

Lan

On Mar 25, 2016, at 6:35 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:


Hi kc

I guess "relevant" means they are relevant to http://redmine.named-data.net/issues/1966 ?

Yours, Junxiao

On Mar 23, 2016 11:58 AM, "k claffy" <kc at caida.org<mailto:kc at caida.org>> wrote:
Title: Enabling Correct Interest Forwarding and Retransmissions in a Content
  Centric Network
Authors: J.J. Garcia-Luna-Aceves, Maziar Mirzazad-Barijough
Categories: cs.NI
\\
  We show that the mechanisms used in the name data networking (NDN) and the
original content centric networking (CCN) architectures may not detect Interest
loops, even if the network in which they operate is static and no faults occur.
Furthermore, we show that no correct Interest forwarding strategy can be
defined that allows Interest aggregation and attempts to detect Interest
looping by identifying Interests uniquely. We introduce SIFAH (Strategy for
Interest Forwarding and Aggregation with Hop-Counts), the first Interest
forwarding strategy shown to be correct under any operational conditions of a
content centric network. SIFAH operates by having forwarding information bases
(FIBs) store the next hops and number of hops to named content, and by having
each Interest state the name of the requested content and the hop count from
the router forwarding an Interest to the content. We present the results of
simulation experiments using the ndnSIM simulator comparing CCN and NDN with
SIFAH. The results of these experiments illustrate the negative impact of
undetected Interest looping when Interests are aggregated in CCN and NDN, and
the performance advantages of using SIFAH.
\\ ( http://arxiv.org/abs/1603.06012 ,  657kb)
------------------------------------------------------------------------------
\\
arXiv:1603.06044
Date: Sat, 19 Mar 2016 04:03:01 GMT   (4155kb,D)

Title: A Light-Weight Forwarding Plane for Content-Centric Networks
Authors: J.J. Garcia-Luna-Aceves, Maziar Mirzazad-Barijough
Categories: cs.NI
\\
  We present CCN-DART, a more efficient forwarding approach for content-centric
networking (CCN) than named data networking (NDN) that substitutes Pending
Interest Tables (PIT) with Data Answer Routing Tables (DART) and uses a novel
approach to eliminate forwarding loops. The forwarding state required at each
router using CCN-DART consists of segments of the routes between consumers and
content providers that traverse a content router, rather than the Interests
that the router forwards towards content providers. Accordingly, the size of a
DART is proportional to the number of routes used by Interests traversing a
router, rather than the number of Interests traversing a router. We show that
CCN-DART avoids forwarding loops by comparing distances to name prefixes
reported by neighbors, even when routing loops exist. Results of simulation
experiments comparing CCN-DART with NDN using the ndnSIM simulation tool show
that CCN-DART incurs 10 to 20 times less storage overhead.
\\ ( http://arxiv.org/abs/1603.06044 ,  4155kb)
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto: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<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160328/92bda722/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Mar 29 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 29 Mar 2016 07:00:02 -0700
Subject: [Nfd-dev] NFD call 20160329
Message-ID: <201603291400.u2TE0278016988@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160329/5cf8dc10/attachment.html>

From omarilias.elmimouni at nist.gov  Tue Mar 29 09:48:07 2016
From: omarilias.elmimouni at nist.gov (El Mimouni, Omar Ilias (IntlAssoc))
Date: Tue, 29 Mar 2016 16:48:07 +0000
Subject: [Nfd-dev] Content Store entries?
Message-ID: <BN3PR09MB0545633B4096DB165396BED696870@BN3PR09MB0545.namprd09.prod.outlook.com>

Hi all,

Is there a way to access the CS and know what are the CS entries within?

Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160329/351816b0/attachment.html>

From shijunxiao at email.arizona.edu  Tue Mar 29 09:51:55 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 29 Mar 2016 09:51:55 -0700
Subject: [Nfd-dev] Content Store entries?
In-Reply-To: <BN3PR09MB0545633B4096DB165396BED696870@BN3PR09MB0545.namprd09.prod.outlook.com>
References: <BN3PR09MB0545633B4096DB165396BED696870@BN3PR09MB0545.namprd09.prod.outlook.com>
Message-ID: <56fab2ac.1612620a.32056.4cd3@mx.google.com>

Hi El

It?s possible if you attach a debugger to NFD process, or run it within ndnSIM.
See NFD Feature 2340 and associated commits.

Yours, Junxiao

From: El Mimouni, Omar Ilias (IntlAssoc)
Sent: Tuesday, March 29, 2016 09:48
To: nfd-dev at lists.cs.ucla.edu
Subject: [Nfd-dev] Content Store entries?

Hi all,

Is there a way to access the CS and know what are the CS entries within?

Cheers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160329/0d01119a/attachment.html>

From shijunxiao at email.arizona.edu  Wed Mar 30 13:40:44 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 30 Mar 2016 13:40:44 -0700
Subject: [Nfd-dev] KEY in certificate names
In-Reply-To: <ef3c7370-a4bb-43a6-8036-5c42c96c0f47@emhub4.ad.ucla.edu>
References: <D321755A.34347%jefft0@remap.ucla.edu>
	<ef3c7370-a4bb-43a6-8036-5c42c96c0f47@emhub4.ad.ucla.edu>
Message-ID: <CAOFH+OZunRejcC4fG+au11_Lr6qtoUcdQHOAyjUn7vh4tvqZ_Q@mail.gmail.com>

Hi Jeff

The KeyChain is organized in three levels: identity - key - certificate.
An identity name is user specified. An identity requested through ndncert
system is derived from your email address.
A key name is the identity name plus an arbitrary component, which usually
starts with "ksk-" or "dsk-".
A certificate name is the key name with a "KEY" inserted at somewhere
before the last component, and appended with "ID-CERT". A certificate
requested through ndncert system has its "KEY" component inserted after the
institution's site prefix but before user's email username. A certificate
signed through other means can have its "KEY" component appear elsewhere.

When #3568 turns off nfd-autoreg for site prefix, as indicated in the
"implication" of that issue, only those certificates requested through
ndncert system would be usable with automatic prefix propagation.
These certificates are published in a repository running on the gateway
router. That repository has a prefix registration like
/ndn/edu/arizona/KEY, so that it can receive Interests asking for the
certificate of a user. The main reason for having the "KEY" component after
the institution's site prefix is to enable such a repository to register
this prefix and receive Interests for certificates but not other Interests.

Yours, Junxiao

> On Mar 30, 2016, at 12:21 PM, Thompson, Jeff <jefft0 at remap.ucla.edu>
> wrote:
>
> Hi Peter,
>
> I?m looking at the list of test bed certificates:
> http://ndncert.named-data.net/cert/list/html
>
> It seems that everyone?s certificate name has KEY in a weird place. For
> example:
> /ndn/edu/ucla/*KEY*
> /cs/haitao/ksk-1456165717090/ID-CERT/%FD%00%00%01S%0A%82B%B2
> /ndn/edu/ucla/remap/*KEY*
> /peter/ksk-1457996583505/ID-CERT/%FD%00%00%01S%80H%FE%12
>
> Have you talked with the NFD team about this? Will it cause a problem with
> automatic prefix propagation in NdnCon?
>
> Thanks,
> - Jeff T
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160330/bb8fc49c/attachment.html>

From peter at remap.ucla.edu  Wed Mar 30 13:51:15 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Wed, 30 Mar 2016 20:51:15 +0000
Subject: [Nfd-dev] KEY in certificate names
In-Reply-To: <CAOFH+OZunRejcC4fG+au11_Lr6qtoUcdQHOAyjUn7vh4tvqZ_Q@mail.gmail.com>
References: <D321755A.34347%jefft0@remap.ucla.edu>
	<ef3c7370-a4bb-43a6-8036-5c42c96c0f47@emhub4.ad.ucla.edu>
	<CAOFH+OZunRejcC4fG+au11_Lr6qtoUcdQHOAyjUn7vh4tvqZ_Q@mail.gmail.com>
Message-ID: <EED3C464-2C77-4BC7-ABBF-A9155C2E5F94@remap.ucla.edu>

Junxiao,

every data packet signed with my certificate has a keylocator.
question - a Keylocator is a name of certificate (or public key)?
does consumer uses keylocator as-is to issue interest with corresponding name?

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 30, 2016, at 1:40 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Jeff

The KeyChain is organized in three levels: identity - key - certificate.
An identity name is user specified. An identity requested through ndncert system is derived from your email address.
A key name is the identity name plus an arbitrary component, which usually starts with "ksk-" or "dsk-".
A certificate name is the key name with a "KEY" inserted at somewhere before the last component, and appended with "ID-CERT". A certificate requested through ndncert system has its "KEY" component inserted after the institution's site prefix but before user's email username. A certificate signed through other means can have its "KEY" component appear elsewhere.

When #3568 turns off nfd-autoreg for site prefix, as indicated in the "implication" of that issue, only those certificates requested through ndncert system would be usable with automatic prefix propagation.
These certificates are published in a repository running on the gateway router. That repository has a prefix registration like /ndn/edu/arizona/KEY, so that it can receive Interests asking for the certificate of a user. The main reason for having the "KEY" component after the institution's site prefix is to enable such a repository to register this prefix and receive Interests for certificates but not other Interests.

Yours, Junxiao
On Mar 30, 2016, at 12:21 PM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

Hi Peter,

I?m looking at the list of test bed certificates:
http://ndncert.named-data.net/cert/list/html

It seems that everyone?s certificate name has KEY in a weird place. For example:
/ndn/edu/ucla/KEY/cs/haitao/ksk-1456165717090/ID-CERT/%FD%00%00%01S%0A%82B%B2
/ndn/edu/ucla/remap/KEY/peter/ksk-1457996583505/ID-CERT/%FD%00%00%01S%80H%FE%12

Have you talked with the NFD team about this? Will it cause a problem with automatic prefix propagation in NdnCon?

Thanks,
- Jeff T



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160330/7f2df696/attachment.html>

From shijunxiao at email.arizona.edu  Wed Mar 30 14:02:29 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 30 Mar 2016 14:02:29 -0700
Subject: [Nfd-dev] KEY in certificate names
In-Reply-To: <8a268253-dd31-4f3b-b9a6-54c5f6c0590a@EMHUB5.ad.ucla.edu>
References: <D321755A.34347%jefft0@remap.ucla.edu>
	<ef3c7370-a4bb-43a6-8036-5c42c96c0f47@emhub4.ad.ucla.edu>
	<CAOFH+OZunRejcC4fG+au11_Lr6qtoUcdQHOAyjUn7vh4tvqZ_Q@mail.gmail.com>
	<8a268253-dd31-4f3b-b9a6-54c5f6c0590a@EMHUB5.ad.ucla.edu>
Message-ID: <CAOFH+OaOWvvScxGCoHy4pWLL-TGHEND7HdfodMB6eXCmka4CLQ@mail.gmail.com>

Hi Peter

KeyLocator Name field typically contains the certificate name minus the
version number. A verifier should express an Interest with that name to
retrieve the certificate.
Version number is excluded because there could be multiple certificate
versions of the same key.

Having multiple certificate versions of the same key is useful in case of a
site certificate rollover.
Suppose I own key pair K1, and my certificate C1 is signed by Arizona's
certificate A1. Later A1 expires, and is replaced by a new key and new
certificate A2. I can have Arizona sign my same public key K1 into my
certificate C2. C1 and C2 will have same name except different version
numbers. Since both C1 and C2 refer to the same key pair K1, all my old and
new Data can be verified with C2 which is signed by an unexpired
certificate A2.

Yours, Junxiao

On Wed, Mar 30, 2016 at 1:51 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

> every data packet signed with my certificate has a keylocator.
> question - a Keylocator is a name of certificate (or public key)?
> does consumer uses keylocator as-is to issue interest with corresponding
> name?
>
> Thanks,
>
> --
> Peter Gusev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160330/32b6883c/attachment.html>

From peter at remap.UCLA.edu  Wed Mar 30 14:14:45 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Wed, 30 Mar 2016 21:14:45 +0000
Subject: [Nfd-dev] KEY in certificate names
In-Reply-To: <CAOFH+OaOWvvScxGCoHy4pWLL-TGHEND7HdfodMB6eXCmka4CLQ@mail.gmail.com>
References: <D321755A.34347%jefft0@remap.ucla.edu>
	<ef3c7370-a4bb-43a6-8036-5c42c96c0f47@emhub4.ad.ucla.edu>
	<CAOFH+OZunRejcC4fG+au11_Lr6qtoUcdQHOAyjUn7vh4tvqZ_Q@mail.gmail.com>
	<8a268253-dd31-4f3b-b9a6-54c5f6c0590a@EMHUB5.ad.ucla.edu>
	<CAOFH+OaOWvvScxGCoHy4pWLL-TGHEND7HdfodMB6eXCmka4CLQ@mail.gmail.com>
Message-ID: <C8E47574-424D-4B1B-8E9F-D1A7F6599D10@remap.ucla.edu>

Thanks! this clarifies a bit?

i think it?s a good time to ask of the ?canonical? way applications should behave in terms of generating certificates/identities.

here?s how I see it now (with the example of user ?mrfoo? form remap institution):

? User gets testbed certificate (which reflects her identity - can I say that?):
?/ndn/edu/ucla/remap/mrfoo
? his public key is:
?/ndn/edu/ucla/remap/mrfoo/ksk-12345?

? user launches app for the first time and (based on user?s identity) it generates ?app identity? for signing instance certificates:
?/ndn/edu/ucla/remap/mrfoo/ndncon
? app?s public key and certificate:
?/ndn/edu/ucla/remap/mrfoo/ndncon/ksk-<timestamp>
?/ndn/edu/ucla/remap/mrfoo/ndncon/KEY/ksk-<timestamp>/ID-CERT

? app uses app certificate to create an ?instance identity?:
?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>
? app instance public key and cert:
?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/dsk-<timestamp>
?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/KEY/dsk-<timestamp>/ID-CERT

? app instance registers prefix and serves data under this prefix:
?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>

? app?s data packets are signed with instance certificate and keylocator is:
?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/KEY/dsk-<timestamp>/ID-CERT

? app adds instance certificate to its? memory content cache so that it can answer incoming interests with keylocator name

looking forward for your feedback.

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Mar 30, 2016, at 2:02 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

KeyLocator Name field typically contains the certificate name minus the version number. A verifier should express an Interest with that name to retrieve the certificate.
Version number is excluded because there could be multiple certificate versions of the same key.

Having multiple certificate versions of the same key is useful in case of a site certificate rollover.
Suppose I own key pair K1, and my certificate C1 is signed by Arizona's certificate A1. Later A1 expires, and is replaced by a new key and new certificate A2. I can have Arizona sign my same public key K1 into my certificate C2. C1 and C2 will have same name except different version numbers. Since both C1 and C2 refer to the same key pair K1, all my old and new Data can be verified with C2 which is signed by an unexpired certificate A2.

Yours, Junxiao

On Wed, Mar 30, 2016 at 1:51 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
every data packet signed with my certificate has a keylocator.
question - a Keylocator is a name of certificate (or public key)?
does consumer uses keylocator as-is to issue interest with corresponding name?

Thanks,

--
Peter Gusev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160330/f67d9992/attachment.html>

From shijunxiao at email.arizona.edu  Wed Mar 30 21:38:03 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 30 Mar 2016 21:38:03 -0700
Subject: [Nfd-dev] KEY in certificate names
In-Reply-To: <67c5c841-912b-415d-ba40-120959ecb698@emhub4.ad.ucla.edu>
References: <D321755A.34347%jefft0@remap.ucla.edu>
	<ef3c7370-a4bb-43a6-8036-5c42c96c0f47@emhub4.ad.ucla.edu>
	<CAOFH+OZunRejcC4fG+au11_Lr6qtoUcdQHOAyjUn7vh4tvqZ_Q@mail.gmail.com>
	<8a268253-dd31-4f3b-b9a6-54c5f6c0590a@EMHUB5.ad.ucla.edu>
	<CAOFH+OaOWvvScxGCoHy4pWLL-TGHEND7HdfodMB6eXCmka4CLQ@mail.gmail.com>
	<67c5c841-912b-415d-ba40-120959ecb698@emhub4.ad.ucla.edu>
Message-ID: <FEA4964A-ECD9-4A91-9750-F50D33BB57EB@email.arizona.edu>

Hi Peter

This question does not belong to nfd-dev, because it relates to trust model design and not NFD.
I will forward the message to another mailing list and CC you.

NFD?s automatic prefix propagation feature will use the shortest identity available in the KeyChain, which is /ndn/edu/ucla/remap/mrfoo in your example.
Longer, application generated identities do not affect NFD operations.

Yours, Junxiao

> On Mar 30, 2016, at 2:14 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> 
> Thanks! this clarifies a bit?
> 
> i think it?s a good time to ask of the ?canonical? way applications should behave in terms of generating certificates/identities.
> 
> here?s how I see it now (with the example of user ?mrfoo? form remap institution):
> 
> ? User gets testbed certificate (which reflects her identity - can I say that?):
> ?/ndn/edu/ucla/remap/mrfoo
> ? his public key is:
> ?/ndn/edu/ucla/remap/mrfoo/ksk-12345?
> 
> ? user launches app for the first time and (based on user?s identity) it generates ?app identity? for signing instance certificates:
> ?/ndn/edu/ucla/remap/mrfoo/ndncon
> ? app?s public key and certificate:
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/ksk-<timestamp>
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/KEY/ksk-<timestamp>/ID-CERT
> 
> ? app uses app certificate to create an ?instance identity?:
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>
> ? app instance public key and cert:
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/dsk-<timestamp>
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/KEY/dsk-<timestamp>/ID-CERT
> 
> ? app instance registers prefix and serves data under this prefix:
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>
> 
> ? app?s data packets are signed with instance certificate and keylocator is:
> ?/ndn/edu/ucla/remap/mrfoo/ndncon/instance<timestamp>/KEY/dsk-<timestamp>/ID-CERT
> 
> ? app adds instance certificate to its? memory content cache so that it can answer incoming interests with keylocator name 
> 
> looking forward for your feedback. 
> 
> Thanks, 
> 
> -- 
> Peter Gusev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160330/87841c1f/attachment.html>

From shijunxiao at email.arizona.edu  Wed Mar 30 21:56:52 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 30 Mar 2016 21:56:52 -0700
Subject: [Nfd-dev] Jenkins down 20160330
Message-ID: <E0DA3BBC-A9C5-4374-B63C-3ECB777742BB@email.arizona.edu>

Dear folks

The machine that runs a proxy to Jenkins is inaccessible. Jenkins backend is still up but cannot be accessed from Internet.
Lab staff has been contacted.

Yours, Junxiao


From shijunxiao at email.arizona.edu  Wed Mar 30 23:05:40 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 30 Mar 2016 23:05:40 -0700
Subject: [Nfd-dev] Jenkins Master Release Upgrade
In-Reply-To: <56FCBC64.2020900@email.arizona.edu>
References: <56FCBC64.2020900@email.arizona.edu>
Message-ID: <48AABCC9-E434-4E7A-B80C-811FDB9BB1A8@email.arizona.edu>

Hi Eric

If I remember correctly, the master is running Ubuntu 14.04 which is supported until 2019. Thus, it?s unnecessary to perform an upgrade to 15.10 or 16.04.

When Ubuntu 18.04 comes out, we can install a new master and restore the backup.
By that time, I?m probably graduated, and you are probably the main developer :-)

Yours, Junxiao

> On Mar 30, 2016, at 10:57 PM, Eric Newberry <enewberry at email.arizona.edu> wrote:
> 
> Hi Junxiao,
> 
> I think the downtime on Jenkins is a great time for a release upgrade to 15.10. If you think it's a good time, I can go ahead and do a release upgrade. When 16.04 comes out we can upgrade it to an LTS release and leave it there.
> 
> Eric
> 
> --
> Eric Newberry
> 
> Computer Science Undergraduate
> The University of Arizona
> Vice President, University of Arizona ACM Student Chapter
> 




From enewberry at email.arizona.edu  Wed Mar 30 23:09:08 2016
From: enewberry at email.arizona.edu (Eric Newberry)
Date: Wed, 30 Mar 2016 23:09:08 -0700
Subject: [Nfd-dev] Jenkins Master Release Upgrade
In-Reply-To: <48AABCC9-E434-4E7A-B80C-811FDB9BB1A8@email.arizona.edu>
References: <56FCBC64.2020900@email.arizona.edu>
	<48AABCC9-E434-4E7A-B80C-811FDB9BB1A8@email.arizona.edu>
Message-ID: <56FCBF04.4080605@email.arizona.edu>

Hi Junxiao,

I just checked and the current master runs 15.04. I believe the old one 
ran 14.04, however.

Eric

--
Eric Newberry

Computer Science Undergraduate
The University of Arizona
Vice President, University of Arizona ACM Student Chapter

On 3/30/2016 11:05 PM, Junxiao Shi wrote:
> Hi Eric
>
> If I remember correctly, the master is running Ubuntu 14.04 which is supported until 2019. Thus, it?s unnecessary to perform an upgrade to 15.10 or 16.04.
>
> When Ubuntu 18.04 comes out, we can install a new master and restore the backup.
> By that time, I?m probably graduated, and you are probably the main developer :-)
>
> Yours, Junxiao
>
>> On Mar 30, 2016, at 10:57 PM, Eric Newberry <enewberry at email.arizona.edu> wrote:
>>
>> Hi Junxiao,
>>
>> I think the downtime on Jenkins is a great time for a release upgrade to 15.10. If you think it's a good time, I can go ahead and do a release upgrade. When 16.04 comes out we can upgrade it to an LTS release and leave it there.
>>
>> Eric
>>
>> --
>> Eric Newberry
>>
>> Computer Science Undergraduate
>> The University of Arizona
>> Vice President, University of Arizona ACM Student Chapter
>>



From shijunxiao at email.arizona.edu  Wed Mar 30 23:12:05 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 30 Mar 2016 23:12:05 -0700
Subject: [Nfd-dev] Jenkins Master Release Upgrade
In-Reply-To: <56FCBF04.4080605@email.arizona.edu>
References: <56FCBC64.2020900@email.arizona.edu>
	<48AABCC9-E434-4E7A-B80C-811FDB9BB1A8@email.arizona.edu>
	<56FCBF04.4080605@email.arizona.edu>
Message-ID: <D2768A1F-8B3F-480E-8C5C-48B53AE268EA@email.arizona.edu>

Hi Eric

If it?s 15.04, we are already past EOL.
Thus, I agree with upgrading to 15.10 and then to 16.04 upon its release.
I hate that Ubuntu severely reduced the support period of non-LTS versions to only 9 months.

Yours, Junxiao

> On Mar 30, 2016, at 11:09 PM, Eric Newberry <enewberry at email.arizona.edu> wrote:
> 
> Hi Junxiao,
> 
> I just checked and the current master runs 15.04. I believe the old one ran 14.04, however.
> 
> Eric
> 
> --
> Eric Newberry
> 
> Computer Science Undergraduate
> The University of Arizona
> Vice President, University of Arizona ACM Student Chapter
> 
> On 3/30/2016 11:05 PM, Junxiao Shi wrote:
>> Hi Eric
>> 
>> If I remember correctly, the master is running Ubuntu 14.04 which is supported until 2019. Thus, it?s unnecessary to perform an upgrade to 15.10 or 16.04.
>> 
>> When Ubuntu 18.04 comes out, we can install a new master and restore the backup.
>> By that time, I?m probably graduated, and you are probably the main developer :-)
>> 
>> Yours, Junxiao
>> 
>>> On Mar 30, 2016, at 10:57 PM, Eric Newberry <enewberry at email.arizona.edu> wrote:
>>> 
>>> Hi Junxiao,
>>> 
>>> I think the downtime on Jenkins is a great time for a release upgrade to 15.10. If you think it's a good time, I can go ahead and do a release upgrade. When 16.04 comes out we can upgrade it to an LTS release and leave it there.
>>> 
>>> Eric
>>> 
>>> --
>>> Eric Newberry
>>> 
>>> Computer Science Undergraduate
>>> The University of Arizona
>>> Vice President, University of Arizona ACM Student Chapter
>>> 
> 




From enewberry at email.arizona.edu  Thu Mar 31 00:17:33 2016
From: enewberry at email.arizona.edu (Eric Newberry)
Date: Thu, 31 Mar 2016 00:17:33 -0700
Subject: [Nfd-dev] Jenkins Master Release Upgrade
In-Reply-To: <D2768A1F-8B3F-480E-8C5C-48B53AE268EA@email.arizona.edu>
References: <56FCBC64.2020900@email.arizona.edu>
	<48AABCC9-E434-4E7A-B80C-811FDB9BB1A8@email.arizona.edu>
	<56FCBF04.4080605@email.arizona.edu>
	<D2768A1F-8B3F-480E-8C5C-48B53AE268EA@email.arizona.edu>
Message-ID: <56FCCF0D.4060209@email.arizona.edu>

The Jenkins master has been upgraded to 15.10.

--
Eric Newberry

Computer Science Undergraduate
The University of Arizona
Vice President, University of Arizona ACM Student Chapter

On 3/30/2016 11:12 PM, Junxiao Shi wrote:
> Hi Eric
>
> If it?s 15.04, we are already past EOL.
> Thus, I agree with upgrading to 15.10 and then to 16.04 upon its release.
> I hate that Ubuntu severely reduced the support period of non-LTS versions to only 9 months.
>
> Yours, Junxiao
>
>> On Mar 30, 2016, at 11:09 PM, Eric Newberry <enewberry at email.arizona.edu> wrote:
>>
>> Hi Junxiao,
>>
>> I just checked and the current master runs 15.04. I believe the old one ran 14.04, however.
>>
>> Eric
>>
>> --
>> Eric Newberry
>>
>> Computer Science Undergraduate
>> The University of Arizona
>> Vice President, University of Arizona ACM Student Chapter
>>
>> On 3/30/2016 11:05 PM, Junxiao Shi wrote:
>>> Hi Eric
>>>
>>> If I remember correctly, the master is running Ubuntu 14.04 which is supported until 2019. Thus, it?s unnecessary to perform an upgrade to 15.10 or 16.04.
>>>
>>> When Ubuntu 18.04 comes out, we can install a new master and restore the backup.
>>> By that time, I?m probably graduated, and you are probably the main developer :-)
>>>
>>> Yours, Junxiao
>>>
>>>> On Mar 30, 2016, at 10:57 PM, Eric Newberry <enewberry at email.arizona.edu> wrote:
>>>>
>>>> Hi Junxiao,
>>>>
>>>> I think the downtime on Jenkins is a great time for a release upgrade to 15.10. If you think it's a good time, I can go ahead and do a release upgrade. When 16.04 comes out we can upgrade it to an LTS release and leave it there.
>>>>
>>>> Eric
>>>>
>>>> --
>>>> Eric Newberry
>>>>
>>>> Computer Science Undergraduate
>>>> The University of Arizona
>>>> Vice President, University of Arizona ACM Student Chapter
>>>>



From nfd-call-notification at mail1.yoursunny.com  Thu Mar 31 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 31 Mar 2016 07:00:02 -0700
Subject: [Nfd-dev] NFD call 20160331
Message-ID: <201603311400.u2VE02oF007389@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160331/7e943335/attachment.html>