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.

Views: 25

Reply to This

Replies to This Discussion

In the second session, we did not care to propose any new qualities/requirements for the list.

We noticed that longevity is probably not objective, because the objects in question are abstractions, and their boundaries are more a matter of naming than of reality. For example, there are programming languages in use today, called "FORTRAN" and "BASIC," that are distantly related to things that I programmed with under those names in the 1960s. On the other hand "Scheme" is a variation of "LISP," probably more similar to it than current FORTRAN is to my good ol' FORTRAN. So maybe it should be removed, and we should just keep in mind the robustness over time of all other qualities.

We also discussed management (from which we liked to remove the word "better," as it seemed ambiguous, and not much of a contribution to the meaning). We wandered through some history of network management, found a lot of confusion as to the boundaries of management vs. configuration vs. administration vs. security vs. ... We were interested in the possibility that better (oops!) protocol agreements regarding the initial self-configuring and management capabilities of standard computing, networking, and networked-peripheral devices (e.g. printers) would improve the Internet a lot, and enable a broader scope with less labor. Such protocols probably require understanding the qualities of these devices as data objects with carefully designed network-relevant semantics. IP forwarding does not appear to be affected, but a global agreement among vendors is required, so this could be an important issue in basic infrastructure design.

Reply to Discussion

RSS

© 2024   Created by David Clark.   Powered by

Report an Issue  |  Terms of Service