Tema 6.- Redes inalámbricas Ad Hoc. TCP Overview of TCP The problems of TCP over MANETs Estudios realizados por el Grupo GRC Interacción Routing Protocols & TCP

Transmission Control Protocol / Internet Protocol TCP/IP Internet Protocol (IP) Packets may be delivered out-of-order Packets may be lost Packets may be duplicated Transmission Control Protocol (TCP) Provide reliable end-to-end message transmission Reliability achieved by means of retransmissions if necessary Implements congestion avoidance and control Window and ack based End-to-end semantics Acknowledgements sent to TCP sender confirm delivery of data Ack for data sent only after data has reached receiver TCP is still needed for MANETs It is widely used in the current Internet We would like to achieve a smooth integration with the fixed Internet

How TCP adapt to the network requirements? TCP Overview How TCP adapt to the network requirements? Flow Control: It regulate the number of packets it sends by inflating or deflating a window To do that TCP uses the cumulative acknowledge (ACKs) sent by the receiver It can affect the average throughput Congestion Control: It tries to solve the delay caused by packet losses due to congestion Congestion control scheme in regular (Tahoe) TCP implementation has three main phases: Slow-start Congestion Avoidance (CA) Fast Retransmit

Cumulative Acknowledge A new cumulative acknowledgement is generated only on receipt of a new in-sequence packet It ack’s all contiguously received data Duplicate Acknowledgements A dupack is generated whenever an out-of-order segment arrives at the receiver Duplicate acks may be generated when a packet is lost, or a packet is delivered out-of-order (OOO) Thanks to: Nitin Vaidya, University of Illinois at Urbana-Champaign

Window Based Flow Control Sliding window protocol Window size minimum of receiver’s advertised window determined by available buffer space at the receiver congestion window determined by the sender, based on feedback from the network

Congestion Control On detecting a packet loss, TCP sender assumes that network congestion has occurred On detecting packet loss, TCP sender drastically reduces the congestion window Reducing congestion window reduces amount of data that can be sent per RTT throughput may decrease Questions? How does TCP detect a packet loss? How Congestion Control Works? Multiple choices … TCP-Reno, TCP-Vegas, … Slow-start Congestion Avoidance (CA) Fast Retransmit

How does TCP detect a packet loss? Retransmission timeout (RTO) If acknowledgement for the timed packet is not received before timer goes off, the packet is assumed to be lost RTO dynamically calculated If (RTO = mean + 4 mean deviation)  It assume packet lost Duplicate acknowledgements Timeouts can take too long how to initiate retransmission sooner? Fast retransmit: TCP sender assumes that a packet loss has occurred if it receives three dupacks consecutively Remember: Dupacks may be generated due to packet loss, or out-of-order packet delivery

How Congestion Control Works? Overview of congestion control mechanisms Slow-start phase: cwnd start from 1 and increase exponentially It increment window size on each new ack slow start phase ends when window size reaches the slow-start threshold Congestion avoidance (CA): cwnd increase linearly

Congestion Control -- Timeout On a timeout, the congestion window is reduced to 1 The slow start threshold is set to half the window size before packet loss Slow start is initiated

Congestion Control - Fast retransmit Fast retransmit occurs when multiple (>= 3) dupacks come back Fast recovery follows fast retransmit Different from timeout: (slow start follows timeout) timeout occurs when no more packets are getting across fast retransmit occurs when a packet is lost, but latter packets get through So, no need to slow start Fast retransmit - Fast recovery Retransmit the missing segment (fast retransmit) After fast retransmit and fast recovery window size is reduced in half

Impact of Transmission Errors and Mobility on TCP TCP cannot distinguish between packet losses due to congestion and transmission errors Unnecessarily reduces congestion window Throughput suffers There are to many schemes in the literature to Improve Performance of TCP in Presence of Transmission Errors and mobility based on: Retransmit a packet lost due to transmission errors, without taking any congestion control actions Transmission errors should be hidden from the sender -- the errors should be recovered transparently and efficiently Hide mobility from the TCP sender Make TCP adaptive to mobility In MANET : Issues in multi-hop wireless networks

