Cross-Layer Explicit Link Status Notification to Improve TCP Performance in Wireless Networks
© Ji-Hoon Yun. 2009
Received: 17 January 2009
Accepted: 28 April 2009
Published: 7 June 2009
To alleviate the performance degradation of conventional TCP in wireless networks, many schemes have been proposed so far. One category of such schemes is the Explicit Loss Notification (ELN) scheme in which TCP senders are notified of wireless losses so as to avoid congestion control against those losses. Thus the key design factor of the ELN scheme is how to detect wireless losses accurately and rapidly. This paper proposes a new ELN scheme, in which wireless losses are detected by monitoring the operation of the wireless link layer. By exploiting such cross-layer design, the proposed scheme can detect wireless losses without additional transmission over the wireless link and thus achieves accurate detection with minimum delay. The proposed scheme additionally sends new information, that is, Explicit Retransmission Start Notification, in order to prevent spurious timeouts of the TCP senders. Furthermore, in order to handle packet reordering and avoid successive shrinking of a congestion window due to multiple packet drops, a new TCP modification is proposed. Through intensive simulations, it is demonstrated that the proposed scheme outperforms the other ELN schemes, and yields the throughput performance of more than 400% of TCP-Reno and 150% of Snoop in the considered environments.
In recent years, wireless networks become more common in real life and many services such as e-mail, web browsing, e-commerce, and so fourth are available in the current wireless networks. In the near future, wireless networks will provide more services that are provided in the wired Internet, and will gradually carry the traffic similar to that of the wired networks. In the current wired networks, the majority of traffic relies on the Transmission Control Protocol (TCP) , which implies that the majority of traffic in the future wireless networks may also use TCP for the same services.
TCP is the prevailing transport layer protocol that provides the connection-oriented service and reliable transmission by acknowledgment (ACK). It also has a delicate congestion control mechanism  to deal with network congestion in a distributed manner. However, it is reported that TCP suffers from severe performance degradation in wireless networks .
TCP was originally designed for the use in the wired networks comprising reliable wired links and stationary hosts. It assumes that packet losses and unusual delays result from congestion in the network. Thus a TCP sender reduces its congestion window size to alleviate the congestion when it identifies the loss of a packet either by the arrival of several duplicate ACKs or the absence of an ACK for the packet within a timeout interval. However, wireless links can also suffer from packet losses due to high Bit Error Rate (BER), collisions in random access channels and handoffs in mobile networks. We refer to such packet losses as wireless losses to differentiate them from congestion losses. Although a packet is lost in the wireless link, not by congestion, the TCP sender reduces its congestion window size because the packet loss assumes that it is due to congestion in the network. Such TCP behavior results in significant throughput degradation and high interactive delay.
Recently, many schemes have been proposed to improve the end-to-end throughput of TCP in wireless networks. In this paper, we refer to these sort of schemes to improve the TCP performance against wireless losses as wireless TCP as a whole. Wireless TCP can be classified into three basic categories : end-to-end schemes, split-connection schemes, and link-layer schemes. The end-to-end schemes mostly use three techniques, that is, selective acknowledgments , Explicit Loss Notification (ELN) [6–10], and Bandwidth Estimation (BWE) [11–15]. (We do not consider the split-connection schemes in this paper because they violate the end-to-end semantics of a transport layer protocol considerably and put much overhead on the base station.)
In ELN schemes, the TCP sender is notified of wireless losses to preserve its congestion window. Although an ELN scheme is used, the TCP sender may reduce its congestion window even due to a wireless loss if the corresponding loss notification arrives too lately or if the detection of the wireless loss fails. Thus, how accurately and rapidly wireless losses can be notified is the main concern of ELN schemes. There have been various proposals which attempt to achieve this goal. In Balakrishnan et al.'s scheme , the TCP sequence numbers are cached at a Base Station (BS), and if the packet whose sequence number is cached is lost, the ELN bit of the ACK packet is set active by BS. In TCP HACK , the TCP sender puts extra header checksum bits in the options field of the TCP header. If the TCP receiver receives a data segment of which the data portion is corrupted while the header is intact, the receiver considers it to be a wireless loss and sends an ACK with the reserved bit for ELN set. EWLN  and TCP-ELN  are based on the similar idea. LHP  tries to improve the detection probability by fragmentation. In LHP, each data frame is fragmented before being transmitted over the wireless link and the first fragment which contains the TCP/IP header is sent repeatedly prior to the rest of fragments until it is successfully transmitted or all allocated link time slots for the frame are exhausted. If the receiver does not receive the whole frame except the first fragment, the receiver regards it as a wireless loss and sends an ACK packet with the ELN bit set.
However, the previous ELN schemes have long detection delay and nonzero detection failure probability. Balakrishnan et al.'s scheme requires an exchange of additional data and ACK packets over the wireless link for the detection of a wireless loss, which adds additional transmission delay to the detection delay. The delay gets even longer in poor channel condition due to frequent retransmissions. The other schemes require that a certain part of a data packet should be transmitted successfully in order to detect its wireless loss. However, if the wireless channel condition is poor, there is the possibility that such a part is also corrupted. Also, handoff or collision may result in the loss of the whole packet. In such cases, the TCP receiver will not detect the wireless loss correctly. Even though the receiver detects the wireless loss correctly, the ELN ACK should be transmitted over the wireless link. This takes an additional delay until loss notification and increases the possibility of notification failure further.
Meanwhile, a TCP sender can invoke congestion control due to the acknowledgment timeout of a packet while BS is still attempting to transmit the packet in the wireless link. This is called spurious timeout and more likely to occur if BS has slow loss recovery mechanism (e.g., 80 100 milliseconds for loss awareness in UMTS Rel'99) . The above schemes cannot prevent spurious timeout because their notification process gets started after BS finishes the whole transmission procedure for a packet.
In this paper, a new ELN scheme, called (Link Layer originated Explicit Link Status Notification) LL-ELSN, is proposed. LL-ELSN does not require additional transmission over a wireless link for loss notification and thus enables accurate detection with minimum delay. This is achieved by exploiting cross-layer design. The key idea of LL-ELSN is to send ELN when a data frame is discarded at the wireless link layer due to excessive retry. Along with ELN, the proposed scheme sends a new information, that is, Explicit Retransmission Start Notification (ERSN), which notifies the TCP sender of the start of the retransmission process at the wireless link layer, in order to prevent spurious timeouts at the TCP sender. The author also proposes an SACK-based TCP modification, that is, ELN-capable SACK (ESACK), which can handle ELN messages and packet reordering due to the immediate retransmission of a lost packet indicated by ELN. ESACK is designed to avoid consecutive invocation of congestion control when multiple packets of a congestion window are dropped due to congestion. ESACK also mitigates bandwidth waste due to continuous ELN generation in a disconnection by appropriately filtering received ELNs according to their causes.
To investigate the performance improvement of the proposed scheme, we perform simulation using ns-2  and compare various wireless TCP schemes. Through simulation, it is shown that the combination of the proposed ELN scheme and ESACK achieves goodput performance of more than 400% compared to TCP-Reno and 150% to Snoop . Consequently, we demonstrate that the proposed scheme, when combined with the Link Layer Automatic Repeat Request (LL-ARQ) using a small retry limit, achieves consistently good performance against both uniform and bursty channel errors. Moreover, considering that many wireless TCP proposals compare their schemes only with TCP Reno or a few other schemes, our simulation results provide a comprehensive performance comparison of the various schemes on a single simulation platform.
We only consider last-hop wireless networks, that is, only the link between BS and user equipments is wireless, such as cellular networks and infrastructure Wireless Local Area Networks (WLANs).
The rest of this paper is organized as follows. Section 2 briefly describes recent wireless TCP schemes and analyzes their pros and cons. In Section 3, we describe the implementation details of LL-ELSN and compare it with other ELN schemes. Section 4 explains ESACK, and Section 5 presents the simulation results and their analysis. We conclude this paper in Section 6.
2. Related Work
In this section, we review the wireless TCP schemes that have been proposed recently. The wireless TCP schemes considered in this paper are ELN and BWE schemes as well as SACK , Snoop , and TCP-DCR . In the following, we briefly describe each of them and analyze their pros and cons.
2.1. Explicit Loss Notification Schemes
ELN schemes attempt to detect wireless losses and notify the TCP sender of their occurrences by marking the reserved bit of TCP ACK or sending a newly defined message. Accordingly, how to accurately detect wireless losses and how to rapidly notify them are important design factors in ELN schemes.
In TCP HACK , the TCP sender puts extra header checksum bits in the options field of the TCP header. If the TCP receiver receives a data segment of which the data portion is corrupted while the header is okay, the receiver considers it as a wireless loss and sends an ACK with the reserved bit for ELN set to one. HACK assumes that SACK is used basically and the sender, upon reception of the ACK with the ELN bit set, immediately retransmits the lost packet without triggering congestion control. However, in HACK, if the wireless channel condition is poor, there is the possibility that the header is also corrupted. Also, handoff or channel contention may result in the loss of the whole packet. In such cases, the TCP receiver cannot judge the wireless link error correctly. So, the TCP sender of HACK can reduce its congestion window even due to a wireless loss. Even though the receiver detects the wireless loss correctly, the ELN ACK should be transmitted over the wireless link. This takes an additional delay until loss notification and increases the possibility of notification failure further.
LHP  tries to improve the detection probability by fragmentation. In LHP, each data frame is fragmented before being transmitted over the wireless link and the first fragment that contains the TCP/IP header is sent repeatedly prior to the rest of the fragments until it is successfully transmitted or all allocated link time slots for the frame are exhausted. When the receiver does not receive the whole frame except the first fragment, the receiver regards it as a wireless loss and sends an ACK packet with the ELN bit set. By fragmentation, LHP can increase the transmission probability of the TCP/IP header portion, which after all improves the detection probability. LHP also utilizes selective acknowledgement and the packet list which manages congestion control by keeping the unacknowledged packets in the sending order. However, the first fragment has to be transmitted successfully, which increases detection delay. Moreover, the first fragment can still be lost. Also, ACK packets that notify the wireless loss should go through wireless medium and this increases the detection failure probability and the notification delay further. The packet list works poorly with detection failures because the sender retransmits packets redundantly and invokes congestion control if the notification fails. If SMART  is used for LHP, whenever an ACK is lost, congestion control is invoked because the SMART ACK only contains the information of the single packet which has been successfully received and has triggered the ACK. In addition, fragmentation increases header overhead considerably, especially in 802.11 .
2.2. Bandwidth Estimation Schemes
BWE schemes keep on estimating the available bandwidth to monitor the network state. If a packet loss occurs in a noncongestive state based on the estimated bandwidth, the TCP sender does not invoke congestion control or reduces a congestion window conservatively. However, as BWE schemes infer the network state from indirect information, they have high probability of misjudgement.
TCP Westwood  estimates the available bandwidth from a low-pass filtered ACK reception rate. Its slow start and congestion avoidance phases are the same as those of TCP Reno. If duplicate ACKs are received ( is typically 3), the sender sets the and as the estimated bandwidth. When a timeout occurs, the sender sets the as the estimated bandwidth and the as one. In this way, it can maintain a proper sending rate even with wireless losses. However, the low pass filter incurs additional processing overhead due to its complexity. The filter also has the parameters whose optimal configuration may be different network by network. If ACKs are lost, the sender reduces its estimated bandwidth. For a timeout, it reduces the to one. Therefore, with wireless links having poor channel condition, TCP Westwood will underestimate the available bandwidth and have degraded performance since TCP ACKs can be also lost.
TCP Veno  adopts the measurement technique of Vegas  to estimate the network state. Veno does not change much of Reno. In the congestion avoidance phase, if the estimated backlogged segments from the Vegas measurement is smaller than the threshold , it assumes that the available bandwidth is not fully utilized and increases by 1/ when each new ACK is received as in TCP Reno. If , it increases by 1/ when every other new ACK is received, so as to reach the maximum achievable bandwidth rather slowly. When duplicate ACKs are received, if , Veno assumes a wireless loss and reduces the and by a small amount. Otherwise it behaves as TCP Reno. Veno has only two network states: congestion ( ) or noncongestion ( ). In the congestion state, every packet loss is assumed to be a wireless loss. Therefore, Veno cannot appropriately handle wireless losses when the network is in congestion.
TCP-Santa Cruz  also uses the measurement technique of Vegas to estimate the number of backlogged segments in the network. It updates a three-state machine based on the changes of . Within the state machine, an increase of during two consecutive intervals leads to the transition to the congestion state. TCP-Santa Cruz classifies a packet loss as a congestion loss and invokes congestion control against it only in the congestion state. However, TCP Santa Cruz has the same problem as TCP Veno has.
TCP-Jersey  is similar to TCP Westwood. It estimates the available bandwidth also from the ACK reception rate, but it filters the rate with the simpler filter than TCP Westwood's, which also needs less parameters. Contrary to the other schemes, TCP-Jersey's congestion event totally depends on Explicit Congestion Notification (ECN) . If the sender receives a new ACK or duplicate ACKs with the congestion warning (CW) bit set in a congestion avoidance phase, it invokes the rate control, in which and are set to the estimated available bandwidth. Otherwise, it maintains its and , assuming that the network is underutilized. The weakness of TCP-Jersey is that it requires ECN-capable routers without probabilistic marking, which increases the network cost and processing overhead on the routers. Although it has less parameters than TCP Westwood, it still requires some parameters whose optimum values are hard to be decided because of their high dependence on network states. Also, it has no solution against timeouts due to wireless losses.
Jitter-based TCP (JTCP)  utilizes another metric, the jitter of data transmission time used in Real-time Transport Protocol (RTP) . From the jitter reported by the receiver, it estimates the fraction of queued TCP segments in the network. If the number of queued segments estimated is more than a threshold, it behaves just like TCP Reno, except that it enters the fast retransmit phase only when duplicate ACKs have been received over several Round-Trip Time (RTT). Otherwise it maintains and for duplicate ACKs or halves and for a timeout. To calculate the jitter, the TCP sender has to store the sending time of each segment and the receiver has to report the segment receiving time in each ACK to the sender.
TCP TIBET  provides unbiased bandwidth estimation by filtering the interdeparture time of packets and the estimated bandwidth based on the core stateless fair queueing (CSFQ) algorithm. TCP TIBET uses the minimum RTT, denoted as , to calculate the available bandwidth accurately without depending on the coarse clock granularity of TCP. So, TCP TIBET has an updating algorithm, in which is multiplied by a reducing factor less than one. However, since the updating algorithm is invoked whenever a congestion event occurs, goes eventually to zero in congested networks. This makes small, and hence the corresponding connection remain in the congestion avoidance phase.
TCP NewReno-FF  discriminates packet losses based on RTT variation. It uses the flip flop filter technique  to estimate RTT. The flip flop filter exploits two exponentially weighted moving average (EWMA) filters where one of them, called agile filter, gives more weight to recent RTT samples. The agile filter is used prior to the other one when the deviation of the measured RTT sample is within a certain limit. If more than RTT samples among the last samples exceed the limit, a packet loss is classified as a congestion loss assuming that RTT will vary much in congestion. Otherwise it is classified as a wireless loss. As the other BWE schemes, it also has several parameters for configuring the filters and loss discrimination criterion. Moreover, it cannot detect wireless losses under congestion since it has only two network states as TCP Veno.
2.3. Another End-to-End Schemes
There are the end-to-end schemes which do not use the three techniques. TCP-DCR  is one of them. TCP-DCR delays a response to congestion by one RTT after the first duplicate ACK is received so that it gives time for LL-ARQ of the wireless link to recover a possible wireless error. If a new ACK arrives before the timer of one RTT expires, it switches to the normal operation. Otherwise it assumes that the loss is due to congestion and triggers the fast retransmissions and recovery operations.
With TCP-Casablanca , the TCP sender marks packets with two different discard priorities and intermediate routers drop the packets of the lower priority first in congestion. Thus the probability distribution of congestion losses will be different for the two types of packets while that of wireless losses may be similar for both of them assuming the uniform distribution of wireless losses. The TCP sender exploits such a difference when determining the cause of a packet loss. However, TCP-Casablanca requires the change of every router in networks and this makes it hard to be deployed. It discriminates the cause of a packet loss in a stochastic manner, therefore has higher detection failure probability of wireless losses than ELN schemes. Furthermore, under heavy congestion or bursty-loss wireless channel condition, the probability distribution of packet losses may not follow the presumed one and thus the detection failure probability will increase.
3. Link Layer Originated Explicit Link Status Notification
In this section, we describe the detailed operation of the proposed ELN scheme, that is, LL-ELSN, and analyze its behavior in the aspects of detection delay, accuracy, and bandwidth overhead.
3.1. Notification Operation
LL-ELSN assumes that the link layer protocol of a wireless link adopts an acknowledged service. The assumption is practical as many link layer protocols for wireless communication such as IEEE 802.11 Medium Access Control (MAC)  and Radio Link Protocol (RLP)  for cellular networks provide acknowledged services with ARQ. In such link layer protocols, when the number of retransmission attempts of a frame exceeds a limit, the link layer discards the frame and begins to transmit the next one. The discard of the frame results in the wireless loss of the corresponding TCP packet. In LL-ELSN, those discard events are monitored by BS or a wireless station. Here, BS indicates the network element which is responsible for reliable transmission over a wireless link in downlink communication, for example, Radio Network Controller (RNC) in UMTS  and Access Point (AP) in IEEE 802.11 WLANs.
For uplink communication shown in Figure 1(b), the link layer directly informs the upper TCP stack which packet enters a retransmission process and which packet is dropped because the monitored link layer and the TCP stack are within the same station. The behavior of the TCP sender against ERSN and ELN is the same as that in downlink communication. If a TCP packet is fragmented into several frames at the wireless link layer, ERSN is generated only for the first retransmission of a fragment while ELN is generated for the discard of the whole fragments.
3.2. Comparison to Other ELN Schemes
Comparison of ELN schemes.
the time when a wireless loss for a TCP packet occurs is the instance for the TCP packet being discarded at the wireless link layer;
the ELN delay is the time duration that takes until the TCP sender receives a notification for a wireless loss from the loss occurrence.
where and are the required time for a single transmission attempt of data and ACK packet, respectively, and and are the transmission failure probability of the corresponding packet. is the one-way trip time between BS and the remote TCP node (either sender or receiver) in the wired network.
As shown in Table 1, the ELN delay of LL-ELSN is only for downlink communication. However, the other schemes have additional delay plus since the ACK packet corresponding to an ELN message has to be transmitted over a wireless link. Furthermore, Balakrishnan et al.'s scheme has another delay component for successful transmission of the next data packet. On the other hand, for uplink communication, LL-ELSN has negligible ELN delay because the TCP sender is notified of wireless losses by the link layer within the same station. The other schemes need additional in uplink communication because the wireless link and the TCP receiver are located separately.
Although the other schemes (except LL-ELSN) have less delay than Balakrishnan et al.'s scheme, they have the probability of a detection failure that the TCP sender does not have any notification for a wireless loss ( is the probability that the header of the received TCP packet is corrupted and is the probability that the first fragment fails to be transmitted.). That is because at least the TCP/IP header and the first fragment have to be transmitted successfully over the wireless link. In LL-ELSN, there is no additional transmission over the wireless link and thus it has no detection failure in uplink communication. LL-ELSN also has no detection failure in downlink communication if ELN messages do not suffer from congestion losses on the wired path from BS to a TCP sender.
Compared to the other ELN schemes, LL-ELSN has the least delay and detection failure probability for both downlink and uplink, and also does not need any memory overhead at BS, which may enable fast handoffs. One disadvantage of LL-ELSN is that it violates the layering semantics because the link layer refers to the TCP/IP header to send ERSN and ELN messages. However, cross-layer design [32, 33] is a currently popular trend to utilize the restricted bandwidth of wireless links as much as possible. Thus the violation of the layering semantics could be acceptable if the performance is the most important metric.
3.3. Bandwidth Overhead of ERSN and ELN
4. ELSN-Capable SACK
The operation of the TCP sender needs to be redesigned to handle the received ERSN and ELN messages. In this section we describe the proposed TCP modification which can be used with LL-ELSN as well as generic ELN schemes.
4.1. Congestion Control Algorithm
FirstUnsacked: the sequence number of the first segment which is not SACKed in the retransmission queue.
HighSACK: the highest sequence number which is SACKed.
The FirstUnsacked segment should be acknowledged cumulatively or selectively by a very next ACK unless it is reordered or dropped by congestion. If the segment is lost in a wireless link, it will be notified by an ELN and the entry of the segment will be moved to the tail of the retransmission queue after being retransmitted. Therefore, if FirstUnsacked is identified to be less than HighSACK after a duplicate ACK is processed, the TCP sender understands that the FirstUnsacked segment is reordered or dropped by congestion assuming that ELN is not dropped. Thus, by checking FirstUnsacked and HighSACK of the retransmission queue, the TCP sender can react to congestion while processing ELN. The procedure of ESACK when an ACK is received is specified in Algorithm 1.
Algorithm 1: Pseudocode of ESACK congestion control algorithm.
else if(duplicate ACK)
if(there is a SACK option)
update retransmission queue
if(HighACK == FirstUnsacked)
if(FirstUnsacked is changed)
dupacks = 1
else dupacks ++
else if(HighACK segment is SACKed)
Typical TCP operation for DupThresh duplicate ACKs
When an ELN is received, ESACK retransmits the lost segment indicated by the ELN immediately since the reception of an ELN indicates not only a packet was corrupted in a wireless link but also the packet has been dropped from the network. Thus the immediate retransmission ensures that the TCP connection remains ACK-clocked.
When a duplicate ACK is received, the sender checks FirstUnsacked and HighSACK to investigate whether it is due to congestion. If FirstUnsacked is equal to HighACK, it means that the FirstUnsacked segment was reordered or dropped due to congestion (we assume that an ACK acknowledges the sequence number or the first byte of the expected data). (HighACK is defined as the sequence number of the highest byte of data that has been cumulatively ACKed at a given point in .) Otherwise, if FirstUnsacked is less than HighSACK, it means that the FirstUnsacked segment was reordered or dropped due to congestion while waiting for a new ACK for the segment retransmitted by an ELN. If the segment of HighACK is already SACKed, it means that the segment was dropped in the receiver queue. Therefore, the segment needs to be transmitted again. If the counter of received duplicate ACKs becomes three, the sender triggers the congestion recovery algorithms of fast retransmit and recovery. In fast retransmit phase, the sender retransmits the FirstUnsacked segment. The other operations of ESACK are equal to SACK. Therefore, if there is no wireless loss, ESACK behaves just like SACK.
4.2. ELN Filtering
When a TCP receiver is disconnected from BS in downlink communication, the transmission attempts of the frames for the disconnected receiver fail consecutively. If the BS keeps on sending ELN messages for those frames to the corresponding TCP sender, the TCP connection will not be removed since the TCP sender keeps on retransmitting the lost segments. This wastes the bandwidth of the wired network unnecessarily. One solution to avoid this problem is to let the BS stop sending ELN messages for disconnection. The BS can assume disconnection when a certain number of successive segments for a connection are discarded. However, this approach is not scalable since the BS should store per-connection information. We solve this problem in the sender side.
ESACK can solve the bandwidth waste problem due to consecutive ELNs by differentiating the causes of the ELNs: channel noise or permanent disconnection. ESACK assumes that channel noise can maximally result in consecutive ELNs. To obtain the appropriate value of , let be the probability that a transmitted frame is corrupted by channel noise and be the retry limit. Then, the probability that a transmission leads to at least consecutive transmission failures is obtained by . We configure so that is reasonably high. For example, assume that is 20% and there is no retransmission ( ). Then, the probabilities of two and three consecutive failures are 4% and 0.8%, respectively, and we can configure as 2 since three consecutive failures due to channel noise is rather rare as 0.8%. For more conservative operation, we can increase . For those wireless losses due to channel noise, the TCP sender retransmits the discarded segments immediately without invoking congestion control. If ELNs are received for more than successive data packets, we consider this a disconnection. In this case, the TCP sender freezes all the TCP-related parameters and retransmits the discarded segments at every other ELN. By doing this, ESACK can reduce the bandwidth waste of unnecessary retransmission due to consecutive ELNs gradually in permanent disconnection. The reason of gradual slow down is for the case when a wireless station temporarily looks disconnected due to deep fading, handoff, and so fourth If the TCP sender receives a new ACK, the TCP sender restores the parameters and resumes data service.
5. Simulation Results
To investigate the quantitative performance of the proposed scheme, we perform comprehensive simulation using the ns-2 simulator .
5.1. Simulation Setup
5.2. Comparison of Wireless TCP Schemes
In this subsection, we compare the various aspects of wireless TCP schemes. We first set the retry limit of 802.11 MAC to one in order to investigate the robustness of the testing schemes against wireless losses while excluding the effect of LL-ARQ. In this case, FER of the wireless link is equal to the Packet Error Rate (PER). It is noted that wireless losses due to collisions are not counted in FER, so there are still wireless losses even with small FER.
5.3. Effect of TCP Sender Operation
5.4. Effect of Link Layer ARQ
To investigate the effect of a bursty loss channel originated from inherent channel characteristics or temporary link outage from weak signal power or handoffs, we use a Markov chain for the wireless channel model and simulate 10 concurrent TCP connections. The Markov chain can be also used to model Rayleigh fading channels. Tan and Beaulieu  proposed a first-order Markov model for Rayleigh fading channels and analytically proved its accuracy. Babich and Lombardi  proposed a first-order Markov model for three-level quantized Rayleigh fading channels. Zorzi et al.  showed that a two state Markov model well approximates Rayleigh fading channels. As such, modeling Rayleigh fading channels using a first-order Markov model has gained some acceptance in literature and seems to find a growing number of applications [28, 46]. The Markov chain considered in this paper consists of two states: good and bad. We assume that state transitions occur per frame transmission and all the frames are transmitted successfully except when collisions occur in the good state while all the frames are lost with probability one in the bad state. We set the transition probability from the good state to the bad state, denoted as , to 0.01 and vary the staying probability in the bad state, denoted as , from 0.1 to 0.5. As increases, the burstiness of channel loss gets higher.
In this paper, we proposed a new ELN scheme and a TCP modification. The proposed ELN scheme can detect wireless losses rapidly and accurately with minimum overhead since it does not need any additional data exchange over wireless links. We also showed that the proposed TCP modification can deal with multiple packet drops in a congestion window. The combination of these two schemes gives the significant performance improvement over existing protocols as we have demonstrated throughout the simulation results. We conclude that the combination of LL-ELSN and LL-ARQ with a small retry limit will perform well flexibly in various environments.
- Postel J: Transmission Control Protocol. IETF RFC 793, September 1981View ArticleGoogle Scholar
- Allman M, et al.: TCP Congestion Control. IETF RFC 2581, April 1999View ArticleGoogle Scholar
- Caceres R, Iftode L: Improving the performance of reliable transport protocols in mobile computing environments. IEEE Journal on Selected Areas in Communications 1995, 13(5):850-857. 10.1109/49.391749View ArticleGoogle Scholar
- Balakrishnan H, Padmanabhan VN, Seshan S, Katz RH: A comparison of mechanisms for improving TCP performance over wireless links. IEEE/ACM Transactions on Networking 1997, 5(6):756-769. 10.1109/90.650137View ArticleGoogle Scholar
- Mathis M, et al.: TCP Selective Acknowledgment Options. IETF RFC 2018, October 1996View ArticleGoogle Scholar
- Balakrishnan H, Katz RH: Explicit loss notification and wireless web performance. Proceedings of IEEE Global Telecommunications Conference (GLOBECOM '98), November 1998, Sydney, AustraliaGoogle Scholar
- Balan RK, Lee BP, Kumar KRR, Jacob L, Seah WKG, Ananda AL: TCP HACK: TCP header checksum option to improve performance over lossy links. Proceedings of the 20th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '01), April 2001, Anchorage, Alaska, USA 1: 309-318.Google Scholar
- Zhang B, Shirazi MN: Implementation of explicit wireless loss notification using MAC-layer information. Proceedings of the IEEE Wireless Communications and Networking (WCNC '03), March 2003, New Orleans, La, USA 2: 1339 -1343.Google Scholar
- Buchholcz G, Ziegler T, Van Do T: TCP-ELN: on the protocol aspects and performance of explicit loss notification for TCP over wireless networks. Proceedings of the 1st International Conference on Wireless Internet (WICON '05), July 2005, Budapest 172-179.View ArticleGoogle Scholar
- Gao X, Diggavi SN, Muthukrishnan S: LHP: an end-to-end reliable transport protocol over wireless data networks. Proceedings of the IEEE International Conference on Communications (ICC '03), May 2003, Anchorage, Alaska, USA 1: 66-70.Google Scholar
- Mascolo S, Casetti C, Gerla M, Sanadidi MY, Wang R: TCP Westwood: bandwidth estimation for enhanced transport over wireless links. Proceedings of the 7th Annual International Conference on Mobile Computing and Networking (MOBICOM '01), July 2001, Rome, Italy 287-297.View ArticleGoogle Scholar
- Fu CP, Liew SC: TCP veno: TCP enhancement for transmission over wireless access networks. IEEE Journal on Selected Areas in Communications 2003, 21(2):216-228. 10.1109/JSAC.2002.807336View ArticleGoogle Scholar
- Xu K, Tian Y, Ansari N: TCP-Jersey for wireless IP communications. IEEE Journal on Selected Areas in Communications 2004, 22(4):747-756. 10.1109/JSAC.2004.825989View ArticleGoogle Scholar
- Wu EH-K, Chen M-Z: JTCP: jitter-based TCP for heterogeneous wireless networks. IEEE Journal on Selected Areas in Communications 2004, 22(4):757-766. 10.1109/JSAC.2004.825999View ArticleGoogle Scholar
- Capone A, Fratta L, Martignon F: Bandwidth estimation schemes for TCP over wireless networks. IEEE Transactions on Mobile Computing 2004, 3(2):129-143. 10.1109/TMC.2004.5View ArticleGoogle Scholar
- Nortel Networks : HSDPA and Beyond. white paper, 2005Google Scholar
- The Network Simulator-ns-2, http://www.isi.edu/nsnam/ns
- Balakrishnan H, Seshan S, Katz RH: Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks 1995, 1(4):469-481. 10.1007/BF01985757View ArticleGoogle Scholar
- Bhandarkar S, Narasimha Reddy AL, Allman M, Blanton E: Improving the robustness of TCP to Non-Congestion Events. IETF RFC 4653, August 2006Google Scholar
- Keshav S, Morgan SP: SMART retransmission: performance with overload and random losses. Proceedings of the 16th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '97), April 1997, Kobe, Japan 3: 1131-1138.Google Scholar
- Qiao D, Choi S: Goodput enhancement of IEEE 802.11a wireless LAN via link adaptation. Proceedings of the IEEE International Conference on Communications (ICC '01), June 2001, Helsinki, Finland 7: 1995-2000.Google Scholar
- Brakmo LS, Peterson LL: TCP Vegas: end to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications 1995, 13(8):1465-1480. 10.1109/49.464716View ArticleGoogle Scholar
- Parsa C, Garcia-Luna-Aceves JJ: Differentiating congestion vs. random loss: a method for improving TCP performance over wireless links. Proceedings of the IEEE Wireless Communications and Networking (WCNC '00), September 2000, Chicago, Ill, USA 90-93.Google Scholar
- Ramakrishnan K, et al.: The Addition of Explicit Congestion Notification (ECN) to IP. IETF RFC 3168, September 2001View ArticleGoogle Scholar
- Schulzrinne H, et al.: RTP: A Transport Protocol for Real-Time Applications. IETF RFC 3550, July 2003Google Scholar
- Barman D, Matta I: Effectiveness of loss labeling in improving TCP performance in wired/wireless networks. Proceedings of the 10th IEEE International Conference Network Protocols (ICNP '02), November 2002, Paris, France 2-11.Google Scholar
- Kim M, Noble B: Mobile network estimation. Proceedings of the 7th Annual International Conference on Mobile Computing and Networking (MOBICOM '01), July 2001, Rome, Italy 298-309.View ArticleGoogle Scholar
- Biaz S, Vaidya NH: "De-randomizing" congestion losses to improve TCP performance over wired-wireless networks. IEEE/ACM Transactions on Networking 2005, 13(3):596-608.View ArticleGoogle Scholar
- IEEE Std. 802.11-1999 Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Reference number ISO/IEC 8802-11:1999(E), 1999Google Scholar
- 3rd Generation Partnership Project Technical Specification Group Radio Core Network; Radio Link Protocol (RLP) for circuit switched bearer and teleservices. Release 6. 3GPP TS 24.022 (V.6.0.0), December 2004Google Scholar
- 3rd Generation Partnership Project Technical Specification Group Radio Access Network; HSDPA Overall Description. Release 7. 3GPP TS 25.308 (V.7.0.0), March 2006Google Scholar
- Lin X, Shroff NB, Srikant R: A tutorial on cross-layer optimization in wireless networks. IEEE Journal on Selected Areas in Communications 2006, 24(8):1452-1463.View ArticleGoogle Scholar
- Jiang H, et al.: Cross-layer design for resource allocation in 3G wireless networks and beyond. IEEE Communications Magazine 2005, 43(12):120-126.View ArticleGoogle Scholar
- Blanton E, et al.: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. IETF RFC 3517, April 2003View ArticleGoogle Scholar
- Floyd S, et al.: The NewReno Modification to TCP's Fast Recovery Algorithm. IETF RFC 2582, April 1999Google Scholar
- TCP Westwood modules for ns-2, http://www.cs.ucla.edu/NRL/hpi/tcpw
- TCP-DCR modules for ns-2, http://students.cs.tamu.edu/sumitha
- IEEE Std. 802.11b Supplement to Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Higherspeed Physical Layer Extension in the 2.4 GHz Band, IEEE Std. 802.11b-1999, 1999Google Scholar
- Padhye J, Firoiu V, Towsley D, Kurose J: Modeling TCP throughput: a simple model and its empirical validation. Proceedings of the ACM SIGCOMM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (ACM SIGCOMM '89), October 1998, Vancouver, Canada 303-314.Google Scholar
- Jain R, et al.: A quantitative measure of fairness and discrimination for resource allocation in shared computer systems. In DEC Research Report. Digital Equipment Corporation, Littleton, Mass, USA; 1984.Google Scholar
- Pahdye J, Floyd S: On inferring TCP behavior. Proceedings of the ACM SIGCOMM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (ACM SIGCOMM '01), August 2001, San Diego, Calif, USA 287-298.Google Scholar
- Barman D, Matta I, Altman E, El Azouzi R: TCP optimization through FEC, ARQ, and transmission power tradeoffs. In Proceedings of the Wired/Wireless Internet Communications (WWIC '04), 2004, Lecture Notes in Computer Science. Volume 2957. Springer; 87-98.View ArticleGoogle Scholar
- Tan CC, Beaulieu NC: On first-order Markov modeling for the rayleigh fading channel. IEEE Transactions on Communications 2000, 48(12):2032-2040. 10.1109/26.891214View ArticleGoogle Scholar
- Fulvio B, Lombardi G: On verifying a first-order Markovian model for the multi-threshold success/failure process for Rayleigh channel. Proceedings of the 8th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC '97), September 1997, Helsinki, Finland 1: 12-16.View ArticleGoogle Scholar
- Zorzi M, Rao RR, Milstein LB: On the accuracy of a first-order Markov model for data transmission on fading channels. Proceedings of the 4th IEEE International Conference on Universal Personal Communications Record, November 1995, Tokyo, Japan 211-215.View ArticleGoogle Scholar
- Pham PP: Comprehensive analysis of the IEEE 802.11. Mobile Networks and Applications 2005, 10(5):691-703. 10.1007/s11036-005-3363-xView ArticleGoogle Scholar
- Portoles M, et al.: IEEE 802.11 downlink traffic shaping scheme for multi-user service enhancement. Proceedings of the 14th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC '03), September 2003, Beijing, China 2: 1712-1716.Google Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.