Project

General

Profile

Actions

Bug #2054

closed

NdnCon cannot fetch if connected to a HUB with multiple clients

Added by Junxiao Shi over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
10/13/2014
Due date:
% Done:

100%

Estimated time:

Description

Meanwhile, we’ve tested with JeffT through the REMAP hub (http://128.97.98.7/) and tests failed - he was able to fetch from me (sound and video) however I could not.
Later we tested with Zhehao the same scenario: i connected to REMAP hub, then he connected to it ($ nfdc register /ndn/edu/ucla/remap udp://128.97.98.7 && ndnping /ndn/edu/ucla/remap) and we got the same output: one of us could fetch from the other, but not the other one. And on the REMAP’s NFD status page we could see two faces created for the same prefix /ndn/edu/ucla/remap which is correct.

Finally, we ended up connecting to two different hubs, but those are not just randomly selected hubs - we have to find those hubs that do not have faces registered for their prefixes yet. So I connected to caida hub and Zhehao connected to UCI hub. Both of these hubs after we connected to them had one face registered for their prefixes (/ndn/org/caida and /ndn/edu/uci respectively) and we were able to establish a full conference.

This reveals the problem, that we can’t use NDN-RTC if users connect to the same hub and more than that - we even can’t use NDN-RTC if at the moment of connecting to the hub there is already a registered face with this hub’s prefix.


Related issues 2 (0 open2 closed)

Related to NFD - Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is usedClosedJunxiao Shi10/13/2014

Actions
Blocked by NFD - Feature #2056: nrd: remote prefix registrationClosedYanbiao Li

Actions
Actions #1

Updated by Junxiao Shi over 9 years ago

  • Is duplicate of Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is used added
Actions #2

Updated by Junxiao Shi over 9 years ago

Either #2055 or #2056 can solve this problem.

Actions #3

Updated by Junxiao Shi over 9 years ago

  • Is duplicate of deleted (Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is used)
Actions #4

Updated by Junxiao Shi over 9 years ago

  • Related to Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is used added
Actions #5

Updated by Junxiao Shi over 9 years ago

  • Blocked by Feature #2056: nrd: remote prefix registration added
Actions #6

Updated by Junxiao Shi over 9 years ago

20141013 conference call discussed this problem.

This problem is ultimately caused by the lack of specific prefix registrations on the gateway router.
Each laptop should register a specific Route that it can serve, instead of having nfd-autoreg register a broad Route that it cannot serve all contents.
This means, the gateway router should have a Route such as ndn:/ndn/edu/arizona/ndnrtc/video1 toward laptopA, instead of having a Route ndn:/ndn/edu/arizona and expecting the strategy to figure out video1 is served by laptopA.

#2056 is needed to solve this problem.


Before the ultimate solution is ready, we suggest to try broadcast strategy on ndnrtc prefixes at the gateway router.

The testbed currently configures best-route v2 strategy on ndnrtc prefixes.

The experiment is to change this setting as follows:

  • Set broadcast strategy on ndnrtc prefix under local site prefix. (eg. on ARIZONA, ndn:/ndn/edu/arizona/ndnrtc should use broadcast)
  • Keep best-route v2 strategy on ndnrtc prefixes under remote prefixes. (eg. on ARIZONA, ndn:/ndn/org/caida/ndnrtc should keep best-route)

This configuration may or may not work better than the current configuration, but it's worth trying.

As mentioned in #2055, broadcast strategy is unable to recover from a packet loss. But the probability of a packet loss on this particular hop is no greater than packet loss on other hops.
I'm thinking about making a broadcast v2 strategy that permits consumer retransmission, but this won't happen before #1953 completes because I don't want to increase the risk of persistent loops.

Actions #7

Updated by Peter Gusev over 9 years ago

NDN-RTC works better with updated strategies when more than 2 clients connect to the same hub:

  • Set broadcast strategy on ndnrtc prefix under local site prefix. (eg. on ARIZONA, ndn:/ndn/edu/arizona/ndnrtc should use broadcast)
  • Keep best-route v2 strategy on ndnrtc prefixes under remote prefixes. (eg. on ARIZONA, ndn:/ndn/org/caida/ndnrtc should keep best-route)

However, no quantitative results ready yet.

Actions #8

Updated by Peter Gusev over 9 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF