IRDS client-server protocols such as HTTP (used by NCSA Mosaic and www) are rapidly evolving. Optimal design of servers, clients, and the protocols by which they communicate will require understanding characteristics of both the aggregate workload of many users as well as the workload of individual sessions. Other technology developments, such as distributed or mirrored servers, will also need coordination between traffic analysts and protocol designers to assess how the changes in information services will impact the Internet.
More detailed traffic characterization studies of www and related traffic will enable improvements in both server and caching design. A flow-based methodology for traffic characterization, discussed in [6], is particularly applicable to IRDS traffic, since the principal burden on the servers is no longer so much in terms of packet counts, but by transaction frequencies as well as the range in complexity of each transaction. Objectives in IRDS traffic characterization include finding answers to the following questions:
An additional issue is server performance capability. Current measurements indicate that NCSA Mosaic traffic is significantly rate-limited by the performance of the servers. More powerful hardware will handle transactions faster, but we also need to examine server behavior to determine suboptimalities. One example we discovered in this study is that the NCSA server resolves the hostname for each IP address from which it receives a request, for transaction logging purposes. The server could ease its own workload by not performing all gethostbyaddr() resolution system calls in real-time for each access in order to log the name of the requesting host, but rather queueing ten or twenty IP addresses and obtaining the mappings in a batch mode.
However, such advances have ominous implications. As the servers get more efficient, simultaneous with advanced client workstations that are able to request more transactions per second, the result on the system is a higher Internet bandwidth per transaction and a reduction in the mean flow interarrival rate to the servers. As a simple example, a Mosaic page with embedded images will produce a small text-only flow to a client without automatic image download options set. If the any of three independent components of the user environment: server power, client workstation power, or client network bandwidth, improves, the user will enable the automatic image download option, resulting in multiple back-to-back flows for each object that contains embedded images. Present client/server protocols such as http will satisfy such requests with several high-bandwidth flows back-to-back as separate TCP connections between client and server.