TCP: Error Handling with Explicit Notification Schemes

Transcription

1 TCP: Error Handling with Explicit Notification Schemes Andrei Khurri Department of Computer Science University of Helsinki October 14, 2004 Abstract Wireless networks widely used in Internet nowadays have high error rates. Transmission Control Protocol (TCP) originally designed for wired links needs for improving its performance over wireless links. In other words congestion avoidance approach is not sufficient when packet losses in the wireless networks occur due to corruption. In this paper I describe the schemes namely Explicit Loss Notification Schemes (ELN schemes) or Explicit Transport Error Notification Schemes (ETEN schemes) that allow the transport protocol to distinguish between a loss due to congestion and a loss due to corruption in the wireless networks, yielding performance benefits. Keywords: explicit transport error notification, explicit loss notification, TCP performance, unmodified TCP, wireless networks, corruption, bit error rate.

2 Table of Contents 1. Introduction 3 2. Primary questions and issues 4 3. Explicit Transport Error Notification (ETEN) 5 Types of ETEN 5 Simulation results 8 4. An ELN scheme example using TCP options An ELN scheme example using ICMP protocol Conclusion References 16 2

3 1. Introduction In the recent few years we are witnesses of tremendous evolution in communication technologies including hardware and software as well. This rapid progress has made possible the birth of mobile computing. The popularity of laptop computers, cellular phones and other mobile devices grows day by day. And it is possible to ensure that wireless links will be an integral part of future networks. The increasing role of mobile computing in our life has produced a vast deal of research in this area. It is very important to note that wireless networks, widely used nowadays, have fundamentally different characteristics than wired networks. The low bandwidth, high error rates, burst and time-varying, caused by the noisy environment, are basic features of wireless links. A considerable proportion of papers in this field has devoted to updating Internet s network layer protocol (IP) to achieve the most success in mobile networks and incorporate mobility on network layer. However, not so much researches have introduced the impact of mobility on transport layer protocols, such as Transmission Control Protocol (TCP). And this problem arguably remains less accomplished task than in case with IP. TCP is the widely used transport layer protocol in Internet today. Originally designed for wired networks TCP needs for improving its performance over wireless links. In particular, TCP assumes congestion in the network to be the basic reason for packet losses and unusual delays, and adapts to it. Since the TCP sink sends cumulative acknowledgments (ACKs) for successfully received segments TCP sender identifies the loss of a packet either by the arrival of duplicate cumulative ACKs or by the absence of an ACK for a timeout period. Thus TCP invokes congestion control by reducing its transmission window size and backing off its retransmission timer. This approach reduces the level of congestion on the links and is efficient if corruption losses are infrequent. However, as was mentioned above wireless networks have high bit error rate. So when packets are lost for reason other than congestion, the measures, such as congestion (transmission) window reduction and reset timers, will cause TCP to needlessly reduce its sending rate. That is, non-negligible degradation in TCP performance. Thus in my understanding and according to recent researches in this field the main goal is to improve TCP so that it can differentiate between congestion and corruption losses. In this paper I present the schemes namely Explicit Loss Notification Schemes (ELN schemes) or Explicit Transport Error Notification Schemes (ETEN schemes) that allow the transport protocol to distinguish between a loss due to congestion and a loss due to corruption in the wireless networks, yielding performance benefits. The performance benefits can be realized if TCP can retransmit a packet lost due to corruption without needlessly reducing the transmission rate, while continuing to protect network stability by decreasing the sending rate when loss is caused by network congestion. The rest of the document is structured as follows. Section 2 presents basic questions to be answered in the context of Explicit Notification Schemes. It describes some issues that should be taken into account while using ELN-based methods. In section 3 I will give the classification of ELN schemes according to [2]. The following sections (4 and 5) represent description of existent explicit notification schemes in more details including the simulation results. Such schemes are based on different possibilities to deliver the notification information to the sender so it is interesting to evaluate how they work in these cases. I conclude my presentation in section 6. References are included at the end. 3

