A communications network is as good or as bad as its users perceive it to be. Network performance should therefore be measured in terms of overall user satisfaction with the service they receive. However network performance is usually expressed in terms of network engineering measures such as average packet delay or loss rate. These engineering measures are an imperfect reflection of overall user satisfaction because user requirements vary widely, in every service dimension and over time.

  • Example 1: some real-time interactive applications are able to tolerate relatively frequent packet loss without significant quality degradation, whereas some command and control functions require essentially lossless transmission.

  • Example 2: interactive communications usually have an upper limit on total delay and delay variation corresponding to the limits of human perception (e.g. 400-500 millisec maximum delay, with maximum variation an order of magnitude lower), whereas some offline data transfers are essentially insensitive to delays.

  • Example 3: packet delay or loss may be valued differently by different users even if they are running the same application. Similarly, a user's valuation of quality of service (QOS) may vary depending on destination or time of day.

  • Example 4: some users want deterministic worst-case performance guarantees, whereas others are satisfied with average-case statistical guarantees. Some users may be content with ''best-effort'' service, for which the network offers no guarantees on loss or delay, especially if there are periods in which network utilization is low enough that even best-effort traffic is reliably transferred.

Accounting for individual QOS requirements makes network operation and control considerably more complicated. In practice, user objectives are averaged across all users and over time. These averaged objectives are reduced to engineering measures and then are used to drive the network control process (see Figure 1): the users are not in the loop when making operational decisions.

Figure 1: Network design and control loops (a)Figure 1: Network design and control loops (a)

In an effort to reflect variations in QOS requirements, many researchers divide usage into classes according to application requirements and traffic characteristics; for example, real-time video, real-time audio, one-way video playback, or off-line file transfer. Each class is then regarded as having a single representative user for analytical and control purposes. However, this approach ignores substantial heterogeneity within application classes and across users.

  • Heterogeneity across time: a user's valuation of a given application will be different at different times, and thus the user's requirements for network performance for the same application will vary over time.

  • Heterogeneity across users: different users will differently value a given application and its QOS. A common — but we believe erroneous — assumption is that video applications should receive network priority because the performance degrades more drastically with delay than for, say, a World Wide Web session. In fact, some users may place sufficiently high value on low latency Web usage that total user valuation of the network would be increased by giving higher priority to their Web sessions than to some video sessions.

Therefore we think it is increasingly important for network operators to develop flexible tools that can support heterogeneity in usage types and user valuations.

One such tool is the ever-increasing intelligence located within the users' end-stations. It is already feasible for many traffic sources and sinks to do some basic processing on the transmitted data; for example, TCP congestion control schemes [5] respond to network feedback by adjusting the traffic inputs. And as technology advances, these capabilities will continue to expand. This intelligence represents a network resource that, if properly managed, could enable a "tighter" network control loop than before.[a]

As a natural extension of existing network feedback control mechanisms, we propose bringing users back into the loop and thereby ensuring that performance measures are user-oriented (see Figure 2). We propose a form of feedback which we call responsive pricing and argue that it represents a particularly useful mechanism for maximizing network value. Users would gain by obtaining service more closely matched to their needs; network operators would gain through improved network utilization and increased user satisfaction with the service they receive. In particular, responsive pricing helps network operators by its ''value discovery'' function: it reveals how the valuations for QOS differ across time, users and applications. Summary network engineering measures will continue to be important, but we believe that user preferences should be the primary consideration driving resource allocation and congestion control schemes.

Figure 2: Network design and control loops (b)Figure 2: Network design and control loops (b)