TCP in Mobile Ad Hoc Networks Issues Effects of long partition on TCP Effects of mobility on TCP MAC layer impacts on TCP Network layer impacts on TCP Out-of-Order Packet Delivery

Effects of long partition on TCP Problems due to partitions After a packet lost is detected due to timeout TCP retransmits the lost packet and doubles its RTO (Retransmission timeout up to 64 s) What happens if the partition disappears? Dead time.

Effects of mobility on TCP Throughput generally degrades with increasing speed … But not always

Why Does Throughput Improve? Low Speed Scenario Route from A to D is broken for ~1.5 second. When TCP sender times after 1 second, route still broken. TCP times out after another 2 seconds, and only then resumes. Higher Speed Scenario Route from A to D is broken for ~ 0.75 second. When TCP sender times after 1 second, route is repaired. TCP timeout interval somewhat (not entirely) independent of speed Network state at higher speed, when timeout occurs, may be more favorable than at lower speed

MAC layer impacts on TCP MAC layer problems (hidden node and exposed node) can seriously hurt the TCP performance Hidden and exposed nodes can cause lack of ACKs at the TCP sender. This will either: Trigger a TCP retransmission by timeout Impact the TCP fast retransmission The more number of hops  the lower the expected throughput

Network layer impacts on TCP Problems with approaches using caches Route caching has been suggested as a mechanism to reduce route discovery overhead  DSR Each node may cache one or more routes to a given destination Generally: When a route from S to D is detected as broken, node S may: Use another cached route from local cache, or Obtain a new route using cached route at another node Unless the stale route can be detected and recovery in a fast way, TCP can be led to backoff state, which will deteriorate its performance critically. Not using caching: tradeoff Routing overhead vs route accuracy  TCP Caching can reduce overhead of route discovery But if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs

Why Performance Degrades With Caching Caching can result in faster route “repair” Faster does not necessarily mean correct When a route is broken, route discovery returns a cached route from local cache or from a nearby node After a time-out, TCP sender transmits a packet on the new route. However, the cached route has also broken after it was cached Another route discovery, and TCP time-out interval Process repeats until a good route is found timeout due to route failure timeout, cached route is broken timeout, second cached route also broken

Network layer impacts on TCP Problems with approaches using multiple paths ¿Why using multiple path? Problem with TCP: Out of order packets  Retransmission of packets Some approaches try to use a self-adaptive mechanism to avoid new packets using shorter paths. Problems with PATH asymmetry Asymmetrical path can seriously affect TCP performance If TCP can not receive timely ACKs it can not expand the CWND to make use of the full capacity of the channel Bandwidth asymmetry, Loss rate asymmetry, Media access asymmetry, Route asymmetry Asymmetry can also induce inaccuracy on RTT estimation. Some solutions: Try to reduce the number of ACKs in the backward path  Delayed Acknowledgements Since ACKs are cumulative

Delayed Acknowledgements An ack is delayed until another packet is received, or delayed ack timer expires (200 ms typical) Reduces ack traffic New ack not produced on receipt of packet 36, but on receipt of 37 40 39 38 37 33 35 41 40 39 38 35 37

Out-of-Order Packet Delivery Route changes may result in out-of-order (OOO) delivery Significantly OOO delivery confuses TCP, triggering fast retransmit Potential solutions: Avoid OOO delivery by ordering packets before delivering to IP layer can result in variable delay turn off fast retransmit can result in poor performance in presence of congestion

Other TCP issues Window Size After Route Repair RTO After Route Repair Same as before route break: may be too optimistic Same as startup: may be too conservative RTO After Route Repair Same as before route break If new route long, this RTO may be too small, leading to timeouts Same as TCP start-up (6 second) May be too large Will result in slow response to future losses Proposals: new RTO = function of old RTO, old route length, and new route length MAC Delay variability Large and variable delays result in larger RTO On packet loss, timeout takes much longer to occur Idle source (waiting for timeout to occur)

