Bug #2054
closed
NdnCon cannot fetch if connected to a HUB with multiple clients
Added by Junxiao Shi about 10 years ago.
Updated almost 10 years ago.
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.
- Is duplicate of Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is used added
- Is duplicate of deleted (Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is used)
- Related to Bug #2055: No strategy can support realtime traffic over lossy link when autoreg is used added
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.
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.
- Status changed from New to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF
Updated by 
Updated by