4 2. Primary questions and issues The main idea of Explicit Notification Schemes is that we need somehow propagate notification information to TCP sender so that one can use it to make the appropriate decisions in congestion and corruption control. In my understanding the basic questions are: 1. When an Explicit Notification Scheme should start its work? 2. How is it possible? What mechanisms can we use to notify the sender about losses in wireless link? 3. What is response of the TCP sender? What actions does it take on receiving ELN information? 4. What are requirements to the topology of network and its nodes? Is it easy to implement an ELN scheme? It should be noted that a vast deal of research has been proposed in this field. Basically an intermediate node (i.e., base station or router) or end point generates an ELN message or sets an ELN bit to the TCP header when it identifies losses due to corruption in wireless link. To identify corruption errors several possibilities, such as consulting holes list or checking the sequence number of packets or some others, might be used. The second step is to deliver this notification message to the TCP sender. There are various solutions as well. The first one is a new protocol s creation to exchange notification messages, but it might be better to use existing protocols with some extensions for this purpose. For example, we can report information about specific corrupted packets using the Internet Control Message Protocol (ICMP) as has been done in [4]. Cumulative error rates can also be reported using ICMP. The reserved bits in TCP header is the second solution. We can add ETEN information within an IP or TCP option. These methods can be used to mark subsequent packets in a flow to indicate previous losses due to packet corruption in the same flow. An example of using this possibility has been presented in [1]. Another solution is to mark individual packets and pass them along rather than discard them when corruption is detected. When ELN message is delivered to the TCP sender, one has to identify this information. In other words TCP source should either start retransmission of packets lost due to corruption or reduce the sending rate in case of congestion. It is too important to sender be able to react to ELN information in time to achieve performance benefits. Well, since the algorithm is more or less clear let us think about implementation of an ETEN scheme, that is, special issue. Some of these methods require cooperation between layers in network model, instruments to determine the correct source and destination (since the header may be corrupted), and changes in requirements to routers, base stations and hosts. Some schemes also imply many assumptions about network topology. It is not always simply to turn from theoretical assumptions to real life networks. Finally, we should consider results. How large are performance benefits? Did implementation reach peaks that expected? The overhead of network in different terms, such as bandwidth, number of packets, time taken to completion and others, should be taken into account. We also should evaluate, does an ETEN method preserve the semantic of TCP. For example, in the approach of split connection that has been presented by Barke et al. in [7] and Yavatkar et al. in [8], one end-to-end TCP connection is divided into two separate TCP connections. One is over the wired network and the other over the wireless link, with the common base station. The semantic of TCP is violated in this case. Another important issue that related to ETEN mechanisms is network security. Techniques used in ETEN schemes are vulnerable to distributed denial of service (DDOC) attacks because the ETEN messages usually enter or leave their networks. An adversary in this case can launch a DOC attack by bombarding a host (or a network) with ETEN messages that may result in overwhelming 4

