On estimating end-to-end network path properties

Abstract

The more information about current network conditions available to a transport protocol, the more efficiently it can use the network to transfer its data. In networks such as the Internet, the transport protocol must often form its own estimates of network properties based on measurements performed by the connection endpoints. We consider two basic transport estimation problems: determining the setting of the retransmission timer (RTO) for a reliable protocol, and estimating the bandwidth available to a connection as it begins. We look at both of these problems in the context of TCP, using a large TCP measurement set [Pax97b] for trace-driven simulations. For RTO estimation, we evaluate a number of different algorithms, finding that the performance of the estimators is dominated by their minimum values, and to a lesser extent, the timer granularity, while being virtually unaffected by how often round-trip time measurements are made or the settings of the parameters in the exponentially-weighted moving average estimators commonly used. For bandwidth estimation, we explore techniques previously sketched in the literature [Hoe96, AD98] and find that in practice they perform less well than anticipated. We then develop a receiver-side algorithm that performs significantly better.

Proxy-assisted interactive-video services over networks with large delays

“…To date, several enhancements (e.g., [1,11,12]) have been proposed to improve the initial implementation [6]. However, these proposals are naturally not suitable for delay-sensitive applications in the sense that their estimators are considerably conservative and adapt to the network conditions slowly.…”

“…Namely, the number of frames in a GOP, the GOP structure, encoding bitrate, video frame rate and IP packet size are the main parameters that vary the transmission times of the packets in a GOP. 1 As an illustrative Note that some video applications encode the video without a strict GOP structure. Instead, a small percentage of the macroblocks are intra-coded in every frame, resulting almost equal-sized frames, and hence, less-bursty video traffic.…”

TCP throughput and fairness performance in presence of delay spikes in wireless networks

“…Those include cell reselection, link-level error recovery, bandwidth fluctuation, and blocking by high-priority traffic [8,9]. The mobile terminal may perform some time-consuming actions during the handover procedure and the introduced delay can exceed as much as 10 s [7].…”

“…In the past few years many researchers have been working on improving the TCP's poor performance in wireless networks, which is resulted directly from the main assumption of TCP that any increase in delay should be interpreted as packet losses caused by congestion. Another problem, called spurious timeout, however has not been addressed sufficiently and only has attracted researcher's attention very recently [4][5][6][7][8][9].…”

“…Many studies on Internet performance show that highly variable delays are not uncommon [4,5,9] and especially in a General Packet Radio Service (GPRS) wireless cellular Wide Area Network (WAN), the sudden delay can exceed as much as 10 s and thus a likely reason for spurious TCP timeouts [7]. The wireless link in other cellular networks may also often experience delay spikes in the order of up to a few seconds [7].…”