LWN.net Weekly Edition for October 25, 2012

Content-centric networking with CCNx

Content-centric networking (CCN) is a novel approach to networking that abstracts away the specifics of the connection, and focuses on disseminating the content efficiently. This is in contrast to the connection-oriented approach used in most IP applications, which requires establishing a channel between two nodes with known addresses. CCN excels at the comparatively common task of fetching static documents for multiple end users, which causes significant strain on the network as it is implemented in the one-to-one-connection-oriented TCP. The concept has been discussed for decades, but Palo Alto Research Center (PARC, formerly a subsidiary of Xerox) is actively developing a real-life implementation called CCNx, which is usable on Linux and other UNIX-like systems today.

What centric what?

CCNx is the brainchild of PARC's Van Jacobson, and if anyone is qualified to rethink core Internet protocols, Jacobson is. Among other things, he fixed TCP flow control and designed the IP multicast backbone. CCNx clearly draws on the lessons Jacobson has learned about network congestion over the years; in a 2006 talk at Google, he described how the NBC television network was slowed to a crawl during the Olympics by thousands of web users requesting copies of the same video clip. The data was identical and there was no secrecy required; if the backbone of the network could only recognize that the requests were identical, it could dispense with retransmitting it from the originating server — and make use of the existing copies closer to the final hop.

That said, CCNx (and CCN in general) is not a replacement for existing transport protocols; it is designed to run on top of them, and in fact to be oblivious as to which mechanisms are used underneath: TCP, UDP, IP multicast, link-level broadcast, or even point-to-point wireless. The goal is that a party sends a request for a document out into the open — with no destination address — and anyone who hears the request and has a copy of the document can respond to it. It is irrelevant whether the copy that is eventually returned originates from disk storage on a server, memory in a gateway router, or any other source. Naturally, making the network efficient means that the closest party who both hears the request and has the document should return it. In practice, CCN expects nodes to intelligently cache the documents that they route to the end-user nodes; doing so (and keeping popular documents close to the final hop of the route) is what prevents congestion.

For the scheme to work, of course, the authenticity of the content must be verifiable from the data itself. If that property holds, the most noticeable benefit is that, when popular content is requested by numerous end-users, there is far less congestion on the network — ideally no additional congestion, as routers at the edges of the network retransmit their existing copies of the content, without even needing to propagate the requests upstream. There are other benefits as well, such as the fact that participating nodes do not need static or globally-unique names. This allows low-power sensors to respond to requests (e.g., "what is the current temperature") without needing a complete multilayer network stack, and it allows clients to send such requests without knowing the topology of the network.

On the flip side, CCN does pack more information into the names and metadata of documents, incorporating things like versioning and timestamps. For example, once a server publishes a document over CCN, it no longer has control over it, because it propagates across the network. Consequently, all updates to a document must be issued as superseding publications that can be identified as updates referring to the original, and that can be verified as authentic.

CCNx specifics

CCNx tackles both the document-updating question and the authentication question in its messaging scheme. Nodes ask for content with an Interest message, in which the only required field is the name of the desired content (although time-limits, maximum number of hops, and other fields are available). Such sending nodes could be either end-user applications making the original request, or network infrastructure nodes passing along requests they cannot answer.

A Data message that can be authenticated as consistent with the original publisher is required to complete the puzzle; however the original publisher never needs to be made aware of the request. The Data message includes the requested data plus a cryptographic signature. The signature is generated against the data and an information block that contains a time stamp, the digest of the publisher's public key (which is required for nodes to verify the signature), and may optionally include other information such as the data type. Nodes are supposed to check the signatures and discard any content that fails verification; this "lazy" invalidation is intended to cut down on spoofing attacks without introducing significant overhead.

That is essentially all there is to CCNx; there are just two message types. Additional features like encryption and application state management are left entirely up to the layer above CCNx. Participating nodes are allowed to shape traffic as best they see fit. On the application side, that could mean interleaving requests for chunks of large file downloads with higher-priority requests to check mail. Because CCNx does not keep persistent connections open between nodes, Quality of service (QoS) is in the hands of the end-user.