5 the capacity of network. DDOC attacks are not specific to ETEN but, for example, ICMP protocol used for delivering notification information is vulnerable to DDOC. However, effects of such attacks are strict and may become congestion collapse of the network since the response to ETEN is a retransmission. In contrast with ECN (Explicit Congestion Notification), when the response is a reduction in the sending rate, faked message can at worst throttle the connection. Other vulnerability is that an adversary can send spurious notifications corresponding to the packets that are not corrupted or were dropped due to congestion. Hence, the sender will either retransmit packets needlessly or bypass congestion avoidance and continue sending at higher rate. To launch this form of attacks attacker must know information about IP address, TCP port and TCP sequence number. It can be obtained by snooping on the network, by initiating session from compromised end-systems, by compromising routers or by hijacking TCP sessions. Another problem arises in interoperability ETEN schemes with existing security mechanisms. A good example is encryption and IPsec. The last one hides TCP port information as well as original source address. Therefore, it can be very difficult for intermediate routers to identify the correct TCP endpoint to which notification information should be delivered. The ETEN security issues mentioned above are touched upon by Krishnan et al. in [2]. In the following sections I will present the possible classification of ETEN mechanisms and some ELN-based schemes in more details. All the questions and issues that were considered above in this section should be taken into account as carefully as possible while analysing and evaluating such ELN-based methods. 3. Explicit transport error notifications 3.1. Types of explicit transport error notifications In my opinion it is important to consider in this section possible categorization in Explicit Notification Schemes field because different mechanisms have dissimilar algorithms and also diverse implementations. There are two types of Explicit Transport Error Notification (ETEN) mechanisms according to [2] that help TCP in distinguishing packets loss due to congestion from ones due to corruption. Per-packet mechanism notifies end points of each detected corruption and cumulative mechanism notifies endpoints of total corruption statistics. Per-packet mechanism in turn can be categorized into three different kinds when ideal knowledge of the IP addresses, TCP ports, and the TCP sequence number corresponding to the corrupted packet are available. The first of these, called Oracle ETEN, is an idealized case that allows instantaneous and perfect notification of errors. The other two schemes, Backward ETEN and Forward ETEN, use ICMPlike signalling to notify hosts of a corruption. Oracle ETEN. Oracle ETEN is a theoretical construct that assumes sufficient knowledge about the corrupted packet (sender and destination IP addresses, sender and destination TCP port numbers, and the TCP sequence number) is available to the intermediate router or the end-system that detects corruption. Furthermore, this mechanism assumes that the source of the flow can be instantaneously notified of the packet corruption. Oracle ETEN provides an upper bound on the performance improvement achievable by ETEN mechanisms that notify the source. While the Oracle ETEN mechanism is impossibility in the real-world, it can be used to distinguish between cases in which some ETEN mechanism would be useful and cases when no ETEN scheme would aid performance [2]. Backward ETEN. The backward ETEN (BETEN) mechanism, illustrated in Figure 1, assumes that the intermediate router can extract or reconstruct sufficient knowledge about the corrupted packet that is required to notify the sender. A BETEN mechanism has been implemented in network simulator where an intermediate node transmits an explicit (ICMP-like) message to the sender upon detecting a corrupted packet. The BETEN mechanism requires less time than Forward ETEN algorithm to notify the sender that a corrupted packet has been detected [2]. 5

6 Figure 1: Backward ETEN Forward ETEN. The forward ETEN mechanism illustrated in Figure 2 also assumes that the intermediate router can extract complete and correct knowledge of the IP addresses, TCP ports, and TCP sequence number corresponding to the corrupted packet. Upon detection of a corrupted packet, the intermediate router transmits a FETEN message to the destination host, which then conveys the information to the sender on a subsequent acknowledgment. If separate messages are generated per corruption loss, it is easy to see that BETEN will lead to faster recovery than FETEN. The benefit of using BETEN is higher if the corruption occurs closer to the sender and it increases with the round-trip delay of the path. Two alternatives that do not require generation of new packets for FETEN exist. With the first alternative, the intermediate node that detects the corrupted packet will wait for a subsequent (uncorrupted) packet from the corresponding flow and piggyback the corruption information on that packet. The other approach is to mark the corrupted packet and pass it along to the destination (subsequent nodes must also forward this packet). The destination in turn will notify the sender of the packet lost due to corruption [2]. Figure 2: Forward ETEN 6

