yoursunny blog
computer, Internet, and life

Why Ownly does not Work on the ndn6 Network? A Decade of Policy-Blind Routing

Junxiao Shi

Stardate 1481.6, Antwerp. Three friends opened Ownly, the flagship NDN application developed and published by UCLA Internet Research Laboratory. They started typing into the decentralized collaborative editor, but one of them cannot see the edits. They checked the connection: 📶 online. They checked the prefix registration: ✅ successful. However, the document will not sync.

What worked seamlessly in a UCLA lab failed in the wild because of a missing feature in the routing protocol. This article moves beyond the #2856 confinement issue in the last episode and identifies additional gaps that prevent applications from working across autonomous system boundaries. In particular, we assume a relaxed prefix registration policy that allows the Ownly application to register its desired prefixes in both the global NDN testbed and the ndn6 network, and explore what other features are necessary in order to enable the sync-based communication patterns.

Inter-Domain Routing Built on Grep and Hope

I currently operate two global-scale networks: AS200690 and ndn6.

  • AS200690 is an IPv6-only network registered with RIPE NCC. I have eight routers connected with each other via WireGuard or GRE tunnels. Each router runs the BIRD Internet Routing Daemon in a KVM server.
  • ndn6 is an independent NDN network. I have six routers connected via UDP tunnels over IPv6. Each router runs the NDN Forwarding Daemon (NFD) and NDN Link State Routing (NLSR) in Docker containers.
(read more)

Why Ownly does not Work on the ndn6 Network? A Decade of #2856

Junxiao Shi
last updated

Christmas week 2024, Sydney. A user opened Ownly (then called NDN Workspace), the flagship NDN application developed and published by UCLA Internet Research Laboratory. Her laptop could reach the network, but it couldn't publish. Every attempt to register a prefix was met with a blunt "403 prefix-disallowed" error.

What worked seamlessly in a UCLA lab failed in the wild because of a collision between competing network philosophies. This article looks back on operations of two NDN networks under different philosophies, analyzes why the Ownly application is incompatible with one of the networks. Then I present the lessons learned and identify the practical gaps on why NDN is not ready for transitioning from a "UCLA experiment" to a "global Internet".

ndn6 Network and NDN-FCH 2021

Since 2021, I (re)started operating the ndn6 network, my own global scale NDN network. The ndn6 network is connected to the global NDN testbed but not a part of it. It's an independent network that conforms to the NDN protocol, but has its own routing protocol and prefix registration policies.

The same year, I participated in the NDN-FCH: The Big Rewriteâ„¢ project at the 11th NDN Hackathon, during which I led a team to build a new version of "Find Closest Hub" service:

(read more)

Capture and Analysis of Traffic Traces on a Wide-Area NDN Testbed

Sankalpa Timilsina, Davide Pesavento, Junxiao Shi, Susmit Shannigrahi, Lotfi Benmohamed

Presented at: 10th ACM Conference on Information-Centric Networking (ICN 2023)

High-quality network traffic measurements from realistic network deployments are crucial to analyze and better understand emerging network technologies for the purpose of maturing them. However, achieving this measurement goal for the Named Data Networking (NDN) protocol remains a challenge mainly due to the lack of real-world deployments. To address this gap, we have created a dataset of NDN traffic traces and a software toolkit for capturing, analyzing, and replaying these traces. Our dataset, obtained directly from the real routers of the official NDN testbed, is the first non-synthetic dataset of this scale openly available to the research community. This paper presents the dataset and the tools, discusses its properties, and shares insights applicable to other NDN research.

Read full paper at ACM Digital Library: Capture and Analysis of Traffic Traces on a Wide-Area NDN Testbed

Software and datasets available on GitHub:

(read more)

Use NFD nightly with Mini-NDN

Junxiao Shi

Mini-NDN is a network emulation tool that enables testing, experimentation, and research on the Named Data Networking (NDN) platform. It uses container technology to emulate a small-to-medium NDN network topology. Each container represents a network node, in which it runs NDN Forwarding Daemon (NFD), NLSR routing daemon, and other NDN programs. Virtual Ethernet adapters are added between containers to simulated network links.

During the recent 12th NDN hackathon, I worked with my buddy Saurab Dulal to improve Mini-NDN. One of our achievements was a shiny new Mini-NDN installation script. The new script can install NDN software binary packages from named-data PPA, which saves time significantly compared to the alternative of compiling from source code.

However, a drawback of named-data PPA is that, the binary packages available there are only updated after each NFD release, which occurs a few times a year. If it has been several months since the release, the PPA packages would be ancient. They would not include the latest features, improvements, and bug fixes in the NDN codebase.

If you want to use up-to-date NDN software, but do not want to wait for the software to compile from source, I can offer another option: install the weekly automated builds from NFD-nightly. This article explains how to do that.

Operating System

(read more)

NFD nightly APT repository

Junxiao Shi

This article contains instructions of NFD nightly APT repository, which provides automated builds of NDN Forwarding Daemon (NFD) and related software.

This article was latest updated on 2021-10-30 to reflect latest changes.

Instructions

To install NDN software from NFD nightly APT repository:

  1. If you have previously installed NDN software from named-data PPA or source code, you need to delete them to avoid conflict. See switch between installation methods section below.

  2. Visit https://nfd-nightly.ndn.today webpage, choose your operating system and CPU architecture, and you'll get a setup command.

    Run this setup command in the terminal, which adds NFD-nightly as a package source.

  3. Update package lists:

    sudo apt update

  4. Install desired packages, such as:

    sudo apt install nfd ndnping ndnpeek infoedit

    You can see available packages on https://nfd-nightly.ndn.today webpage.