Interestingly enough, CCNx does not impose any restrictions on the formatting of the actual document name, other than that it be a sequence of bytes and be hierarchical. The hierarchical dimension exists to allow publishers to publish related content using the same prefix. That could be interpreted as a given prefix representing a directory, or as a given prefix representing small chunks of a single file that needs to be reassembled further up in the application stack. The documentation describes an URL-like syntax for CCNx names of the form ccnx:/PARC/%00%01%02 and includes some recommended naming conventions, but they are advisory only. For example, it suggests using a DNS name for the first component in order to ease the transition, and it recommends encoding the timestamp as another component. Although optional, these conventions should allow nodes to perform efficient matching of content names by comparing the prefixes and without examining the data itself.

The strategy for running an efficient CCNx node is also left up to the implementer, although here again the project's documentation includes recommendations (under the "CCNx Node Model" sub-heading). The recommendation includes maintaining a content store (CS) indexed by document name, a table of unsatisfied Interest requests, and a table of outbound interfaces on which unsatisfied Interests have been forwarded. It is anticipated that a node will have multiple options at its disposal for forwarding Interest messages it cannot fulfill; choosing which links or routes are best at any given moment allows the node to be opportunistic.

Running CCNx

The CCNx distribution contains a handful of utilities that allow one to test CCNx on a single machine or on the local network. The latest release is 0.6.2, from October 3. It includes C source for both a simple CCNx forwarder and a content repository, a simple CCNx chat application written in Java, CCNx plugins for the VLC media player and Wireshark packet sniffer, and Android versions of the repository and chat applications. Ubuntu is the only Linux distribution tested, but the dependencies are lightweight: libcrypto, expat, libpcap, and libxml2.

With the software built, the first step is to start the CCNx daemon with bin/ccndstart. This is a script that launches the ccnd daemon and directs output messages to the terminal, although you can also monitor its status from http://localhost:9695 in a web browser. The ccnd daemon is what passes CCNx messages to other nodes; how it does so depends on the network transports defined in its configuration. For testing on one machine, ccnd does not require any configuration; however, editing the ~/.ccnx/ccnd.conf is required to forward CCNx requests between machines. The example configuration file is light on detail; its only example entry is the line

    add ccnx:/ccnx.org udp 224.0.23.170 59695

which tells ccnd to route all ccnx: URL requests that begin with ccnx.org to UDP port 59695, over the 224.0.23.170 multicast address. This address is reserved for CCNx with IANA.

The content repository can be started with the bin/ccnr binary. It defaults to running the repository on the current directory, but another location can be specified by setting the CCNR_DIRECTORY environment variable. Similarly, a name prefix for the available files can be set using the CCNR_GLOBAL_PREFIX variable. The repository's other key settings are configured in the data/policy.xml file, the most important setting being which prefixes the repository should answer for. By default, however, this prefix is empty, so the repository will answer all requests — good for testing, but not terribly practical for deployment.

The file utilities include the command-line tools ccnls, ccnputfile, and ccngetfile, as well as the graphical file browser ccnexplore. Dropping files in and rearranging them gets old after a few hours, but the chat application and VLC plugin offer more amusement. Both make it clearer how CCNx's network abstraction simplifies things from the user's perspective. To join a chat room, for example, one needs only the name of the room (e.g., ccnchat ccnx:/testroom1); the underlying transport and the network addresses of the participants never factor in.

In that sense, working in CCN is reminiscent of Zeroconf service discovery, except that there is no discrete discovery step involved. The long hierarchical document names suggest the route-embedding features of IPv6 addresses as well; similarly, the ability to retrieve a valid chunk of data from any source reminds one of Bittorrent. Of course, it is difficult to assess the congestion-prevention capabilities of CCN with just one or two machines, but the same would be true for most traffic-shaping or QoS techniques.

