[Ndn-interest] Current state of NDN?

[Dehart, John]

On Jul 1, 2020, at 1:51 PM, Junxiao Shi via Ndn-interest <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>> wrote:

Hi Michael

>> As I understand, one of the "unfit" policies is that every NDN testbed node must be controlled by "the NDN testbed management institution".
>
> Yes, that is an issue.

Actually, we have been working with a site for a few months now where we, NDN Testbed management, do not control their node.
So far it seems to be working well. We should be able to officially loosen this restriction.

How much freedom does this site have in terms of configuration choices?
For example, can they use a forwarder other than NFD and a routing program other than NLSR? Can they decide what names to advertise into routing system?
If they still have to use the configuration generated by the NDN testbed management institution, the node operator is effectively a robot that executes Ansible commands.

The intent and so far the practice has been that the local node operator is, as you say, effectively a robot that executes Ansible commands.

John



> The reason is that the current testbed is technically an intra-domain network. In IP terms, it's a single Autonomous System (AS). Naturally, a single entity should be managing this network.
> To have an "open testnet" without centralized control, we would need an inter-domain network.
>
> What we already have:
>       • High speed forwarding.
>       • Inter-domain hyperbolic routing.
> What are still unresolved:
>       • Name assignment policy, as you already mentioned. One of the ideas is to derive NDN names from DNSSEC, but this would create a dependency on IP infrastructure.

I have mixed feelings about this. As I understand it, this proposal uses DNS right at the top level instead of behind a prefix, like /dns/? I hope this is just for presentation.

I met the author at a seminar. His idea was to use DNS at the top, so that NDN doesn't need to deal with legal disputes surrounding name assignments, but delegate these problems to ICANN.
The NDN name is the reverse of DNS name. Thus, I can have /com/yoursunny and Cupertino can have /com/apple.


>       • Producer mobility. On the current testbed, producer mobility is supported through prefix readvertisement. When a mobile producer connects to any of the testbed nodes, its prefix is announced into the global routing system. This would not scale in an inter-domain network. The solution is forwarding hint, but it's neither fully specified nor adopted by applications.

The web has come a long way without producer mobility. I don’t think this is required to get started.

The web has producer mobility in the form of DNS. My website is https://yoursunny.com<https://yoursunny.com/> , which is the only name my visitors remember. I can move between provider network freely, as long as I update the DNS record. My visitors can still type https://yoursunny.com<https://yoursunny.com/> and reach my site.

In NDN without producer mobility, my website name has to start with the network's name, so my website name becomes /ndn/edu/neu/com/yoursunny. If I move, I have to rename my website to /ndn/edu/wustl/com/yoursunny. My visitors cannot find my site anymore.

NDNS is supposed to take the role of DNS. I can have /com/yoursunny, and use NDNS to associate this name with a forwarding hint such as /ndn/edu/neu assocated with the network. My visitors type /com/yoursunny , and their browser can query NDNS to find the forwarding hint and reach my site.
NDNS is one form of producer mobility. The problem is that, NDNS software is not actively maintained or deployed, and there's almost no application adoption.


>       • Trust of routing messages. Although we have hyperbolic routing, the trust schema in the routing protocol still depends on a single trust anchor, which does not work in an inter-domain network.
>
> I wonder what other policies are deemed "unfit for everybody else"?

"13. We strongly discourage and will not accept requests to join the NDN testbed if there is no intention to use it for productive research. Connecting to the testbed for the sake of being connected is a violation of the current policies.”

Maybe there is room for interpretation in “productive research”, but I think this excludes everybody who is not part of a research group. Sure, I can start tinkering without the testbed by setting up my own network, but that’s missing the magic of networking.

I think that rule applies to becoming a testbed router, with routing and stuff.
You can surely connect to the testbed as an end host, and there's no technical means to stop you from sending commercial traffic.
I asked a few years ago whether I'm allowed to watch YouTube via Ethernet tunnel over NDN testbed, and I got a yes answer. https://yoursunny.com/t/2017/tunnel-Ethernet-over-NDN/ I got the tunnel working, but never reached the speed needed for YouTube.


As the NDNSSEC-paper says, there are many non-technical challenges and I wonder if it’s time to start experimenting by starting a testbed that is not managed centrally.

If you can afford the efforts and equipment and headaches and law suits, sure.

Yours, Junxiao
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20200701/edb4659a/attachment.html>