|
|
|
|
|
| From a physical perspective, the Internet constitutes a tremendously diverse collection of hardware. Likewise, from a digital perspective, the Internet plays host to a huge variety of software protocols. However, either by limitation or design, some hardware blocks certain protocols. Likewise, most protocols fail to take advantage of the full capabilities afforded by the hardware. Thus, protocol developers tend to limit themselves to the lowest common denomenator that is allowed by hardware, while hardware developers focus their efforts on the features used by the most protocols. This homogenizing influence prevents exploiting the full potential of what is technically possible. To counteract this unfortunate trend we must improve the Internet in such a way that high-level protocols and low-level hardware can advertise their needs and match their capabilities directly, thereby bypassing the lowest common denominator. |
|
|
|
| Physically, the Internet is growing increasingly diverse at an accelerating pace. It's widely accepted that all devices, fixed and portable, will soon come equipped with a wide variety of wired and unwired network connections. Physically, there are a huge number of options available to developers allowing to mix-and-match between range, bandwidth, power consumption, cost, footprint, and many other factors. Some of these hardware advancements are summarized below: |
|
>
|
Satellite: Satellite network connections will mostly result in high-throughput, very wide coverage, high-latency connections. Due to the power requirements of broadcasting to a satellite, these connections will generally be limited to very remote regions, or mostly downlink applications. |
|
>
|
Airborne: Using a redundant set of continuously circling drones and aircraft over moderately populated regions, these will use RF connections for high-throughput, long-range, low-latency connections. Although requiring much less than satellite connections, broadcasting to airborne platforms will require substantial power (akin than a traditional cell-phone). |
|
>
|
Fixed Ground: The connection of choice for heavily populated and indoor regions, fixed ground stations will bridge physical Internet connections with mid-range, 802.11-style wireless links. Provides very high-throughput, very low-latency, mid-range, low-power connections. |
|
>
|
Portable Ground: Generally used for very short-range, point-to-point connections between portable, or between portable and fixed devices. Characterized by extremely low power consumption, high-bandwidth, low-latency connections. |
|
>
|
Contact: Unlike other wireless technologies, most of which use radio-frequency (RF) or infrared (IR) connnections that travel through the air, it shouldn't be forgotten that human skin or metal tabletops provide excellent networking environments. Given the implicit security and identification benefits of limiting communication to that which is in physical contact, there are great possibilties afforded by contact-based wireless networking. |
|
|
|
| Likewise, from a digital, application-programmer perspective, there is a huge variety of protocols from which to choose. The choice of which type of protocol to use depends heavily upon the needs of the application. Due to the intense variety of application needs, no single protocol is adequate for all applications. |
|
| Some of the attributes that delineate the range of possible protocols are given below: |
|
>
|
Synchronous / Asynchronous: Synchronous protocols guarantee ordered delivery of data, such that the first message is always received before the second message, and so on. Asynchronous protocols allow messages to be delivered in any order, possibly in a different order than in which they were sent. In general, asynchronous protocols are more robust in harsh environments as they provide greater flexibility for message delivery. However, synchronous protocols are much easier to use. |
|
>
|
Event-Based / Stream-Based: Event-based protocols are built around individual, self-contained messages passed between sender and receiver. In general, a given event has little to no relationship and does not depend upon the information contained in other events. Indeed, successive events may be delivered to different recipients. Stream-based protocols, on the other hand, are akin to continuous conversations: messages over a stream depend heavily upon the messages delivered previously, and heavily influence the meaning of future messages. Successive messages sent to the stream generally go to the same recipients. The choice between an event- or stream-based protocol generally depends upon the nature of what is being communicated: continous conversations use streams, while sporatic notifications use events. |
|
>
|
Unicast / Multicast: Unicast protocols create "1:1" connections, meaning they connect one sender to one receiver. Multicast protocols, however, create "1:many" or even "many:many connections", where a one or more senders can communicate simultaneously with one or more recipients. |
|
>
|
Secure: Security in communciation actually consists of a long list of attributes, such as privacy, integrity, nonrepudiatabity, and so on. Connections can have none, any, or all of these security attributes. The choice of whether or not a secure connection is required generally depends on the sensitivity of the information being sent, the accessibilty of the network doing the transmission, and the computational power available at the sender and receiving ends. |
|
>
|
Reliable: Reliable protocols guarantee delivery of messages, while unreliable protocols might disregard information without warning. In general, reliable protocols are easier to use as they're more predictable, but might impose extra overhead and performance penalties in harsh environments. |
|
>
|
Redundant: Redundant protocols use multiple network connections, possibly over physically distinct networks, to deliver the same messages. This redundancy can offer increased reliability or performance in harsh networking environments. However, redundancy can also be wasteful across strong networks. |
|
|
|
|
Networking Diversity Bottleneck
|
|
|
|
| While in theory the application programmer should be able to choose the exact protocol that is most suited to the application design without concern for the underlying hardware, this is hardly the case. In reality, the programmer must be very aware of the underlying hardware used in the application's deployment environment in order to ensure correct operation. Consider the following examples: |
|
>
|
Due to the tendency for firewalls to block most UDP ports, application designers are increasingly hestent to make use of this fast, unreliable protocol even when it's ideally suited to the application's needs. Even were the application designer confident that the application's deployment environment supports UDP today, it's not known whether UDP will be available tomorrow. Thus, despite UDP being the ideal protocol, the application designer may be forced to make *probable* architectural compromises in order to operate in an environment in which it may *possibly* not be supported. |
|
>
|
As the computational divide between fixed and portable devices narrows, the range of networking environments in which the average application is deployed grows greatly more complex. It's no longer acceptable to assume that a fast, reliable, and secure Internet connection is always available. However, it's unnecessary to assume that fast, reliable, and secure Internet connection will *never* be available. In short, it is becoming increasingly difficult to make *any* assumptions about the network environment in which an application is deployed. |
|
| In each of these examples, the application designer uncertainty is faced with uncertainty as to the application's final deployment environment. The natural response to this uncertainty is to either find the lowest common denominator between all environments and support that, or narrow the range of deployment environments supported. Either way, the application suffers from needless complexity or restricted deployment. |
|
| Hardware designers face similarly tough decisions. Consider the following: |
|
>
|
Cellphones, calculators, portable computers, and PDAs have been equipped with infrared ports for years. Ad hoc 802.11 networks have been available for some time. Bluetooth-enabled devices have recently started to ship. The hardware is and has been in place for some time to support seamless interoperation of decentralized portable devices linked in a point-to-point fashion. However, despite this widespread deployment, there are very few ad hoc networking applications, and those that do exist are mere baubles that fail to capture major user momentum. Of many possible explanations, one key contributing factor to this situation is the complete paradigm shift between these point-to-point devices and the rigid hierarchy imposed by the Interent: applications written for the Internet just do not work over these non-Internet connections. Accordingly the consumer base, lacking a critical mass of functionality to justify integrating ad hoc networking into their lives, shows little interest in research and products along these lines. This results in the market dictating that this new, ground-breaking research be relegated to the back burner in favor of new research that falls in line with existing widespread Internet applications. |
|
>
|
Despite major advances in multicast, quality-of-service, and transport-level-security features, to name a few, the Internet is a long way from overcoming the limitations of its youth. As long as these features are not common on most networks, these features will be used by no applications. And as long as no applications use these features, hardware developers will forever lack the incentive to continue research and development along these lines. |
|
| As long as application developers eschew fancy features for the tried-and-true, hardware deveopers will lack the necessary customer base to warrant bringing products with these features to market. This unfortunate trend results in a stagnation of the Internet's core, and creates a critical bottleneck for networking diversity. |
|
|
|
| There are two needs that must be balanced: application development cost, and application deployment portability. This balancing act embodies the crux of the problem. Thus, any solution to the problem must improve upon both of these fronts. The solution must make applications cheaper to develop, while also allowing them to be deployed in a wider environment. One possible solution, presented below, consists of three primary layers: hardware, software, and protocol. |
|
>
|
Hardware Layer: At the lowest layer, the hardware must be able to clearly describe its capabilities in a standard form. This form need be flexible and exhaustive, and must be able to represent all possible configurations of hardware features. This form might be a simple static file that passively enumerates all possible hardware configurations, or a dynamic component that can be actively queried as to whether or not a particular configuration is supported. Either way, software executing on or accessing that hardware must be able to definitively ascertain its capabilites. |
|
>
|
Software Layer: At the highest layer there must be a set of software components that provide a standard API to applications to obtain network connections. This API must provide exhaustive and extensible abstract representations of all types of network connections. Applications would connect to this software layer and request the ideal network connection for its purposes, irrespective of what the underlying hardware actually supports. It would be the responsibility of the software layer (with possible assistance from the application) to interrogate the available hardware to find the best configuration to meet the application's needs, and then emulate any features the application requests that are not otherwise supported in hardware. |
|
>
|
Protocol Layer: Finally, between the hardware and software layers, there must be a layer of protocol standards that allows this globally distributed set of software components (each working on behalf of one or more applications) to self-organize and make optimum use of the available hardware resources. One possible approach would be to have components in the software layer to initially establish the most widely available, lowest-common-denominator connection, and then work "down" to successively more ideal connections. |
|
| With a solution of the sort summarized above, application developers could be allowed to focus on creating the most simple application architecture based on the ideal networking protocol. In this way, the underlying software layer could perform the complex and difficult work of prioritizing the available features supported by the available hardware, as well as negotiating the ideal protocol with other software components located on the "other side" of the connections. In this way, the application would be "forward-compatible", and able to exploit new networking hardware advances without additional development cost. |
|
|
|
|