'Telecommunications traffic' is a phrase used to describe all the variety and complexity of the usage of a network. It is the comings and goings of demand, in response to user behaviour and to the network's reaction. Its detailed specification is a means to an end - merely the first step in the evaluation of the quantities that are meaningful and useful to the network engineer, and therefore the type and complexity of its characterisation reflects the richness of its array of uses. Time-honoured representations of network traffic by pure-chance streams, which have worked well for many years, are now insufficient. The new data networks display a complexity of behaviour which requires a corresponding richness of input, and this has required the development of a multitude of traffic descriptions. These include not only extensions of classical models, such as multi-bit-rate sources, but also such very different areas as the effective bandwidth models now in widespread use for ATM modelling, self-similar or fractal traffics, and the complex self-coupled and adaptive behaviour of TCP/IP traffic streams. This chapter will distinguish loosely between characterisation and modelling. The first of these implies the purely phenomenological description of traffic, i.e. the analysis of measurement data, and the production of high-level statistical descriptions. Modelling, by contrast, covers the detailed low-level production of probabilistic models of traffic that can actually be used to make predictions about network and system behaviour.

Following the success of the Internet, over the last five years or so IP has firmly established itself as the networking protocol of choice for a wide range of both traditional and emerging applications. More recently, among business users, there has been much interest in adding real-time applications, including voice over IP (VoIP) and interactive videoconferencing. A major driver for this is the desire to consolidate all applications on to a single, multi-service platform. This chapter focuses specifically on the DiffServ approach to QoS. DiffServ involves the segregation of traffic into a small number of classes, but unlike either the ATM QoS approach, or the IETF IntServ approach, there is no signalling control plane to look at end-to-end behaviour. Instead the approach relies upon per-class capacity planning at each router individually (the so-called per hop mechanism) in order to ensure that, overall, each class gets the standard of service required.

In its most abstract sense performance testing is the loading of a system, or a part of a system, with a synthetic workload, i.e. taking a real system and using specialist scripts and tools to emulate the activities of multiple users (where a user may be another system) performing typical user actions. Atypical workloads are sometimes used to stretch a system to, and beyond, the anticipated limit to add confidence that it will be able to support.What differentiates performance testing is that the focus of the work is on a real system with a controlled load rather than a chapter or computer simulation-based exercise, or a live system with a live and uncontrolled load. An advantage that performance testing has is that it works with the full complexity of the system in its implemented state, rather than a simplified model, or how it should work according to the design. The downside is that testing can only begin when there is something to test and this is inevitably later in the life cycle than other forms of performanceengineering, and obviously major problems found at a late stage are more costly to fix than if they had been found at an earlier point in time.However, as many modern systems are an integration of specialist components bought in from third parties, who may be reluctant to share details of how their product operates for good commercial reasons, performance testing may be the first opportunity for the integrator to find out if the components being used to build the system live up to their specifications and expectations. It should be noted that performance testing is not limited to a particular technology, although the choice of tools used may be strongly linked to either the underlying technology or to the system interfaces where work is presented.

The original idea of an 'intelligent network' (IN) was to be able to define a system capability that would support the rapid building and deployment of a large range of new services into a telephony network. Services include those with advanced call distribution features, such as call queueing. The ITU specifies a series of recommendations that define such a capability, incorporating the intelligent network application protocol (INAP). Abernethy and Munday provide a useful overview of IN standards and services.

The Capacity Forum is at the centre of the whole capacity management process, while the Capacity Report is at the centre of the data collection and analysis. The Capacity Forum is the co-ordinating team that keeps the issues and methods under constant review. It recognises that focusing the reporting into one work area is efficient, economical and effective. It takes the statistical reporting task away from separate business units, which contributes to local morale. It puts the task under the control of a dedicated individual who is free to develop the skills required to produce a very high quality report. The motivation for this emphasis on capacity and performance is 'customer satisfaction', but capacity and performance engineering is also about minimising costs. The aim, therefore, is to prime the business with the network information required to achieve customer satisfaction at minimum cost. Covering both systems and services, each new issue of the Capacity Report builds on the picture established in previous months, and projects this picture into the future. Managers use the report, primarily, for managing engineering intervention necessitated by forthcoming special events, system changes, new services and market trends. In addition, account managers of major customers appreciate the information delivered through the Capacity Report, because it puts them in a position of real knowledge to discuss issues that their customers may not fully, or correctly, understand. It also enables them to discuss new services, and how to create better business solutions from the current and future product range. The TeleMarketing Services Capacity Report has been in production every month for several years. It was a very successful innovation that has grown and evolved in a way that could never have been envisaged at the outset. A web of links now reaches out to the business, giving the kind of coherence and structure that encourages objective discussion among otherwise disjoint communities. With its comprehensive and flexible coverage, straightforward and consistent format, simple graphs and tables, together with its emphasis on end-to-end performance and focus on customer satisfaction, the TeleMarketing Services Capacity Report stands as a prime example of how to monitor a complex, evolving system, and plan its progress towards providing the yet more sophisticated services of the future.

This chapter will take a critical personal look at traditional and future potential broadband markets, consider competing technologies, and try to argue whether or not any significant network market exists in each case. While there may be no single 'killer application' that will justify a high-speed network on its own, there are many services that add together to give traffic demand, and some services that can soak up whatever bandwidth is available, if the price is right.