[Ndn-interest] Current state of NDN?

[Junxiao Shi]

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 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 , 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20200701/cfdc955e/attachment.html>