7 Cumulative ETEN. It might be not always possible to accurately retrieve the source and destination IP address, source and destination TCP port numbers, and TCP sequence number from a corrupted packet or link-layer frame. Hence, there is another ETEN mechanism based on cumulative error rates (i.e., average error rates over an interval of time and across various flows). The cumulative ETEN (CETEN) information conveyed to the end-hosts can be in one of several different forms [2]: An absolute bit error rate, byte error rate, or packet error rate observed within a moving window in time. The error rate may be quantized into a small number of steps (for example, high, medium, and low). A relative error rate that simply indicates that the quantized error rate has increased or decreased from the previous value. An estimate of the probability that a packet survives corruption. CETEN information can be delivered to a sender via forward or backward signalling, analogous to a FETEN-based or a BETEN-based strategy. Also, as noted before, CETEN can be piggybacked on data and acknowledgment packets, rather than using additional distinct messages. CETEN information can be collected on a per-hop basis or aggregated over the end-to-end path within the lifetime of a particular flow. It is difficult to collect statistic using CETEN mechanisms for short flows that may have terminated before we obtain a good estimate of the packet corruption probability. The CETEN-based mechanism adds two survival-probability fields (for two directions) which indicate the probability that a packet avoids corruption. The forward path survival probability field is initialized to 1 by the source of the packet. This probability is updated by routers along the path. Therefore, when a packet arrives at the receiver the survival probability in the packet is the survival probability of the path. The transport endpoint at the destination keeps a record of the survival probability of the forward path. When the endpoint generates a packet or an ACK it copies this saved value into the reverse path survival probability, and initializes the forward path survival probability to 1. Using such a mechanism each router would probabilistically transmit a message to the sender of an incoming packet informing the sender of the error rate on the incoming link. After a while the sender will have received information from each router along the path and can calculate the current path error rate. The disadvantage of this mechanism is that it adds traffic to the network and requires the sender to transmit a fairly large amount of traffic to ensure enough path information is collected [2]. Computing the per-link packet corruption survival probability at each router per-link. Each router multiplies the forward path survival probability field in each packet by the router s own estimate of the survival probability for the link on which the packet arrived. The estimate of the survival probability for the link is computed on receiving each packet on the link as follows: pi = α xi + ( 1 α ) pi 1, where x i = 1 if the i th packet is received correctly, and x i = 0 if the i th packet is corrupted. The parameter α is chosen from [0, 1]. The equation outlined above gives us corruption survival probability. An additional pair of packet header fields has been added to carry the congestion survival probability, computed in the same way. Every intermediate node estimates the packet survival probability from congestion (in addition to the probability of surviving corruption). This information gets recorded in subsequent packets traversing the router. At the pcong transport endpoint the loss event is taken as a congestion event with probability. p + p Otherwise, corruption event has probability TCP sender make appropriate decision. p corr pcorr + p cong cong corr. Depending on this final probability the 7

8 3.2. Simulation results To observe how ETEN mechanisms behave in practice let us take a look at some simulations that have been done using ns-2 simulator [6]. The experiment parameter ranges are given in Table 1: Parameter Link capacity Forward link bit error rate Backward link bit error rate Link propagation delay TCP variants ETEN mechanisms MSS Receiver window Router buffers Value 1.5 Mb/s, 10 Mb/s, 100 Mb/s 1.56E E-5 0 or same as forward bit error rate 10 ms, 100 ms, 320 ms Reno, SACK, Westwood None, Oracle ETEN, BETEN 536 bytes 20 segments 50 packets shared FIFO queue Table 1: Experiment Parameter Ranges Consider a single TCP flow with no cross-traffic over a single uncongested link with channel errors that result in packet corruption. Each simulation consists of a bulk TCP flow (FTP application) of 120 seconds duration with unlimited data to send. Figure 3 shows that Oracle ETEN as well as BETEN provide a significant improvement in goodput, particularly at high bit error rates. The performance of BETEN with SACK at low bit error rates is close to Oracle ETEN. However as the BER increases, the chance to loss notifications also increases and the benefits from BETEN start to reduce. Figure 3: TCP with ETEN over an uncongested long fat network (LFN) 8

9 Figure 4: TCP Westwood versus SACK TCP with ETEN As was mentioned above the Oracle ETEN is idealized and impossible in practice case. But it allows making better the comparison between others cases. In the second example of simulations we compare the performance of TCP Westwood when both congestion and corruption losses are present. Figure 4 shows the performance of TCP Westwood and BETEN over a 3-hop linear topology with 1.5 Mb/s links each with a one-way delay of 10 ms. The plot shows that BETEN with SACK outperforms TCP Westwood at a BER of 10E-5 regardless of congestion level. In addition, the plot shows that when no competing flows are present TCP SACK performs similar to or better than TCP Westwood. When using 4 competing flows TCP Westwood outperforms stock SACK TCP (except at a BER of 10E-5). Figure 5 illustrates the TCP Reno performance with and without CETEN over a 3-hop topology of 100 Mb/s links each with a one-way delay 100 ms in the presence of UDP cross traffic. The bit error rate of each link in the topology is varied according to Table 1. The traffic generators use an exponential on-off model with mean burst and mean idle time, set to 500 ms. The plot shows that under some heavy BERs (e.g., 10E-6) ETEN with TCP Reno performs better than standard TCP Reno. However, at the highest BER tested (1.56E-5) CETEN offers roughly the same performance as stock TCP Reno under all congestion levels. Further, under low BERs CETEN performance is roughly the same as stock TCP Reno, except under heavy congestion (4 UDP flows), in which case CETEN with TCP Reno performs slightly worse than TCP Reno alone. Making conclusions from these figures we can say that TCP with an ETEN significantly outperforms unmodified TCP only at high bit error rates, such as BER of 10E-5. This case raises no doubt. But in practice we often have bit error rates that are lowered by using for example link-level FEC (Forward Error Correction). In this situation we should think about expediency of using ETEN. The Figure 3 also shows that TCP SACK outperforms TCP Reno. It could be most probably because of the best ability of SACK to correct multiple losses. Figure 5 shows that in some situations CETEN offers worse performance than TCP Reno so additional investigations are required in this area. 9

