ndnrtc

So based on our testing today w/ Chengyu I’d like to clarify these steps for publishing using ndncon with WebEX bridging:

• Testbed connection:

  • should be UDP only (TCP connection performs unacceptably poorly for ndncon):

    $ nfdc register / udp://<home hub hostname or IP>
    

  • make sure your home hub has created a backroute towards your machine’s IP address, this makes you discoverable

    to check this, go to your hub’s status webpage and look for your IP address in faces table; then, use located face ID to check it appears in FIB entries for /ndn/broadcast and <home hub prefix> routes

    !!! if hub didn’t created a backroute - contact John DeHart or me immediately so that we can help fixing it

• Configure ndncon to have 1 audio stream and 1 screen stream:

  • remove all other streams by clicking on “X” for corresponding stream panel

  • your screen stream should have just one thread:

    “mid” (700Kbps) thread is enough for demonstrating slides. remove all other threads by clicking on “X” for corresponding thread panel.

• Make sure you see user “confbridge” and group chat “confbridge”

  • if you don’t see them, check your Testbed connection (see above)

• Join chat “confbridge”:

  • make sure that option “Auto-fetch media from joining users:” has at least audio selected (highlighted in blue)

    this way, audio streams from the users who joins this chat will be fetched automatically

• Start publishing your streams

You should be now accessible on ndncon and WebEX.

Peter: After a user does the 'nfdc' they need to do an 'ndnping', right?

John DeHart wrote:

Peter: After a user does the 'nfdc' they need to do an 'ndnping', right?

Not necessarily if the ndncon is running - it issues interests every two second for discovery.
But in general, yes - ndnping will ensure creating a backroute.
I'll create a checklist for ndncon publishers later and mention this.

I sketched up a quick bootstrap checklist for ndncon user. Plan to publish it on ndncon's wiki soon. Let me know if I miss anyting.

• □ get the latest NFD
• □ configure NFD
• □ get the latest ndncon
• □ choose your home hub on NDN testbed, note your home hub's prefix (further: home prefix)
• □ start NFD
• □ start ndncon
• □ enter your ndncon username and your home prefix as a publishing prefix in ndncon's Preferences > General

• □ register UDP tunnel to your home hub:

  $ nfdc register / udp://<home hub ip or hostname>

• □ make sure a backroute was created on your home hub

  go to your home hub status web page, look for your IP address in "Faces" and then lookup corresponding face id in FIB entries; this face id should be found at least in /ndn/broadcast and <home prefix> FIB entries

  if backroute was not created, try running $ ndnping <home prefix> and see if it helped; if it didn't help, contact Peter Gusev or John DeHart

• □ check that you see test producers (/ndn/edu/ucla/remap/freeculture and/or /ndn/edu/ucla/remap/test) in "Active users" of the main ndncon window; if you don't see any, contact Peter Gusev

• □ test fetching

• □ test publishing

• □ test joining a group chat "freechat"; if you don't see a group chat, contact Peter Gusev

Just to confirm - John were you also fetching being connected to WU?

In that case, I think WU-UM-MICH-CSU traffic can be explained by NFD treating one of the consumer's Interests as retransmissions and trying other different faces: i.e. there's a default retransmission suppression of 10ms (Junxiao can confirm on whether it has been changed since the last time we talked at NDNComm 2015) - when multiple consumers are present and are in "fetching" mode (synchronized to the producer), they issue roughly same Interests, though these Interests can be easily timed with more than 10ms difference, thus NFD treats them as retransmissions and tries different faces.

I guess @Junxiao can shed more light on that.

@John, @Junxiao asked (NFD call 3/3/2016) whether we have CPU usage info of UCLA hub for the period @Alex had raging NFD CPU usage during 3/2/2016 Seminar (it's time range b/w/ 2:03 and 2:15pm)?

JeffT may have experienced problems due to changes in traffic routes.

I was connected to WU and watching the traffic map. Normally the traffic from REMAP went through CSU and UIUC. When the seminar audio dropped, I noticed this path was dark and I saw some traffic from CSU through MICH. I don't know how to test the cause of this (Interests not getting through or return Data blocked.)

Also, I never saw traffic through UA, even though it looks like it should be a good route to WU. Any idea why?

Yes, I was connected to WU.

I also found it curious that UA was never used but it could be because the cost of the path from WU-UA-REMAP (58) is
higher than the cost on the path WU-UIUC-CSU-REMAP (39) and then on the way along that path it finds
the data at CSU.

But it seems like it should have tried that path sometimes. I'll check to see if there
is anything wrong with UA.

Peter Gusev wrote:

@John, @Junxiao asked (NFD call 3/3/2016) whether we have CPU usage info of UCLA hub for the period @Alex had raging NFD CPU usage during 3/2/2016 Seminar (it's time range b/w/ 2:03 and 2:15pm)?

Unfortunately, I am not collecting CPU load data yet. I'll add that next.