From eyh5@ee.cornell.edu Wed Oct 17 17:57:15 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9HLvFo16710 for ; Wed, 17 Oct 2001 17:57:15 -0400 (EDT) Received: from james (james.ee.cornell.edu [128.84.236.65]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f9HLurQ00690 for ; Wed, 17 Oct 2001 17:56:53 -0400 Date: Wed, 17 Oct 2001 17:56:42 -0400 (EDT) From: Edward Hua To: egs@CS.Cornell.EDU Subject: 615 Paper # 29 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Analysis of TCP Performance over Mobile Ad Hoc Networks Gavin Holland and Nitin Vaidya This paper presents a comprehensive analysis on the performance of the TCP in an ad hoc network. Specifically, it recognizes the shortcoming in that TCP tends to perform poorly by degrading the throughput in the network when link failures along a transmission path occur. This is due to the TCP's inability to distinguish a link failure from network congestion. The analysis uses DSR as the underlying routing protocol, on top of which TCP's performance is evaluated. The authors present a multitude of evaluations in this paper to illustrate the impact of this TCP action on the overall throughput. In doing so, the authors have developed an expected throughput as the upper bound and used it as a benchmark to compare the measured throughputs at various (relative) nodal speeds. One conclusion drawn is the higher relative mobility between nodes tends to degrade the throughput. The performance evaluations show that several characteristics of the routing protocol have contributed to the degraded throughput performance. They are: 1)the route caches proposed in DSR may contain stale routes that are not recognized by the packet sender. An intermediate node may contain such stale routes, and when a salvaging mechanism invoked by an intermediate node after a link failure occurs, these stale routes could be used fruitlessly. The information of stale routes may even be propogated when a promiscuous listening mode is in place. 2)When the minimum path between sender and receiver has increased in length, as it often occurs in MANET, the data flow could be stalled. because the DSR does not attempt to lengthen a route until a failure occurs. That is, the sender is unaware of the increase in hops to reach the destination and still keeps sending the packets with its stored route information. The result is the packets never get to the destination, which eventually prompts the sender to halt the data traffic. 3)DSR's route request retransmission back-off algorithm also contributes to the degraded throughput performance because of the difficulty of choosing the appropriate time-out value. The authors also propose using explicit feedback to counter the defficiency of TCP in case of link failures. To do this, an Explicit Link Failure Notification (ELFN) is piggybacked in a route failure message that is sent to the sender. ELFN notifies then notifies the sender of the link failure, thus preventing it from treating it as a network congestion case and acting accordingly. As demonstrated in the performance evaluations, the incorporation of ELFN in DSR greatly enhances the throughput of the network. One interesting point is in Figure 9, the performance of DSR with ELFN with a probe interval of 30seconds is worse than the performance of DSR with basic TCP, regardless of the speeds of the mobile nodes. This appears to have placed a cap on how the probe interval should be defined in the ad hoc network that will prevent it from performing worse than the original scheme. Because this paper is mostly on the evaluation of an existing routing protocol with TCP, there is no comment on the routing protocol itself. However, in looking at the graphs of the simulation results, I am wondering if it has given an impartial picture of TCP's true performance with DSR. The only metric used is the throughput, largely affected by TCP. However, there are other performance metrics, one of which is the end-to-end delay, that one should also take into consideration when evaluating the TCP performance in an ad hoc network. This paper could be more comprehensive with the inclusion of such performance metrics. From wbell@CS.Cornell.EDU Wed Oct 17 22:47:41 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9I2leo17209 for ; Wed, 17 Oct 2001 22:47:41 -0400 (EDT) Received: from [192.168.1.102] (syr-66-24-16-64.twcny.rr.com [66.24.16.64]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id WAA16960 for ; Wed, 17 Oct 2001 22:47:39 -0400 (EDT) Subject: 615 PAPER #29 From: Walter Bell To: egs@CS.Cornell.EDU Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14.99+cvs.2001.09.29.08.08 (Preview Release) Date: 17 Oct 2001 22:47:27 -0400 Message-Id: <1003373277.3657.229.camel@brute> Mime-Version: 1.0 29) Analysis of TCP over Mobile Ad Hoc Networks This paper investigates how TCP reacts to some of the specifics of ad-hoc networking environments, specifically how the TCP congestion avoidance works under link failures. The key insight here is that TCP collision avoidance is based on the assumption that packets not getting through is a function of the congestion of the network, which is clearly untrue in Ad-Hoc networks, as link failures in otherwise idle networks can provide a source for many lost packets. They provide a simple investigation of a single-sender single-recipient model to adequately model the communication interactions in isolation of most network effects. This was a useful tact to take on the problem, however, it was not clear that their observations in the idle network case would scale properly-- in particular, DSR will perform better with added network traffic, as it can learn of alternate paths to destinations, which was one of the major sources for TCP latency as shown in the paper. I do however believe that their suggested alteration to TCP [the suspension of backoff during link failures] would be a useful addition to an implementation of TCP targeted at mobile hosts. From daehyun@csl.cornell.edu Wed Oct 17 23:30:58 2001 Return-Path: Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9I3Uwo21589 for ; Wed, 17 Oct 2001 23:30:58 -0400 (EDT) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id XAA88694 for egs@cs.cornell.edu; Wed, 17 Oct 2001 23:30:08 -0400 (EDT) (envelope-from daehyun) From: Daehyun Kim Message-Id: <200110180330.XAA88694@wilkes.csl.cornell.edu> Subject: 615 PAPER 29 To: egs@CS.Cornell.EDU Date: Wed, 17 Oct 2001 23:30:08 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper analyzes TCP performance over ad hoc networks with respect to node mobility and proposes a technique through which the problem can be solved. This paper shows that TCP performance drops significantly when node moves and explains that it is because TCP does not distinguish between link failure and network congestion. TCP assumes that all packet losses are caused by congestion. So it reduces congestion window and backs off retransmission timeout. This works well in stationary networks. But in ad hoc networks, the link failure caused by node movements, not congestion, is frequent, which affect the TCP performance a lot. This paper defines a metric called 'Expected Throughput' and uses it as a upper bound of TCP performance. Conceptually, it is throughput when the sender and the receiver is connected by the shortest path regardless of network dynamics. And it also does not include any overhead such as route establishment and link failure. To overcome this problem, this paper suggests a technique called Explicit Link Failure Notification (ELFN) and analyzes the performance. The key idea of ELFN is to notify the sender about link failures, so that it may not react as if congestion occur. This paper shows the performance of ELFN with respect to various parameters such as probe packet interval. Generally, ELFN helps the performance a lot. But the parameter selection for different network configurations might be another issue. In my opinion, the main contribution of this paper is that it tries to measure the overall performance of ad hoc networks, including both of the network layer and transport layer. In routing protocol papers, they focused on routing algorithms, so they measures only the routing performance. But, the performance of networks is the interactions between various layers. this paper is good in that it considers the interactions between two different layers. They used DSR for the underling routing protocol. But the routing protocol has big effect on the performance and there is no standard such as TCP. So it will be a very good research topic to compare the different routing protocols. (They mentioned this in the future work section.) From teifel@csl.cornell.edu Wed Oct 17 23:33:53 2001 Return-Path: Received: from disney.csl.cornell.edu (disney.csl.cornell.edu [132.236.71.87]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9I3Xro21700 for ; Wed, 17 Oct 2001 23:33:53 -0400 (EDT) Received: from localhost (teifel@localhost) by disney.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id f9I3Xlj11601 for ; Wed, 17 Oct 2001 23:33:47 -0400 (EDT) (envelope-from teifel@disney.csl.cornell.edu) X-Authentication-Warning: disney.csl.cornell.edu: teifel owned process doing -bs Date: Wed, 17 Oct 2001 23:33:47 -0400 (EDT) From: "John R. Teifel" To: Subject: 615 PAPER 29 Message-ID: <20011017233238.M11256-100000@disney.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII TCP: This paper investigates TCP performance over ad hoc networks. More specifically the authors concentrate on TCP performance in the presence of link failures. This paper mainly discusses TCP simulation results for ad hoc networks and mechanisms for how TCP performance may be improved in mobile networks. They run simulations with ns and assume a DSR routing protocol. Throughput is the TCP performance metric used in this paper. Since TCP assumes that all packet loss is caused by congestion (as opposed to link breakages), a new metric called ``expected throughput'' is used as an upper bound on TCP performance. The simulations show that routing protocols can have a significant impact on TCP performance, which I found to be rather surprising and interesting. The observed TCP performance degradation was mainly caused by stale route information, even in slowly changing topologies. The authors show how explicit feedback can improve TCP performance. A weakness of the simulations, which the authors acknowledge, is that only one TCP link was simulated and the performance of multiple TCP links and the effects of the underlying routing protocols on these multiple links was not investigated. This paper was interesting in that we finally saw the effect of routing protocols on a higher level network element, and perhaps necessary improvements to routing protocols that may be needed to acheive good performance at the higher network layers (such as cache management protocols). From c.tavoularis@utoronto.ca Thu Oct 18 00:57:15 2001 Return-Path: Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9I4vEo00887 for ; Thu, 18 Oct 2001 00:57:14 -0400 (EDT) Received: from webmail3.ns.utoronto.ca ([128.100.132.26] EHLO webmail3 ident: IDENT-NOT-QUERIED [port 52243]) by bureau6.utcc.utoronto.ca with ESMTP id <239484-12939>; Thu, 18 Oct 2001 00:57:02 -0400 Received: by webmail3.ns.utoronto.ca id <414676-222>; Thu, 18 Oct 2001 00:56:58 -0400 To: COM S 615 Subject: 615 PAPER 29 Message-ID: <1003381017.3bce611990159@webmail.utoronto.ca> Date: Thu, 18 Oct 2001 00:56:57 -0400 (EDT) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 This paper addresses the performance of TCP in mobile networks and a scheme to improve TCP throughput in the face of link failures and temporary network partitions. Analysis was performed with the ns network simulator with TCP-Reno running over IP and 802.11. Traditional TCP performs poorly in mobile networks since it treats link breakage like congestion by repeatedly: reducing the congestion window, timing- out, and backing off before retransmitting. Throughput is evaluated through simulation and compared to the expected throughput that is measured as the simulated throughput through a fixed linear chain of n-1 wireless hops. Throughput is counted as the number of acknowledgments received by the sender. The expected throughput can never actually be achieved because the routing protocol does not always choose the shortest path and there is overhead caused by route discovery. It is found that while the expected throughput is independent of node speed, measured throughput in general worsens with faster mobility. The interesting result is that there are anomalies and the throughput will actually improve with node speed if connectivity happens to be maintained. Another cause of performance deterioration is stale routes being used by the routing protocol. Obviously the routing control is a bottleneck, and suggested amelioration is dynamic timeout of cache data related to route failure rate. Also, the optimal back-off time before performing a new route request in the event of link failure is still an outstanding issue. In effect, TCP throughput depends on interaction between the MAC, ARP, and routing protocols as well as the TCP congestion control mechanism. The authors propose to equip TCP with the mobility specific mechanism Explicit Link Failure Notification (ELFN), separate from congestion control. An ICMP message is sent (or piggybacked) to the sender indicating a link failure. TCP will temporarily disable congestion control until the route is restored. The network must be probed periodically to detect when the link is back up and congestion control can be resumed. It was found that ELFN improves throughput and makes consistent the performance of different mobility patterns. It was found that the probe time was a critical parameter, as well as post-ELFN retransmission timeout. The choice of probe packet was less severe, and I’m not sure why it was even mentioned. I applaud the authors for their approach to simulation, that is, fixing the node moving patterns and evaluating performance at different rates of mobility. It simplifies the association of the problem with the cause. Simulation appeared to have transmission diameter (500m) wider than the entire network area width (300), resulting in linear routing. Maybe that was the idea, since they were comparing with the expected throughput, which is also linear? From kewang@CS.Cornell.EDU Thu Oct 18 01:30:37 2001 Return-Path: Received: from opus.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9I5Ubo03837 for ; Thu, 18 Oct 2001 01:30:37 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: 615 PAPER 29 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 18 Oct 2001 01:30:36 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301FB6327@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 29 Thread-Index: AcFXlgQKGZRquA0HRHy7UjMsEhBQnw== From: "Ke Wang" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sundial.cs.cornell.edu id f9I5Ubo03837 Review for “Analysis of TCP performance over Mobile Ad Hoc Network”, by Holland and Vaidya This is a good performance evaluation paper. It investigated the performance of TCP, which is the current standard protocol on network, when it is used on ad hoc network instead of the traditional network. It’s quite obvious that some characteristics of TCP will worsen the performance on ah hoc network. Because TCP is reliable, it requires acknowledgement and other higher overhead when do communication. On the other hand, its wide existence for Internet and Internet applications make it’s attractive to try to use TCP also for ad hoc network. In this paper, the authors focus on the impact of link failure on TCP, which is resulted from mobility of ad hoc network. TCP performance drops greatly when nodes move. This is mainly because TCP always assumes packet losses are caused by congestion, without distinguishing between link failure and network congestion. This assumption is reasonable for traditional network. But for ad hoc network, there is a lot of link failures introduced by frequent nodes’ move. Thus, this paper gives a new metric “expected throughput ” to have proper evaluation. It’s a function of mobility pattern, independent of routing algorithm and speed of movement. A contribution of this paper is they propose a simple way to overcome this problem, which is called Explicit Link Failure Notification (ELFN). The performance improved a lot after adapting it. The main idea is intuitive but effective: just notify the senders about link failure, so they can distinguish it from network congestion. This paper gives a pretty thorough analysis about the TCP performance. But there are still some problems. They only based on DSR as the routing algorithm, but in fact the performance depends much on the routing algorithm’s characteristic. Maybe they should choose some proactive routing algorithm to compare with the reactive one. Also they tested TCP with an environment with no competing traffic in the network, which is not so realistic. To get idea about performance of TCP on real ad hoc network, there seems still need a lot of simulations. From papadp@ece.cornell.edu Thu Oct 18 02:33:13 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9I6XDo10110 for ; Thu, 18 Oct 2001 02:33:13 -0400 (EDT) Received: from hegel (hegel.ee.cornell.edu [128.84.236.63]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f9I6WmQ08278; Thu, 18 Oct 2001 02:32:48 -0400 Date: Thu, 18 Oct 2001 02:33:01 -0400 (EDT) From: "Panagiotis (Panos) Papadimitratos" X-Sender: papadp@hegel.ee.cornell.edu To: Emin Gun Sirer cc: Panagiotis Papadimitratos Subject: 615 PAPER 29 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of : "Analysis of TCP Performance over Mobile Ad Hoc Networks," by G. Holland and N. Vaidya Panagiotis Papadimitratos papadp@ece.cornell.edu The presented work is a simulation study of the performance of TCP in a MANET setting. TCP has been developed for a wire-line network with congestion being the sole cause of data loss, i.e., packet dropping. This is exactly the reason why TCP is not expected to perform adequately in an environment where transmissions may be impaired for different reasons. In particular, as identified by the authors, frequent path breakages due to mobility occur in a dynamically changing multihop topology. The consequent loss of segments and acknowledgements or the time-out of the TCP sender are expected due to the route re-construction delays and can cause the sender to adjust the Send window and reduce the transmission rate. It is apparent that the path breakage and the necessary route maintenance and new route discovery, among others, are closely related to the achieved performance, since the forwarding of data relies on the underlying routing protocol. More specifically, the bi-directionality of TCP traffic adds one more 'parameter' to this dependence, as indicated from the presentation of the experiment traces. In general, the analysis of the experiments draws heavily from the interpretation of the routing protocol behavior, in order to explain the TCP performance. Other factors that are considered are the mobility pattern, and more specifically, the average node speed, the interaction with other IP-suite protocols such as ARP, the use of explicit link failure notification (ELFN) messages, variations of the window size and the TCP retransmission timer and the impact of more than one traffic flows. It is argued that the employed protocol (DSR) appears to create pathological situations due to the use of stale routes, independent discovery of reverse routes from the TCP receiver, and possibly large 'recovery' delays, i.e., times till a new route is discovered. Moreover, it is diagnosed that the increase of the shortest route length between two nodes cannot be effectively addressed by DSR; instead, a decrease virtually always results in successful adaptation of the protocol, the reason possibly being related to all three above-mentioned factors. Another issue related to the impact of stale topological knowledge is probed by the comparison of the average performance with and without the DSR caching mechanism on. It is also conjectured that performance (throughput) should deteriorate for increasing speed, which appears to be intuitive, but a counterexample is presented. Finally, the use of ELFN appears to provide a significant improvement. In particular, their TCP is modified so that upon reception of ELFN, the sender enters a 'stand-by' state and probes the network after a delay-period by transmitting a single segment. Although the paper relies on extensive simulations does not provide a definitive analysis of the observed phenomena. Moreover, the dependence upon DSR appears to reduce the scope of the paper from a "TCP in MANET" to a "TCP over DSR". Nevertheless, the fact that a more realistic type of traffic, compared to the notorious CBR source, should be perceived as merit. On the other hand, the presence of a single flow does not contribute in exploring throughput degradation reasons pertinent to the MANET paradigm (Fig. 12 is not very suggestive either). As for the observations related to the node velocity, it would have been much more meaningful to measure average rates of the graph change, something that would show that the increase of the velocity for the specific mobility pattern does not result to a proportional link breakage rate. In conclusion, the paper transcribes a well-known issue, the misinterpretation of TCP feedback by the sender in a wireless, mobile setting, in that of a multihop topology and performs an extensive simulation study. Nonetheless, the complex issue is further obscured by the experimental setting, which does not achieve much more than a well-focused critique of DSR. From gupta@CS.Cornell.EDU Thu Oct 18 10:52:28 2001 Return-Path: Received: from ringding.cs.cornell.edu (ringding.cs.cornell.edu [128.84.96.109]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IEqSo03419 for ; Thu, 18 Oct 2001 10:52:28 -0400 (EDT) From: Indranil Gupta Received: (from gupta@localhost) by ringding.cs.cornell.edu (8.11.3/8.11.3/C-3.2) id f9IEqRG27019 for egs@cs.cornell.edu; Thu, 18 Oct 2001 10:52:27 -0400 (EDT) Message-Id: <200110181452.f9IEqRG27019@ringding.cs.cornell.edu> Subject: 615 PAPER 29 To: egs@CS.Cornell.EDU Date: Thu, 18 Oct 2001 10:52:27 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Analysis of TCP performance over mobile ad hoc networks, G. Holland and N. Vaidya. Reviewer: Indranil Gupta This paper presents simulation results to show that the original implementation of TCP for wired networks, performs badly in wireless ad-hoc networks. The message throughput obtained by running TCP is much below the best achievable. The primary cause of this is that TCP treats link breakages as congestion, and the resulting filling up of the message buffer window and exponential decrease kills the throughput. This behavior is further amplified if stale (cached) routes are used to reroute messages (or acknowledgments) at intermediate nodes on the path (as in DSR, the routing protocol used in the paper's simulations). In general, with increasing node mobility, TCP throughput falls. The authors present a scenario where an increase in node speed actually increases throughput; this does not seem to be explained in the paper (at all ?). The authors find that the factors that might improve the performance of TCP in such an environment are a) lack of caching that might lead to stale routes, and b) use of explicit TCP feedback. Comments: - Figure 1 shows that TCP throughput decreases (almost) exponentially with increasing path length. Why does this happen - is it because of rising rate of link breakages, or a window-size limitation ? If the latter, can the TCP window size be adjusted to the path length (proportionally) to provide stable throughput at different path lengths, in the absence of link breakages ? - Does TCP have a fundamental limitation over a wireless link (because the link bandwidth vary at a much higher rate than a wired link). Or could TCP be 'hacked' to correct these errors ? - The TCP window size increase-decrease algorithm could potentially be modified so that it tolerates up to K (say 3) link failures at a time, guaranteeing smooth message arrival rate with up to K broken links in the current route. Another alternative is to have TCP throughput degrade with a rising number of link breakages. - TCP over wireless ad hoc networks seems to have an extremely 'bursty' message arrival. A lot of applications require a steady message throughput, in spite of topology changes. Could one design a more 'benign' TCP that has a low average throughput, but a smoother variation in message arrival rates ? (In fact, disabling caching has an effect similar to this.) - The author's experiments show that disabling caching increases TCP throughput. Will TCP perform well over other ad-hoc routing protocols that do not use caching of routes ? From avneesh@csl.cornell.edu Thu Oct 18 11:56:47 2001 Return-Path: Received: from capricorn.ds.csl.cornell.edu (capricorn.csl.cornell.edu [132.236.71.92]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IFulo10769 for ; Thu, 18 Oct 2001 11:56:47 -0400 (EDT) Subject: 615 Paper 29 Date: Thu, 18 Oct 2001 11:57:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <97C142C1212ED545B0023A177F5349C405666E@capricorn.ds.csl.cornell.edu> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-TNEF-Correlator: Thread-Topic: 615 Paper 29 Thread-Index: AcFX7Z6DZ7npyXZjTRS8OYSAOs3iGw== From: "Avneesh Bhatnagar" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f9IFulo10769 Analysis of TCP performance over Mobile Ad Hoc Networks Summary/Critique This paper focuses and determining the effect that node mobility may have over the TCP protocol. The study shows the interaction between TCP and a adhoc routing protocol such as DSR. Other issues such as the inadequacy of the Address Resolution Protocol (ARP) over the MAC layer, are highlighted, showing that the simulated implementation of ARP needs to be modified to improve the TCP throughput. The emphasis is on analyzing mobility induced instability, and the performance metric used is TCP throughput. The main problem that occurs when a link breaks is that, the TCP sender assumes a congested link, and reduces its congestion window, which means that the number of bytes to be send by the sender would be reduced. This is of course detrimental to the overall throughout of the protocol, since two things are going to happen simultaneously: TCP will back off, increasing its RTO, and the underlying DSR will back off if it is not able to find a route in the mean time. So while the congestion window will continually decrease, even when a new route is found, it would take some time for the throughput to be restored according to the TCP algorithm (e.g. if we were to use a mechanism such as the Jacobson's slow start algorithm). The throughput however, might never reach its expected value, since it may happen that the new link may also break due to node movement. The problem goes further since now the TCP retransmission time depends on the backoff time of DSR, so it might happen that TCP backs off more than required. This might also explain the near exponential looking decrease in the TCP throughput in Fig. 1. In order to simulate the throughput, the authors use the means of expected throughput, which employs a weighted average. The throughput itself is measured as a function of the amount of data that has been acknowledged to the sender. The authors simulate a fairly simplistic model over varying node speeds. There is a particular case where the throughput increases as the node speed increases. I am not quite sure that I understand the reason (any?) given in this paper. It seemed to me that the reason was because of a particular simulation pattern, where the hops changed so that throughput became better, but I don't see why it was a TCP issue. The ways in which this problem can be solved are: a. Use of an explicit ICMP mechanism. b. Piggy back notice on routing message (simulated). The authors use the latter mechanism and have an Explicit Link Failure Notification which sends the underlying TCP into standby mode. Packet probing is used to find out if a route is established. There are some good simulation results indicating the detrimental effects of a large probe interval. However a smaller probe interval might not be great either. The function chosen needs to involve an RTT factor. In any case the introduction of ELFN does improve the performance. Final Comments: a.TCP performance in an adhoc setting has been simulated, but it seems that the topology and mobility patterns chosen are too simplistic to derive a definite conclusion that what changes the authors suggested might solve all problems. However it must be said that within the realm of their discussion, the authors have provided a lot of simulation results. b.The authors simulate a non-cached behavior of DSR, and find better performance. Was this just a protocol specific issue? How would a reactive protocol, which has a good semantic for finding routes in a shorter amount of time perform? An idea: I think that some more tweaking could be done by keeping into account the history of the throughput change, and modify the TCP congestion window based on the 'expected' decrease in throughput, so that when link failures actually occur, we don't get a sharp decrease in throughput, but actually a gradual degradation. From jcb35@cornell.edu Thu Oct 18 12:02:14 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IG2Do11772 for ; Thu, 18 Oct 2001 12:02:13 -0400 (EDT) Received: from localhost.localdomain (syr-66-66-30-147.twcny.rr.com [66.66.30.147]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA02704 for ; Thu, 18 Oct 2001 12:02:11 -0400 (EDT) Received: from localhost (john@localhost) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f9IG31A06181 for ; Thu, 18 Oct 2001 12:03:01 -0400 Date: Thu, 18 Oct 2001 12:03:00 -0400 (EDT) From: "John C. Bicket" To: egs@CS.Cornell.EDU Subject: 615 PAPER 29 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This paper presents an analysis of TCP performance over ad-hoc networks. Specifically, they identify what effect ad-hoc networks topology and mobility models have on throughput and congestion in tcp. The paper seeks to address the fundamental issue that TCP does not distinguish between congestion and link failure when run over an ad-hoc network. Because a mobile node will cause many link failures, a tcp session may grind to a halt when one of the nodes starts moving, and the session will fail to pick up speed when a route will stabilize. This paper ran its simulations using DSR. They also use a random way point mobility model, where each node picks a random destination and speed and moves until it gets there. Once it gets there, it picks another destination and begins moving again. The paper coins a term "expected throughput", where they take a static chain of n nodes and see what the throughput is from one end to another. They compare the results of their experiments with this metric. In the first set of simulations, they present the measured throughput and compare it against what the expected throughput should be for fifty different patterns (initial placement of the nodes) with the same mobility pattern. Their results indicated that actual throughput initially decreases with speed, but then it has the odd property that, for certain mobility patterns, the throughput increase. They attributed this property to stale routes and these routes becoming active through packet salvaging. The also found that for some scenarios, throughput is surprisingly low due to partitioning and stale routes. To alleviate some of these problems, the authors present the idea of using Explicit Link Failure Notification by using some sort of ICMP host unreachable message. This would allow a node to "suspend" a tcp session so that tcp can disable congestion control until the link is brought back up. The idea is that this will increase throughput by distinguishing between congestion and link failure. The present convincing evidence that this has a significant positive effect on tcp throughput. comments: - I would like to see this analysis done over other routing protocols - it seemed that some of the problems that stale routes and packet salvaging caused might be protocol related might be absent in another protocol. Specifically, it would be interesting to see this analysis on associativity-based routing protocols, which gives preferences to stable route. - they mention that the expect their results to be similar for congested networks - I would be very curious and I don't think that conclusion is a trivial one. - I'm not sure their "expected throughput" was a great measure, but it at least gave an upper bound for route capacities. From ramasv@CS.Cornell.EDU Thu Oct 18 12:05:31 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IG5Uo12227 for ; Thu, 18 Oct 2001 12:05:30 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: cs615 PAPER 29 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 18 Oct 2001 10:55:08 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7CE71@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 29 Thread-Index: AcFX5OFqAbg1AcWJTUarxcHsOySoQA== From: "Venu Ramasubramanian" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f9IG5Uo12227 Analysis of TCP Performance over Mobile Ad Hoc Network This paper is perhaps the first study of the performance of higher layer protocols in ad hoc networks. This study bring out two main problems. The unsuitability of an end-end mechanism like TCP to work in an ad-hoc network with no assumptions whatsoever of the nature of the network. The unsuitability of routing protocols like DSR to provide a transparent abstraction to the higher layers to enable them function in an ad hoc network without major alterations. This problem has been brought forth clearly by simulations run with identical mobility scenarios at different speeds and studying the detailed time variant activities of a single TCP connection in each scenario. TCP is a reliable connection oriented end-end transport mechanism. TCP controls congestion by adapting the size of the send window based on routd trip time and receipt of acknowledgements. It does so assuming that congestion is the predominant source of packet loss in the network. TCP is known to face throughout problems even in wireline network scenarions that violate this assumption. In ad hoc networks however link breakage due to mobility causes frequent changes in the routes and this problem is further increased by use of reactive routing protocol (DSR) that does not repair link breakages until a packet is actually lost due to that. This paper shows that TCP throughput decreases significantly because of this. They also propose a mechanism (ELFN) that disables TCP congestion control whenever a link breakage affecting this route is detected. This mechanism does help but its real significance will be clear only if simulations with several concurrent TCP sessions is conducted. The paper also identifies in detail problems associated with DSR. Caching of stale routes, route replies by intermediate node based on cache and completely reactive link repair strategy puts DSR in a bad light. DSR only attempts link repair when a packet actually is dropped across it. While this might be OK for data packets, it is detrimental when control packets of higher layer protocols (such as TCP ACK) are dropped. These problem with DSR also surface with an even greater impact for routing in the presence of asymmetric links. There are several goods in this paper. The most important of which is the detailed analysis of TCP over DSR with time variant statistics. The definition of a metric called expected throughput is also very relevant and makes studying and understanding very easy. It would have been more useful to have several concurrent TCP connections at the same time. One of my suggestions towards TCP congestion control is that the length of the route (number of hops) may be used for setting the window size. I think this might produce a much better throughput response from TCP upon link breakages. From ranveer@CS.Cornell.EDU Thu Oct 18 12:05:32 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IG5Vo12254 for ; Thu, 18 Oct 2001 12:05:32 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: 615 PAPER 29 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 18 Oct 2001 10:23:55 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D430213A7AB@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 29 Thread-Index: AcFX4ITsuKJ4phUAT3mmj5oqz/PR2w== From: "Ranveer Chandra" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sundial.cs.cornell.edu id f9IG5Vo12254 Analysis of TCP Performance over Mobile Ad Hoc Networks This paper shows the poor performance of TCP with respect to mobility in mobile ad hoc networks. Movement of nodes results in link breakages and so confuses TCP to think it as a congestion. TCP responds to congestion by changing the window size, and this is followed by a slow start mechanism. This overhead is high and results in low throughput when used over ad hoc networks. In this paper, TCP is simulated over DSR as the routing protocol and 802.11 as the MAC. Interesting features of TCP are shown and described. The paper then proposes a simple scheme to notify TCP of link breakages, to solve the confusion. This modification results in some improvement. The paper is a good attempt to show the deficiencies of TCP for ad hoc networks. The confusion in TCP between a link break and congestion is bound to occur in ad hoc networks and a fix is necessarily required. ELFN is one strategy which seems to work well. However, a number of problems seem to come from DSR, the underlying routing protocol. In fact more problems could be because of 802.11, which was shown in a journal paper as not being suited for mobile ad hoc networks, and its affect on TCP was shown. So, it seems that either all the layers will have to be rewritten or at least designed with the others in mind. An independent approach for all layers will delay the realization of ad hoc networks. From viran@csl.cornell.edu Thu Oct 18 12:07:27 2001 Return-Path: Received: from moore.csl.cornell.edu (moore.csl.cornell.edu [132.236.71.83]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IG7Ro12815 for ; Thu, 18 Oct 2001 12:07:27 -0400 (EDT) Received: from localhost (viran@localhost) by moore.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id f9IG7Lu85829 for ; Thu, 18 Oct 2001 12:07:21 -0400 (EDT) (envelope-from viran@moore.csl.cornell.edu) X-Authentication-Warning: moore.csl.cornell.edu: viran owned process doing -bs Date: Thu, 18 Oct 2001 12:07:21 -0400 (EDT) From: "Virantha N. Ekanayake" To: Subject: 615 PAPER 29 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Analysis of TCP Performance over MANETs This paper studies TCP throughput numbers for ad-hoc networks utilizing DSR. They show that node movement affects the TCP transmission rate significantly (since a link breakage is considered no different to congestion) with TCP exponentially backing off the retransmission for link breakage, when in fact the backoff is not necessary. They also introduce a new metric to judge how good an observed throughput is by introducing a theoretical maximum for the ad-hoc network called the expected throughput. To mitigate the TCP stalls due to linkage errors, they introduce an error notification (ELFN) to the TCP sender that turns off the retransmission timer, and probes the network until the route is reestablished. Overall, this paper was very well written, it attempted to explain all the observations clearly, and did not try to sweep certain shortcomings under the rug. Although the simulation methodology was simple (30 nodes) they did do something different in using a rectangular area. They also used 50 fixed randomly generated initial patterns and ran the experiments using these patterns, which approach differs from many other papers where there was no repeatability possible. An interesting outcome was that DSR without route caches yielded a much better TCP throughput (due to the avoidance of caching and propagating stale routes, and thereby yielding dropped packets). However, as they point out, this system only had one data traffic path, and the results may be different for a more realistic network. The ELFN approach was interesting, and it did increase the throughput. It seems like more inter-layer communication could also yield benefits by informing the TCP layer when a route has been established. From andre@CS.Cornell.EDU Thu Oct 18 12:32:30 2001 Return-Path: Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IGWTo15865 for ; Thu, 18 Oct 2001 12:32:29 -0400 (EDT) Received: from khaffy (mail@dhcp99-178.cs.cornell.edu [128.84.99.178]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id f9IGWTi04488 for ; Thu, 18 Oct 2001 12:32:29 -0400 (EDT) Received: from andre by khaffy with local (Exim 3.32 #1 (Debian)) id 15uGq8-0003h1-00 for ; Thu, 18 Oct 2001 12:20:16 -0500 Date: Thu, 18 Oct 2001 12:20:16 -0500 From: =?iso-8859-1?Q?Andr=E9?= Allavena To: egs@CS.Cornell.EDU Subject: 615 PAPER # 29 Message-ID: <20011018122016.B14074@khaffy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.22i Sender: =?iso-8859-1?Q?Andr=E9_Allavena?= Analysis of TCP performance This analysis is done using the DSR routing protocol, and evaluates the performance (here there throughput) of TCP over a set of mobil hosts. In general, the faster the evenements happen, the less throughput. There are two concerns: TCP doesn't really understand that a route is broken (it takes it to be a congestion notification), and DSR tends to use stale routes when reconstructiong a broken route. This paper suggests to modify TCP to add a proper notification of broken routes, then send a packet at a time (and wait for an ack) to test the validity of the new route. I think thenotification is a good idea and will improve performances over other routing protocols. Testing the correctness of the new route at the TCP level seems odd, I would say it is part of the routing pprotocol itself. First it shouldn't use stale route when reconstructiong (AODV or DSDV don't). If the routing protocol can still provide incorrect routes, then why develop the interaction between the routing protocol and the upper layer. TCP would stop upon a route failure notification, and sort of consider that the following TCP packet to be sent is used by the routing protocol to check the validity of the route. If no ack is receive, the routing protocol tries again. If an ack is received, then the upper level is notified and TCP can start again. If the previous means lots of modification of the upper levels, then just make part of the routing protocol a probe of the choosen route. -- André Allavena (local) 154 A Valentine Place École Centrale Paris (France) Ithaca NY 14850 USA Cornell University (NY) (permanent) 879 Route de Beausoleil PhD in Computer Science 06320 La Turbie FRANCE From samar@ece.cornell.edu Thu Oct 18 12:35:59 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9IGZxo15972 for ; Thu, 18 Oct 2001 12:35:59 -0400 (EDT) Received: from descartes (descartes.ee.cornell.edu [128.84.236.60]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f9IGZWQ17876 for ; Thu, 18 Oct 2001 12:35:32 -0400 Date: Thu, 18 Oct 2001 12:35:37 -0400 (EDT) From: Prince Samar X-Sender: samar@descartes.ee.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 29 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 29) Analysis of TCP performance over Mobile Ad hoc Networks This paper is probably one of the earliest studies of the interaction of the higher layers with routing in ad hoc networks. The paper analyzes, through simulation, the performance of regular TCP for communication over mobile ad hoc networks and suggests a few possible ways that might lead to better performance. It is found that the throughput drops significantly due to link breakages resulting from mobility. The reason for this is that TCP fails to recognize the difference between link failure and congestion, treating the two similarly. The authors bound the actual throughput with "expected throughput". To obtain the expected throughput, the throughput (as a function of the number of hops n) obtained over a static network of n nodes that form a linear chain containing n-1 hops is measured. The average of these throughputs, weighted by the fraction of total simulation time that the route between these nodes is of n hops, is defined as the expected throughput. The simulation results show that some mobility patterns yield very low throughput. This is essentially because TCP is unable to receive acknowledgments due to link failure, use of stale routes and inability to distinguish between congestion and link failure. Also, for some mobility pattern, throughput may increase when the velocity is increased. The particular characteristics have a significant effect on the TCP performance and this paper brings out a very important point that routing protocols should be designed based on the requirements of the upper layers. Caching and propagation of stale routes (problems with DSR) could lead to worse performance. The paper also demonstarted an interesting point that data flow across the TCP flow is maintained across the TCP flow is paths are shortened but is lost if path is enlongated. Another problem that was demonstrated was that of route request time-out and exponential back off. The use of Explicit Link Failure Notification (ELFN) to TCP was found be an effective way of mitigating some of these effects. Essentailly, when TCP receives the ELFN message, it goes into a stand-by node, periodically probing the network to see if a route has been estabilished. The throughput is found to be dependent of the time between these probe packets. The authors looked into some intuitive ways to improve to performance of TCP over MANETs. A more thorough study needs to be performed to study the effect of varying the different parameters, using other routing protocols and changing some of the algorithms (eg. TCP window increase-decrease algorithm). A big question is whether TCP should be changed to improve the performance over MANETs or whether improvements and efficient designs of the routing protocols would do the trick. From haom@csl.cornell.edu Mon Oct 22 18:49:10 2001 Return-Path: Received: from mauchly.csl.cornell.edu (mauchly.csl.cornell.edu [132.236.71.68]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9MMnAo18573 for ; Mon, 22 Oct 2001 18:49:10 -0400 (EDT) Received: from localhost (haom@localhost) by mauchly.csl.cornell.edu (8.9.3/8.9.2) with ESMTP id SAA10419 for ; Mon, 22 Oct 2001 18:49:04 -0400 (EDT) (envelope-from haom@mauchly.csl.cornell.edu) X-Authentication-Warning: mauchly.csl.cornell.edu: haom owned process doing -bs Date: Mon, 22 Oct 2001 18:49:04 -0400 (EDT) From: Ming Hao To: egs@CS.Cornell.EDU Subject: 615 PAPER 29 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Analysis of TCP Performance over Mobile Ad Hoc Networks Gavin Holland and Nitin Vaidya the main idea of paper is that MAC layer informs the TCP layer so that TCP layer can differentiate the link failure and network congestion and thus react differently. when link failure happens, the TCP will not increase the retransmission timer and enters a stand-by mode. in this mode, node will send probe packet periodically to check if route is set up. if yes, TCP restores the previous timer and work again. this scheme avoids the increase of retransimission timer so that the node can resend packets more aggressively when route restored. the scheme works supprisingly well. in the simulation, it can increase the throughput by 30% of expected thoughput. unbelievable. the paper spent many pages showing the performance of TCP over a ad hoc network with DSR as routing algorithm in differnt moving pattern and node speed. the result complies with the intuition that link failure can results in the bad performance of TCP. in some cases, even 0 thoughput. though the idea is not totally new, it shows us a interesting field that the high level protocol, TCP, designed based on wired connection may be not appropriate for the wireless ad hoc network. this happened already when researchers changed TCP/IP for the fast system area network communication. -ming Ming Hao PH.D Candidate, EE mh97@cornell.edu Cornell University Office: (607) 255-0817 Ithaca, NY 14853 http://www.ee.cornell.edu/~haom/