ATP: A Reliable Transport Protocol for Ad-hoc Networks Sundaresan, Anantharam, Hseih, Sivakumar 1 TCP in MANET TCP performance degrades significantly in MANET – – Some approaches as TCP variation to alleviate the performance degradation – – – Use cross layer notifications to report route failure TCP-ELFN: Explicit Link Failure Notification TCP-EPLN&BEAD The authors have more to say: – 2 TCP assumes the packet losses as an indication of network congestion. But link failures due to mobility are the primary reason for most of packet losses. TCP mechanisms are fundamentally inappropriate for adhoc networks Outline TCP in mobile ad-hoc networks and drawbacks ATP (Ad-hoc Transport Protocol) Performance evaluation – 3 TCP, TCP-ELFN, ATP Conclusions Reliable Transportation in TCP (1) 4 Window based transmission Slow-start Loss based congestion detection Linear increase multiplicative decrease Dependence on Acks Reliable Transportation in TCP (2) Window Based Transmissions – Flow control: rwind How many more packets can the receiver handle? – Congestion control: cwind How many more packets can the network handle? – 5 Sending rate is determined by min( rwind, cwind ) Window Based Transmissions Burstiness Leads to burstiness Bunch of ACKs arrive together is quite common in MANET – – Short-term unfairness of the CSMA/CA mechanism Burstiness: bunch of ACKs trigger bunch of packets in a very short period. Why is burstiness bad? – Varying round-trip time estimates cause RTO inflation – 6 Potentially leads to delayed loss recovery Bursty transmissions can result in higher contention at MAC layer; pose a problem especially under the heavy-load conditions Burstiness in RTT measurements The value of RTT changes dramatically. 7 Slow Start Exponential growth to available capacity – Slow start is not a serious problem for wireline network – It takes several RTT periods to reach available bandwidth associations are expected in the congestion avoidance phase for most of the time. Not good for wireless ad hoc network Due to the dynamic nature of ad hoc network frequent packet losses → frequent timeouts → more slow start phases Again, packet loss does not necessarily mean congestion. – During the lifetime of an association, considerable amount of time is spent in slow start phase – Under-utilization of network resources – 8 Time spent in Slow-Start phase 1. The time spent in Slow-Start increases with the increasing of the mobility. 2. The proportion of time goes above 50% for the higher load 50% situation. Average time in Slow-Start phase. Total simulation time: 100s TCP New Reno 9 3. The connections spend a large portion of the lifetime probing for the available bandwidth. Loss Based Congestion Indication TCP detects congestion through the occurrence of losses – – 10 Either three duplicate ACKs or a timeout Congestion is by far the main source of packet losses in wireline network. Losses in ad-hoc networks can occur due to either congestion or route failures Loss on wireless links means try harder, loss on wired means backoff Losses due to route failure 50% Significant portion of losses “perceived” to be due to route failures 11 Multiplicative Decrease Multiplicative decrease on congestion window when TCP detects congestion In MANET, losses can happen by route failure – – TCP-ELFN freezes the TCP sender while a new route is being calculated, but still uses the old congestion windows state after freezing – 12 A new route might be used instead Slow start to reach available bandwidth Congestion window state for previous route is not appropriate for the new route Dependence on ACKs TCP relies on ACK very much – – 13 The acknowledgement of the correct receiving. The progression of its congestion window Acks can amount to 10-20% of data stream rate Large volume of ACKs introduces more contention in MAC layer if the same path is used as reverse path. Large volume of ACKs increases the probability of experiencing route failures (loss of ACKs) if different path is used. Outline TCP in mobile ad-hoc networks and drawbacks ATP (Ad-hoc Transport Protocol) Performance evaluations – 14 TCP, TCP-ELFN, ATP Conclusions Key design elements of ATP Cross layer coordination Rate based transmissions – 15 This is the core of ATP Decoupled congestion control and reliability Layer Coordination Similar to TCP-ELFN – ATP uses layer coordination for – – 16 Utilize explicit feedback from intermediate nodes. Path failure notification Initiating a sending-rate estimation for the new route Rate based transmissions What is rate based transmission – Transmit fixed size of data in each time interval. – Use timer to clock the new data, not the sending window Avoids drawbacks due to burstiness The need for self-clocking by the arrival of ACKs is eliminated – 17 GSM example, 260bits from speech codec in every 20ms Allows decoupling of congestion control mechanism from the reliability mechanism Timer granularity in low bandwidth MANETS large enough to be realized without significant overheads Decoupling of Congestion Control & Reliability For congestion control: – – – For reliability: – – 18 Intermediate nodes provide the feedback of available rate. The feedback is piggybacked on forward path and sent back from receiver to sender. The sender adjusts the sending rate accordingly. The receiver uses SACK to report any new holes in the data stream. Only use SACK, no cumulative ACK Detailed ATP 19 ATP Intermediate Node ATP Receiver ATP Sender ATP Intermediate Node (1) Two parameters are measured – – – – Qt , the average queuing delay per packet at the node itself Tt , the average transmission delay at the node’s transmitter Qt and Tt are maintained on a per-node basis Update after every instantaneous measurement Qt Qt (1 ) Qsample Tt Tt (1 ) Tsample – 20 D = Qt +Tt , the total delay at current node, 1/D is the rate that the current node can handle. ATP Intermediate Node (2) ATP header has an additional field other than TCP header: the rate feedback D Update the D in each outgoing packet Di Source Di-1 Node i Destination Node i+1 Node i-1 Di (Qt Tt )i if (Qt Tt )i Di 1 if (Qt Tt )i Di 1 Di Di 1 Max Delay 21 ATP Receiver (1) The receiver provides periodic feedback to the sender for reliability and congestion control purpose – Feedback is triggered by an epoch timer of period E Congestion & Flow Control feedback – Calculate the average delay for one flow Davg Davg (1 ) D – – 22 Application reading rate Rapp --- flow control Send rate feedback to the sender Davg if Davg 1/ Rapp The value of feedback otherwise 1/ Rapp ATP Receiver (2) Reliability feedback – – – 23 Selective ACKs Send out periodically to the sender Contain at most 20 SACK blocks in every feedback packet (report 20 holes in the received data stream). ATP Sender (1) Quick Start – – – – Send a probe packet to the receiver in order to get back the initial sending rate After rate feedback comes back, the sender adjusts the sending rate accordingly. The sender reaches available rate after 1 RTT. Quick-start is performed both during 24 Associate establishment New path takes place of the original path due to link failures. ATP Sender (2) Congestion Control – – Three phases: (rate) increase phase, decrease phase, maintain phase Update the sending rate S RS S S k SR unchange 25 if S R S else if S R otherwise R : the new feedback rate; Φ : a small constant used to prevent fluctuations; k : a scale to reduce the increasing amount since increasing 1 pkt per sec in upper layer can introduce more control pkts in MAC layer. ATP Sender (3) In case of the loss of feedback packets – – Reliability: Process the SACK information – – 26 Multiplicative decrease of sending rate if feedback does not appear in every epoch time If no feedback till the end of the third epoch, send a probe packet to the receiver Mark the packets for retransmission accordingly. Data for retransmission have higher preference than new data. Performance Evaluation Simulation environment – – – ns2 simulator 1000m*1000m square, 100 nodes Random way point mobility with 3 speeds 1 m/s, – – – – – 27 10 m/s, 20 m/s DSR routing IEEE802.11b MAC Network load: 1 flow, 5 flows and 25 flows, resp. Packet size: 512 bytes Epoch time: 1 sec Congestion window/rate progression vs. time (1 flow) Route failure Default TCP 28 TCP-ELFN ATP Congestion window/rate progression vs. time (25 flow) Default TCP 29 TCP-ELFN ATP Reasoning 30 ATP does not decrease its rate on route failures unless dicated by the rate feedback mechanism Owing to quick-start, it quickly catches upto the available bandwidth Once it reaches avalable capacity, it maintains a steady rate Throughput vs. Mobility ATP TCP ELFN TCP default 5 flows 25 flows It would be interesting to see the comparison between ATP and TCPEPLN&BEAD. 31 Conclusions TCP not appropriate for MANETs ATP looks promising – – – – – 32 Rate based transmissions Quick start Decoupling of congestion control and reliability Layer coordination Avoid use of retransmission timeouts What about VANETs?
© Copyright 2026 Paperzz