330 likes | 341 Views
This research paper discusses a transport layer approach to achieve aggregate bandwidths on multi-homed mobile hosts. It explores the design and protocol of a transport layer protocol that allows for simultaneous use of multiple wireless access technologies and provides reliable and sequenced delivery.
E N D
A Transport Layer Approach for Achieving Aggregate Bandwidths on Multi-homed Mobile Hosts Hung-Yun Hsieh and Raghupathy Sivakumar GNAN Research Group School of Electrical and Computer Engineering Georgia Institute of Technology September 26, 2002
Outline • Introduction • Motivation • Design • Protocol • Evaluation • Conclusions
Introduction • A multitude of wireless access technologies • How can these technologies co-exist in providing the best service to a multi-homed mobile user? • Use only the interface with the highest data rate at any given time • Objective • Allow simultaneous use of multiple wireless access technologies (striping) • Design a transport layer protocol that provides reliable and sequenced delivery like in TCP, and achieves effective bandwidth aggregation
Why Not Lower Layers? • Link layer striping [Adiseshu ’96, Snoeren ’99] • Stripe according to estimates of link bandwidths • Optimal link layer striping optimal bandwidth aggregation across multi-hop paths • Not applicable to multi-homed mobile hosts • Network layer striping [Phatak ’02] • IP performs tunneling and striping • TCP’s RTT estimates lose meaning • TCP adversely reacts to packet reordering • Lower layer approaches fail due to the multi-hop nature of paths and TCP’s reliance on FIFO delivery!
pipe 1 pipe 2 Why Not Multiple Sockets? • Application layer striping • Open multiple TCP sockets • Each socket is in charge of only one path (pipe) • Perform bandwidth estimation at the sending end and packet re-sequencing at the receiving end • Optimal aggregate bandwidth = sum of maximum achievable bandwidths on the individual pipes • Problems • Data rate differential • Data rate fluctuations • Blackouts
Sequence Number (Unaware Application) 6 Throughput vs. Bandwidth Ratio Pipe 1 (2500kbps) Pipe 2 (500kbps) 6 5 Ideal Smart Application 5 Unaware Application 4 Sequence Number (x1000) 4 3 Throughput (Mbps) 3 2 2 1 1 35 36 37 38 39 40 Time (sec) 0 1 2 3 4 5 6 7 8 9 10 Bandwidth Ratio (to 500kbps) Data Rate Differential • Head of line blocking will result in the slower pipes stalling the faster pipes • Example • Two pipes with mismatched bandwidths • Unaware application • Write until blocked • Smart application • Coarse-grained bandwidth estimation • The aggregate bandwidth is limited by the slower pipe in the unaware application
Data Rate Fluctuations 3.5 3.3 Bandwidth Fluctuations (5Mbps Pipe) 3.1 6 2.9 2.7 5 Throughput (Mbps) 2.5 4 2.3 Ideal 2.1 Bandwidth (Mbps) Smart Application 3 Unaware Application 1.9 1.7 2 1.5 10 9 8 7 6 5 4 3 2 1 1 Fluctuation Period (sec) 0 0 20 40 60 80 100 Time (sec) Data Rate Fluctuations • Data rate fluctuations cause disproportional striping • Example • Twopipes with random data rate fluctuations every t seconds • Smart application • Performs bandwidth estimation every T seconds • Smart application’s performance is limited by disproportional striping
Smart Application during Blackouts 25 Pipe 1 (does not experience blackout) Pipe 2 (experiences blackout) 20 15 Sequence Number (x1000) stalled due to pipe 1 blackout 10 5 blackout 0 0 10 20 30 40 50 60 70 80 90 100 Time (sec) Blackouts • Undelivered packet in the blackout pipe will cause head of line blocking • Example • One of the two pipes experiences blackout • The other pipe does not experience any blackout • Blackouts on one pipe will stall the entire aggregate connection
Agenda • Introduction • Motivation • pTCP Design • pTCP Protocol • Evaluation • Conclusions
Design Elements • Decoupling of functionalities • Per-pipe (TCP-v) behavior vs. aggregate connection (pTCP) behavior • TCP-v: virtual packets; pTCP: data packets • TCP-v: congestion control; pTCP: reliability • TCP-v: how much to send; pTCP: what to send • Allow plug-in of different congestion control schemes for different pipes
Design Elements • Congestion window based striping • A packet is given to a TCP-v only when its congestion window has space • Reuse TCP’s congestion control for bandwidth estimation • Dynamic reassignment • Reassign packets that fall out of TCP-v’s window • Avoid packets being held up by one pipe • Redundant striping • Redundantly stripe the first packet after timeouts • Allow the concerned pipe to probe while not potentially stalling the rest
data packet virtual packet Application control write read pTCP open/close TCP-v established/closed receive send bindings active virtual send buffer send buffer resume pipes virtual recv buffer recv buffer shrunk ip-output ptcp-recv IP pTCP Architecture
data packet virtual packet Application control write read pTCP open/close TCP-v established/closed receive send bindings active virtual send buffer send buffer resume pipes virtual recv buffer recv buffer shrunk ip-output ptcp-recv IP pTCP Architecture
pTCP Protocol • Congestion control • Performed by each TCP-v on a per-pipe basis • Any congestion control mechanism can be used • Flow control • Managed by pTCP through window advertisement • No flow control by TCP-v • Reliability • pTCP delegates reliability to each TCP-v unless the packet has to be reassigned • Connection management • pTCP manages the aggregation connection while TCP-v manages the individual pipes
client server open socket nIF interfaces S Y N , n T x = n I F ( T C P - v ) 1 ) v - P C T ( F 1 I n = x R n , K C A + N Y S send data A C K ( T C P - v ) first pipe 1 S Y N ( T C P - v ) established 2 S Y N (connection ( T C P - v ) established) I n F ) v - P C T ( K 2 C A + N Y S ) v - P C T ( F I K n C A + N Y S A C K ( T C P - v ) 2 A C K ( T C P e - v ) all pipes m I n F i t established pTCP Connection Handshake
Agenda • Introduction • Motivation • Design • Protocol • Evaluation • Conclusions
Simulation Environment • Topology • Pipe 1: BW = 500kbps ~ 5Mbps, RTT = 100ms • Pipe 2: BW = 2Mbps, RTT = 400ms • Pipe 3: BW = 500kbps, RTT = 400ms • Approaches • Ideal • pTCP • Smart application • Unaware application
Throughput vs. Bandwidth Ratio 6 Ideal pTCP 5 Smart Application Unaware Application 4 Throughput (Mbps) 3 2 1 0 1 2 3 4 5 6 7 8 9 10 Bandwidth Ratio (to 500kbps) Data Rate Differential
Throughput vs. Number of Pipes 30 Ideal pTCP 25 Smart Application Unaware Application 20 Throughput (Mbps) 15 10 5 0 2 3 4 5 6 7 8 9 10 Number of Pipes Number of Pipes
Throughput vs. Number of Pipes (with Fluctuations) 16 Ideal 14 pTCP Smart Application 12 Unaware Application 10 Throughput (Mbps) 8 6 4 2 0 2 3 4 5 6 7 8 9 10 Number of Pipes Data Rate Fluctuations
pTCP during Blackouts 60 Pipe 1 (does not experience blackout) Pipe 2 (experiences blackout) 50 40 Sequence Number (x1000) continues progression 30 20 blackout 10 0 0 10 20 30 40 50 60 70 80 90 100 Time (sec) Blackouts (pTCP)
Multiple Congestion Control Schemes 7 6 5 4 Throughput (Mbps) 3 Ideal: TCP (Pipe 1) + ELN (Pipe 2) 2 pTCP: TCP (Pipe 1) + ELN (Pipe 2) Smart Application: TCP (Pipe 1) + ELN (Pipe 2) 1 Smart Application: TCP (Pipe 1) + TCP (Pipe 2) 0 1.00E-05 1.00E-04 1.00E-03 1.00E-02 Packet Drop Probability (Pipe 2) Multiple Congestion Control Schemes • Use TCP-ELN for lossy link (Pipe 2)
Related Work • Link layer • Scalable striping [Adiseshu ’96] • Adaptive inverse multiplexing [Snoeren ’99] • Network layer • Multi-IP links streaming [Phatak ’02] • Transport layer • SCTP [Stewart ’00] • RMTP [Magalhaes ’01] • Application layer • PSockets [Sivakumar ’00]
Conclusions • Bandwidth aggregation can be used to provide better service to multi-homed mobile hosts • A transport layer approach is more effective than other layers in the target environment • pTCP achieves effective bandwidth aggregation despite the data rate mismatch, fluctuations, and blackouts of different pipes • For more information: http://www.ece.gatech.edu/research/GNAN
Application Complexity • Sophisticated implementation • Need to re-implement most TCP functionalities • Very complicated bandwidth estimation scheme at least the time-granularity of TCP • It is not desirable to overload application • Not application specific functionalities • Data rate differential can be solved using a larger re-sequencing buffer • Need larger buffer than pTCP uses (transport layer buffering) • Buffer over-provisioning
Throughput vs. Socket Buffer Ratio (5Mbps vs. 500kbps) 6 5 4 Throughput (Mbps) 3 2 1 Ideal Unaware Application 0 1 2 3 4 5 6 7 8 9 10 Socket Buffer Ratio (5Mbps to 500kbps) Buffer Over-provisioning
CLOSED OPEN [ TCP-v open( ), p = nIF ] 1 CLOSE ESTABLISH WAIT [ TCP-v close( ) ] 1 TCP-v established( ) 1 [ TCP-v open( ), n = 1 ] 2...nIF TCP-v established( ) ESTABLISHED ( n ) n +1 [ n = n + 1 ] CLOSE [ TCP-v close( ), m = n ] 1... n TCP-v closed( ) CLOSE WAIT ( m ) m [ m = m - 1 ] m == 0 pTCP State Diagram
Throughput Aggregation vs. Bandwidth Ratio (Two Links) Bandwidth Aggregation vs. Number of Links (Fluctuations) 5500 11 Ideal Ideal pTCP 5000 10 pTCP Multiple Sockets Multiple Sockets 4500 9 4000 8 3500 7 Application Throughput (kbps) Application Throughput (Mbps) 3000 6 2500 5 2000 4 1500 3 1000 2 500 1 1 2 3 4 5 6 7 8 9 10 2 (5M+2M) 3 (+500k) 4 (+1M) 5 (+10M) Bandwidth Ratio (to 500kbps) Number of Links Multi-homed Mobile Hosts
RMTP • Coupling of congestion control and reliability • Does not have fine-grained handling of fluctuations & blackout • Does not have delayed binding (fine-grained packet assignment) • Does not have dynamic reassignment • Does not have redundant stripingA
Smart Application during Blackouts 25 Pipe 1 (does not experience blackout) Pipe 2 (experiences blackout) 20 15 stalled due to pipe 1 blackout Sequence Number (x1000) 10 5 blackout 0 0 10 20 30 40 50 60 70 80 90 100 Time (sec) Blackouts (Smart Application)
Issues • Bandwidth-delay product • TCP friendliness • Backward compatibility • Complexity • Handoffs