The Bottom-Up Design group shares its implausibly deniable thoughts:
- Design is highly entangled with constraint.
- Basic infrastructure design should go bottom-up, trying to provide a set of resources effectively with minimal constraint on their use. (Applications should be designed more top-down.)
- The problems that need to be solved in basic infrastructure design, for which we must agree on some constraints, are the problems of sharing the resources among various uses/users without destructive interference.
- A key question to filter infrastructural issues from other issues in the Internet: Does the issue affect packet forwarding, or does it require an essentially global agreement in order to be useful?
Use cases are helpful to think about if they alert us to constraints that we can avoid in order to support such use. They may lead us astray if they persuade us to introduce constraints friendly to a particular use, but potentially unfriendly to other uses.
The
crucial use case is the general one: everybody doing what she wants with minimal constraint to avoid interfering destructively with others. The most important
specific use cases are usually the ones that we don't think of until we have used the resources for some time, so there is no way we can design specifically for them.
IP was a pretty good design to allow shared use of the new resources presented by coupling electronic/optical digital communication links with switching speeds sufficient to support packet switching (a finer granularity than circuit switching). It would have failed if targeted too precisely at a few specific uses. At the time, those uses would have been file transfer, and email (which has the same data granularity as file transfer). The last-minute separation of IP from TCP was crucial to the long-term health of the design.
So, new and near-future Internet infrastructural design should spring from the recognition of new resources/capabilities. Some that pop to mind are
- Software radio, which allows switching-like computations to interact with a waveform and not just a whole packet.
- Boodles of new and diverse endpoint hosts (e.g., primitive processors sprinkled into concrete to monitor a structure).
- Asymmetric cryptography.
Let's look for the minimally constrained deployments of these (and other) new resources/capabilities that allow everybody to use them.