INTRODUCTION

The growth of the Internet is placing strain on the world wide telecommunications infrastructure. In particular it is no longer possible to purchase capacity on terrestrial cables to some parts of the world. The demand for network services continues to grow despite the lack of terrestrial capacity. To meet this demand Network Service Providers (NSPs) must move some traffic to satellite circuits, despite the inability of standard window size TCP[1] implementations to perform well in high bandwidth-delay product environments.[2] Traffic between the US and other countries is typically asymmetric. To minimise the additional latency imposed by a satellite circuit and also because of cost considerations, an attractive solution is to use a unidirectional satellite circuit. In this case the high volume inbound traffic is carried on a satellite circuit and the low volume outbound traffic on a terrestrial circuit. This causes asymmetric delays in the TCP connection, with a high bandwidth-delay product in one direction only. Such connections have not been widely studied. Allman et al, [3] when discussing asymmetric satellite links, note that ``This asymmetry may have an impact on TCP performance.'' The NSP must choose an architecture for the international component of the network. Depending on the architecture chosen the traffic on the international circuit might be made up of a large number of independent connections or a small number of connections carrying aggregated traffic. The former would be the case if each HTTP request is carried directly over the link. The latter is the case if user connections are concentrated between a pair of proxies. More tuning is possible if proxies are used because the TCP connection is terminated at devices under the control of the NSP. The TCP stacks can be tuned to better meet the needs of the satellite connection. Without proxies TCP connections terminate at the end users, whose TCP implementations are outside the control of the NSP. The asymmetric satellite case between proxies is shown in figure 1. To make the descriptions easier this figure and the rest of the paper,` are written in terms of an international connection between New Zealand and the United States. The results are, of course, more widely applicable.

Figure 1: Asymmetric Satellite path for HTTP traffic

There are advantages to both design approaches described above. The NZ only proxy case is simpler to implement and does not require the NSP to deploy and maintain US based proxy equipment. However the full effect of slow start will be felt by every HTTP request. This effect may be magnified because there are often many HTTP requests required for a single HTML page. The US-proxy case improves slow start behavior because slow start only occurs once for each inter-proxy TCP connection. When an HTTP request slow start does not normally occur for the international part of the connection. It will still occur locally within NZ and the US. Further performance bay be gained in the proxy-to-proxy case because the TCP stacks operating over the international link are under the control of the NSP and may be tuned. In particular a large buffer size may be selected. Finally the aggregation of several HTTP connections over a single TCP connection may allow TCP to better package the data and to carry more piggy-backed acknowledgments. Opposing these performance gains for the proxy-to-proxy case performance may be limited by the number of TCP connections available between the proxies. In this paper we describe a discrete event simulation that investigates the effect of carrying multiplexed HTTP connections over an asymmetric high delay bandwidth circuit. The simulations include a real TCP/IP protocol stack and are driven by a trace of HTTP activity collected from the NZ international exchange (NZIX). We show that a high degree of multiplexing mitigates against TCP's bandwidth delay product limits but that if a TCP connection is used for every HTTP request a significant increase delay is experienced. The simulations indicate that multiplexed HTTP connections between proxies at both ends of the link reduce this additional latency provided sufficient TCP connections are available between the proxies. The rest of this paper is organised as follows. Section 2 describes the network being simulated, including the capacities of the links and transmission delays. The simulation is driven from an HTTP trace collected at the University of Waikato. Section 3 describes the workload including the main characteristics and how heavier workloads were formed to simulate the high capacity links. The simulator design is explained in section 4 and the results of the simulation runs are shown in section 5. The paper ends with the primary conclusions we draw from the results.