TRANMISSION CONTROL PROTOCOL (TCP)
The protocol aims at providing a reliable service with the following features:
1. Fairness to other flows that potentially share a channel’s bandwidth
2. Dynamic discovery of current availability of bandwidth
1. Mechanisms for congestion avoidance and control and for optimization of
the error recovery process.
Error control mechanisms are the central component of reliable protocols. They affect a protocol’s performance with respect to goodput, energy expenditure, and overhead. Error control is usually a two-step process: error detection, followed by error recovery [1]. TCP assumes a relatively reliable underlying network where most packet losses are due to congestion [2]. TCP error control is centered on congestion losses and ignores the possibility of transient random errors or temporary blackouts due to handoffs and extended burst errors that are typical in wireless networks. TCP detects errors by monitoring the sequence of data segments acknowledged (received). When timeouts are correctly configured, a missing segment is taken to indicate an error, namely that the segment is lost due to congestion (i.e. buffer overflow). Reliable protocols usually implement an error recovery strategy based on two techniques: retransmission of lost segments; and downward adjustment of the sender’s window size and readjustment of the timeout period. When using TCP over wireless links results in congestion control measure being invoked at the source.
The Additive Increase Multiplicative Decrease (AIMD) algorithm is used to implement TCP window adjustments; based on the analysis the algorithm achieves stability and converges to fairness in situations where the demand (of competing flows) exceeds the channel’s bandwidth [1].
In a wireless network, however packet looses will occur more often due to unreliable wireless links than due to congestion. It is shown that the performance of TCP is sensitive to the packet size, and that significant performance improvements are obtained if a ‘good’ packet size is used. Packets on the internet may get lost either due to congestion, or due to corruption by the underlying physical medium. Given the low error rates of wired links, almost all losses are related to congestion. TCP’s reaction to looses is based on this very observation. Losses are detected either by timeouts at the source or by multiple duplicate acknowledgements ( dupacks ) from the receiver. TCP assumes that each packet loss is solely due to congestion. However, in a wireless network, TCP will encounter packet looses that may be unrelated to congestion. Nonetheless, these losses trigger congestion control measures at the source and severely degrade performance.
TCP was designed and carefully calibrated to overcome the problems like as
follows:
1. Stability.
2. Heterogeneous ( receiver buffers, network bandwidth and delay ).
3. Fairness in bandwidth consumption of competing flows.
4. Efficiency in utilization.
5. Congestion control ( that effectively avoids situations of congestive collapse ).
Transmission Control Protocol (TCP) is a means for building a reliable communications stream on top of the unreliable packet Internet Protocol (IP). TCP is the protocol that supports nearly all Internet applications. The combination of TCP and IP is referred to as TCP/IP and many people imagine, incorrectly, that TCP/IP is a single protocol.
2.1 Performance Metrics of TCP :
2.1.1 Goodput :
This is the measure of how efficiently a connection utilizes the network. It is determined as the ratio of useful data received at the destination and the total amount of data transmitted by the source. If a connection requires a lot of extra packets to traverse the network due to retransmission, its goodput is low. It is desirable that each connection have as high a goodput as possible. Clearly, this metric is of great significance for efficient operation of a network.
2.1.2 Throughput :
This is the measure of how soon an end user is able to receive data. It is determined as the ratio of the total data received by the end user and the connection time. A higher throughput will directly impact the user’s perception of the quality of service.
STANDARD TCP MECHANISM
The error control mechanism of TCP is primarily oriented toward congestion control. Congestion control can be beneficial to the flow that experiences congestion, since avoiding unnecessary retransmission can lead to better goodput. The basic idea is for each source to determine how much bandwidth is available in the network, so that it knows how many segments it can safely have in transit. TCP utilizes acknowledgments to pace the transmission of segments and interprets timeout events as indicating congestion. In response to congestion, the TCP sender reduces the transmission rate by shrinking its window. Tahoe and
3.1 TCP Tahoe
TCP Tahoe congestion control algorithm includes Slow Start, Congestion Avoidance, and Fast Retransmit. It also implements an RTT-based estimation of the retransmission timeout. In the Fast Retransmit mechanism, a number of successive (the threshold is usually set at three), duplicate acknowledgments (dacks) carrying the same sequence number triggers a retransmission without waiting for the associated timeout event to occur. The window adjustment strategy for this “early timeout” is the same as for the regular timeout: Slow Start is applied. The problem, however, is that Slow Start is not always efficient, especially if the error was purely transient or random in nature, and not persistent. In such a case the shrinkage of the congestion window is, in fact, unnecessary, and renders the protocol unable to fully utilize the available bandwidth of the communication channel during the subsequent phase of window re-expansion.
3.2 TCP
TCP Reno introduces Fast Recovery in conjunction with Fast Retransmit. The idea behind Fast Recovery is that a dack is an indication of available channel bandwidth since a segment has been successfully delivered. This, in turn, implies that the congestion window (cwnd) should actually be incremented upon a dack delivery. In particular, receiving the threshold number of dacks triggers Fast Recovery: the sender retransmits one segment, and sets the congestion threshold to half the current cwnd. Then, instead of entering Slow Start as in Tahoe, the sender increases its current cwnd by the dack threshold number. Thereafter, and for as long as the sender remains in Fast Recovery, cwnd is increased by one for each additional dack received. This procedure is called “inflating” the window. The Fast Recovery stage is completed when an acknowledgment (ack) for new data is received. The sender then sets cwnd to the current congestion threshold value (“deflating” the window), and resets the dack counter. In Fast Recovery, cwnd is thus effectively set to half its previous value in the presence of dacks, and grows with Additive Increase rather than Slow Start. TCP Reno’s Fast Recovery can be effective when there is only one segment drop from a window of data, given the fact that
3.3 TCP Vegas
TCP Vegas approaches the problem of congestion from another perspective. Based on sample RTT measurements, and the size of the sending window, the sender calculates the throughput rate every RTT. This rate is compared to an expected rate, which is calculated based on what is up-to-now known as best RTT (called base RTT). Two thresholds _ and _trigger an additive increase or decrease, depending of whether the channel is under- or over-utilized, respectively. Although not obvious, the protocol is compliant to the rules of fairness: it applies multiplicative adjustments when congestion is detected. Indeed, it applies Slow Start in the event of a time-out. Vegas’s approach is interesting: it attempts to estimate the level of congestion before it happens, and consequently avoid it, thereby avoiding unnecessary packet drops. One of the problems that it does not seem to overcome is the path asymmetry. The sender makes decisions based on the RTT measurements, which, however, might not accurately indicate the congestion level of the forward path. Furthermore, packet drops caused by transmission deficiencies or fading channels may trigger a Slow Start. However, this problem is common to all the above versions and is detailed below.
RESEARCH ISSUES
In the presence of infrequent and transient errors, TCP’s back-off strategy avoids only minor retransmission at the cost of significantly degraded goodput, which increases overall connection time. Yet, when an error occurs and TCP does back off, it continues to forcefully attempt transmissions within the confines of the reduced window size. In the presence of errors of a relatively persistent nature (fading channel, prolonged and frequent burst errors, congestion), this behavior does not favor energy saving, since it might yield only minor goodput improvement at high cost in transmission energy. In summary, from the perspective of energy expenditure in the context of heterogeneous wired/wireless networks, TCP seems to possess an inherent tendency to back off too much when it should not, and too little when it should.
The central problem lies in the inability of TCP’s mechanism to correctly detect the nature of the error, and so it is incapable of responding in an appropriate manner. In addition, the protocol lacks the ability to efficiently monitor network conditions, rapidly readjust its window size in response to changes in these conditions, and detect congestion without inducing packet drops, thereby degrading overall performance through additional retransmission and wasted opportunities in maintaining the communication pipe full.
Since TCP is not optimized for a specific network type or application requirement, its mechanisms permit for several application and network-specific improvements. Recently, TCP behavior over wireless and satellite networks has become a focus of attention. Recent research results have shown that TCP throughput (i.e. sending rate) degrades, in the presence of the kind of random/burst errors and long propagation delays typical of wireless and satellite environments, respectively. As a result, some researchers have tended to focus on the development of architectures (e.g., wireless proxies) that assist the protocol’s operation over specific networks in order to introduce minor changes to the protocol itself. Therefore, a large number of suggested proposals aiming at improving TCP performance and avoid or control network congestion deal with the functionality of network devices that can assist the protocol operations.
TCP performance can be enhanced by means of avoiding losses of data windows due to limited buffer space at the bottleneck router, and congestive collapse can be avoided. Clearly, it could be beneficial for the sender to know with precision that congestion is about to happen. However, in the context of wireless networks ECN contribution might be limited: by not receiving an explicit notification the TCP sender will not be able to safely assume that a detected drop was not caused due to congestion. The desired precision of ECN-capable TCP senders would be better approached if the level of congestion could also be indicated in order to allow TCP to implement more sophisticated recovery. Precision however comes at a cost: the functionality of the routers is more complex, modifications are required to both routers and TCP itself, and finally, the return might be small due to heterogeneity, i.e. some routers are not ECN-capable.
There are three salient points to make: First, TCP performs error control that is specifically tailored toward congestion induced errors; hence it does not have the entire error control functionality required for heterogeneous networks in place. Second, the proposed optimizations frequently exhibit a conflicting behavior with TCP’s mechanisms; that is, a retransmission attempt at a lower level might result in extending the RTT estimates of TCP and hence its timeout. This extended timeout might adversely affect the ability of TCP to effectively detect error-free conditions. Furthermore, we cannot assume that all network devices or link layer related modules would have the required functionality to support a defective TCP. Third, low-level modifications might constrain future TCP evolution. That is, the transport layer seems to be the natural place for implementing the core functionality for error control. This does not exclude potential optimizations based on the more precise or accurate information that could be gathered from lower layers. For example, having a TCP-aware gateway at the border of the wired and wireless networks enables a more precise determination (i.e., localization) of the source of the error. By and large, it appears that there is no much supportive theory behind the above design issue; cost, applicability and impact appear to be the major criteria for evaluating different approaches.
ERROR DETECTION
In fact, determining that the error has occurred in the wireless portion does not really provide sufficient information for the sender’s recovery tactic. For example, further adjustments in response to a transient error could be practically unnecessary; suspending data transmission during burst errors could result in energy savings; and a conservative strategy during highly erroneous transmission could possibly conserve significant amounts of energy for a minor degradation in goodput. Therefore, the “nature” of the error even within the wireless network seems to call for distinctive recovery tactics by the TCP sender. For example: to adjust the timeout and apply graduated adjustments after retransmission (e.g., during congestion); to suspend data transmission for periods of “blackout” and retransmit aggressively when conditions clear (e.g., during hand-offs); to reduce transmission effort for some period of time (e.g., during fading channels); to do nothing (e.g., after a transient random loss). In summary, error detection needs to go beyond localization and practically detect (classify) the “nature” of the error in order to provide feedback to the error recovery strategy. Notably, most of recent proposals do not tackle the problem of fine-grained error classification.
In order to enhance TCP goodput and energy efficiency, Tsaoussidis and Badr proposed TCP-Probing, grafting a probing mechanism into standard TCP. In this scheme, a “Probe Cycle” consists of a structured exchange of “probe” segments between the sender and receiver that monitor network conditions. The sender enters a probe cycle when a segment is detected lost either by a time-out event, or by three dacks. When a data segment is detected lost, the sender, instead of retransmitting and adjusting the congestion window and threshold, initiates a probe cycle during which data transmission is suspended and only probe segments (header without payload) are sent. A lost probe or acknowledgment re-initiates the cycle, hence suspending data transmission for the duration of the error. When the probe cycle is completed, the sender compares the measured probe RTTs and determines the level of congestion. Had congestion been the possible cause of the drop, the sender would have applied backward adjustments as in Tahoe or
Hence, a ”probing device” models two properties:
1. It inspects the network load whenever an error is detected and rules on the cause of that error and,
2. It suspends data transmission for as long as the error persists, thereby forcing the sender to adapt its data transmission rate to the actual conditions of the channel.
A base station at the border of a wired and wireless network can also detect the nature of the error, and inform the sender or take actions appropriate to the error type. In WTCP , the base station buffers data segments received from the sender. WTCP in the base station can then locally recover segments lost on the wireless link. WTCP independently performs flow control for the wireless connection (between the base station and mobile host). WTCP transmits from its buffer all the segments that fall within the wireless link transmission window.
Each time a segment is sent to the mobile host (including a retransmission), the timestamp of the segment is incremented by the amount of time that segment spent in the WTCP buffer (residence time). The reason for doing this is discussed shortly. The base station acknowledges a segment to the fixed host only after the mobile host actually receives and acknowledges that segment. Hence, TCP end-to-end semantics is maintained throughout the lifetime of the connection. Also, the round trip time seen by the source is the actual round trip time taken by a segment to reach and return from the mobile host, i.e. it does not include residence time at the base station needed for local recovery. Thus WTCP attempts to exclude the effect of the wireless link on the round trip time estimate and hence timeout maintained by the sender. Not doing so may unnecessarily increase the timeout value, which in turn may hinder the ability of the TCP sender to quickly detect congestion over the wired portion of the network.
6.1 The TCP sending Window and Timeout Adjustments
TCP itself needs improvements that deal with various types of error, not only lost segments due to buffer overflow. Because TCP assumes only congestion-induced losses, Fast Recovery and Fast Retransmit are not fast enough when the detected losses are not because of network congestion. For example, the sender needs to respond to the error detected using the congestion window and the timeout mechanism appropriately. The regular course of action of most approaches is to shrink the congestion window and extend the timeout period due to congestion, or freeze the window and timeout upon drops due to non-congestion errors. Freeze-TCP avoids timeouts at the sender during handoffs since a timeout shrinks the sending window to a minimum in all TCP versions. To this end, Freeze-TCP exploits the ability of the receiver to advertise a window of zero. Based on the signal’s strength the receiver detects the handoff and advertises a Zero Window Adjustment (ZWA). The sender then freezes its transmission and its timeout value. Once the handoff is completed, the receiver advertises a non-zero window so that the sender resumes with its window and timeout values unaffected due to the handoff.
Immediate Recovery is in marked distinction to
6.1.1 Decoupling the Sending Window from RTT
TCP window increases/decreases, in response to the receipt of acknowledgments and their delay or loss due to insufficient bandwidth availability at the reverse path, cause a conservative behavior at the forward path. Similarly, timeout extensions due to lost acknowledgments might degrade further the protocol’s ability to rapidly detect error-free conditions and consequently degrade its capability to detect the windows of opportunity to exploit the available bandwidth. In TCP Santa Cruz, propose an interesting modification, which replaces the round trip delay measurements of TCP with estimations of delay along the forward path, and use an operating point for the number of packets in the bottleneck. In TCP-Real, propose modifications to (i) enhance the real-time capabilities of the protocol over wired/wireless networks and (ii) tackle the problem of asymmetry by decoupling the size of congestion window from the timeout. TCP-Real implements the wave mechanism presented in [41]. Congestion control is now receiver-oriented, and the congestion window is included in the TCP header in order for the receiver to communicate with the sender. As noted earlier, the receiver observes the network dynamics based on the ratio of the wave size to the wave delivery time.
Since the receiver is aware of the size of the current wave sent, it can further estimate the level of loss and the changes in current conditions by measuring the number of successfully delivered segments within a wave and the wave delivery time, respectively. Based on the observation of the forward-path dynamics, the receiver directs the sender’s congestion control. The congestion window (at the sender) is not adjusted backwards when problems are identified in the reverse direction; the RTT however is taken into account for the calculation of the timeout in order to avoid duplicate packets that unnecessarily increase the overhead. More precisely, in TCP-Real the timeout can be extended but the window size could remain the same or even increase. The reasoning behind this strategic modification is that the sender needs to extend the timeout based on the RTT measurements, in order to accommodate potential delays on the reverse path and avoid an early timeout. However, only the perceived congestion of the forward path will determine the sender’s congestion window size. Congestion control in TCP-Real has therefore two additional properties: (i) it can avoid unnecessary congestion window adjustments due to path asymmetry, and (ii) it can determine the level of loss and jitter with better precision since the size of the sending window is known to the receiver (i.e., the wave pattern).
6.2 Acknowledgment Strategy
It is important to note that the acknowledgment strategy contributes to error detection. It is presented here mainly because it does not contribute much to error classification and, in addition, because it directs the behavior of the congestion window. That is, TCP is an ack-clocked protocol and the acknowledgment strategy determines, in effect, the transmission rate. The standard protocol’s strategy is to acknowledge each packet received. It has been shown that, occasionally, it can be beneficial for the sender to communicate with a receiver that delays the generation of acknowledgments. The mechanism is widely known as “Delayed Acks”. Delaying Acks reduces the processing overhead and also the communication overhead. Many TCP implementations acknowledge only every Kth segment out of a group of segments that arrive within a short time interval. The TCP sender must measure the effective RTT, including the additional time due to delayed ACKs, or else it will retransmit prematurely.
The delayed acknowledgments approach could be potentially a useful mechanism for controlling the sender’s transmission rate at the receiver. Similarly, the pace of the TCP sender can also be adjusted by a network device in accordance with the current conditions detected. For example, the fast-retransmission approach reduces the effect of mobile host hand-off. During a mobile host hand-off from one base station to another, TCP segments can be lost or delayed, and the source can timeout. Because of the typical coarse granularity of the TCP clock, the timeout period is much higher than hand-off time, and the mobile host has to unnecessarily wait for a long duration to receive a retransmission of a lost TCP segment from the source. In the fast retransmit approach, immediately after completing the hand-off, the IP in the mobile host triggers TCP to generate a certain number of duplicate acknowledgments. Since most of TCP implementations now have fast-retransmit, these duplicate acknowledgments cause the source to retransmit the lost segment without waiting for the timeout period to expire.
TCP makes use of duplicate acknowledgments mainly to indicate the next in-sequence byte expected. However, indirectly, a DACK is an indication that packets are not stuck at some bottleneck device. Fast Recovery is designed based on this dynamic. New
6.3 Wired-Wireless Gateway
Most proxy-based solutions, typically implemented at the base station at the wired-wireless boundary, attempt to hide the effect of wireless losses from TCP. This is achieved by either avoiding timeouts and fast retransmit (and hence window shrinkage) at the sender, or avoiding unnecessary increases in timeout (and hence delayed reaction to congestion). These solutions affect the recovery at the sender either implicitly or explicitly. For example, implicit approaches include dropping dacks resulting from wireless losses so that fast retransmit is not trigerred, or setting ZWA in acknowledgments to freeze TCP so that timeout is not trigerred. Explicit approaches include sending ECN-like notifications, which require code modification (at least) at the sender. We next discuss some proxy-based solutions.
The Indirect-TCP (I-TCP) proposal splits the transport link at the wireline–wireless border so as to completely shield the sender from the effect of wireless losses. The base station maintains two TCP connections, one over the fixed network, and another over the wireless link. This way, the poor quality of the wireless link is hidden from the fixed network. By splitting the transport link, I-TCP does not maintain end-to-end TCP semantics, i.e. I-TCP relies on the application layer to ensure reliability. It is argued that many applications provide end-to-end reliability, and one can choose I-TCP if the application provides reliability, and choose TCP otherwise. Thus, the mobile host must be aware of an application’s ability to provide reliability when choosing a proper protocol for the transport layer. Provided the mobile host can choose the appropriate transmission control protocol, the base station should be informed about the mobile host’s selection as it is where I-TCP executes. Since I-TCP uses TCP over the wireless link, it suffers from poor performance in dealing with wireless losses.
Like other approaches, Explicit Bad State Notification (EBSN) uses local retransmission from the base station to shield wireless link errors and improve throughput. However, if the wireless link is in error state for an extended duration, the source may timeout causing unnecessary source retransmission. The EBSN approach avoids source timeout by using an explicit feedback mechanism. If the wireless link is in bad state, the base station sends an EBSN message to the source for every retransmission of a segment to the mobile host. The EBSN message causes the source to reinitialize the timer. If the base station sends the EBSN messages before the source timer expires, then there will be no timeouts at the source. However, the main disadvantage of this approach is that it requires TCP code modification at the source to be able to interpret EBSN messages.
TCP Reno assumes that a duplicate acknowledgment is caused by a TCP segment being lost due to congestion and the connection is put in the congestion avoidance phase. However, for duplicate acknowledgment, WTCP does not alter the wireless transmission window assuming that the reception of the duplicate acknowledgement is an indication that the wireless link is in good state, and immediately retransmits the lost segment. The base station continues to transmit the remaining segments that are within the transmission window if they have not already been transmitted. However, until the mobile host receives the lost segment, the reception of each out-of-order segment will generate a duplicate acknowledgment. The number of these additional duplicate acknowledgments can be determined by the base station, which ceases to retransmit during their reception. By avoiding more than one duplicate acknowledgment based retransmission for a segment, WTCP attempts to improve the utilization of the wireless channel.
No comments:
Post a Comment