[Nfd-dev] NDN-RTC testing, next steps
iliamo at mailbox.org
Tue Mar 1 11:36:53 PST 2016
Before anyone puts efforts in Mininet emulation, I suggest to read section 5 and
Table 1 of Mininet paper
Mininet is a good tool for achieving protocol correctness, but it's not a good
choice for experiments that depend on precise timing.
> On February 28, 2016 at 6:38 PM "Burke, Jeff" <jburke at remap.ucla.edu>
> 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?
> 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?
> 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?
> 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.
> 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 .
> 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
> 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?)
> 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
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nfd-dev