I’ve been thinking for several years about the flaws in the Internet’s (nearly non-existant) caching model, and have reached several conclusions. First, caching policy is very difficult, basically impossible, to specify in some arbitrary protocol. This is one of the biggest problems we’ve got with caching – the cache manager has a lot of settings he can adjust, but the data provider has almost none – basically cache or don’t cache (oh yeah, he can specify a timeout, too). So, I’m led to conclude that data providers need a very flexible way to inform caches of their data’s caching policy, like a remote executable format, i.e. Java. My second conclusion is that what limited caching we’ve got is destroyed when people want to provide dynamic content. The only way I can see to cache dynamic content is to cache not the data, but the program used to create the data, and expect the client to run the program in order to display the data. And we don’t want to do that on the caches (if we can help it) for performance reasons. Again, a remote executable format, this time on the client, i.e. Java. My third major conclusion is that caching is a multicast operation and requires multicast support to be done, but that’s for a diferent paper. Thus, I’m proposing an integrated Java-based caching architecture using what I call “cachelets” on the caches to provide a flexible and usable caching architecture.
Software Checkpointing using Networking
If we design our operating system so that processes perform all external operations using networking, in particular IP packets, then we can easily checkpoint processes.
Demand TV… we could have it today
What would it take to offer a demand video service based on local cable TV? Let’s consider how to build a bank of computers that would record and save the last week of video on each of sixty cable TV channels, then deliver any part of the recorded video on a demand basis.
My Response to Thomas Friedman
In his best seller “The World is Flat”, Thomas Friedman identifies ten “flatteners” that are leveling the global economy; forces such as outsourcing, offshoring, supply chaining, and the collapse of the Soviet empire. His fourth flattener is open source software. None of his issues are particularly new, but it is Friedman’s treatment of them, notably both his and Bill Gates’s shocking misunderstanding of free software, that raises some of the most provocative questions of a provocative book.
Will Multicast kill Packet Switching?
With the demise of ATM, many technologists believe that circuit switching is dead and packet switching has won. Yet the current Internet multicast architecture is essentially circuit switching in disguise, since every router along the path of a multicast session has to maintain explicit connection state. Which leads me to wonder… can packet switching support multicast, or is circuit switching required?
NAT and the Failure of Source Routing
Paul Francis, in the conclusion of his 1994 Ph.D. thesis, traces the evolution of the IPv4 address scheme. After quoting a June 1978 Clark/Cohen paper (IEN 46), Francis notes:
Well, something happened here. An argument was put forth that 32 bits is enough because the address does not have to do routing – the source route can handle the rest. Clearly it was recognized that a variable length something was needed, but the source route was deemed sufficient for that, and the 32-bit address won out in the end. So, perhaps what killed IP is not that the address is too short (though probably it is), but that the ability for DNS to hand a host a source route (which it could then put in the header so that the right thing could happen in the network) was not created.
(p. 177)
Not only did the failure to fully implement source routing (in DNS) make it impossible to address into a private network, it also created the situation where NAT had to be implemented as it was.
Lightweight Multicast (LWM)
The Internet has become infamous among network professionals for its near pathological inability to deploy multicast. The Internet’s current multicast specifications place significant demands on the network, most significantly the need for routers to maintain a multicast routing tree for each multicast address. I propose a lightwight multicast (LWM) designed specifically to alleviate this requirement by listing a full set of destination addresses in each packet header, using a header option.
Network distributed databases
Most database designs are tied to a single master server, which might get replicated out to various slaves, but what we’re really after is a database distributed and replicated across the network with no distinguished master server.
A Theory for Analyzing Addressing Structures
Years ago, I described the “fundamental principle of routing” that “logical addresses correspond to physical locations”. This implies some kind of relationship between addressing structure and network topology. Using concepts from (mathematical) topology, we can make this relationship more precise, and obtain a theory for analyzing addressing structures. I use this theory particularly to note the inadequacy of CIDR and to establish a framework for analyzing possible extensions or replacements to CIDR.
Continue reading “A Theory for Analyzing Addressing Structures”
The Location Layer
Over the past quarter century, stack-based layered architectures have become ubiquitous in networking, most notably the seven-layer OSI model. OSI seperates a Network Layer (responsible primarily for routing) from the Transport Layer and other layers above it. In recent years the Internet’s difficulty in handling mobile devices had suggested flaws in this original design. I propose that a new layer, the “Location Layer”, is needed between the Transport and Network Layers, whose function is to locate network resources, including mobile devices.