Mobile TCP :
The Problem with TCP
TCP is a connection-oriented transport layer protocol that provides reliable, in-order delivery of data to the TCP receiver. Since mobile hosts will expect the same services that are offered to fixed hosts, it is necessary to implement TCP for the mobile domain. If we use TCP without any modifcation in mobile networks, we experience a serious drop in the throughput of the connection. There are several reasons for such a drastic drop in TCP throughput and in this section we examine these reasons in some detail.
1. The Effect of a High Bit Error Rate (BER)
It has been suggested that the wireless link suffers from a high bit error rate. While this may be true in some cases, recent studies indicate that the bit error may be no worse which can be reduced by one or two orders
of magnitude by the use of appropriate FEC (Forward Error Correcting) codes and retransmission schemes at the link layer, However the wireless link is susceptible to inordinately high bit error rates.
Bit errors cause packets to get corrupted which result in lost TCP data segments or acknowledgements. When acknowledgements do not arrive at the TCP sender within a short amount of time, (the retransmit timeout or RTO which is a multiple of half a second), the sender retransmits the segment, exponentially backs off its retransmit timer for the next retransmission, and closes its congestion window to one segment. Repeated errors will ensure that the congestion window at the sender remains small resulting in low throughput. It is important to note that FEC may be used to combat high BER, but it will waste valuable wireless bandwidth when correction is not necessary.
2. The Effect of Disconnections
TCP is a connection-oriented transport layer protocol that provides reliable, in-order delivery of data to the TCP receiver. Since mobile hosts will expect the same services that are offered to fixed hosts, it is necessary to implement TCP for the mobile domain. If we use TCP without any modifcation in mobile networks, we experience a serious drop in the throughput of the connection. There are several reasons for such a drastic drop in TCP throughput and in this section we examine these reasons in some detail.
1. The Effect of a High Bit Error Rate (BER)
It has been suggested that the wireless link suffers from a high bit error rate. While this may be true in some cases, recent studies indicate that the bit error may be no worse which can be reduced by one or two orders
of magnitude by the use of appropriate FEC (Forward Error Correcting) codes and retransmission schemes at the link layer, However the wireless link is susceptible to inordinately high bit error rates.
Bit errors cause packets to get corrupted which result in lost TCP data segments or acknowledgements. When acknowledgements do not arrive at the TCP sender within a short amount of time, (the retransmit timeout or RTO which is a multiple of half a second), the sender retransmits the segment, exponentially backs off its retransmit timer for the next retransmission, and closes its congestion window to one segment. Repeated errors will ensure that the congestion window at the sender remains small resulting in low throughput. It is important to note that FEC may be used to combat high BER, but it will waste valuable wireless bandwidth when correction is not necessary.
2. The Effect of Disconnections
In a mobile environment, as a user moves between cells, there is a brief blackout period (or disconnection) while the mobile performs a handoff with the new MSS. Disconnections may also be caused by physical obstacles in the environment that block radio signals, such as buildings. If a cell contains many users, some connections (of newly arriving mobiles) may not receive any bandwidth for large time periods (call blocking) { this can also be considered a disconnection event }. Disconnection periods can be of the order of several seconds causing packet loss or delay in the transmission of acknowledgements of received packets. Since these disconnections tend to be fairly lengthy, forward error correction schemes are ineffective.
3. The Effect of Frequent Disconnections
It is likely that in order to provide high-bandwidth wireless connections, cell sizes will have to be reduced. Small cell sizes unfortunately result in small cell latencies that, in turn, cause frequent disconnections as a user roams. All the problems that result from disconnections, as we discussed above, occur more often here.
4. Other problems
Another problem caused by small cell latencies and frequent disconnections is that of serial timeouts at the
TCP sender. A serial timeout is a condition wherein multiple consecutive retransmissions of the same segment are transmitted to the mobile while it is disconnected. All these retransmissions are thus lost. Since the
retransmission timer at the sender is doubled with each unsuccessful retransmission attempt (until it reaches 64 sec), several consecutive failures can lead to inactivity lasting several minutes. Thus, even when the mobile is reconnected no data is successfully transmitted for as long as 1 minute! We have found that serial timeouts at the TCP sender can prove to be even more harmful to overall throughput than losses due to bit errors or small congestion windows.
Solutions
1. Snoop :
One proposed solution for losses caused by high BER is the Berkeley Snoop Module . The snoop module resides at an intermediate host near the mobile user (typically the base station). It inspects the TCP header of TCP data packets and acknowledgements which pass through and buffers copies of the data packets. Using the information from the headers, the snoop module detects lost packets (a packet is assumed to be lost when duplicate acknowledgements are received) and performs local retransmissions to the mobile. The module also implements its own retransmission timer, similar to the TCP retransmission timeout, and performs retransmissions when an acknowledgement is not received within this interval. An improved version of the snoop module adds selective retransmissions from the intermediate node to the mobile.
2. Indirect IP:
Another solution to the problem caused by high BER is the I-TCP protocol (Indirect-TCP). In the I-TCP
protocol a TCP connection between a fxed host and a Mobile Host (MH) is split in two at the Mobile Support Station (MSS) or base station. Data sent to the MH is received and ACK'ed by the MSS before being delivered to the MH. Note that on the connection between the MSS and MH it is not necessary to use TCP, rather some protocol optimized for the wireless link could be used. The MTCP protocol of is very similar to I-TCP. It also splits a TCP connection in two { one from the MH to MSS and another from the MSS to the FH (i.e., the Fixed Host or sender). The MH to MSS connection passes through MHP, a session layer protocol. Two implementations for MHP are proposed. In the frst, MHP uses TCP over the wireless link to the MSS. In the second implementation, a selective repeat protocol, SRP, is used over the wireless link. SRP lies below the socket layer but above TCP.
Both I-TCP and MTCP achieve better throughputs than standard TCP for the following reason:
===> the node where the connection is split is, hopefully, one or two hops away from the MH's cell and can adapt more quickly to the dynamic mobile environment because the round trip time (RTT) is very small. This means that even if the MSS sender (the node where the connection is split) reduces its congestion window to one because of lost acknowledgements from the mobile, the window will quickly build up to the maximum again when new ACKs arrive from the mobile because of the short RTT.
No comments:
Post a Comment