Chapter 3. Wireless Access of Internet Using TCP/IP A Survey of Issues and Recommendations 3.1 INTRODUCTION

Transcription

1 Chapter 3 Wireless Access of Internet Using TCP/IP A Survey of Issues and Recommendations Sridhar Komandur, Spencer Dawkins and Jogen Pathak Cynela Networks, Inc 3.1 INTRODUCTION The Internet has many different kinds of applications (e.g., audio, , chat). The applications interact with a few transport protocols like TCP, UDP and RTP. There is only one widely-deployed network protocol, the Internet Protocol (IP). The IP protocol facilitates routing and subnetwork specific details from the transport protocols. While this allows transport protocols to run over many different kinds of sub net (e.g., Ethernet, wireless network, FDDI), they are not optimized for any specific subnetwork. The basic functionality provided by IP is a best effort delivery of packets to their destination. Packets flowing between a source and a destination are not acknowledged by intermediate gateways and need not follow the same path through the network. Thus it is acceptable in the Internet for the packets to be delivered out-of-order, duplicated or even lost in transit. Applications requiring reliability and in-order delivery use TCP over IP. K. Makki et al. (ed.), Mobile and Wireless Internet Kluwer Academic Publishers 2003

2 66 Chapter 3 Surilng!he www R..roIving fi<mlnaml! $ 1 I J Figure 3J internet Protocol (IP) Interaction In the next section we delve into the details of TCP. In Section 3.3 we discuss wireless networks. Section 3.4 describes the issues related to wireless access of Internet using TCP and some recommendations to improve performance. We summarize current standards-track TCP recommendations and describe some current research topics in Section TRANSMISSION CONTROL PROTOCOL (TCP) TCP provides an in-order and reliable byte-stream across the network between two endpoint hosts. The underlying services are: Use all available bandwidth between the end points, Retransmit lost datagrams, Present out-of-order datagrams to applications in-order and Absorb duplicated datagrams. The main objective of TCP is to avoid sustained network congestion in the network through congestion avoidance and congestion control Window Based Flow Control TCP uses a windows based mechanism for flow control. As Figure 3.2 shows, a windows based flow control has better performance than a sender that sends a new packet only upon receiving acknowledgement of the previous packet.

3 3. Wireless Access of Internet Using TCPIIP 67 ;r ;r ;r ;r.. Doo't want to stq> and wait foc each ack SIq> "IIItlUinU 4 "IIItlUinU 12 Figure 3.2. Windows Based Flow Control The receiver notifies the sender ofthe available buffer space referred to as the receiver s advertised window. The sender determines the optimum amount of unacknowledged data that can be in-flight at a given time and is referred to as congestion window. The window size used by TCP at a given time is the minimum of advertised and congestion windows. Figure 3.3 shows the sliding window mechanisms: Window'" 5 segments (,. Not yet transmitted AOKs received Figure 3.3. Sliding Windows Mechsnism In the figure above, the client has acknowledged packets 1 through 5, while packets 6 through 10 are in-flight. TCP uses an ACK-clocking window control mechanism to maintain equilibrium. Initially it is in Slow Start mode, where the congestion window increases exponentially. After a certain threshold on the congestion window is reached, the sender's TCP stack enters a congestion avoidance phase as illustrated in the figures below.

4 68 Chapter 3 TCP Slow Start Probe for bandwidth aggressively -===:--- Round Trip ~ I 11 Round Wilhoul.low-._.rl I Tnp 2 ~ Round Trip 3 ~ WHh 810w-.,.rl Figure 3.4. TCP Slow Start During slow start phase sender congestion window increases by 1 MSS for every ACK received and by IIMSS during congestion avoidance phase. The slow start phase ends when the congestion window reaches slow start threshold (ssthresh). TCP Congestion Avoidance Probe for bandwidth gently RaundTrtp4 RaundT~p5 Figure 3.5. TCP Congestion Avoidance The ideal congestion window size (cwnd) is ~ = (RTf bandwidth). If sender's cwnd > ~, then it will increase RTf, causing potential packet loss and retransmission timeout (RTO) at the sender. The following figure illustrates the congestion window growth:

5 3. Wireless Access of Internet Using TCPIIP 69 Slow Start and Congestion Avoidance Congestion avoidance ~.--" --"J=/_-- Slow start / threshold./ Slow start n...(rwjki~) Detecting Packet Loss Figure Slow Start and Congestion Avoidance TCP detects packet loss using retransmission timeout (RTO) and duplicate acknowledgements (DupAcks). At a given time, the sender times the earliest unacknowledged packet. If the ACK is not received within this time, TCP assumes loss of packet due to network congestion. If the sender receives some (typically 3) duplicate ACKs requesting the same packet, TCP assumes loss of that packet and resends it again (Fast Retransmit & Fast Recovery). In the subsections below we discuss the consequences of RTO and Fast Retransmit Retransmission Timeout (RTO) The sender dynamically calculates RTO as (mean RTT + 4 * mean RTT deviation). Implications of this approach are: Fewer false "positives": Responds well to large variations in RTT Loss of data leads to increased recovery time and as the RTO is increased. RTO time is doubled for each subsequent timeout. So the losses need to be infrequent. Congestion window is reduced to initial congestion window (typically 1 or 2 MSS)

