[Nfd-dev] Help with NDN-RTC measurement/troubleshooting

[Burke, Jeff]

Forwarding a portion of this thread from the PI mailing list for consideration in the call today. (Unfortunately neither Peter or I can join the call but we can check in with Jeff Thompson about the discussion and join next week.)
Jeff

From: Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>>
Date: Wednesday, February 24, 2016 at 3:23 PM
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "ndn-pis at lists.cs.ucla.edu<mailto:ndn-pis at lists.cs.ucla.edu>" <ndn-pis at lists.cs.ucla.edu<mailto:ndn-pis at lists.cs.ucla.edu>>, "Dehart, John" <jdd at wustl.edu<mailto:jdd at wustl.edu>>, "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
Subject: Re: [Ndn-pis] Week-by-week steps with NDN-RTC

I think today's ndn-rtc trial is a great success -- although maybe just half dozen people on it, still perhaps the largest size we have tried.
I fully support that we should keep doing it from now on, to tune it up.  Hope we get more people on ndn-rtc next time (I will make sure that everyone in my group gets on it)

I was disappointed that we only had 4 PIs on the call -- everyone stated on the doodle pool that they are available on this time slot (2PM PT Wed).  Hope to see more people get on next seminar.

I assume the NFD call group would follow up the specific questions you listed below.

Lixia

On Feb 24, 2016, at 3:14 PM, Burke, Jeff <jburke at remap.UCLA.EDU<mailto:jburke at remap.ucla.edu>> wrote:

Hi,

So, I think the call quality of NDN-RTC was not so great for the seminar... but we tried it. Thanks to all that participated!

I'd like to suggest that we keep using NDN-RTC each week (with WebEx as a backup) and treat its performance as an engineering problem to be collectively solved in steps week-by-week with participation from people in each group as time allows, in addition to driving bigger picture research questions.   (Put another way – I am excited that we are dealing with congestion control but the conversation seems to be not heading to make any performance impact in the next two months.)

Would people be open to this approach?

For example,

1) Could we hack traffic monitoring tools specific to the NDN-RTC namespace, and use them next week to understand what's happening at each node?

2) Any quick solution to audio prioritization?

3) Peter, can we turn on the "adaptive rate control" detection algorithms for next week but disable stream switching, so we can start to log whether or not the E2E approach detect congestion but not actually rely on it working?

4) Is there an immediate congestion control idea that could be tried on just a couple of (perhaps non-testbed nodes) in

5) Should we explicitly collect impressions from everyone on performance?

Just brainstorming out-loud, but I'm wondering if it makes sense to try to treat this as a practical collective problem to get working ASAP...  we could use the help.

Thanks,
Jeff

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