There are still aspects of CCNx that have yet to be finalized, how to avoid content naming collisions or spoofing for example. Perhaps the advisory naming conventions will be formalized, or perhaps if CCNx becomes an IETF standard, other techniques will arise. Also, CCN offers better aggregate throughput on the network by answering content requests with a nearby copy of the document, rather than fetching the original again. The downside is that publishers generally want to know page view statistics, so some form of reporting may need to be devised.

In his Google talk, Jacobson described CCN as a different perspective on how to use the network, rather than as a new suite of protocols. He compared it to the difference between telephone companies' circuit-switched networks and the first packet-switching data networks. The wires and the nodes were the same — the difference is in how the conversations and connections are expressed. Pessimists are understandably unhappy with the glacial pace of the IETF or of widespread IPv6 adoption, and the same people might argue that CCN will never replace the entrenched protocols like HTTP that dominate today. Perhaps it will not; it is still intriguing to experiment with, however, and one should certainly never discount the commercial Internet players' drive to adopt a new technology when it offers the prospect of saving them money — which CCN certainly could.

Comments (19 posted)

GNOME and/or systemd

While GNOME is used predominantly on Linux desktops, it has historically supported other platforms as well. But the project is again debating whether or not it should add hard dependencies on low-level system components when those dependencies could have the side effect of making the GNOME desktop unusable on non-Linux operating systems and a large portion of Linux distributions. In this instance, workarounds for other systems are not too onerous, but the topic invariably leads to a larger discussion about how the project operates and establishes its direction.

Daemons and desktops

On October 19, Bastien Nocera announced to the GNOME desktop-devel-list that he would make systemd a hard requirement for gnome-settings-daemon's power plugin. Doing so, he said, would allow the plugin to better handle suspending the system, and it would simplify the power management codebase. The patch set also drops support for ConsoleKit and UPower. Nocera enumerated several benefits of using systemd for suspends, including providing better information to applications about suspending.

Perhaps predictably, several developers replied that adding a systemd dependency would make GNOME harder to deploy on systems that do not use systemd: in particular Ubuntu, Gentoo, the BSDs, and Solaris. At the very least, these downstream projects would have to patch gnome-settings-daemon, which makes maintenance more difficult for everyone. The distributions will have to dedicate time to patching and testing their branches, but a number of bug reports will invariably make their way back to Nocera and the other GNOME developers, too — bug reports that GNOME can do little about, since they involve downstream work.

Antoine Jacoutot said that the change would impact OpenBSD's decision to ship GNOME in future releases; Sebastien Bacher echoed the sentiment for Ubuntu, as did Brian Cameron for Solaris, and Alexandre Rostovtsev for Gentoo. For the present, however, the non-systemd projects are looking for a workaround, starting with a way to re-implement the systemd features expected by the power plugin. Although many seemed to initially interpret Nocera's "hard requirement" message to mean that gnome-settings-daemon would have a build-time dependency on systemd, he later clarified that the change relied on systemd's D-Bus interface, and that through run-time detection, the system would simply disable the power plugin if systemd was unavailable. According to another message, the power plugin only uses two systemd interfaces, inhibitor locks and session tracking.

But if the plugin that introduces the dependency only needs to access two well-known interfaces over D-Bus, the question becomes whether or not systemd is actually required at all. In the email cited above, Bacher asked if Nocera had considered defining the interfaces as a standard, so that GNOME would work on any system that implemented them. Nocera responded that the question should be directed at the systemd developers, as he was not interested in taking on the task. That suggestion garnered little support; although Rostovtsev expressed some interest, Bacher replied that he did not have time to undertake the task.

Complicating matters further is the prospect that if systemd becomes a dependency for one GNOME module, it is increasingly likely that additional modules will start expecting it as well. That could lead to the point where the non-systemd OSes conclude that the GNOME desktop environment is more work to support than it is worth, and the OS projects simply drop it. Jacoutot, who maintains the GNOME packages for OpenBSD, expressed concern over that possibility:

