TCP Westwood (TCPW) and Bandwidth Estimation cs218 – fall 2003 Claudio E. Palazzi tutor: Dr. Giovanni Pau

Outline Background: TCP and wireless environment TCP Westwood overview New bandwidth estimation algorithm Simulations results with NS-2 Conclusions

TCP Congestion Control (1/2) end-end control (no network assistance) sender limits transmission: LastByteSent-LastByteAcked  CongWin Roughly, CongWin is dynamic, function of perceived network congestion How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate ( CongWin ) after loss event two mechanisms: –AIMD –slow start rate = CongWin RTT Bytes/sec

TCP Congestion Control (2/2)

Problems Affecting Current TCP Error losses in wireless environment: –wrong congestion assumption. Random errors results in low performance: –Congestion window cut too much –If happens during slow start, cause TCP premature exits

Related TCP + Bdw estimation work TCP Vegas monitors bandwidth and RTT to infer the bottleneck backlog; then, from backlog it derives feedback to congestion window. Keshav’s Packet Pair scheme also monitors bandwidth to estimate the bottleneck backlog and compare to common target; it adjusts source rate. … TCP-Probing discriminates between error losses, congestion losses, handoffs and disconnections using probing cycles after each loss. WTCP estimates the bandwidth at the receiver considering the packets received, then calculates the new sending ratio and communicates it to the sender (SACK and no more T.O.) …

Enhance congestion control via Eligible Rate Estimate (ERE) Samples are derived from ACK arrival statistics, and info in ACKs regarding bytes delivered ERE is used by sender to set cwnd and ssthresh after packet loss indication Receiver Sender Internet Bottleneck packets ACKs measure TCP Westwood

TCP Westwood: Control After Packet Loss Indication When three duplicate ACKs are received : set ssthresh=ERE*RTTmin (instead of ssthresh=cwin/2 as in Reno and NewReno) if (cwin > ssthresh) set cwin=ssthresh When a TIMEOUT expires : set ssthresh=ERE*RTTmin (instead of ssthresh=cwnd/2 as in Reno) and set cwin=1

TCP Westwood: Eligible Rate Estimate BE Sampling : Packet pair, effective under random loss, overestimates under congestion Under Congestion Under No Congestion TkTk TkTk RE Sampling: Packet train, fair estimate under congestion, underestimates under random loss To obtain ERE: adapt the sample interval T k according to congestion level Congestion level is similar to that in Vegas: Expected Rate-Achieved Rate T k ranges from one ‘interACK’ interval to RTT

TCP Westwood and random losses Reno overreacts to random loss (cwin cut by half) TCPW less sensitive to random loss a small fraction of “randomly” lost packets minimally impacts the rate estimate RE Thus, cwin = RE x RTT remains unchanged As a result, TCPW throughput is higher than Reno and SACK But…

Current BW Estimation Weakness Principle behind Westwood (and others): BW estimation = Bytes_acked / time NOT ALWAYS CORRECT ! It doesn’t consider idle time at sender… 1 TCP Westwood Agile connection - 70 ms RTT - queue = pipesize Multiple losses caused by UDP flows which start when the queue is almost full

Rationale of the idea Time line chunked into slots Pckts departure Corresponding acks arrival Effective tx timeSender idle time Bandwidth estimation mechanism that rely on byte transmitted on time, should take into account the unused time at sender.

New BW estimation algorithm At sender side, divide time into slots In each slot, N packets are sent to destination The corresponding N acks will return back in a certain amount of time T The bandwidth computation considers also the time the sender was idle (it hasn’t sent anything because he was waiting for ACKS…) BWE sample: Slot size is computed at the starting of the new one as a multiple of the RTO Bwe sample is averaged (k less or equal than 1): BWES = Bytes_in_slot / (Time_for_acks – Time_sender_idle) BWE i = (1-k)*BWE i-1 + k*BWES

Data Structure RTT 0 RTT 1 RTT 2 RTT 3 RTT 9 Element of the array: Seq no. of first pkt tx in that rtt Seq no. of last pkt tx in that rtt Dep. time first pkt tx in that rtt Dep. time last pkt tx in that rtt Start time receiving slot Arr. time last ack rec in that rtt Every slot change element where insert new departures Every slot compute new bandwidth estimation Just after last bwe calculation