10 Figure 5: CETEN Performance with TCP Reno and UDP cross traffic 4. An ELN scheme example using TCP options In this section I will consider how explicit loss notifications can be used for improving TCP performance in wireless link when a mobile host is the TCP sender and Snoop agent is using at the base station that divide a wireless link and a wired network. A situation seems to be very typical. This scheme is provided by [1]. A representative topology is shown on the Figure 6. Figure 6: Topology for data transfer from a mobile host 10

11 Suppose we need to transmit data packets from mobile host to the fixed receiver through a cellular wireless link. In this case if the receiver or a base station knows for sure that the loss of a segment was not due to congestion, it sets the ELN (Explicit Loss Notification) bit in the TCP header and propagate it to the source. It should be noted that in this case an ELN message is sent as part of the same connection (and not in a separate way, using ICMP for instance). The snoop agent running at the base station monitors all TCP segments that arrive over the wireless link. It does not cache any TCP segments but keeps track of holes in the sequence space as it receives data segments, where a hole is a missing interval in the sequence space. These holes correspond to segments that have been lost over the wireless link. However, the packet can be lost due to congestion at the base station. To avoid against wrongly marking a congestion hole as having been due to a wireless loss, the agent only adds a hole to the list of holes when the number of packets queued on the base station's input interface is not close to the maximum queue length. When ACKs, especially duplicate ACKs, arrive from the receiver, the agent at the base station checks its list of holes. It sets the ELN bit on the ACK if it corresponds to a segment in the list before forwarding it to the data sender. It also cleans up all holes with sequence numbers smaller than the current ACK, since they correspond to segments that have been successfully received by the receiver. When the sender receives an ACK with ELN information in it, it retransmits the next segment, but does not take any congestion control actions and reduces transmission rate. The sender also makes sure that each segment is retransmitted at most once during the course of a single round-trip, as the snoop agent would flag an ELN for each duplicate ACK following a loss [1]. Several experiments have been performed to measure the performance of data transfer from the MH to the FH using TCP Reno with and without ELN across a range of exponentiallydistributed bit-error rates. In Figure 7 we can see significant performance benefits of using the snoop protocol coupled with the ELN mechanism in this situation. These measurements were made for wide-area transfers between UC Berkeley and IBM Watson, across one wireless WaveLAN hop and 16 Internet hops. The performance improvement due to ELN at high error rates is roughly a factor of 2. The main advantage of ELN is that it helps maintain a large TCP congestion window even when wireless error rates are high, reacting only to congestion [1]. Figure 7: Throughput of TCP Reno and Reno enhanced with ELN across a range of exponentially distributed bit-error rates for transfer from a mobile host [1] 11

12 To make certain of independence of location a wireless link in the network path to reach performance gains using ELN-based scheme let s briefly consider the case of cellular wireless transit links that shown in the Figure 8. The TCP ACKs traverse the same base stations as the data packets on the forward path. Suppose a loss happened due to corruption over the wireless link. In this case, the agent at base station A would have seen the packet, while B would not, so the packet gets added to B's list of holes using the same algorithms. When duplicate ACKs arrive for the missing packet at B, its agent sets the ELN information bit and propagates it towards A. Since A originally saw the packet (it is not in its list of holes), it infers that the packet was obviously lost over the wireless link and simply lets the ACK go through to the data sender with the ELN information set on it. Of course, it is possible to deploy a snoop agent that caches and locally retransmits packets at A in this topology. In this case, the agent also suppresses duplicate ACKs for corrupted packets, as described earlier. It is important to note that local retransmissions from the snoop agent at A now happen only upon duplicate ACKs with ELN set. Now suppose that the packet was lost due to congestion elsewhere on the path. If it was lost before A, then the agent at A, upon seeing an ELN ACK via B, resets this bit because this packet did not reach A to start with. The sender now reacts to this loss in the conventional way and performs congestion control. Similarly, if the packet was lost due to congestion after B, no agent in the network sets the ELN information on any duplicate ACK, leading to correct congestion control. It is easy to see how this approach generalizes to the case when there is more than one single-hop wireless link on the path [1]. Figure 8: Topology for data transfer over a cellular wireless transit link 12