Similarly, in his message, Cameron noted that Solaris already has its own power management features, several of which support enterprise and cluster-management features that are not addressed by systemd. As a result, although Solaris is interested in making GNOME run if possible, the potential loss of features expected by customers is a likely deal-breaker.

GNOME ripples

For his part, Nocera argued that as module maintainer, the decision was his, and ultimately he needed to make it on the basis of how it affected his ability to maintain the code — not on the needs of downstream projects. As he told Jacoutot:

But there were critics of adding the dependency within the GNOME project, too. Florian Müllner pointed out that other packages would be affected by the patches, including GNOME Shell, and Colin Walters argued that because the full GNOME desktop depends on gnome-settings-daemon, the move did affect other packages and other maintainers.

In particular, Walters took issue with dropping support for ConsoleKit and UPower systems, because doing so would cause a major regression for GNOME on systems that used them. He offered to take over maintainership of the relevant bits of code. Nocera objected to that idea, characterizing it as a "we 'support it, kind of, but not really'" approach that would result in numerous bugs. Walters replied that bugs of that sort are an ongoing burden already, and that his objection was one based on general principle:

Nocera countered that he had carefully responded to every comment, and that his decision was in line with GNOME's guidelines. As to the process, he said:

Walters also pointed out another issue, which was that maintaining ConsoleKit support is unnecessarily complex because of how little code is shared between the various GNOME modules. Matthias Clasen agreed, saying "in some cases (such as power or randr), we have dbus interfaces, in others we share code in libraries (randr again, xkb, backgrounds), and we also copy some glue code around (user accounts come to mind)."

Steering

Certainly, no one would argue that Nocera and other module maintainers are not free to make the decisions that they see as the best path forward; in fact GNOME has long held "maintainers rule" as a mantra. As this case illustrates, though, that philosophy is far trickier to live by in the real world than in the abstract. Maintaining systemd and ConsoleKit support in parallel is a considerable amount of work, and it does not seem fair to impose that burden on Nocera. But as Walters and others pointed out, GNOME's modules do not live in isolation — introducing an external dependency in one module pulls it in for others (which can become chaotic), while dropping support for existing configurations harms users (and should not be done cavalierly).

Systemd is also something of a special case because its availability is a decision historically made by the distributions (and other downstream OS projects), based on system-wide factors that GNOME does not control. As Jacoutot explained, implementing workarounds for the gnome-settings-daemon power plugin is not likely to be a Herculean ordeal, but adding such a low-level dependency suggests that the number of workarounds require will begin to increase. Systemd's maintainers have no problem with this; they are intent on making the tool useful for more and more tasks.

But GNOME as a cross-platform project has different considerations. In this case, perhaps the long-term impact of the decision means "maintainers rule" is insufficient. Vincent Untz thought so, saying "this is exactly the kind of stuff that, at least from my perspective, was raised during the [Annual General Meeting] at GUADEC." At the meeting, several suggested that GNOME needed a "Technical Board" of some sort to set long-term strategy and make broader decisions that would affect multiple modules.

There has not been significant movement on that point since GUADEC; at the time the GNOME Release Team told the audience that it had been serving as sort of an ad hoc decision-making board in recent years, but that it was not entirely comfortable with the role. Nevertheless, it is still functioning in that capacity; Nocera pushed the changes through on October 22, in response to which Frederic Peters from the Release Team commented:

Thus, GNOME users should know in a few days whether or not GNOME 3.8 is likely to require systemd or to drop support for ConsoleKit. But whichever happens, the debate is likely to continue.

Comments (72 posted)

The Boxee Box: too free to live?

It may still be difficult to wander into a local electronics retailer and come away with a desktop system running Linux. But there is likely no shortage of Linux-based devices on sale in that store; one needs only wander past the Linux-based phones and cameras to the shelf where the networked video players live. Linux dominates on such devices, but, as the recent history of the Boxee Box shows, "Linux inside" does not necessarily mean "free" or that the device has a future.

