In such situations of moderate scarcity, however, not all people can have whatever means of communications they want. The means are rationed. The system of rationing may or may not be equitable or just. There are an infinity of ways to partition a scarce resource .. egalitarian .. meritocratic .. [recognizing] privilege .. cultural values .. [rewarding] skill and motivation, as that which allows communications institutions to earn profits that depend on their efficiency. -Ithiel de Sola Pool, Technologies of Freedom, 1983, p.240.
Most architecture and instrumentation for accounting and traffic control in the Internet reflect its historical status as a typically government bulk-funded service for the academic community. It has been a research environment with usage-insensitive costs that are often transparent to the end-users. As a result the current Internet architecture is not conducive to allocating network resources among multiple entities or at multiple qualities of service. Presently there is no incentive to limit the use of bandwidth, and the appetite for bandwidth is growing far faster than the Internet can support. As traffic grows, and new applications with fundamentally different traffic characteristics come into widespread use, resource contention will become a problem.
Earlier networks, such as the ARPAnet, relied on inflow control into
switching nodes within the network to
reduce the likelihood of
resource contention. However today's Internet is inherently based on
a datagram architecture which aggregates traffic from many
endpoints through distributed packet forwarders, few if any of
which implement admission control.
Most entrance points into transit networks cannot provide significant back
pressure to peer points that inject more traffic than the transit network
can handle. This situation pervades the Internet environment, leaving end
systems able to unfairly monopolize available bandwidth and cause
significant congestion in the transit networks they use.
During the mid-80s on the 56kbps NSFNET backbone, congestion developed to a dangerous degree. In response the NSFNET engineers deployed an emergency measure to provide certain interactive network applications, specifically telnet, preferential treatment over other traffic. The priority transit allowed interactive users requiring better network responsiveness to continue working under highly congested circumstances. At the same time the NSFNET backbone established support for separate queues in the routers according to the IP Precedence value in the IP header field. Because the backbone administrators did not have any way to provide an incentive to not use the highest priority, they did not publicize the priority-based treatment of traffic, and end users did thus not know it was possible to give high precedence to other applications.
When the NSFNET was upgraded to T1 capacity, offering a 24-fold bandwidth increase and a richer topology, the designers did not re-introduce the priority queuing for end-user traffic. The new infrastructure used multiple queues only to differentiate between user traffic and network management traffic. An overabundance of bandwidth rendered superfluous the use of multiple queues. In the case of the NSFNET backbone, the project partners bore all the costs of maintaining this bandwidth ahead of demand. The subsequent upgrade to the T3 network further exemplified this method of coping with network congestion by increasing the bandwidth and switching capacity ahead of demand.
However, today software developers are building advanced network applications which can consume as much bandwidth as network operators provide. In particular, real-time applications using packet voice and video do not exhibit the same stochastic burstiness characteristics of more conventional applications such as interactive login sessions and electronic mail. The latter traffic is typically aggregated across a large number of individual sources with relatively modest resource requirements [4]. Real-time applications rather require prolonged delivery of large amounts of traffic in near real-time, and thus continuously consume significant amounts of bandwidth. Clearly usage of such applications will not scale in the current Internet architecture, which has no facilities to support continuous high volume services for many individual connections, as it does with the current traffic cross-section.
Many recent videoconferencing applications
require 125kb/s to 1Mb/s over LANs.
People accept lower quality and bandwidth over
WANs because of cost. For example, CU-SeeMe developed
at Cornell University uses compression to
reduce the bandwidth requirements
to under 100kb/sec [3]. Current Macintoshes come instrumented with
a microphone and hardware enabling
transmission of audio across the Internet;
within a year it will be feasible for an undergraduate
with a $2000 Macintosh AV and a $500
camcorder to send real-time video to
friends on another continent.
(How much will arrive at its destination
will depend on actual network contention.)
Most video and audio applications are currently still in a prototype phase; they enjoy a wide-area infrastructure which is not yet subject to overwhelming congestion. Once network resource congestion occurs, however, parts of the infrastructure may become quite unpredictable due to switching contention. One way to accelerate toward that point is continued wide-spread deployment of these applications. Their success and popularity bodes ominously for an infrastructure not able to: distinguish among certain traffic types; provide more than a best-effort guarantee to datagram traffic; or upgrade in a time efficient way towards an availability of higher bandwidth (if only due to lack of accounting and billing mechanisms to enable cost recovery).
Appropriate ways to deal with the situation involve considerations of fairness to network clients, whether to penalize larger flows first, or implement preferred service classes, latency-sensitive applications, etc. No solution will satisfy every constraint, especially if the scale of the answer must encompass the integrity, operability, and manageability of the global infrastructure.
At present, users have no motivation other than altruism to conserve their use of bandwidth. Ewing and Schwartz measure that more than half of all FTP file transfers do not use compressed format [5]. If the current use of FTP is any indication of the awareness of needless bandwidth consumption, video will make matters worse. There is plenty of evidence of widespread dissemination of video streams pointing at trees outside people's offices, or even empty offices at night where people have neglected to turn the video transmission off as they leave their office in the evening. While an FTP session eventually completes, or a telnet session essentially exchanges no data without a person actually typing, a video stream can continue to transmit large volumes of data indefinitely. Indeed, it is difficult to overestimate the dramatic impact which digital continuous media will have on the Internet fabric.
Digital continuous media
traffic profiles are fundamentally different with
volumes of much higher mean
and lower variance, and are not designed for sharing as equitably since
they typically use UDP instead of TCP.
We lose the ``sharing'' part of
stochastic sharing, and although potentially mitigated by compression
techniques, with no back pressure to the traffic sources
by intermediate systems nor incentive to
implement bandwidth-economizing mechanisms, the Internet is defenseless
against them. Because of the lack of inflow control and the lack of
cost recovery mechanisms based on actual traffic composition, the
infrastructure critically depends on the conscientious behavior
of the end systems, and
their users, to utilize well-mannered mechanisms for bandwidth requisition,
such as window-based flow control and backoff in the face of detected
congestion. It is only such mechanisms, which window-based
transport protocols such as
TCP exhibit, that can render relatively predictable the traffic patterns
at aggregation points within environments such as today's Internet.
In fact, one may argue that the impact of the new, specifically real-time, applications will be disastrous: their high bandwidith-duration requirements are so fundamentally at odds with the Internet architecture, that attempting to adapt the Internet service model to their needs may be a sure way to doom the infrastructure. Proponents of this argument also might claim that there is thus no point in implementing usage-based accounting or congestion control mechanisms in an infrastructure which will break if it really has to support those applications to any realistic degree. Those applications may have to be integrated into a different environment, specifically one architected for greater service integration, and one which may eventually absorb the Internet. In the meantime, however, they should leave the Internet to do that for which it was architected.
Despite the pleasant thought that somehow the increasing
population of high bandwidth-duration applications
will find a more appropriate environment and leave the Internet
for traditional applications, we consider
it at the very least a moot argument.
Such real-time applications exist even on today's
Internet, and have already exhibited a detrimental impact on the
traditional shared traffic that is so far carried
largely by applications using relatively small
TCP flows for transport layer communication.