13 5. An ELN scheme example using ICMP protocol In section above I described an ELN scheme that used unreserved bits in TCP header to propagate notification information to the TCP sender. Another possibility is to use existent protocol for carrying control information in the networks, namely Internet Control Message Protocol (ICMP). Goel and Sanghi in [4] proposed two types of ICMP messages called ICMP-DEFER and ICMP- RETRANSMIT. The network topology implies transmitting data from a fixed host to mobile TCP sink through a base station, that is, the last hop wireless link. Two schemes have been proposed by authors, simple and refined. The first one uses only ICMP-DEFER message and has disadvantage basically due to high loss detection latency. That may become more intelligible while describing the refined scheme [4]: 1. If transmission the packet on the wireless side is not successful the base station generates an ICMP-DEFER message. So within one round trip time TCP source will receive either an acknowledgement for the packet or an ICMP message. In that case end-to-end retransmissions do not start. However, link-layer retransmissions may be going on. The control information that consists of TCP and IP headers is enough for TCP sender to decide which particular packet was lost on wireless link. The overhead on the network seems to be minimal since ICMP-messages are not retransmitted. 2. On receiving an ICMP-DEFER message, TCP postpones the retransmission timer if it is active for the lost segment indicated in this control message. It helps to avoid possible conflicts between the local retransmissions at the base station and end-to-end retransmissions. Since the local retransmissions might fail acknowledgement for this packet may be delayed. In assumption done in [4] one RTO time (minimum value 1 second) is seemed to be sufficient to exhaust all local retransmission attempts for a packet. But here can be also seen a problem with Simple scheme. Actually TCP source that receives ICMP-DEFER messages knows only about possible losses due to noise, but it has no way to find out if multiple segments were discarded by the base station. Without this information, TCP has to set retransmit timer for multiple losses detection many times. So the loss detection latency might be very high. To avoid this kind of problem we have Refined Scheme that operates also with ICMP-RETRANSMIT messages. 3. When all the local retransmission attempts for a packet have been exhausted the base station generates an ICMP-RETRANSMIT message and sends it to the TCP source. The one in its turn on receiving this type of message retransmits the segment indicated. It also stores the information that the ICMP-RETRANSMIT message was received for this segment. 4. An ICMP-RETRANSMIT message indicates that one segment was lost from the chain of segments sent by the source TCP. When the destination receives subsequent packets, it generates duplicate acknowledgments. When the source TCP receives the first of such duplicate acknowledgments, it switches to fast recovery algorithm. It discards the information that it received an ICMP-RETRANSMIT message for this segment. When it finally receives a new acknowledgement, it comes out of the fast recovery algorithm and resets cwnd to the value prior to its entering the fast recovery phase. When source TCP suffers a retransmit timeout, it follows normal TCP algorithms. When source TCP receives duplicate acknowledgments for a segment for which it has not received ICMP-RETRANSMIT message earlier, it follows normal TCP algorithms. This scheme works on networks with a wireless link anywhere in the network path (and not necessarily the last hop) [4]. To evaluate the performance benefits of this notification scheme over unmodified TCP some simulation results [4] will be presented below. The parameters that were used are given in Table 2. 13

