Priority TX in 802 - 11
Priority TX in 802 - 11
Priority TX in 802 - 11
Andrei Gurtov
Cellular Systems Development, Sonera Corporation
Abstract: This paper has several contributions. First, we report that long sudden delays
during data transfers are not uncommon in the GPRS wireless WAN. Long
sudden delays can lead to spurious TCP timeouts and unnecessary
retransmissions. Second, we show that the New Reno algorithm increases the
penalty of spurious TCP timeouts and that an aggressive TCP retransmission
timer may trigger a chain of spurious retransmissions. Third, we test how four
widely deployed TCP implementations recover from a spurious timeout and
notice that two of them have severe problems to recover. Finally, we discuss
several existing ways to alleviate the problems.
1. INTRODUCTION
The number of nomadic users that access the Internet using wireless
technology grows rapidly. Nowadays Wireless Wide Area Networks (W-
WAN) are the primary means for nomadic users to access the data services.
With all advantages, mobile computing introduces an environment quite
different from the one found in fixed networks due to scarce radio bandwidth
and intermittent connectivity. Data services provided by W-WANs allow for
a rather low link speed; error losses, changing line rate and variable delays
present additional challenges for an efficient data transport. The Global
System for Mobile Communications (GSM) is a widely successful effort to
build a W-WAN system with millions of users in Europe and worldwide [20,
25]. GSM data, High Speed Circuit Switch Data (HSCSD), and General
Packet Radio Service (GPRS) [4] are data transmission services offered by
GSM.
Many popular Internet applications including World-Wide Web (WWW),
File Transfer Protocol (FTP) and email require reliable data delivery over the
network. The Transmission Control Protocol (TCP) is the most widely used
transport protocol for this purpose; traffic studies in the Internet report that
the dominant fraction of the traffic belongs to TCP [29]. TCP was designed
and tuned to perform well in fixed networks, where the key functionality is
to utilize the available bandwidth and avoid overloading the network.
However, nomadic users want to run their favorite applications that are built
88 Andrei Gurtov
2. BACKGROUND
2.1 TCP
The Transmission Control Protocol (TCP) [24, 3, 2] is the most used
transport protocol in the Internet. TCP provides applications with reliable
byte-oriented delivery of data on the top of the Internet Protocol (IP). TCP
sends user data in segments not exceeding the Maximum Segment Size
(MSS) of the connection. Each byte of the data is assigned a unique
sequence number. The receiver sends an acknowledgment (ACK) upon
reception of a segment. TCP acknowledgments are cumulative; the sender
has no information whether some of the data beyond the acknowledged byte
has been received. TCP has an important property of self-clocking; in the
equilibrium condition each arriving ACK triggers a transmission of a new
segment. Data are not always delivered to TCP in a continuous way; the
network can lose, duplicate or re-order packets. Arrived bytes that do not
begin at the number of the next unacknowledged byte are called out-of-order
data. As a response to out-of-order segments, TCP sends duplicate
acknowledgments (DUPACK) that curry the same acknowledgment number
as the previous ACK. In combination with a retransmission timeout (RTO)
on the sender side, ACKs provide reliable data delivery [3]. The
retransmission timer is set up based on the smoothed round trip time (RTT)
Effect of Delays on TCP Performance 89
MSS per each DUPACK. When the congestion window is inflated enough,
each arriving DUPACK triggers a transmission of a new segment, thus the
ACK clock is preserved. When a non-duplicate ACK arrives, the fast
recovery is completed and the congestion window is deflated.
the new base station at the expense of additional delay. As the result, the
data transfer can be suspended for tens of seconds.
Blocking by high-priority traffic. When packet-switched and voice calls
have to co-exist in a W-WAN network, in most cases the network operator
assigns a higher priority to voice calls. An incoming voice call can
temporarily preempt radio resources from packet-switched traffic, thus
causing a delay in data transfer in the order of tens of seconds. Currently the
support for Quality of Service (QoS) is being introduced into packet-
switched W-WANs. Interactive traffic, for example web browsing, may have
higher priority over best-effort bulk data transfers. There can be situations
when the lower-priority traffic is delayed when higher-priority connections
become active.
Figure 1. Reaction of TCP on a 13-second delay (sender and receiver traces) [15].
second sudden delay. No segments are actually lost during the delay, but the
TCP connection cannot recover from the delay for its lifetime unnecessary
retransmitting many segments. Our preliminary measurement results indicate
that the handover delay in the live GPRS network can exceed 10 seconds and
thus is a likely reason for spurious TCP timeouts. Figure 4 shows the
handover delay measured between two cells using the standard ping program
with 32-byte packets. While in general the round trip time is stable at 1.3
seconds, it soars up to 10 seconds and more every time when the cell
reselection is forced from the mobile terminal.
While every effort should be done to identify and remove sources of such
delay spikes, it is unlikely that they can be completely eliminated.
Furthermore, it is hardly possible to avoid spurious TCP timeouts occurring
at such delay spikes, as it would require an extremely conservative TCP
retransmission timer hampering the recovery of lost data. Thus, it is actual to
ensure that existing and future TCP implementations recover reasonably
from spurious timeouts.
94 Andrei Gurtov
Figure 3. A delay during a downlink bulk TCP transfer in the GPRS network.
Figure 4. RTT spikes in GPRS when cell reselection is forced from the mobile terminal.
Effect of Delays on TCP Performance 95
1 Ideas discussed in this section were presented on the end-to-end interest list in August 1-3,
2000
2 RFC2582 permits sending new segments on partial ACKs if allowed by the congestion
window. The available space in the congestion window depends on whether retransmitted
segments are counted into it, which is not clearly said in RFC2581. Not sending new
segments on partial ACKs seems to be a more conformant version of New Reno.
96 Andrei Gurtov
capturing an exact scenario where a delay is present on the real data link is
difficult, and performance comparison of different TCP implementations
may not be valid. Seawind reproduces the basic properties of a wireless data
link such as the limited line rate and a large propagation delay, and also
allows placing a long sudden delay at a certain time in the connection.
Seawind intercepts the flow of packets between a mobile host and a server
and delays IP packets emulating the effect of a wireless link. An advantage
of the emulation approach over tests for example with the NS simulator [9]
is in ability to experiment with and compare the performance of different
existing TCP implementations.
Figure 6. Recovery of TCP in FreeBSD 4.1 from a spurious timeout (complete connection).
Figure 8. Recovery of TCP in Linux 2.2.12 from a spurious timeout (zoomed, total
connection time 115 seconds).
Figure 9. Recovery of TCP in Linux 2.4.0 from a spurious timeout (zoomed, total connection
time 114 seconds).
Effect of Delays on TCP Performance 101
Linux 2.2 (Figure 8) recovers relatively well from the spurious timeout.
Arriving DUPACKs trigger a spurious fast retransmit followed by additional
retransmissions caused by the New Reno algorithm. One old and one new
segment is transmitted per each partial ACK thus resulting in nine additional
unnecessary retransmissions. A 10-second pause after partial ACKs is
caused by congestion avoidance procedures. However, from this point the
connection proceeds normally without additional retransmissions.
Linux 2.4 (Figure 9) is similar to Linux 2.2, except that there is no
spurious fast retransmit and no spurious New Reno retransmissions. When
we have noticed the problem in Linux 2.2, it was reported to developers and
corrected in the kernel release 2.4 by implementing the careful version of the
restriction described in Section 6.
[2]. Examining TCP traces showed that Windows 98 always has been
triggering a fast retransmit already after the second DUPACK, while
Windows NT after the first DUPACK.
7. CONCLUSIONS
Long sudden delays in data transfers are not typical in wireline networks and
their effect on the TCP protocol has not been extensively studied. Such
delays are not uncommon in W-WANs due to link-level retransmissions,
handovers and temporal resource preemption by high-priority packet traffic
or voice calls. As an example, we give preliminary measurements of the cell
reselection delay in the GPRS network. We have shown that the New Reno
algorithm increases the amount of retransmissions after the spurious timeout
roughly by half and that an aggressive retransmission timer may expire
during the fast recovery generating a chain of spurious retransmissions. We
have tested four widespread TCP implementations in their reaction to a long
delay. All four implementations, FreeBSD 4.1, Windows 98, Linux 2.2 and
Linux 2.4 have exhibited go-back-N retransmissions while the following
behavior has been different. FreeBSD and Windows are recovering
especially poorly, partly due to implementation problems that we also have
listed. We have to highlight the importance of the Eifel algorithm as the only
known solution that prevents go-back-N retransmissions thus nearly
altogether eliminating the penalty of a spurious TCP timeout. We
recommend that all TCPs implement the careful version of New Reno, as it
prevents many of the discussed problems. Resetting the retransmission timer
upon a reception of DUPACK would avoid spurious timeouts during fast
recovery, but we have to study the effect of this modification in more detail.
Future work will include examination of delay sources in the GPRS and
UMTS wireless networks, as well as designing new algorithms to improve
the response of TCP to long sudden delays.
104 Andrei Gurtov
8. ACKNOWLEDGMENTS
REFERENCES
[1] BSS GPRS protocol (BSSGP). 3GPP TS 08.18 V8.4.0, October 2000.
[2] M. Allman, V. Paxson, and W. Stevens. TCP congestion control. IETF RFC 2581, April
1999.
[3] R. Braden. Requirements for internet hosts-- communication layers. IETF RFC 1122,
October 1989.
[4] G. Brasche and B. Walke. Concepts, services and protocols of the new GSM phase 2+
general packet radio service. IEEE Communications Magazine, pages 94-- 104, August
1997.
[5] K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno, and SACK TCP.
ACM Computer Communication Review, July 1996.
[6] S. Floyd and T. Henderson. The NewReno modification to TCP's fast recovery algorithm.
IETF RFC 2582, April 1999.
[7] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An extension to the selective
acknowledgment (SACK) option for TCP. IETF RFC 2883, July 2000.
[8] A. Gurtov. TCP performance in presence of congestion and corruption losses. Master's
thesis, Department of Computer Science, University of Helsinki, December 2000.
Available at: http://www. cs.Helsinki.FI/group/iwtcp/papers/.
[9] ISI at University of South California. Network simulator 2. Available at:
http://www.isi.edu/nsnam/ns/.
[10] V. Jacobson. Congestion avoidance and control. In Proceedings of ACM SIGCOMM '88,
pages 314--329, August 1988.
[11] V. Jacobson, C. Leres, and S. McCanne. tcpdump. Available at http://ee.lbl.gov/, June
1997.
[ 12] M. Kojo, A. Gurtov, J. Mannner, P. Sarolahti, T. Alanko, and K. Raatikainen. Seawind: a
wireless network emulator. Submitted to MMB 2001.
[I3] J. Korhonen, O. Aalto, A. Gurtov, and H. Laamanen. Measured performance of GSM
HSCSD and GPRS. In Proceedings of the IEEE International Conference on
Communications, 2001. To appear.
[ 14] R. Ludwig. Eliminating Inefficient Cross-Layer Interactions in Wireless Networking.
PhD thesis, Aachen University of Technology, April 2000.
[15] R. Ludwig and R. H. Katz. The Eifel algorithm: Making TCP robust against spurious
retransmissions. ACM Computer Communication Review, 30(1), January 2000. Available
at: http://www. acm. org/sigcomm/ccr/archive/2000/jan00/ccr-200001 -1udwig.html.
[ 16] R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, and A. Joseph. Multi-layer tracing of TCP
over a reliable wireless link. In Proceedings of the ACM SIGMETRICS International
Conference on Measurement and Modeling of Computing Systems (SIGMETRICS-99),
Effect of Delays on TCP Performance 105
volume 27,1 of SIGMETRICS Performance Evaluation Review, pages 144--1 54, New
York, May 1—4 1999. ACM Press.
[17] R. Ludwig and K. Sklower. The Eifel retransmission timer. ACM Computer
Communication Review, 30(3), July 2000.
[18] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP selective acknowledgement
options. IETF RFC 2018, October 1996. Standards Track.
[19] Microsoft. TCP/IP may retransmit packets prematurely. Available at:
http://support.microsoft.com/support/kb/articles/Q236/9/26.ASP.
[20] M. Mouly and M. Pautet. The GSM System for Mobile Communications. Europe Media
Duplication S.A., 1992.
[21] V. Paxson. Automated packet trace analysis of TCP implementations. In Proceedings of
the ACM SIGCOMM Conference: Applications, Technologies, Architectures, and
Protocols for Computer Communication (SIGCOMM-97), volume 27 of Computer
Communication Review, pages 167--180, Cannes, France, Sept. 14--18 1997. ACM Press.
[22] V. Paxson and M. Allman. Computing TCP's retransmission timer. IETF RFC 2988,
November 2000. Standards Track.
[23] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J.
Semke, and B. Volz. Known TCP implementation problems. IETF RFC 2988, Mar. 1999.
[24] J. Postel. Transmission control protocol. IETF RFC 793, 1981. Standard.
[25] M. Rahnema. Overview of the GSM system and protocol architecture. IEEE
Communications Magazine, 3 1 (4):92-- 100, April 1993.
[26] W. Stevens. TCP slow start, congestion avoidance, fast retransmit, and fast recovery
algorithms. IETF RFC 2001, Jan. 1997.
[27] R. H. Stine. FYI on a network management tool catalog: Tools for monitoring and
debugging TCP/IP internets and interconnected devices. IETF RFC 1147, Apr. 1990.
[28] A. S. Tanenbaum. Computer Networks. Prentice-Hall International, 1996.
[29] K. Thompson, G. J. Miller, and R. Wilder. Wide-area internet traffic patterns and
characteristics. IEEE Network, 1 1(6): 10--23, November/December 1997.