[Nfd-dev] NDN-RTC testing, next steps

Tue Mar 1 11:36:53 PST 2016

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>