(read more)

NDN Video Streaming on the ndn6 Network

Junxiao Shi

The ndn6 network, my own global scale Named Data Networking network, came back earlier this year. I moved my NDNts video streaming app into the ndn6 network, to reduce dependency on the NDN testbed. How well is it performing?

QUIC ⇒ HTTP/3

In my last article "NDN video streaming over QUIC", I used Chrome browser's experimental QuicTransport feature to perform video streaming over Named Data Networking. The analysis revealed that QUIC transport was generally performing better than WebSockets in this application, according to metrics including video resolution and startup latency.

Web technologies are constantly evolving. QuicTransport was in Origin Trial status at the time, but it was discontinued as of Chrome 91. WebTransport was introduced in its place. The main difference is that, WebTransport uses HTTP/3 as the underlying network protocol, while QuicTransport uses QUIC datagrams.

Since HTTP/3 runs over QUIC, I expect no performance difference between the two. I promptly registered for the WebTransport Origin Trial, and updated my gateways and NDNts libraries to use the new API.

(read more)

Return of the ndn6 Network

Junxiao Shi

In 2014, I installed NDN Forwarding Daemon (NFD) router on a tiny 128MB virtual machine. I named this node ndn6: IPv6 NDN router, because the virtual machine, purchased from the original Low End Spirit forum for €3.00/year, was an IPv6-primary service. I idled this router for three years, and then shut it down in 2017.

I created NDNts: NDN libraries for the modern web in 2019. Since then, I have been publishing my own content over Named Data Networking, most prominently the NDN push-ups. NDNts does not require a local forwarder, so that I operated video repositories by directly connecting to a nearby testbed router via UDP tunnel. Shortly after, I started experimenting with QUIC transport, which involved deploying several NDN-QUIC gateways to translate between NFD's plain UDP packets and Chrome's QUIC transport protocol.

One day, I realized: my content is sent to the global NDN testbed, and then retrieved back to my servers for delivery to browsers over QUIC. My video repository in Buffalo and NDN-QUIC gateway in Montreal are quite close to each other, but the packets are taking a detour to Boston, increasing latency by at least 10ms. Also, since I statically assign a testbed router for each application, a downtime of that router would bring my application offline as well. I thought, instead of operating isolated applications and gateways, I should setup my own NDN network.

Setting up a new NDN network is no small feat. NFD and NLSR implement forwarding and routing, but I also need to:

  • Decide on a topology between different routers.
  • Assign a name prefix to each router.
  • Install and update software in each router.
  • Generate configuration files for NFD and NLSR, and modify them as the topology changes.
  • Monitor the network and know about ongoing problems.
(read more)

Face and PacketHandler in NDNph

Junxiao Shi
last updated

Face is an overloaded term in Named Data Networking (NDN). My last article explained what is a face in NDN forwarders and NDN libraries, and then described the endpoint design in my NDNts library. This time, I'll introduce a unique face API design in my NDNph library.

NDNph is a C++ header-only library that enables low level application development. It supports multiple platforms, but is primarily designed for microcontrollers with limited hardware resources. In particular, RAM capacity is very limited, with typical values ranging from 50KB (ESP8266) to 320KB (ESP32). This necessitates a different API design for the face.

Overhead of a Traditional Face

Traditionally, a face in NDN libraries has the following features:

  • send and receive NDN network layer packets
  • match incoming Data against outgoing Interests
  • keep track of Interest timeouts
  • dispatch incoming Interests to producer callback functions
(read more)

NDN Video Streaming over QUIC

Junxiao Shi

NDN over WebSockets == TCP over TCP

Named Data Networking (NDN) was first ported to web browser environment in 2012. At that time, a browser-based JavaScript application can communicate with the Internet via either XMLHTTPRequest or WebSocket. Feeling that WebSocket is a better match for the NDN implementation at the time, I wrote the initial code for a CCNx WebSocket proxy.

Web applications would connect to this proxy over TCP, negotiate a WebSocket connection, and send NDN packets in WebSocket frames. The proxy then decapsulates these frames, and delivers the NDN packets to ccnd forwarder over TCP.

NDN-over-WebSockets survived multiple protocol changes over the years, and made its way into the NDN Forwarding Daemon (NFD). It worked fine for simple NDN web applications, such as status pages and text chat, and even file retrievals.

Recently, with the rise of video streaming on the NDN testbed, congestion control functionality starts to show up in NDN libraries. Then, a question popped into my mind: WebSockets run over TCP, and NDN congestion control algorithms are largely borrowed from TCP, would this cause any problems?

(read more)

What is a "Face" in Named Data Networking?

Junxiao Shi
last updated

Face is an overloaded term in Named Data Networking (NDN). Most developers have some feeling of what a face is, but often find it hard to explain. This article attempts to demystify the concept of face in NDN.

"Face" as Defined in Publications

The original NDN paper, Networking Named Content, introduces the term face in a footnote:

We use the term face rather than interface because packets are not only forwarded over hardware network interfaces but also exchanged directly with application processes within a machine.

NFD, the original NDN forwarder software, explains in the NFD Developer Guide:

(read more)