if the local NFD instance has a FIB entry for a very broad prefix (in our case, it was /ndn/edu/ucla
), then even one misbehaving or malicious prefix anchored there is capable of causing major routing disruptions for all traffic at that prefix.
It doesn't need a misbehaving or malicious prefix to have major routing disruptions.
As many have observed, yoursunny ndn6 network peers with the global NDN testbed in multiple locations around the world.
In early 2022, I was announcing a single prefix, /yoursunny
, to the testbed.
Consequently, ASF strategy maintains a single set of measurements for all names under that prefix.
If I start ndnping /yoursunny/_/nrt
on several end hosts each single-homed to a testbed router, testbed routers will gradually optimize their paths toward Japan, applied to the prefix /yoursunny
.
When I add ndnping /yoursunny/_/mia
, I would observe traffic going toward Japan, even if the latter prefix is in USA.
Neither prefix is misbehaving or malicious, but all but one prefix would suffer from suboptimal forwarding paths.
I have one suggestion to mitigate this: Whenever some interest provokes a NACK or is timed-out, the strategy should remember which namespace that was, and only change its nexthop selection for that namespace. Moreover, the strategy could choose to isolate a namespace that's an n-component prefix of the offending interest. The amount of components to remove should be configurable.
This is the classical name granularity problem.
n-component prefix isn't going to work well, because the configuration parameter has to be tailored to each namespace.
While I can describe every name pattern in my network, the patterns may change over time, which means I have to repeatedly request NDNOPS to update their configs.
Instead, ASF strategy should adopt the self-tuning solution is described in:
Teng Liang, Junxiao Shi, and Beichuan Zhang. 2020. On the Prefix Granularity Problem in NDN Adaptive Forwarding. In Proceedings of the 7th ACM Conference on Information-Centric Networking (ICN '20). Association for Computing Machinery, New York, NY, USA, 41–51. https://doi.org/10.1145/3405656.3418712
There's also an issue with ForwardingHint.
Suppose consumers are trying to fetch different content from yoursunny ndn6 network, using the same ForwardingHint=/yoursunny
.
In this case, the strategy should keep separate measurements for "ForwardingHint + a prefix of Interest name", instead of just the ForwardingHint or just the name.