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

Wed Mar 2 13:18:32 PST 2016

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>