TCP for Mobile Ad Hoc Networks Much work on routing in ad hoc networks Some work on TCP for ad hoc networks TCP variants Non TCP variants They try to avoid the exponential backoff mechanism when losses take place by factors others than congestion However other factors should also be considered Path asymmetry, cross layer impact? Need to investigate many issues MAC-TCP interaction Routing-TCP interaction Impact of route changes on window size, RTO choice after move Power management, cross-layer, interoperation, security

Propuestas del Grupo GRC Objective: To find the more suitable TCP variants for MANET has increased First trial to extensively compare the two TCPs over AODV and OLSR Dongkyun Kim, Juan-Carlos Cano, Pietro Manzoni, C.K. Toh, "A comparison of the performance of TCP-Reno and TCP-Vegas over MANETs", Third IEEE International Symposium on Wireless Communication Systems (ISWCS), 5-8 of September 2006, Valencia (Spain).

Most widely used TCP variant TCP-Reno Most widely used TCP variant Slow Start, Congestion Avoidance, Fast Recovery Packet loss cwnd time Slow Start Congestion Avoidance Timeout Slow Start

Trying to alleviate TCP’s oscillation. TCP-Vegas Trying to alleviate TCP’s oscillation. Estimating available bandwidth based on the difference between expected and actual flows rates. Upon an ack arrivals: Expected = CWND/BaseRTT Actual = CWND/ActualRTT Diff = (Expected – Actual) BaseRTT CWND + 1 if Diff <  CWND = CWND – 1 if Diff >  CWND otherwise

2 Mbps Wireless LAN (CSMA/CA) Simulation Simulation tool : NS-2 Simulation environment Application Protocol FTP Transport Protocol TCP-Reno, TCP-Vegas Routing Protocol AODV, OLSR MAC Protocol 2 Mbps Wireless LAN (CSMA/CA) Terrain Dimensions 1000×1000 Number of Nodes 50 Mobility Random waypoint

Simulation Results Performance Comparison of TCP-Reno over AODV and OLSR A long latency of route discovery due to route breakage in AODV TCP Sender experiences many timeout events Reduce its CWND However, OLSR forces a node with changed link topology to promptly flood the change Every node using OLSR finds another next-hop quickly Continues transmitting its TCP segments before a timeout event occurs Pause time = 0 Pause time = 20

Simulation Results (con’t) The OLSR reduces the dropping of the contention window size

Simulation Results (con’t) Also: TCP throughput decreases as the hop distance between source and destination nodes increase OLSR obtains easily the shortest path Each node can view the network topology AODV cannot guarantee the usage of shortest path An RREP corresponding to the RREQ which has reached the receiver earliest is simply sent

Simulation Results (con’t) Performance Comparison of TCP-Vegas over AODV and OLSR Similar results Pause time = 0 Pause time = 20

Simulation Results (con’t) Performance Comparison of TCP-Reno and TCP-Vegas over AODV (Sometimes we do not have the implementation of a required routing protocol) TCP-Reno aggressively increase its CWND Unnecessary increase of window size causes much contention on the shared channel Occurrences of unnecessary route discovery caused by “hidden node problem” Pause time = 0 Pause time = 20

Simulation Results (con’t) Performance Comparison of TCP-Reno and TCP-Vegas over OLSR Pause time = 0 Pause time = 20

Simulation Results (con’t) Sending rate of a source using TCP-Vegas Determined according to the difference between expected throughput and actual throughput If TCP-Vegas begins using a new route due to node mobility Its base RTT is not a new base RTT, but the base RTT over the old route Inaccuracy results in performance degradation AODV Adheres to the same route until the route is broken OLSR Link change triggers node to update their routing tables, which allows another route to be selected The frequent change of route causes the inaccuracy of base RTT to be exaggerated.

Conclusions TCP is not the most appropriate protocol for MANETs, TCP will be on top of the routing protocol irrespective of TCP Variants In summary, from the view of throughput OLSR is the best routing protocol irrespective of TCP variants TCP-Vegas performs better for AODV TCP-Reno is more suitable for OLSR we found that which to select among routing protocols is more important than which to select among TCP variants