14 Parameters Wired link Bandwidth Propagation delay Loss Probability Error characteristics of wireless link: *GOOD state - mean value of exponential distribution - loss probability *BAD state - mean value of exponential distribution - loss probability Receiver s advertised window size Value 8 Mbps 50 ms 0 (reliable) 5 seconds 0 (reliable) 0.1 to 0.5 second 1 4 to 64 KB Table 2: Parameter values used in simulations As you can see from Figures 9-10, the Refined Scheme performs better than Simple Scheme for all values of window size. The performance of Simple scheme is worse than Unmodified TCP, especially at higher values of mean_bad_state. The reason of this is that when the duration of BAD state increases, the possibility of multiple losses increases as well. As was discussed earlier, this is the important weakness of Simple Scheme. Figure 9: Propagation delay of wired link: 50 ms and mean_bad_state: 0.3 sec. Finally, it would be very important to summarize the advantages of ICMP-based Refined Scheme [4]: There are significant performance gains while using modified TCP with ICMP based scheme over wireless links. Very low overhead of the scheme. It peaked during simulation at 5 % in terms of number of packets, but mostly remained less than 1 %. Since ICMP packets are very small, the overhead in terms of bandwidth was much lower. The host which does not implement the new message types purely discards it. Refined Scheme saves semantics of TCP. The scheme is symmetric. The generation of ICMP messages is triggered by the link layer for the wireless link. When a mobile host is the TCP source, ICMP messages will be triggered by the link layer of the mobile host, that is, no special case. No assumptions about the location of the wireless link in the network path. 14

15 Figure 10: Propagation delay of wired link: 50 ms and mean_bad_state: 0.5 sec. 6. Conclusion Originally designed for wired networks TCP needs to improve its performance over wireless links. Since mobile networks have high bit error rates the congestion avoidance approach is not efficient in that case. To make correct decision TCP sender has to be able to differentiate between congestion and corruption losses. Otherwise, when packets are lost for reason other than congestion, the measures, such as sending rate reduction and reset timers, will be the reason of TCP performance degradation. In this paper I presented Explicit Loss Notification Schemes (ELN schemes) or called by some authors Explicit Transport Error Notification Schemes (ETEN schemes) that allow the transport protocol to distinguish between a loss due to congestion and a loss due to corruption in the wireless networks, yielding performance benefit. The performance benefit can be realized if TCP can retransmit a packet lost due to corruption without needlessly reducing the transmission rate, while continuing to protect network stability by decreasing the sending rate when loss is caused by network congestion. In most of cases the simulation results show that use of TCP with ELN-based schemes causes significant performance gains over unmodified TCP. However, there is still a deal of unsettled questions related to implementations of ELN schemes in real networks. As simulation results showed, additional investigations are needed in CETEN-based schemes. Some methods require changes in work of network nodes and adding functionality to it. Sometime this measures violate algorithm s symmetry and semantic of TCP and increase overhead of network as well. I think it is needed a few years to start wide using of ELN schemes in real-life world because many of these algorithms are implemented to date only in simulators. There is also another research issue that requires careful consideration, such as security. All these questions represent very important and tremendous fields for future work. 15

16 7. References 1. H. Bal Krishnan and R. H. Katz, "Explicit Loss Notification and Wireless Web Performance," Proc. of IEEE GLOBECOM, November R. Krishnan, J.P.G. Sterbenz, W.M. Eddy, C. Partridge and M. Allman "Explicit Transport Error Notification for Error-Prone Wireless and Satellite Networks," BBN Technical Report No. 8333, BBN Technologies, February, Revised version published in Computer Networks, Vol 46, Issue 3, October J. A. Cobb and P. Agrawal, "Congestion or corruption? a strategy for efficient wireless TCP sessions," in IEEE Symposium on Computers and Communications, Alexandria, Egypt, pp , S. Goel and D. Sanghi "Improving TCP Performance over Wireless Links," In Proceedings of TENCON'98, pages IEEE, December K. Chandran, S.Raghunathan, S.Venkatesan, and R.Prakash, "A feedback based scheme for improvingd TCP performance in ad-hoc wireless networks," Tech. Rep., Computer Science, University of Texas-Dallas, October Also published in ICDCS' ns-2 simulator, 7. A. Bakre and B.R. Badrinath. I-TCP: Indirect TCP for mobile hosts. In Proc. 15 th International Conference on Distributed Computing Systems (ICDCS), May R. Yavatkar and N. Bhagwat. Improving end-to-end performance of TCP over mobile internetworks. In Mobile 94 Workshop on Mobile Computing Systems and Applications, December