If most Internet traffic is content, should we make content accommodations in the protocols used? As someone recently noted in a LinkedIn comment on a previous blog of mine, PARC has promoted a concept called “Content-Centric Networking” or CCN to do just that. The idea got a lot of attention four or five years ago, but it seems to have lost visibility recently. There have been a lot of initiatives to change or supplement the Internet’s protocols, most of which haven’t had much impact. Rather than just look just at CCN, let’s look deeper at the issues associated with the Internet’s own protocols as its foundation.
The Internet, as many know, goes back to a set of research projects involving the government and some universities. The goal was to establish an academic network for collaboration within that community, a network that accommodated the reality of data transmission at the time—the late ‘60s. The emerging set of protocols, key among which was the Internet Protocol or IP, has changed a bit over time, but the basic approach has been fairly constant.
The thing that made “the Internet” into The Internet as we know it was the Worldwide Web, a model of HTML-authored content delivered on HTTP, a higher layer on IP designed for hypertext transfer (hence the name). This came along in 1989, and by the early ‘90s the web gave birth to a consumeristic model of data networking, just at the time when network operators were struggling to understand what would consume the growing optical trunk capacity they could deploy.
Because Internet nodes—routers—were much cheaper than the custom nodes associated with the business networks (notably IBM’s System Network Architecture, SNA) of the time, IP also changed business data networking and became the universal protocol for data exchange. One business in the early ‘90s told me they could deploy a national IP network for the cost of one of the IBM SNA 3745 controllers, and cheap wins. However, IP was not really designed for the web, for business networks, or for the emerging content-centric Internet we have today.
Some of the changes that new missions for the Internet have brought about are well-known, like the IPv6 change to enhance address spaces, or like the Ipsilon fusion of stateless IP with connection-oriented ATM that morphed into MPLS. Others, like identity-based routing, are designed to alter the fundamental addresses-are-locations nature of IP. Some are mission-focused, which is what CCN arguably is.
The basic theory of content-centricity is that content is hosted and identified, meaning that users aren’t looking for a stream of packets, but for the delivery of some specific thing that happens to be stored on a computer, in a database. Perhaps, on several computers in different locations. CCN seeks to make the host-organized content store one of the goals of the network itself. There are “content packets” in CCN, and “interest packets”. I think the big difference between CCN’s approach and traditional HTML/IP is the interest packet. The PARC material offers the analogy of a golden retriever, something you send out to find the thing you want.
The overall CCN approach is complicated, and if you need to understand the details, you can look HERE at a detailed explanation. I’ll just make what I think is it’s key point, which is that CCN combines the “what-it-is-where-it-is” process of URL and IP address, mediated by DNS, into more of a “send out the scouts” discovery process. In a real sense, CCN is a form of identity routing, location-independent routing, or service discovery, and that’s why I want to look at it in context rather than try to promote or even explain its details.
This what/where dichotomy has been one of the biggest challenges of both the Internet and the cloud. The more flexibility you have in putting something somewhere, scaling it under load, or replacing it if it fails, the harder it is for users to find the darn thing. There have been many initiatives associated with the notion of adding discovery based on identity to IP. The familiar URL and DNS combo is one, UDDI and directory services in SOA/Web Services is another. None of the newer ones have really swept the old DNS model aside, and I think the reason is practicality. DNS, for most missions, works or can be diddled to make work.
Where DNS is a problem is where the what/where relationship is highly dynamic. That’s why we’re seeing more issues today; the cloud and scaling and redeployment therein create the potential for rapid and dynamic changes. Scaling also means that multiple content or service elements could be represented by a common identity, and so a form of load balancing is needed. Even before the cloud, though, content delivery networks had to provide for dynamic URL decoding to direct content requests to the right cache point rather than to a central server on the Internet. Like IP, DNS is a legacy strategy that’s baked into usage today.
We wouldn’t do the Internet the way we now do it, had we known where it was going. That’s not the same as saying that we should go back and redo it. The biggest problem with CCN, IMHO, is that it solves the wrong who/where problem. CCN kind-of-combines URL/DNS and search into a model that lets you put pages of an article or segments of content where convenient. That would be really useful if it weren’t for the fact that we get most content by going to where we know it is, a website or a streaming service. We use search if we don’t know where.
Where CCN might make sense, even a lot of sense, is in the area of service discovery in cloud-native deployments. The big thing about cloud-native or microservices or serverless functions is that you don’t know automatically where they are, and in any event, they might not stay there. You need a mechanism to bind to an instance of something when you need to send it a message. Something CCN-like is actually a pretty logical way to get it.
Could CCN be adapted to serve as a service discovery protocol? The basic idea is that “interest” packets are sent out to locate a node that has the target “interest”. We could, in theory, use that sort of thing directly within a mesh of microservices, but the idea fails if you assume that unlike content, there aren’t a lot of services per node, so a lot of nodes would have to be queried. We might look at a modification, where the “interest” packet finds not the service, but someone already connected with it.
All of this, though, seems to me to belong the venerable-and-largely-forgotten OSI model, which dates back to 1974, before any of these what/where solutions emerged. Referencing the model, we have Layers 1 through 4 in the Internet today, and Layer 5 (the Session Layer) is where the what/where question is resolved. While OSI concepts are old and often forgotten, the truth is that we still use the Layer references today, and the concept of protocol layers with specific roles and relationships to other layers seems durable. Why not look at our needs in session terms.
The session layer is also what would be responsible, under OSI, with the authentication of user identity and the authorization for access, meaning connection rights. At least one SD-WAN vendor implements zero-touch security through what’s effectively an add-on session layer. We don’t have a Layer 5 in the Internet suite, and so I think what we could say here is that CCN, service discovery, identity routing and all the rest are attempts to introduce Layer 5 features.
Mobility is arguably another example of what should be thought of as a Session Layer feature. A user is a “what” with variable “where”, and so it’s reasonable to add this to the other discovery-related needs out there. In fact, there’s a PARC paper on mobility in CCNs, which claims that CDNs and caching concepts are outdated. Probably IoT in some forms could be an application for discovery/mobility-like features, and so also have a Session Layer connection.
I may seem to be trying to make everything into a session here, and I guess in a sense I am. The Internet is about users and the information/content they want. Communications is about a “conversation” between/among entities. These relationships are what Session Layer was supposed to be about, and we’ve introduced some session concepts in a lot of things already. There seem to be about twenty different session-layer protocol claimants out there already. They tend to be rather specialized to a mission, and many of them don’t fit the OSI definition at all (the point-to-point tunneling protocol, for example). There are OSI standards for the Session Layer (three that I recall) but I can’t say I can remember anyone who’s used them for decades.
There isn’t a critical problem here…yet, at least. We have been able to make IP work for modern missions, but we’ve not yet fully experienced the cloud transformation. It might be the thing that finally makes us realize that we don’t need a bunch of mission-specific tweaks to Internet protocols to make them adequate (but not optimal) for today’s needs. I absolutely don’t think that means tossing the Internet, but I do think it means trying to come up with a single systematic solution to an increasing range of challenges.
Who does that, though? Standards bodies take forever and tend to shoot so far behind the duck that the stuff they produce is useless in the real world by the time it’s available. Open source may coalesce on a software solution, meaning tools or APIs, but can it supply a functional standard for solving the what/where puzzle? Likely what’s going to happen is that cloud discovery and service meshing is going to provide the answer, and so I think we should watch that space carefully. I know I will be.