Inference and Performance Evaluation of Cellular Data Networks through
End-to-End Measurements
Wei Wei
†, Chun Zhang
†, Hui Zang
‡, Jim Kurose
†, Don Towsley
† †Department of Computer Science
University of Massachusetts, Amherst, MA 01003
‡
Sprint Advanced Technology Laboratories, Burlingame, CA 94010
Abstract
Numerous mechanisms have been proposed for improv-ing TCP performance over wireless links, includimprov-ing those in wireless cellular networks. In this paper, we examine TCP performance over cellular data networks using various techniques to detect/infer the existence of such performance-enhancing mechanisms. Special at-tention is given to TCP split approaches. We describe measurements taken on commercial networks operated by three different providers (including two CDMA2000 networks and one GPRS network). We characterize packet-level loss on the cellular link, and discuss its im-pact on the end-to-end throughput of TCP connections. We then present inference techniques to identify whether a cellular provider implements a TCP proxy, Split-TCP, or no specific TCP support at the provider’s end of the cellular link. We find that all three providers selectively implement Split-TCP or TCP proxy for certain appli-cations (e.g., HTTP), but not for others. We also find that Split-TCP implementations differ from provider to provider. We discuss the potential performance gains of Split-TCP and TCP proxy. We find empirically that while Split-TCP can improve performance over cellular networks, the gain depends on flow sizes; TCP proxy using data compression outperforms Split-TCP. We also demonstrate several aspects of cellular networks (asym-metry in downlink/uplink loss rates, call setup delay, out-of-order packets, and MAC-layer packet concatenation) that impact the design and performance of link-layer and transport-layer protocols for such networks.
1 Introduction
The explosive growth of wireless networks poses chal-lenges to existing network protocols and applications that are designed for wired network. For instance, TCP, the most widely used transport protocol in the Internet, has been shown to perform poorly in wireless networks [1].
Numerous mechanisms have been proposed for improv-ing TCP performance over wireless links, includimprov-ing those in wireless cellular networks. These approaches fall broadly into three classes [2, 3, 4]: link layer ap-proaches, end-to-end apap-proaches, and split-connection approaches. Link layer approaches focus on improv-ing the quality of the wireless link usimprov-ing, for example, Forward Error Correction (FEC) or Automatic Repeat reQuest (ARQ). Snoop [2] is a link layer approach in which a snoop agent residing at the base station monitors the TCP flow on both directions and retransmits the lost packets locally instead of passing the duplicate ACKs back to the TCP source. End-to-end approaches improve TCP performance using mechanisms that reside solely at the end hosts. TCP SACK is such an example that re-duces the number of unnecessary retransmissions in TCP. A Split-connection approach inserts a splitting point be-tween the wireless and wired host1and splits the TCP
connection into two connections: one between the wired host and the splitting point, and the other between the splitting point and the wireless host. The main idea be-hind split-connection is to isolate wireless related issues from the TCP sender which usually resides on the wired network. For instance, the splitting point might exploit a protocol specialized for wireless networks [5]. Depend-ing on the techniques used between the splittDepend-ing point and the wireless host, the split-connection approach can have many variations. In this paper, we focus on two split-connection approaches:
• Split-TCP approach, in which a splitting point splits the original TCP connection into two simultaneous connections.
• TCP proxy approach, in which a proxy, located at a splitting point, receives all the data from the sender and then forwards the data to the receiver. A proxy 1The splitting point can be at the base station where traffic is
switched from the wired network to the wireless network, the gateway of the provider’s network to the public internet, or any location within the provider’s network.
also caches data for a period of time and intercepts users’ request for data. If the requested data is still in the cache and has not changed at the server, the proxy sends the cached copy to the user without ob-taining the data again from the server. The proxy also performs other functions such as data compres-sion before it forwards the data.
Note that TCP proxy differs from Split-TCP in that the proxy obtains the data first and then forwards it to the receiver, while data flows simultaneously in the two con-nections in Split-TCP. In the rest of the paper, we use the terminology regular TCP to refer to the traditional end-to-end TCP implementation, as opposed to split-connection TCP.
In this paper, we study TCP performance over cellular data networks. Given the numerous proposals to improve TCP performance in wireless networks, we ask the fol-lowing questions:
• Have these performance-enhancing techniques been deployed in commercial cellular networks? If so, what are the performance gains from these tech-niques?
• What other mechanisms can be or have been intro-duced into the current cellular networks to improve TCP performance?
We answer these questions by conducting end-to-end ex-periments in commercial networks operated by three dif-ferent providers (including two CDMA2000 networks and one GPRS network). Our paper makes the follow-ing main contributions:
• We design techniques to detect/infer the exis-tence of performance-enhancing mechanisms such as TCP proxy and Split-TCP. Our empirical mea-surements indicate that all three providers selec-tively implement Split-TCP or TCP proxy for cer-tain applications (e.g., HTTP). We also find that the performance-enhancing mechanisms differ from provider to provider.
• Using a combination of analysis and measurements, we study the performance gain provided by Split-TCP and Split-TCP proxy. Empirically, we find that the performance gain can be dramatic in some cases. • We characterize the behavior of TCP and Split-TCP
in cellular networks. In particular, we demonstrate that regular TCP behaves like and and be mod-eled as a fluid, that throughput fluctuates due to supplemental channel assignment and release, and that Split-TCP exhibits bursty sending behavior and long end-to-end delay (in tens of seconds). These observations are important for modeling TCP or Split-TCP in cellular networks. We also explore
practical issues in implementing Split-TCP, e.g., whether the TCP connections are terminated grace-fully when a connection is aborted.
• We characterize several aspects of cellular networks (e.g., call setup delay, MAC-layer packet concate-nation) that impact the design and performance of link-layer and transport-layer protocols for such networks.
• Our measurements indicate that introducing a split-ting point offers the flexibility to add other perfor-mance enhancing techniques. Based on our study of current practice in the commercial networks, we point out some techniques that are potentially bene-ficial to cellular networks.
Most proposals to improve TCP performance in wire-less networks have been evaluated performance through analysis and simulation; there are very few performance studies of real implementation of TCP or measurements in an operational network. In [3], the authors compare mechanisms for improving TCP performance over wire-less links by conducting experiments on a testbed, which does not reflect the effects of scheduling in a cellular data network [6]. Also, the bandwidth of a wireless link in that testbed is much higher than most of the real data rate available in today’s cellular data networks. Our exper-iments, on the other hand, are conducted in commercial cellular data networks and the results reflect the influence of various mechanisms (e.g., scheduling that are used in practice) in cellular data networks. A recent study mea-sures TCP performance in GPRS networks by analyzing traces collected at the gateway of the wireless provider’s network to the public Internet [7]. The behavior of the wireless network is inferred from the trace. We differ from this work in that our measurements are end-to-end, with a focus on end-to-end characteristics and the use of TCP split approaches.
The rest of the paper is organized as follows. Sec-tion 2 describes the experimental setup. Measurements of regular TCP in cellular networks are presented in Sec-tion 3. The study of the deployment of split-connecSec-tion approaches is described in Section 4. A performance comparison of various split-connection techniques is pre-sented in Section 5. Section 6 explores the characteris-tics of wireless channels using experiments over UDP. Finally, Section 7 concludes the paper.
2 Experiment Configuration
We conduct experiments using UDP and TCP over three commercial cellular data networks operated by three ser-vice providers. To keep these providers anonymous, we name them CDMA-I, CDMA-II, and GPRS-I, based on the technology that they use. Fig. 1 illustrates the basic
Desktop Internet Cellular Network Laptop Downlink measurements Uplink measurements
Figure 1: Experiment configuration.
configuration of the experiments. A wired host, shown as the desktop in the figure, is connected via an Ethernet in-terface to a LAN, which is in turn connected to the Inter-net via a high-speed wire link. A mobile station, shown as the laptop, is connected to the Internet via a wire-less service provider’s network using either CDMA2000 or GPRS technology. The laptop connects to the ser-vice provider’s network using a commercial wireless data card (also referred to as an aircard) sold by the service provider. The desktop used in the experiments is a Linux server running RedHat 9.0 and the laptop used is running Windows XP.
To better illustrate the relationship between these hosts, in the rest of the paper, we refer to the desktop as the wired host and the laptop the mobile. In Section 4, two wired hosts are used in the experiment and the mo-bile alternatively connects to each of them.
Traffic can flow either from the wired host to the mo-bile or in the reverse direction. In our UDP experiments, traffic only flows in one direction. With TCP applica-tions, data flows in one direction and acknowledgments flows in the other direction. We call an experiment a downlink experiment if the data flows from the wired host to the mobile, and an uplink experiment otherwise. We perform experiments in both directions.
In experiments using TCP, we conduct HTTP down-loads (to the mobile), FTP downdown-loads (to the mobile), FTP uploads (from the mobile), and a general TCP-based file transfer using our own socket program in both di-rections. The objective of these TCP experiments is to discover any TCP acceleration schemes and special TCP behaviors on cellular networks. An Apache HTTP server and a FTP server are running on the wired host. For the general TCP applications, we set up a TCP server running on the wired host (or mobile) which accepts connections from the mobile (or wired host) on a pre-determined TCP port. In experiments using UDP, a se-quence of UDP probe packets (of equal size and equal spacing) are sent in both directions to discover specific artifacts of the wireless channel. In different experi-ments, the payload size of the probes varies from 8 to 1024bytes and the time interval between two consecu-tive probes varies from 10 ms to 1 second.
In all experiments, we collect packet traces using tcp-dump [8] on the wired host and wintcp-dump [9] on the mo-bile. To obtain one way end-to-end delays, we use soft-ware on Linux and Windows XP to synchronize clocks at the sender and receiver.
3 TCP performance over cellular networks
In this section, we examine behavior and performance is-sues of regular TCP in cellular networks. We present par-ticular TCP behaviors over cellular that are not observed in other types of networks. Based on our measurement results, we argue that it is necessary to split TCP connec-tions in cellular networks so that the TCP implementa-tion at the splitting point can be optimized for cellular. We mainly focus on CDMA2000 networks and briefly compare TCP performance in CDMA2000 and GPRS networks.
3.1 Loss rate and RTT
We observe asymmetry in the loss rate between downlink and uplink. In 61 downlink TCP traces (each collected over a 15-minute interval), most of the traces have no data packet loss and the highest data loss rate is around 0.1%. On the other hand, all but one trace have ACK losses, with the largest ACK loss rate of 2.8% while the majority of the ACK loss rates are around 1%. Simi-larly, the data loss rate in the uplink is much higher while the ACK loss rate is much lower. In 36 uplink TCP traces, 35 traces have loss rates between 14% and 18% and the ACK loss rate for these traces are typically zero or close to zero. This is due to the asymmetry in loss rate of both directions. Downlink channels exhibit less loss rates than uplink channels (see Section 6.6). This asymmetry may be acceptable given that the majority of TCP applications, such as web-browsing, are downlink-data-intensive, and data loss has a greater effect on TCP throughput than ACK loss because a lost ACK could be “harmless” as long as a subsequent ACK is received be-fore the sender times out.
The characteristics of RTTs on a downlink transfer also differ from those on an uplink. During the day, downlink RTTs are usually about 1.1 seconds and in-crease to above 3 seconds after 9 p.m.2Among 36 uplink
traces, RTTs lie between 0.6 to 0.7 second in all traces with one exception of 1.2 seconds. Therefore, down-link RTTs are usually larger than updown-link RTTs. Our con-jecture is that this discrepancy is due to both downlink scheduling and power control to reduce interference.
2This increase in RTTs might be due to the increased usage from
5.5e+06 5.6e+06 5.7e+06 5.8e+06 5.9e+06 6e+06 6.1e+06 4 4.02 4.04 4.06 4.08 4.1 bytes
sending time (sec) send ack
Figure 2: Batch behavior of TCP over Ethernet.
3.2 Fluid
behavior
of
TCP
over
CDMA2000
TCP over wired Ethernet usually exhibits a batch behav-ior, namely a batch of packets is sent out back-to-back followed by a period in which no packets are sent out. One example is depicted in Fig. 2. Interestingly, this batch behavior does not occur in cellular data connec-tions. Instead, a continuous packet flow is observed at a TCP sender (see Fig. 3(a) for an uplink case and Fig. 3(b) for a downlink case). This difference might be explained as follows. With Ethernet, when no packet is lost, the TCP congestion window size eventually reaches the TCP receiving window size. Assume that the available band-width is higher than this TCP throughput. Then, the TCP sender sends out all the packets allowed by the current window and then waits for the returning ACKs before sending out more data packets. This produces the batch behavior. In a cellular data network, since the bandwidth is very low, the sender cannot send out all of the data packets within a TCP window before returning ACKs ar-rive. In this case, the sender keeps sending data packets without stopping. This produces a smoooth fluid sending behavior in cellular data networks. The above observa-tion indicates that, although an RTT-based discrete-time model is appropriate for TCP in wired networks, a fluid model is more appropriate for cellular networks.
3.3 Data sending rate versus packet losses
In TCP, the congestion window is cut by half after a lost packet is detected. This usually leads to a drop in the sending rate in a wired network. In cellular networks, we observe that this is not always the case. This is shown in Fig. 3(a), which plots the sequence number (in bytes) versus time, with the slope representing the sending rate. The sequence numbers of both the data and ACK pack-ets are plotted in the figure. The ACK sequence number stays constant between the 13.78th to 21.88th seconds. This indicates that at least one data packet is lost, which is confirmed by the retransmission of a data packet at around the 20th second. However, the sending rate (i.e.,
the slope) does not change after the loss event. This is be-cause, in this case, the sending rate is not constrained by the TCP congestion window. The average sending rate would be 408.8 bps if the congestion window were the constraint. In fact, the sending rate is much less than half of this value as seen in this figure. Therefore, a packet loss does not lead to a reduction in sending rate.
The above example is in the uplink direction. In a downlink TCP trace shown in Fig. 3(b), a similar sit-uation occurs where two packets are lost and yet, the sending rate does drop. We see from Fig. 3(b) that these packet losses lead to reduction in the sending rate, as in-dicated by the change of slope in the figure. The sending rate recovers to its original value after about 10 seconds, which is clearly undesirable because the traffic channel bandwidth assigned to the sender is under utilized dur-ing this recovery period.
Why is the sending rate affected by packet loss in the downlink direction but not the uplink direction? We speculate that this difference is due to the different im-plementations of TCP congestion control in Windows XP and Linux. In the uplink TCP case, the sender is the mobile which runs Windows XP while in the down-link TCP case, the sender is the wired host which runs Linux. In Linux, when a packet is lost, the congestion window is set to be half of the number of outstanding packets [10], as described in RFC2581 [11], instead of half of the previous congestion window size as imple-mented by Windows XP. With the limited bandwidth in cellular networks, the number of outstanding packets is much less than the number of packets in a congestion window. Therefore, with Linux’s TCP implementation, the congestion window size reduces dramatically when-ever a packet is lost and this reduction is large enough to constrain the sending rate. Hence the sending rate changes whenever a loss event occurs.
We also observe that the TCP sending rate can de-crease in the absence of packet loss. One example is shown in Fig. 3(c), which depicts the sequence number (in bytes) of data and ACKs versus time. We observe a change in the slope at around the 18th second. Further-more, at that time, the distance between ACKs and their corresponding data packets becomes larger than earlier, which indicates a larger RTT. This behavior is due to downlink scheduling in CDMA2000 by which the net-work either releases the supplemental channel from this mobile or assigns another supplemental channel with a lower bit rate. The reduction in mobile’s bandwidth leads to a lower sending rate.
3.4 Delayed ACK and “quick ACK mode”
As a general rule in TCP, two data packets are ACKed by one ACK packet. With a delayed ACK, the receiver does not send an ACK immediately after receiving a packet;
0 50000 100000 150000 200000 250000 0 5 10 15 20 25 30 bytes
sending time (sec) data
ack
(a) A packet loss does not affect sending rate (CDMA-I uplink). 1.45e+06 1.5e+06 1.55e+06 1.6e+06 1.65e+06 1.7e+06 1.75e+06 1.8e+06 1.85e+06 1.9e+06 100 105 110 115 120 125 130 bytes
sending time (seconds) data
ack
(b) A packet loss leads to reduction in sending rate (CDMA-I downlink)
0 20000 40000 60000 80000 100000 120000 140000 160000 180000 200000 0 5 10 15 20 25 30 bytes
sending time (sec) data
ack
(c) Sending rate drops without packet lossses (CDMA-II downlink)
Figure 3: TCP sending rate versus packet losses.
0 10000 20000 30000 40000 50000 60000 70000 0 1 2 3 4 5 bytes
sending time (sec) data
ack
Figure 4: CDMA-II uplink, every packet is ACKed at the beginning of the session.
0 10000 20000 30000 40000 50000 60000 0 1 2 3 4 5 bytes
sending time (sec) data
ack
Figure 5: CDMA-II downlink, delayed ACK. instead, it waits until either of two conditions become true: another packet comes in; or a delayed ACK timer expires. In either case, an ACK is then generated. The delayed ACK option is typically implemented in TCP stacks, with a delayed ACK timer of 200 ms. That is, the receiver delays an ACK up to 200 ms before sending it back to the sender. In our traces, we observe that the delayed ACK timer expires very frequently. This is due to the low bandwidth in cellular networks. In fact, when the bandwidth is less than 60 kbps, receiving a packet of 1500bytes takes more than 200 ms, which would always result in the expiration of the delayed ACK timer.
At the wired host, we observe that an ACK is sent out immediately after a data packet is received during the slow start phase. This is demonstrated in Fig. 4 which plots the sequence number of data and ACK packets ver-sus time observed at the receiver in the uplink direction in CDMA-II’s network. We observe that all ACK and data sequence numbers overlap with each other even at the beginning of the connection. This is not true in the downlink direction. Fig. 5 shows the receiver behavior observed at the mobile, again in CDMA-II’s network. At the beginning, ACK and data sequence numbers do not overlap. Instead, ACKs are delayed and sent out at the expirations of the delayed ACK timer.
The different behavior during the slow-start phase be-tween uplink and downlink is consistently observed in all three providers’ networks. Since the receiver in the uplink direction is a Linux PC while the receiver in the downlink direction is a Windows PC, we specu-late that this difference is caused by the different im-plementations of delayed ACK in Linux and in Win-dows. Windows uses a regular delayed ACK during slow start, while Linux uses an “optimized” version of de-layed ACK where every packet is acknowledged during slow start, which can be referred to as to the “quick ACK mode” in the Linux operating system. This behavior of acknowledging every packet in the slow start phase is es-pecially beneficial to wireless connections to reduce the possibility of timeouts in slow start.
3.5 Comparison of TCP over CDMA2000
and GPRS
We also conducted regular TCP experiments in GPRS-I networks. Both the uplink and the downlink TCP ex-periment results were collected on 4/21/2005. Fig. 6 compares the uplink RTT time series in GPRS-I (GPRS) and CDMA-II (CDMA2000) networks. Downlink RTT time series are compared in Fig. 7. We observe com-pletely different RTT behaviors in both networks. The
0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 350 400 RTT (sec)
Sending Time (sec) (a) GPRS-I GPRS 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0 20 40 60 80 100 120 140 RTT (sec)
Sending Time (sec) (b) CDMA-II CDMA2000
Figure 6: Uplink RTT comparison.
0 2 4 6 8 10 12 14 16 0 50 100 150 200 250 300 350 400 450 500 RTT (sec)
Sending Time (sec) (a) GPRS-I GPRS 0 1 2 3 4 5 6 7 8 9 10 0 50 100 150 200 250 300 350 RTT (sec)
Sending Time (sec) (b) CDMA-II CDMA2000
Figure 7: Downlink RTT comparison. burstiness of the GPRS channel (see Section 6) produces
highly variable and non-stationary TCP behavior. On the other hand, RTTs in CDMA2000 data networks are much less variable. Previous work [12] points out that highly varying RTTs degrade TCP throughput by causing spu-rious timeouts (timeouts that would not have occurred had the sender waited “long enough”), which forces the sender to enter the slow start phase followed by the con-gestion avoidance phase.
Fig. 8(a) depicts the sequence numbers of data sent and ACKs received versus time as observed at the sender of a downlink TCP connection in GPRS-I’s network. We can see that the communication between the sender and the receiver is in the form of short bursts (we also ob-served this from UDP experiments in Section 6). The uplink TCP connection also takes the form of bursts as shown in Fig 8(b). However, the switch between on and off of bursts in the uplink direction occurs less frequently and each burst lasts much longer.
We also find that GPRS channels can be very bursty. This is also verified by our TCP experiments. One ex-ample is shown in Fig. 9, where no packet is sent out be-tween the 17th and 28th seconds; while an instantaneous sending rate of 250 kbps is observed at the 29th second. This bursty behavior is not observed in CDMA2000 net-works.
3.6 The need to split TCP connection
Our experiments demonstrate the value of splitting TCP to allow changes to TCP at the splitting point in order to improve TCP throughput. For instance, the splitting point can remove the slow-start mechanism completely. In one of our experiments conducted in the GPRS net-work, at the beginning of the slow start, five consecu-tive timeouts led to a timeout timer of 48 seconds. The TCP sender only managed to send out three data pack-ets successfully during the first 100 seconds (Table 1)! The drastic window size reduction to one significantly in-creases the possibility of timeouts and limits the through-put of TCP. In the downlink direction of CDMA2000 networks, the assignment of a supplemental channel de-pends on the amount of data each user needs to send out. The TCP slow start phase postpones the time by which the mobile can grab the channel. This can affect the throughput between the splitting point and the mobile.
Furthermore, the splitting point may also ACK every packet, especially during the slow start phase, in order to reduce the possibility of timeouts due to ACK losses, as described in Section 3.4. It is clear from the above dis-cussion that TCP performance on both uplink and down-link can be improved if a TCP connection is split.
0 50000 100000 150000 200000 250000 300000 0 5 10 15 20 25 30 bytes
sending time (sec) data
ack
(a) GPRS-I downlink
450000 500000 550000 600000 650000 700000 750000 90 95 100 105 110 115 120 bytes
sending time (sec) data
ack
(b) GPRS-I uplink
Figure 8: Downlink and uplink TCP sender events comparison.
0 20000 40000 60000 80000 100000 120000 140000 160000 180000 0 5 10 15 20 25 30 bytes
sending time (sec) data
ack
(a) GPRS uplink sender events
0 50000 100000 150000 200000 250000 0 5 10 15 20 25 30 throughput(bits) time (sec) instant cum
(b) GPRS uplink sender throughput
Figure 9: Uplink TCP sender events and throughput. Table 1: Consecutive timeouts at the slow start
RTX sending time sequence no. cause
0.000010 1:1411 #1 2.999301 1:1411 ACK loss 5.205234 2821:4231 #2 11.199301 2821:4231 data loss #3 23.199301 2821:4231 data loss 29.996425 4231:5641 #4 53.989321 4231:5641 data loss #5 101.989301 4231:5641 data loss
4 Inferring
Deployment
of
Split-connection Mechanisms
In this section, we describe passive and active tech-niques that detect whether split-connection mechanisms are in use. We then apply these techniques to deter-mine whether TCP connections carrying different proto-cols (i.e., FTP, HTTP, and TCP) are split inside the three providers’ networks. Last, we explore some implemen-tation issues, such as graceful termination of Split-TCP.
4.1 Techniques to detect split-connection
In some cases, a split TCP connection can be detected by inspecting the tcpdump trace. For instance, we some-times observe a third IP address other than the sender’s and the receiver’s — an indication that the TCP connec-tion is split and the third IP address is the IP address of the splitting point. We also sometimes observe different payload sizes if the connection is split or a timestamp op-tion being used by one connecop-tion but not the other. Dif-ferent receiver window sizes advertised in ACK packets are also sometimes observed when the receiver window sizes are different for the splitting point and the receiver. Sometimes, we observe a change in the protocol. For ex-ample, CDMA-II uses UDP instead of TCP on the wire-less path. Also it is possible to observe different IPIDs. If the IPIDs differ for the packet sent out by the TCP source and the packet received at the destination, then the packets are not the same and the TCP connection is split.
However, these are not necessary conditions for a split-connection and a split-connection may not exhibit any of the aforementioned symptoms. For example, the splitting point can spoof the original IP address, in which case inspection of the IP addresses would not indicate a split TCP connection. We therefore design passive and active methods to detect the split of TCP connections us-ing timus-ing information.
sender splitting point receiver
Figure 10: Time diagram of TCP split.
sender splitting point receiver
Ds i Ar j As j Dr i
Figure 11: Detection of split TCP without clock synchro-nization.
We first define our notation. As shown in Fig. 10, let Rspdenote the RTT of the TCP between the sender and
the splitting point. Let Dspbe the one-way delay of data
packet between the sender and the splitting point. Let Dpr be the one-way packet delay between the splitting
point and the receiver, Tr
ackbe the time interval between
receiving a data packet and sending an ACK at the re-ceiver, Tpbe the time interval between receiving a packet
from the first part of the connection and forwarding the packet to the second part of the connection at the splitting point.
Theorem 1 When clocks at the sender and the receiver
are perfectly synchronized, the split of a TCP connection can be detected if Dsp+ Tp+ Dpr+ Tackr > Rsp.
When clocks at the sender and receiver are not per-fectly synchronized, we generalize Theorem 1 to detect
the split of a TCP connection. Again, we define some notation first, as shown in Fig. 11. Consider packets i and j, j ≥ i. Let Let Ds
i be the sending time of the
i-th packet from i-the sender, As
j be the receiving time of
ACK corresponding to j-th data packet, Dr
i be the time
the receiver receives the i-th packet, Ar
j be the time the
receiver acknowledges j-th packet.
Theorem 2 When the offsets of clocks on the sender and
the receiver are fixed, the split of a TCP connection can be detected if As
j− Dis≤ Arj− Dir.
When applying Theorem 2, we usually set i = 1 and vary j to find cases that result in a detected TCP split. Theorem 2 does not require clock synchronization but assumes the offsets of the two clocks are fixed. When ap-plying Theorem 2, we can consider a small error old and assume the offset variation is within this thresh-old. We now present an active method to detect whether a TCP connection is split. This approach does not require clock synchronization or fixed offsets.
Theorem 3 Suppose we increase Tr
ack by T at the receiver and measure the RTTs at the sender. Let {Ri}, i = 1, . . . , n, be the sequence of measured RTTs. If min{Rj} < T, then the TCP connection is split.
We use the passive detection method to detect down-link split-connection and the active detection method to detect uplink split-connection. The passive detection method can detect downlink Split-TCP since Tpis large
(tens of seconds, see Section 4.2.1) in the downlink di-rection. In the uplink direction, Tp is not sufficiently
large. Therefore, the passive method fails to detect Split-TCP in the uplink direction.
4.2 Usage of split-connection in
commer-cial networks
We now report the prevalence of split-connections in the three providers’ networks using the techniques described earlier. In particular, we apply these techniques to appli-cations using FTP and HTTP.
4.2.1 Usage of split-connection by FTP
We run FTP in the downlink and uplink directions in the three commercial provider networks. Combining our detection methods (passive and active) and visual inspection of tcpdump traces, we find that CDMA-I and CDMA-II split TCP connections in both directions, while GPRS-I does not split TCP connection for FTP. We next describe the results in more detail.
We run two FTP experiments in both downlink and uplink directions in CDMA-I’s network. In the downlink trace, we observe 869 packet satisfying the condition in
0 1e+06 2e+06 3e+06 4e+06 5e+06 6e+06 0 20 40 60 80 100 throughput (bps) time (sec)
(a) CDMA-I downlink FTP (Split-TCP) sender throughput (averaged every 100ms)
0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 10 20 30 40 50 60 70 80 90 100
Receiver Window Size (bytes)
ACK Time (sec) recv win size
(b) CDMA-I downlink FTP (Split-TCP) receiver windows size
0 5 10 15 20 25 30 0 20 40 60 80 100 120 140
one-way end-to-end delay (sec)
sending time (sec)
(c) CDMA-I downlink FTP (Split-TCP) end-to-end delay
Figure 12: Characteristics of Split-TCP. Theorem 2. Hence, we conclude that the TCP connection
is split. Fig. 12(a) plots a time series of the throughput (averaged every 100ms) at the sender. The throughput is very bursty: the sender sends for very short period of time and then stops sending since the receiving buffer at the splitting point is full. Fig. 12(b) shows the TCP re-ceiver window size reported from the splitting point. The receiver window size time series agrees with the through-put series illustrated in Fig. 12(a). Fig. 12(c) plots the series of data packet end-to-end delays. In general, the end-to-end delays are very long. Most of the end-to-end delays lie above 10 seconds and the maximum end-to-end delay is around 27 seconds. These long end-to-end-to-end-to-end delays are typical of Split-TCP: the buffer at the splitting point leads to long end-to-end delays.
It is difficult to detect the split of a TCP connection using the passive method on uplink TCP. In order to de-termine whether uplink FTP also split TCP connections, we delay ACKs by 10 seconds using Nistnet [13] at the receiver, which is a wired host at University of Mas-sachusetts, Amherst (UMass). The trace was collected on 02/23/2005. We measure the RTTs at the TCP sender and find that they are all below 10 seconds, which implies that the TCP connection is split.
We detect that CDMA-II splits TCP connections in FTP in both uplink and downlink directions from in-specting tcpdump traces3. In the trace, we observe the IP
address of the splitting point. Furthermore, the protocol used in the connection between the splitting point and the mobile is changed to UDP. We speculate that UDP tun-neling is used between the splitting point and the mobile. That is, TCP packets are encapsulated into UDP packets. most packets sent from the splitting point are 19 bytes. 4.2.2 Usage of split-connection by HTTP
We conduct experiments by requesting an HTTP object from a web host. The HTTP object can be either text data
3Our passive/active techniques lead to the same conclusion
Table 2: TCP acceleration schemes for different providers
CDMA-I CDMA-II GPRS-I
HTTP data TCP proxy Split-TCP Split-TCP
HTTP image TCP proxy TCP proxy TCP proxy
FTP Split-TCP Split-TCP No
TCP No No Split-TCP
Protocol change No Yes No
IP spoofing Yes No Yes
or an image. Using our passive/active detection tech-niques and inspecting tcpdump traces, we discover that all three providers split TCP connections. We further de-termine whether TCP proxy or Split-TCP is used by the three providers using the following methodology. We de-tect the usage of proxy from two aspects. First, all of the ACKs from the splitting point include the same receiv-ing buffer size. Second, when repeatedly downloadreceiv-ing the same file, some of the later downloads are not from the original server, as indicated by the tcpdump trace. We detect the usage of Split-TCP based on the dynamics of the receiving buffer size. When Split-TCP is utilized, we observe that the available receiving buffer size reaches zero, and then increases to the full size, indicating that the receiver buffer is filled and then depleted by the mo-bile user. Using the above methodology, we find that CDMA-I uses a TCP proxy for both HTTP data and im-ages; CDMA-II and GPRS-I use Split-TCP for HTTP data and a proxy for HTTP image, as shown in Table 2. 4.2.3 Summary of TCP acceleration schemes for
different providers
We summarize the usage of TCP acceleration schemes by the three providers in Table 2.
Unlike CDMA-I and CDMA-II, GPRS-I uses Split-TCP for both downlink and uplink Split-TCPs, excluding FTP traffic. This leads to end-to-end delays of tens of
sec-onds. GPRS-I also allows the mobile user to choose whether or not to use TCP acceleration. If not, a regular TCP connection is used. The TCP experiments presented in Section 3 are conducted with the non-acceleration op-tion.
4.3 Graceful Termination of Split-TCP in
HTTP
Since Split-TCP violates the end-end semantics of TCP, one potential problem with it is whether TCP connec-tions (between the sender and the splitting point and be-tween the splitting point and the receiver) can be termi-nated gracefully when a TCP connection is aborted in the middle. We investigate this issue in CDMA-II and GPRS-I networks by downloading HTTP data objects.
We download a file of 2M bytes from a UMass web server. The download is aborted in the middle. By in-specting the tcpdump traces at the server and the mobile, we determine whether the TCP connections are termi-nated gracefully. For CDMA-II, both TCP connections terminate immediately after the downloading is aborted. For GPRS-I, only the TCP connection between the split-ting point and the client is terminated. The TCP connec-tion between the server and splitting point is terminated after 12 minutes. During this period, the server keeps probing the receiver buffer size at the splitting point and always receives zero as the reply. This is because the TCP session between the splitting point and the client is terminated and hence the data in the receiving buffer cannot be removed.
5 Performance
Gains
from
Split-connection Techniques
In this section, we explore performance gains from Split-TCP and Split-TCP proxy techniques using both experiments and analysis.
5.1 Performance gain from Split-TCP
We first compare the performance of Split-TCP and reg-ular TCP using experiments and analysis.
5.1.1 Side-by-side experimental comparison To obtain a fair comparison between Split-TCP and regu-lar TCP, we need to compare them using the exactly same application. From experiments, we find that, in CDMA-I’s network, FTP traffic is split if the FTP server is run-ning on (listerun-ning to) the regular FTP control port (port 21). Otherwise, the traffic is not split. In the follow-ing, we compare Split-TCP and regular TCP using FTP in CDMA-I’s network.
Table 3: Performance Improvement by Split-TCP
Mobile File Size Throughput Time
Location (KBytes) Improvement Reduction
West 100 17% 17% 1000 8% 7% East 1 -39% -59% 5 32% 17% 10 54% 32% 50 71% 39% 100 23% 19% 1000 14% 12%
We configure two FTP servers (wired hosts) running on different ports: one on port 21 (the regular FTP con-trol port and the other on a port other than 21. The two servers are co-located on the west coast. To explore the effect of the server-client distance on performance, we configure two clients (mobiles), one on the east coast and the other on the west coast. A client alternatively connects to each server to download a file. We vary the file size from 1 K to 1000K bytes. Each experiment is re-peated 100 to 1000 times depending on the length of the execution. All experiments are conduct at around 2AM local time, in order to reduce the influence of rate fluc-tuation caused by voice users. Our performance metrics are average throughput and downloading time.
Table 3 summarizes the results over all experiments. When the file size is 50K bytes, Split-TCP leads to the greatest improvement (throughput is increased by 71% over regular TCP). The improvement decreases for larger and smaller files. For a file transfer of 1KB, which can fit into one packet, Split-TCP performs worse than reg-ular TCP, since only a single packet is transferred and the splitting point only adds extra delay. We also ob-serve that Split-TCP provides more dramatic improve-ments when the server and client are far away from each other. We next explain these observations using a simpli-fied analysis.
5.1.2 Analytical study
For ease of exposition, we refer to the TCP session be-tween the sender and the splitting point as the upstream TCP and the other session between the splitting point and the receiver as the downstream TCP. Let v denote the mobile data rate assigned by the cellular network. Let r1 and r2 denote the RTT of upstream TCP and
down-stream TCP respectively. As the sending rate reach-ing v, Split-TCP performs in the same manner as reg-ular TCP. We therefore only focus on the time required for the sending rate to reach v using regular TCP and Split-TCP, denoted as Tregular and Tsplit respectively.
not finished slow-start when its sending rate reaches v. Then Tregular = (r1 + r2) log(r1+ r2)v/s, where s
denotes the size of a packet. In Split-TCP, we first as-sume that the downstream TCP does not go through slow start. Instead, the initial window size is r2v. That is, the downstream TCP fully utilizes the sending rate. The upstream TCP performs slow start and has not fin-ished slow-start when its sending rate reaches v. There-fore, Tsplit = r1log(r2v/s). Since r1/r2 is small,
Tregular− Tsplit≈ r1+ r2log r2+ r2log(v/s).
When v = 96 kbps, s = 1500 bytes, r1 = 0.05
sec-ond, r2 = 1second. We have Tregular− Tsplit ≈ 3.05
seconds. The amount of data downloaded by regular TCP and Split-TCP before the sending rate reaches v is 22.5K bytes without using delayed ACK and 45K bytes when using delayed ACK. This explains why the largest relative performance gain is observed when the file size is around 50K bytes. As the file size increases or de-creases, the relative difference between regular TCP and Split-TCP decreases.
We now assume that the downstream TCP performs slow start. In this case, Tsplit= r2log(r2v/s). We have
Tregular−Tsplit ≈ r1(log r2+logvs+1). Note that, this
difference is roughly proportional to r1, which explains
why the performance gain from Split-TCP is more dra-matic when the server and client are far away from each other. Using the parameters in the earlier example, we have Tregular− Tsplit ≈ 4r1 = 0.2second, indicating
only a slight performance improvement by using Split-TCP. However, when considering the effect of schedul-ing, this improvement might be larger, as discussed be-low. When using Split-TCP, data flow to the wireless network faster than using regular TCP, since the through-put in the upstream TCP session in Split-TCP is higher. Therefore, supplemental channels are more likely to be assigned to a connection using Split-TCP than one using regular TCP (see Section 6.3), leading to a higher data rate in Split-TCP.
5.2 TCP proxy versus Split-TCP
We now compare the performance of TCP proxy and Split-TCP.
5.2.1 Experimental comparison
As shown in Table 2, in CDMA-I’s network, TCP proxy is used for HTTP while Split-TCP is used for FTP. In the following, we compare the performance of TCP proxy and Split-TCP by conducting back-to-back experiments using HTTP and FTP in CDMA-I’s network. A wired host acts as the server (HTTP or FTP) and a mobile acts as the client. Both the server and the client are located at UMass.
In the first set of experiments, the client downloads a file of 12M bytes, which contains a large amount of re-dundancy (evidenced by the fact that the file can be com-pressed to 2M bytes by gzip). We observe an average reduction of 42% (over three experiments) in download-ing time when usdownload-ing TCP proxy over Split-TCP. In the second set of experiments, the client downloads a file of 10M bytes, which contains less redundancy (compress-ible to 5M bytes by gzip). The reduction in downloading time using TCP proxy over Split-TCP is less dramatic, an average of 18%. We next provide an analysis on per-formance improvement of TCP proxy over Split-TCP.
5.2.2 Analytical comparison
Let S denote the size of the file to be downloaded. Let Tproxy and Tsplit denote the downloading time using
TCP proxy and Split-TCP respectively. Let p be the cache hit ratio of the proxy. Let τspbe the TCP
through-put between the sender and the splitting point without re-ceiver buffer back-pressure. Let τprbe the TCP
through-put between the splitting point and the receiver. We as-sume τsp > τpr, which is reasonable since the
band-width in wireless network is much lower than that in the wired network. Assume S is large enough so that we can ignore a one-way delay from the sender to the splitting point, we have Tsplit = τSpr and Tproxy =
(1 − p)(S τsp +
ρS τpr) + p
ρS
τpr, where ρ is the inverse of
the compression ratio. Then Tsplit− Tproxy > 0if and
only if ρ < 1 − (1 − p)τpr
τsp When p = 0, the requirement
for TCP proxy to outperform Split-TCP is ρ < 1 −τpr
τsp.
When τpr= 100kbps, and τsp= 10Mbps, this
require-ment is ρ < 0.99. When τpr = 100kbps, and τsp = 1
Mbps, this requirement is ρ < 0.90. In both cases, the compression ratio is close to 1 and easily achievable for most web contents. Therefore, TCP proxy with data compression outperforms Split-TCP. Following a similar argument, we also find that, without compression, TCP proxy does not out perform Split-TCP even with high cache hit ratio of 0.5 when file size is larger than 34K bytes, which is the TCP receiving buffer size at the split-ting point of the three providers.
6 Artifacts of cellular data network
through UDP experiments
In this section, we first use UDP-based experiments to explore uplink and downlink channel characteristics in CDMA2000 networks. At the end, we briefly discuss bursty packet sending in GPRS networks.
0 20 40 60 80 100 -4 -2 0 2 4 6 Packet # Time (sec)
Figure 13: Estimate of call setup delay using linear re-gression (downlink).
6.1 Call setup delay in CDMA2000
net-works
In both downlink and uplink directions, we observe very small inter-arrival times at the beginning, much smaller than the inter-sending time at the sender. One example is shown in Fig. 13, which plots packet sequence num-bers versus their arrival times at the receiver. These small inter-arrival times at the beginning are caused by the dor-mant state of the mobile. Without any traffic, the mobile is in the dormant state and no traffic channel is assigned to it. The mobile must obtain a fundamental traffic chan-nel (in reverse or forward direction) before it can perform any activity (send or receive). We refer to the duration from initiating a network activity (sending or receiving) to obtaining a fundamental channel as the call setup de-lay of the mobile.
We use linear regression to estimate the call setup de-lay, as illustrated in Fig. 13, and the estimated call setup delay for this example is approximately 4 seconds. In CDMA-I traces, most of the downlink call setup delays are 3 to 8 seconds while most of the uplink delays fall between 2 and 3 seconds. In the CDMA-II traces, the majority of the call setup delays in the downlink direc-tion range from 2 to 5 seconds; the call setup delays in the uplink direction are longer, ranging from 12 to 14 seconds.
This discrepancy between the uplink and downlink might be due to different procedures employed in obtain-ing a fundamental traffic channel in each direction. In the downlink experiments, the base station initiates call setup by paging the mobile on the paging channel. In the uplink experiments, the mobile initiates the call setup by sending a request on the access channel. The downlink call setup delay is mainly determined by the paging strat-egy and the uplink delay depends on the success rate on the access channel. The differences between two cellular networks in call setup delays come from different paging implementations and access protocol, channel capacity, and load on the access channels. Based on our
measure-ments in Umass, CDMA-II seems to have a better paging strategy while CDMA-I has a better access channel engi-neering.
6.2 Loss rate
Loss rate is higher in uplink channels than in downlink channels. In CDMA-II traces, we observe considerably higher loss rate in uplink than downlink. We conjecture the lower downlink loss rate is brought by the implemen-tation of downlink transmission scheduling at the base station which is not available for uplink transmissions. With scheduling combined with power control, a lower downlink SINR (signal-to-noise-interference-ratio) can be achieved than the uplink SINR. Another reason might be that the downlink channel utilizes more aggressive ARQ schemes than the uplink channel (e.g., allows more retransmissions). However, will see that downlink chan-nels also have fewer out-of-order packets, which is an indication of fewer retransmissions.
6.3 Supplemental channel assignment in
CDMA2000 networks
By default, a mobile only has a fundamental channel to receive or send data, which has a fixed a receiv-ing/sending rate of 9.6 kbps. When the data activity re-quires more bandwidth than what the fundamental chan-nel provides, an additional traffic chanchan-nel, known as the supplemental channel, is assigned to the mobile. The duration and bit rate of the supplemental channel may vary. With CDMA2000 RC3 (radio configuration op-tion 3), the supplemental channel can achieve a data rate from 9.6 kbps up to 153.6 kbps. The duration of the supplemental channel is determined by the scheduler of the wireless network. In the following, we use UDP ex-periments to illustrate the assignment and release of the supplemental channel. We send periodic probes from the wired host to the mobile. The packets are 1024 bytes in length, and are sent at an interval of 100 ms. This traffic demands a sending rate of at least 81 kbps. Therefore the supplemental channel is needed for this experiment. Fig. 14 depicts the receiving rate (averaged every sec-ond). In the figure, the frequent change in receiving rate is caused by the assignment and release of the supple-mental channel.
6.4 Out-of-order packets
We observe out-of-order packets in the uplink direction. For instance, in an uplink trace collected on 04/24/2005 in CDMA-II’s network, we observe 41 out-of-order packets among 5, 000 UDP packets (0.8%). Out-of-order packets also occur in the uplink direction in CDMA-I’s network, but less frequently. The out-of-order
0 2 4 6 8 10 12 14 16 18 20 90 100 110 120 130 140 150
receiving rate (pkt per sec)
time (sec)
Figure 14: Sending rate fluctuation caused by supple-mental channel assignment and release.
0 0.005 0.01 0.015 0.02 0.025 30 30.2 30.4 30.6 30.8 31 Inter-arrival(sec) Time (sec)
Figure 15: Effect of link layer concatenation on packet inter-arrival time of periodic probing (inter-sending time of 10 ms, packet payload of 8 bytes).
ets might be caused by link-layer ARQ since ARQ im-plemented by RLP is NACK-based [14]. However, in neither providers’ networks do we observe out-of-order packets in the downlink direction. This might be due to the fact that less retransmissions occur in the down-link direction because the downdown-link channel have lower SINRs.
6.5 Packet concatenation at the MAC layer
For certain probe packet sizes and inter-sending times, we observe that some packets arrive at the receiver at al-most the same time. One example is shown in Fig. 15, which depicts the inter-arrival times of packets received by the mobile. The size of the packets is 8 bytes. The sending time is 10ms. We observe that the inter-arrival time is either 10ms or alternates between 0 and 20ms. We believe that this is due to MAC layer packet concatenation. When the inter-arrival time alternates be-tween 0 and 20 ms, every two packets are sent within the same RLP (Radio Link Protocol) frame. Usually, an IP packet is segmented as PDUs by the MAC layer. PDUs are carried in frames on a traffic channel, and each frame is 20 ms in length. Depending on the data rate, multiple PDUs can be fit in a single frame [14].
460 480 500 520 540 560 580 600 50 51 52 53 54 55 Packet # Time (sec) uplink downlink
Figure 16: Downlink and uplink packet arrival time, pe-riodic probing with 8-byte packets at 100ms interval, CDMA-I
fore, multiple small packets close in time will be con-catenated together. This is confirmed by the disappear-ance of very small inter-arrival times for longer packet inter-sending times (e.g., 300 ms in uplink or 100 ms in downlink direction) or large packet sizes (e.g., packet size of 1024 bytes). To further confirm this, we send out periodic packet trains, each train consisting of four 8-byte packets. We observe that the 4 packets in the same train are received together, which is another evidence of MAC layer concatenation. We noticed that in downlink channels, only packets sent within very small time inter-vals can be concatenated, i.e., below 100 ms. However, in the uplink direction, packets sent within 300ms inter-vals can be concatenated. Therefore, the arrival times in the downlink direction are sometimes more regular than the uplink, as depicted in Fig. 16. With 8-byte packets and 100ms inter-sending time, the downlink inter-arrival time is constantly at 100 ms while a periodic pattern is observed for the uplink direction.
6.6 Summary of asymmetry of uplink and
downlink channels
We observe the following asymmetry between uplink and downlink in the two CDMA2000 networks:
• Loss rate: Loss rate is higher in uplink channels than in downlink channels.
• Call setup delay: In both CDMA2000 networks, the call setup delay in uplink is much longer than down-link.
• Packet concatenation: In the uplink direction, pack-ets sent with larger intervals can be concatenated. • Out-of-order packets: Observed in the direction of
950 1000 1050 1100 1150 1200 1250 1300 100 105 110 115 120 125 130 Packet # Time (sec)
Figure 17: Packet arrival time in uplink direction, peri-odic probing with 8-byte packets at the interval of 100 ms, GPRS-I.
6.7 Burstiness of GPRS channels
Fig. 17 illustrates the uplink channel behavior in the GPRS network when 8-byte packets are sent at 100 ms intervals. We observe that most of the time, the packets are sent in batches as short bursts. Between the 107th and 113th seconds, there are no transmission activities. Then longer data bursts appear and gradually the burst size re-duces back to what it is before the interruption. It seems that the length of the bursts depends on how much data is queued to be transmitted. The more data is queued, the longer the bursts are.
7 Conclusion
In this paper, we performed end-to-end measurements on three commercial cellular data networks. We character-ized TCP behavior and performance issues that are spe-cial to cellular networks. We developed passive and ac-tive techniques to detect whether a split-connection ap-proach is used in each provider’s network. We discov-ered that split-connection has been implemented in all three networks for selected applications. Two mecha-nisms in the split-connection family have been identi-fied: Split-TCP and TCP proxy. We compared the per-formance of the two mechanisms through measurements and interpreted our observations using simple analytical models. We observed that Split-TCP can achieve sig-nificant throughput improvement over regular TCP for small-sized flows. Furthermore, we demonstrated that TCP proxy is quite effective in improving user perceived performance via data compression.
We also performed experiments using UDP probes to examine the artifacts of wireless channels. We found that the wireless channels are asymmetric in several aspects such as call setup delay, loss rate, packet concatenation, and packet re-ordering. These artifacts, especially asym-metry, were found to have significant impact on duplex applications/protocols, such as TCP, which rely on
feed-backs. Hence, we recommend a joint consideration of uplink and downlink channels when designing and mod-eling such protocols in cellular networks.
8 Acknowledgement
The first author would like to thank Sharad Jaiswal for very helpful conversations on details of TCP protocol and implementations.
References
[1] R. Caceres and L. Iftode, “Improving the performance of reliable transport protocols in mobile computing environ-ments,” IEEE J. Select.Areas Commun., vol. 13, no. 5, pp. 850–857, 1994.
[2] H. Balakrishnan, S. Seshan, and R. H. Katz, “Improv-ing reliable transport and handoff performance in cellular wireless networks,” ACM Wireless Networks, vol. 1, no. 4, pp. 469–481, 1995.
[3] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz, “A comparison of mechanisms for improving TCP performance over wireless links,” IEEE/ACM
Trans-actions on Networking, vol. 5, no. 6, pp. 756–769, 1997.
[4] H. Elaarag, “Improving TCP performance over mobile networks,” ACM Computing Suryeys, vol. 34, pp. 357– 374, SEP 2002.
[5] A. Bakre and B. R. Badrinath, “I-TCP: Indirect TCP for mobile hosts,” 15th International Conference on
Dis-tributed Computing Systems, 1995.
[6] B. H. Kim, I. Lee, and K. Chu, “End-to-end application performance impact on scheduler in cdma-1xrtt wireless system,” in IEEE 61st Semiannual Vehicular Technology
Conference, May 2005.
[7] P. Benko, G. Malicsk, and A. Veres, “A large-scale, passive analysis of end-to-end TCP performance over GPRS,” in Proc. Infocom 2004, March 2004.
[8] “Tcpdump,” http://www.tcpdump.org/. [9] “Windump,” http://windump.polito.it/.
[10] P. Sarolahti and A. Kuznetsov, “Congestion control in linux TCP,” in Proc. of USENIX’02, June 2002.
[11] M. Allman, V. Paxson, and W. Stevens, “TCP Congestion Control,” RFC 2581, 1999.
[12] R. Ludwig and R. H. Katz, “The Eifel algorithm: Mak-ing TCP robust against spurious retransmissions,”
SIG-COMM Comput. Commun. Rev., vol. 30, no. 1, pp. 30–36,
2000.
[13] “NIST Net,” http://snad.ncsl.nist.gov/itg/nistnet. [14] V. Vanghi, A. Damnjanovic, and B. Vojcic, The
cdma2000 System for Mobile Communications. Prentice
Hall Communications Engineering and Emerging Tech-nologies Series, 2004.