TCP SPC: Statistic Process Control for Enhanced Transport over Wireless Links Yantai Shu, Dawei Gao, and Li Yu Tanjn University M.Y. Sanadidi, Mario Gerla UCLA

Motivation Overcome sporadic losses in wireless networks Improve TCP performance Improve TCP fairness TCP SPC New congestion control scheme Using RTT as congestion indicator Using SPC (Statistic Process Control) as monitoring method

Network model Model on transport layer –Input: data packet –Output: packet Loss and RTT Packet loss: –employed in TCP congestion control –problematic as congestion indicator in wireless environments –inferred from RTT RTT: more essential for congestion –Insensitive to wireless links

Throughput, RTT and load When load is less than cliff point –delay changes slightly When load is between knee point and cliff point –delay are proportional to load When the load exceeds cliff point –delay increases sharply network status changes → the pattern of delay variance changes → different congestion levels RTT is suitable as a congestion indicator

RTT Load Throughput

Distribution of RTT Assumption: RTT obeys the normal distribution under any invariable-load situation  Using SPC (Statistic Process Control) Proof: –Samples sampled continuously from a stable process obey the normal distribution. –The distribution of RTT in the Internet was shown to be proximate to a Normal distribution. –We verified that the Normal Distribution also suits the wireless network by simulating a wireless network with a linear topology that consists of 8 nodes and one flow.

Distribution verification Simulation: –Using the fixed congestion window to simulate invariable load –100 RTT samples recorded for each window size. –Window size changed from 1 to 100 –10 experiments –Carrying on an one-sample K-S test of normal distribution

Monitoring RTT Assumption: the network load is stable Sampling 15 consecutive RTT values Calculating parameters: –the mean m –the standard deviation σ

Control chart R T T t m -3 σ +3 σ + σ +2 σ - σ -2 σ

Calculating control values – CL (Centre line)= m – UFL (Upper Foco Line) = m + σ – LFL (Lower Foco line) = m - σ – UWL (Upper Warning Line) = m + 2σ – LWL (Lower Warning Line) = m - 2σ – UCL (Upper Control Limit) = m + 3σ – LCL (Lower Control Limit) = m - 3σ

RTT  four sets of criteria Once a RTT is captured, a point is drawn on the Control Chart Any change in RTT values is thus recorded To estimate the status of the network, we use four sets of criteria: –Congestion criteria –Over-load criteria –Under-load criteria –Chart-invalidation criteria

Congestion criteria Over-UCL: one point is over UCL Near-UCL: several points are between UCL and UWL –2 of 3 consecutive points –3 of 7 consecutive points –4 of 10 consecutive points Jitter-Trend-Up: jitters of 7 consecutive points keep larger and larger

Over-load criteria Up-Excursion: several points are larger than CL –7 consecutive points –10 of 11 consecutive points –12 of 14 consecutive points –14 of 17 consecutive points –16 of 20 consecutive points Point-Trend-Up: 7 consecutive points keep larger and larger

Under-load criteria Over-LCL: one point is over LCL Near-LCL: several points are between LCL and LWL (like Near-UCL) Jitter-Trend-Down: jitters of 7 consecutive points keep smaller and smaller Down-Excursion: several points are smaller than CL (like Up-Excursion) Point-Trend-Down: 7 consecutive points keep smaller and smaller

Chart-invalidation criteria –Stratum: 15 points of RTT between UFL and LFL Satisfaction of any criteria is small-probable!

Adjusting window congestion criteria met –Decreasing congestion window drastically over-load criteria met –Decreasing congestion window gently chart-invalidation criteria met –Re-estimating parameters under-load criteria met –Increasing the congestion window Re-estimate parameters after adjustment!

Implementation Using vectors for monitoring – Substituting control chart and criteria – Each vector is consist of several bits – Setting 1 or 0 at right-end and left-shift after comparison to record RTT change – Each vector corresponds to one criterion – Over-UCL and Over-LCL Compare directly

RTT sampling and monitoring Using an array to store 15 RTTs When the array is not full, using criteria: –Jitter-Trend-Up / Jitter-Trend-Down / Point-Trend-Up/Point-Trend-Down / Up- Excursion / Down-Excursion When the array is full –Calculating control values –Using all vectors When congestion or over-load –shifting into Congestion Avoidance –Re-recording RTT after all data packets sent before changing the congestion window have been acknowledged

Window adjustment Slow Start –Doubling the window when a RTT get Congestion Avoidance –Increasing 1 every 15 RTTs When under-load criteria are met –Increasing 1 immediately When congestion criteria are met –Halving the window When over-load criteria are met –Decreasing the window by one quarter

Simulation Line Cross Grid

Effects by hops Line topology, Single flow

Impact of packet error Line topology, 7 nodes, Single flow

Effects by flows Line topology

Effects by flows Cross topology 2 flows

Effects by flows Grid topology 4,6,8 flows

Discussion RTT is suitable to be used as the congestion indicator The throughput of TCP SPC is higher than that of TCP Reno and TCP SACK TCP SPC is better to overcome the sporadic loss in wireless networks The fairness index of TCP SPC is also considerably good

Future work Testifying the distribution assumption Evaluating TCP SPC in testbed Applying TCP SPC in wired/wireless mixed environments and in mesh networks