TCP Westwood (TCPW) and Bandwidth Estimation cs218

1
TCP Westwood (TCPW) and Bandwidth
Estimationcs218 fall 2003Claudio E.
Palazzitutor Dr. Giovanni Pau
2
Outline

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

3
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

4
TCP Congestion Control (2/2)
5
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

6
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.
• Keshavs 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.)

7
TCP Westwood

• 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

8
TCP Westwood Control After Packet Loss
Indication

• When three duplicate ACKs are received
• set ssthreshERERTTmin (instead of
  ssthreshcwin/2 as in Reno and NewReno)
• if (cwin gt ssthresh) set cwinssthresh
• When a TIMEOUT expires
• set ssthreshERERTTmin (instead of
  ssthreshcwnd/2 as in Reno) and
• set cwin1

9
TCP Westwood Eligible Rate Estimate

• BE Sampling
• Packet pair,
• effective under random loss, overestimates
  under congestion

RE Sampling Packet train, fair estimate
under congestion, underestimates under random
loss
Under Congestion
Under No Congestion

• To obtain ERE adapt the sample interval Tk
  according to congestion level
• Congestion level is similar to that in Vegas
  Expected Rate-Achieved Rate
• Tk ranges from one interACK interval to
  RTT

10
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
11
Current BW Estimation Weakness

• Principle behind Westwood (and others) BW
  estimation Bytes_acked / time
• NOT ALWAYS CORRECT ! It doesnt 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
12
Rationale of the idea
Pckts departure
Time line chunked into slots
Corresponding acks arrival
Bandwidth estimation mechanism that rely on byte
transmitted on time, should take into account the
unused time at sender.
Effective tx time
Sender idle time
13
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 hasnt 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)
BWEi (1-k)BWEi-1 kBWES
14
Data Structure
RTT 0
Just after last bwe calculation
RTT 1
Element of the array
RTT 2
Arr. time last ack rec in that rtt
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
RTT 3

• Every slot change element where insert new
  departures
• Every slot compute new bandwidth estimation

RTT 9
15
Simulation Environment
Min RTT 70 ms
Bottleneck (various bw value)33 ms delay
100 Mbps1 ms delay
100 Mbps1 ms delay
Errors in the Bottleneck 0 or 0.1 PER Queue
pipe size 1 flow TCP New estimator tested above
Westwood Agile
16
Simulations 1/4
new bwe no more big drop due to idle time at
sender side
1 TCP Westwood Agile connection - 70 ms
RTT - queue pipesize Multiple losses
caused by UDP flows which start when the queue is
almost full
17
Simulations 2/4
Slot3RTO k_avg0.5
PER 0
PER 0.1
1 TCP Westwood Agile connection - 70 ms
RTT - queue pipesize Bottleneck BW
1Mb - pipe size 9pkts
18
Simulations 3/4
Slot2RTO k_avg0.2
PER 0
PER 0.1
1 TCP Westwood Agile connection - 70 ms
RTT - queue pipesize Bottleneck BW
5Mb - pipe size 44pkts
19
Simulations 4/4
Slot3RTO k_avg0.2
PER 0
PER 0.1
1 TCP Westwood Agile connection - 70 ms
RTT - queue pipesize Bottleneck BW
10Mb - pipe size 88pkts
20
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 Westwoods
  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

21
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

22
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

23
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 2001. 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, 2003. 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. 756 - 769,
december 1997. 5 Lawrence Brakmo, Sean
O'Malley, and Larry Peterson, " TCP Vegas New
Techniques for Congestion Detection and Avoidance
, ACM SIGCOMM, pages 24-35, August 1994.
24
Some Bibliography 2/2
6 C. E. Palazzi, Protocolli di Trasporto in
Ambiente Wireless, Bachelor Degree Thesis,
University of Bologna, July 2002. 7 P. Sinha,
N. Venkitaraman, R. Sivakumar, V. Bharghavan,
"WTCP A Reliable Transport Protocol for Wireless
Wide-Area Networks", ACM Mobicom '99, August
1999. 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 2000.
9 S. Keshav, Packet-Pair Flow Control",
IEEE/ACM Transaction on Networking, February 1995.
25
Questions ?