Simulation Environment 100 Mbps 1 ms delay Min RTT: 70 ms 100 Mbps 1 ms delay Bottleneck (various bw value) 33 ms delay Errors in the Bottleneck: 0 or 0.1% PER Queue = pipe size 1 flow TCP New estimator tested above Westwood Agile

Simulations 1/4 1 TCP Westwood Agile connection - 70 ms RTT - queue = pipesize Multiple losses caused by UDP flows which start when the queue is almost full new bwe: no more big drop due to idle time at sender side

Simulations 2/4 1 TCP Westwood Agile connection - 70 ms RTT - queue = pipesize Bottleneck BW = 1Mb - pipe size = 9pkts PER = 0% PER = 0.1% Slot=3RTO k_avg=0.5

Simulations 3/4 1 TCP Westwood Agile connection - 70 ms RTT - queue = pipesize Bottleneck BW = 5Mb - pipe size = 44pkts PER = 0% PER = 0.1% Slot=2RTO k_avg=0.2

Simulations 4/4 1 TCP Westwood Agile connection - 70 ms RTT - queue = pipesize Bottleneck BW = 10Mb - pipe size = 88pkts PER = 0% PER = 0.1% Slot=3RTO k_avg=0.2

Conclusions With one flow, our proposed algorithm: - provides a bandwidth estimation comparable with TCP Westwood (both with or without random errors) - detects initial available bandwidth as fast as (or faster than) AGILE does - is lighter to calculate than TCP Westwood’s formula - performs better than TCP Westwood in conditions characterized by long sender-side idle time period, as during long Fast Retransmit – Fast Recovery We think that, our algorithm: - differently than TCP Westwood, detects the total bandwidth at the bottleneck, and not the shared bandwidth - could really be effective if integrated with TCP Westwood and/or a mechanism for queue estimation

Work Done Created the new bwe_computationPP function for bwe estimation Modified tcp module in the NS-2 simulator Added tcp-westwood-nr-pp module in the NS-2 simulator Simulated various cases with different bandwidth and PER

Future Work slots and bwe-sample parameters tradeoff analysis simulate cases with more than one single flow to: - determine if the algorithm measures the bottleneck total bandwidth or the shared one. - evaluate effective integration with TCP Westwood - study efficiency vs fairness and friendlyness

Some Bibliography 1/2 [1] S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi, R. Wang, "TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links", MOBICOM 2001, July [2] R. Wang, M. Valla, M.Y. Sanadidi, and M. Gerla, "Adaptive Bandwidth Share Estimation in TCP Westwood", UCLA Technical Report, submitted to Globecom 2002 [3] M. Gerla, B. K. F. Ng, M. Y. Sanadidi, M. Valla, R. Wang, "TCP Westwood with Adaptive Bandwidth Estimation to Improve Efficiency/Friendliness Tradeoffs", to appear in Computer Communication Journal, [4] H. Balakrishnan, V. N. Padmanabhan, S. Sehan, and R. H. Katz, "A comparison of mechanism for improving TCP performance over wireless links", IEEE/ACM Trans. Networking, vol. 5, no. 6, pp , december [5] Lawrence Brakmo, Sean O'Malley, and Larry Peterson, " TCP Vegas: New Techniques for Congestion Detection and Avoidance “, ACM SIGCOMM, pages , August 1994.

Some Bibliography 2/2 [6] C. E. Palazzi, “Protocolli di Trasporto in Ambiente Wireless”, Bachelor Degree Thesis, University of Bologna, July [7] P. Sinha, N. Venkitaraman, R. Sivakumar, V. Bharghavan, "WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks", ACM Mobicom '99, August [8] V. Tsaoussidis, H. Badr, "TCP-Probing: Towards an Error Control Schema with Energy and Throughput Performance Gains", The 8th IEEE Conference on Network Protocols, November [9] S. Keshav, “Packet-Pair Flow Control", IEEE/ACM Transaction on Networking, February 1995.

Questions ?