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

Ilya Moiseenko iliamo at mailbox.org
Tue Mar 1 12:22:26 PST 2016


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>


More information about the Nfd-dev mailing list