6 70 Chapter Fast Retransmit and Fast Recovery Fast Retransmit: Since RTOs take a long time to recover lost packet, duplicate ACKs are used to signal the need to retransmit the lost packet. Fast Recovery: DupAcks indicates that packets are actually reaching the client, even though a packet has been declared lost. So instead of drastically reducing the cwnd to one MSS, a more gentle approach is followed: ssthresh = min(cwnd, receiver's advertised window)/2 (at least 2 MSS) retransmit the missing segment (fast retransmit) cwnd = ssthresh + number of dupacks When a new ACK arrives, enter congestion avoidance Congestion window is cut in half but is still larger than RTO case with cwnd= I 3.3 WIRELESS NETWORKS We highlight characteristics of wireless networks that are not in tune with typical network congestion assumptions made while designing TCP for the Internet. Low bandwidtb: The available bandwidth is low, depending on the number of timeslots allocated over air interface channel for the TCP session. In the presence of contention for the air interface bandwidth, a session's bandwidth could be in the low hundreds of bits per second. Higb latency: The round trip times are high and at times highly variable due to deterioration in air interface bandwidth. The minimum round-trip delay close to one second is not exceptional. High Bit Error Rate (HER): This results in frame or packet losses, or long variable delays due to local link-layer error recovery. Internal Buffering: Some wireless network elements have a lot of internal buffer space and tend to accumulate data, thus resulting in increased and variable queuing delays, increasing retransmission due to timeouts.

7 3. Wireless Access of Internet Using TCPIIP 71 Variable Latency: The wireless network users (or simultaneous TCP sessions for same user) may share common channels for their data packet delivery which, in turn, may cause unexpected delays to the packet delivery of a user due to simultaneous use of the same channel resources by the other users. This could potentially lead to higher RTO and retransmissions. Access Disruptions: Unexpected link disconnections (or intennittent link outages) may occur frequently and the period of disconnection may last a very long time. Link Recovery: (Re)setting the link-connection up may take a long time (several tens of seconds or even minutes) Wireless Links are Expensive. The use of most wireless links is expensive. Many of the service providers apply time-based or volume (bytes)-based charging. Most of the above characteristics are applicable to both 2.5G (e.g., GPRS) and 3G (e.g., UMTS) networks. 3.4 TCP AND WIRELESS NETWORKS The characteristics of wireless network make it difficult for TCP to perform appropriately. The desired behavior is: Retransmit a packet lost due to errors immediately Take congestion control actions if and when there is congestion in the network Fast Retransmit is followed by Fast Recovery, which reduces the congestion window. However, this will result in unnecessarily reduced throughput if the packet loss was due to corruption over air interface, and not to congestion at all. On a COMA channel, errors may occur due to interference from other users or due to noise or fading. Interference due to other users is an indication of congestion. If such interference causes transmission errors, it is appropriate to reduce congestion window. However, ifnoise causes errors, it is not appropriate to reduce window.

8 72 Chapter 3 When a channel is in a degraded state for an extended period of time, it might be better to let TCP back off, so that it does not unnecessarily attempt retransmissions while the channel remains degraded. With its end-to-end feedback mechanisms, TCP is unable to distinguish between packet losses due to congestion and transmission errors. The cwnd is reduced when TCP encounters a transmission error loss and reacts as if the loss was due to network congestion. This mismatch of design results in poor throughput over wireless access networks. The following recommendations have been put forward by IETF's Performance Implications of Link Characteristics (Pll..C) working group to improve TCP performance over 2.5G and 3G wireless networks, and are under IETF review as of this writing: Appropriate Advertised Window Size (RFC 3150, Sec 2.5): The window size should reflect (bandwidth & delay) product. Window-scaling Option - 3G networks (RFC 1323): This allows for congestion window greater than 64K bytes. Large Initial Window (RFC 2581): Allows for an initial congestion window of at least 2MSS/4K bytes and an aggressive slow start behavior. A proposal to increase this value to 4MSS/4K bytes is currently under review in IETF, as of this writing. Note that an RTO timeout still sets cwnd = I MSS. Limited Transmit (RFC 3042): It has been observed in at least one reported case that over 50% of web retransmits occur after RTO, following this scenario: Lost packet sequence number near cwnd Sender doesn't send 3 more packets Receiver doesn't generate 3 dupacks This results in RTO, which slows throughput more than Fast Retransmit Slow Start, which slows throughput more than Fast Recovery "Limited Transmit" was proposed to allow recovery even when three additional packets do not follow a lost packet.

9 3. Wireless Access of Internet Using TCPIIP 73 When duplicate acknowledgements begin to arrive at the congestion window edge, the congestion window is extended and new packets are injected until either a new acknowledgement is received, indicating that the missing segment did arrive, or three duplicate acknowledgements are received, triggering Fast RetransmitlFast Recovery instead of RTO/Slow Start. MTU Larger than Default IP MTU (RFC 791 and RFC 1191): According to RFC 791, IP's minimum Message Transfer Unit is 576, which results in an MSS value of 536 bytes. A larger MTU is recommended especially for 3G networks because the higher bitrates allow larger MTUs without taking away from the application's interactive feel as long as serialization delays are less than 200ms. For example, 3G networks with bandwidth of 48KBps could use MSS = 48KB * 200ms = 960bytes. However, it is less beneficial for 2.5G networks MSS == 1.2KB * 200ms = 240bytes (considering a low bandwidth of 1.2KBps). Path MTU can be determined using probe based methods (RFC 1191). TCP SACK Option (RFC 2018 and RFC 2883): Allows the retransmissions to be more effective by identifying "holes" in the receive window of the receiver. Explicit Congestion Notification option (RFC 3168): This allows the sender to explicitly identify congestion - avoiding packet retransmission due to network congestion. Timestamp Option (RFC 1323): Allows better estimation of RTT and avoid spurious retransmissions. Spurious retransmissions can also be detected using Eiffel proposal. PILC's recommendations form the basis of the Wireless Application Protocol (W AP) Forum's "Wireless Profiled TCP" recommendation as well. W AP 1.0/ was intended to support limited number of applications/devices using a vertical model (modify every layer to be in tune with wireless access networks). However, this added significant complexity as there is no end-to-end transparency - TCP, SSL, HTTP, and HTML all need to be translated. W AP 2.0 has adopted Wireless Profiled TCP as its transport protocol.

10 3.5 CONCLUSION This chapter addressed the challenges and proposed solutions for wireless access of Internet using the Ubiquitous TCPIIP protocol. This area is in its infancy, with researchers focusing on the issue of seamless Internet access - the user/application is unaware of the particular access networks (WLAN/ cellular/ DSLI Ethernet). TCP's reliance on end-to-end mechanisms for loss recovery have served the Internet very well in avoiding sustained congestion losses, but this has come at the expense of TCP's ability to recover from transmission errors without significant reductions in bandwidth utilization. Limited Transmit is the current "state of the art" in standards-track recovery from transmission error losses. Additional research is underway to detect unnecessary Fast Recovery procedures, using TCP Timestamp options (Eifel) or duplicate selective acknowledgements (D-SACK) to detect that a segment that was retransmitted unnecessarily so that the sending TCP can reclaim an unnecessarily-reduced congestion window, and may be less sensitive to reordering in the future. "Forward RTO Recovery" is a proposal for detecting unnecessary retransmissions with sender-side modifications only, without requiring use of either TCP timestamps or selective acknowledgements. Additional interesting challenges for wireless Internet access include billing, routing, mobility and security. REFERENCES The following RFCs ("Requests For Conunents") are published by the Internet Society, and are available from the Internet Engineering Task Force. "RFC 791 Internet Protocol", J. Postel, September 1981 "RFC 793 Transmission Control Protocol", 1. Postel, September 1981 "RFC 1191 Path MTU discovery", J.e. Mogul, S.E. Deering, November 1990 "RFC 1323 TCP Extensions for High Performance", V. Jacobson, R. Braden, D. Borman, May 1992

11 3. Wireless Access of Internet Using Tep/IP 75 "RFC 2018 TCP Selective Acknowledgement Options", M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, October 1996 "RFC 2414 Increasing TCP's Initial Window", M. Allman, S. Floyd, C. Partridge, September 1998 "RFC 2581 TCP Congestion Control", M. Allman, V. Paxson, W. Stevens, April 1999 "RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP", S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, July 2000 "RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit", M. Allman, H. Balakrishnan, S. Floyd, January 2001 "RFC 3150 End-to-end Performance Implications of Slow Links", S. Dawkins, G. Montenegro, M. Kojo, V. Magret, July 2001 "RFC 3155 End-to-end Performance Implications of Links with Errors", S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya August 2001 "RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP", K. Ramakrishnan, S. Floyd, D. Black, September 2001 ''TCP/IP Illustrated Volume 1 ", W. Richard Stevens, Addison-Wesley, 1994 "Wireless Profiled TCP", W AP Forum, W AP-225-TCP a, March 2001 Eifel is described in "The Eifel Retransmission Timer", Reiner Ludwig, Keith Sklower, Computer Communication Review, July 2000, and "The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions", Reiner Ludwig and Randy Katz, Computer Communication Review, January Forward RTO Recovery is described in "F-RTO: A TCP RTO Recovery Algorithm for Avoiding Unnecessary Retransmissions", P. Sarolahti, M. Kojo, June 2002 (Work in Progress, available from Internet-Draft repositories)