The Boxee Box is based on the Boxee software which, in turn, is based on the XBMC media player. It gained an enthusiastic early following as the result of its open-source roots and the device's plugin infrastructure. The Boxee Box handled a wide variety of media types from the outset; in places where it fell short, others could easily provide plugins to fill in the gaps. So the Boxee Box became known as a device that could play almost anything.

Boxee Box users lost some of their enthusiasm over time. Early versions could be "unboxed" and made to run arbitrary software, but the company closed that hole in 2010 and it does not appear that anybody has figured out how to break newer versions. Bug fixes and improvements from Boxee slowed down over time, leading to user frustration. And now those users, the people who have supported Boxee to this point, have been informed that Boxee is abandoning the device in favor of its upcoming, USA-only "Boxee TV" product.

One can maybe understand a company that feels the need to declare end-of-life for a two-year-old consumer electronics product; such offerings often don't last anywhere near that long. But Boxee has not just left a product behind; it also left the entire community that had embraced that product. The new "Boxee TV" is a clear step backward in a number of regards: no plugin support, no support for arbitrary file formats, and a highly proprietary architecture throughout. It now features a new deal with US cable provider Comcast (ensuring that Boxee will not be blocked by the just-allowed encryption of basic cable content in the US) and features designed to warm the entertainment industry's heart. This article in The Verge describes the situation clearly:

What has happened here is clear: Boxee has gone from trying to make its customers happy to making the entertainment industry happy instead. If that meant dumping its old customers and the development community that had built itself around the older product, then so be it. As XBMC developer Nathan Betzen put it, Boxee has moved from trying to expand its users' rights under copyright law to actively restricting those rights. In a sense, Boxee is telling us that we cannot have a box with plugin support and the ability to play "weird video files" — much less a truly open system — under the current copyright regime.

Boxee has also driven home a lesson we've heard many times before: just putting free software onto a device does not make the device free. Most of what is in the Boxee Box is freely licensed, but, without the ability to replace the software, the Boxee Box itself is not under its owner's control. It can have features taken away, contain evil software, or be turned into an obsolete, unsupported paperweight at a corporation's whim. Purchasing such a device may or may not be a rational decision, depending on what the purchaser's goals are. Developing for this kind of device seems like a mistake; one is working to improve an edifice whose foundation can be yanked out at any time.

Suitably skilled users who are aware of these issues will, of course, have avoided a device like the Boxee Box from the outset. It is certainly possible to put XBMC onto a properly equipped computer and have a truly free device to feed one's video consumption habits. That option has not gone away, but the world has still gotten a little worse; from Nathan's post again:

Without an off-the-shelf open system, most viewers are going to be stuck with whatever the entertainment industry is willing to let them to have. Those who want something more flexible will need to build their own systems, run into all kinds of issues trying to access content that is rightfully available to them, and live under the assumption that their primary motivation is piracy.

Version 3 of the GPL will not save us here; manufacturers have shown every sign of being willing to dump software when its licensing gets in the way of their business objectives. Boxee went from being "passionate about open source software" to embracing a fully proprietary solution even without the extra requirements found in GPLv3 to worry about. Solutions to this problem, if they exist, will have to come from elsewhere.

What is needed is a combination of truly free alternatives, a willingness among buyers to insist on free devices, and copyright reform. In the handset market, buyers have begun to understand how nice it is to have alternatives like CyanogenMod — and to not have to go through a scary "jailbreaking" process to install it. As the content industry tries to tighten its grip on what our systems can do, awareness of the value of freedom may grow in this market as well. But it will be too late for Boxee Box owners who are now discovering that they lack the freedom to improve a device after its manufacturer has lost interest.

Comments (27 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Privacyfix; New vulnerabilities in gitolite, haproxy, java, viewvc, ...
• Kernel: Ext4 corruption; Small-task packing; Realtime minisummit; API design.
• Distributions: Debian Python followup; Ubuntu 12.10, ...
• Development: MIDI sequencers; OpenOffice; Wayland 1.0; Arduino Due; ...
• Announcements: Nominations for Free Software Awards, Fellowship Interview with Hugo Roy, ...

Next page: Security>>