TCP over Wireless Networks

WTCP Reliable transport protocol for wide-area wireless networks Alternative to TCP (but completely different unlike the schemes we have seen so far) End-to-end approach

WTCP Approach Rate based transmission control Inter-packet separation based congestion detection Distinguishing cause of packet loss Transmission control computations at receiver Variable granularity rate adjustment Quick start

WTCP Reliability SACK algorithm Probe packets

Reliability Selective acknowledgements SACKs very useful in TCP when random losses occur Better utilization of the network resources (no unnecessary retransmissions)

Reliability (contd.) No retransmit timeouts Since RTOs cannot be relied upon, WTCP does not use RTOs Use probe packets to recover from suffix losses ACK frequency tuned by sender based on factors such as (a) observed loss rate on reverse path, (b) round-trip time, (c ) half-duplex or full-duplex nature of channel

WTCP Algorithm Congestion control 3 phases: increase, decrease, and maintain Chosen based on long-term and short term averages in inter-packet separation RTT computation (for probing) Using loss profile Increase, decrease, maintain phases

WTCP Recap E2E approach Completely different from TCP Uses rate based transmissions Uses inter-packet separation as congestion indication Performs loss classification No RTOs SACK + probe packets

pTCP: A Transport Layer Approach for Achieving Aggregate Bandwidths on Multi-homed Mobile Hosts

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 existing solutions have been considered using the best… for example, … However, the objective of our work is to consider simultaneous use… For example, 7Mbps To achieve this objective, we design… -- effective cost-qos tradeoffs an interesting problem that arises is … the concept of vertical handoff has been proposed to address this problem, where a mobile user is provided access through the higher data connection when it migrates across coverage areas. For example, when a user with 2Mbps Wireless WAN access moves within the coverage of 10Mbps Wireless LAN, … why transport layer emphasize simultaneous use and bandwidth aggregation illustrate 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 bandwidth aggregation at the link layer has been proposed -- But more importantly, TCP’s adversely… causes the problem. adverse reaction: mention fast retransmit causes window cutdown Lower layer approaches fail due to the multi-hop nature of paths and TCP’s reliance on FIFO delivery!

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 pipe 1 pipe 2 an alternative approach is to use application layer striping by opening multiple … to achieve bandwidth aggregation, the sending end…, and to provide in-sequence, .. Note that what we mean by effective bandwidth aggregation is to achieve.. -- smart application coarse level Problems Data rate differential Data rate fluctuations Blackouts

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 Sequence Number (Unaware Application) 1 2 3 4 5 6 35 36 37 38 39 40 Time (sec) Sequence Number (x1000) Pipe 1 (2500kbps) Pipe 2 (500kbps) Throughput vs. Bandwidth Ratio 1 2 3 4 5 6 7 8 9 10 Bandwidth Ratio (to 500kbps) Throughput (Mbps) Ideal Smart Application Unaware Application mention ideal here snapshot , a more generic scenario … describe the problem put up ideal with unaware application smart application stripes based on 5:1 Unaware application does not work. Need some kind of bandwidth estimation Smart application Coarse-grained bandwidth estimation The aggregate bandwidth is limited by the slower pipe in the unaware application

Data Rate Fluctuations Data rate fluctuations cause disproportional striping Data Rate Fluctuations 1.5 1.7 1.9 2.1 2.3 2.5 2.7 2.9 3.1 3.3 3.5 10 9 8 7 6 5 4 3 2 1 Fluctuation Period (sec) Throughput (Mbps) Ideal Smart Application Unaware Application 1 2 3 4 5 6 20 40 60 80 100 Bandwidth (Mbps) Time (sec) Bandwidth Fluctuations (5Mbps Pipe) Example Two pipes with random data rate fluctuations every t seconds Smart application Performs bandwidth estimation every T seconds put up smart application after the fluctuation curve 1. general description 2. describe the link fluctuations (1 to 5Mbps, 200Kbps to 1Mbps) 3. smart application performs coarse grain for every T seconds Need aggressive bandwidth estimation, which will cause overhead Packets will be unnecessarily held up in each socket Smart application’s performance is limited by disproportional striping

Blackouts Undelivered packet in the blackout pipe will cause head of line blocking Smart Application during Blackouts 5 10 15 20 25 30 40 50 60 70 80 90 100 Time (sec) Sequence Number (x1000) Pipe 1 (does not experience blackout) Pipe 2 (experiences blackout) Example One of the two pipes experiences blackout The other pipe does not experience any blackout stalled due to pipe 1 blackout blackout is a phenomenon where the data rate goes to zero -- 1. one generic statement 2. scenario true even for multiple pipes blackout Blackouts on one pipe will stall the entire aggregate connection

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 The fundamental design element of the pTCP protocol is the decoupling of functionalities… in terms of key functionalities, TCP-v handles… Note that although we present pTCP as a wrapper around TCP-v, it can be used in tandem with any single-pipe transport layer protocol TCP-v congestion control, pTCP reliability Allow plug-in of different congestion control schemes for different pipes

Design Elements Congestion window based striping Dynamic reassignment 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 -> differential [say here that pTCP can use any congestion control; also mention that this is fine-grained bandwidth-based striping] -> fluctuations [mention that this addresses the problem caused by fluctuations (disproportional striping)] -> blackouts binding mention Redundant striping Redundantly stripe the first packet after timeouts Allow the concerned pipe to probe while not potentially stalling the rest

pTCP Architecture Application pTCP TCP-v IP data packet virtual packet control read write ptcp-recv ip-output Application IP pTCP TCP-v open/close established/closed receive send shrunk resume recv buffer send buffer bindings active pipes virtual recv buffer virtual send buffer briefly mention open/close/established/closed only can link back to the design?

pTCP Architecture Application pTCP TCP-v IP data packet virtual packet control read write ptcp-recv ip-output Application IP pTCP TCP-v open/close established/closed recv buffer send buffer bindings active pipes receive send virtual recv buffer virtual send buffer resume mention application reads at the end briefly mention open/close/established/closed only can link back to the design? shrunk

pTCP Protocol Congestion control Flow control Reliability 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 congestion control: Any congestion control mechanism can be used (current prototype and results using TCP’s CC) flow control: No flow control by TCP-v which component handles it how does it do it Connection management pTCP manages the aggregation connection while TCP-v manages the individual pipes

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 3 types of pipes representative of different wireless evironments and we consider 4 different types of approaches why such values simulation does not matter

Data Rate Differential Throughput vs. Bandwidth Ratio 1 2 3 4 5 6 7 8 9 10 Bandwidth Ratio (to 500kbps) Throughput (Mbps) Ideal pTCP Smart Application Unaware Application

Data Rate Fluctuations Throughput vs. Number of Pipes (with Fluctuations) 2 4 6 8 10 12 14 16 3 5 7 9 Number of Pipes Throughput (Mbps) Ideal pTCP Smart Application Unaware Application take the same scenario as the “different number of pipes”, and we now introduce data rate fluctuations

Blackouts (pTCP) pTCP during Blackouts 10 20 30 40 50 60 70 80 90 100 10 20 30 40 50 60 70 80 90 100 Time (sec) Sequence Number (x1000) Pipe 1 (does not experience blackout) Pipe 2 (experiences blackout) continues progression blackout

Multiple Congestion Control Schemes Use TCP-ELN for lossy link (Pipe 2) Multiple Congestion Control Schemes 1 2 3 4 5 6 7 1.00E-05 1.00E-04 1.00E-03 1.00E-02 Packet Drop Probability (Pipe 2) Throughput (Mbps) Ideal: TCP (Pipe 1) + ELN (Pipe 2) pTCP: TCP (Pipe 1) + ELN (Pipe 2) Smart Application: TCP (Pipe 1) + ELN (Pipe 2) Smart Application: TCP (Pipe 1) + TCP (Pipe 2) mention bw for each pipe ideal first link back to decoupling of functionalities

Related Work Link layer Network layer Transport layer Scalable striping [Adiseshu ’96] Adaptive inverse multiplexing [Snoeren ’99] Network layer Multi-IP links streaming [Phatak ’02] Transport layer SCTP [Stewart ’00] RMTP no animation? RMTP [Magalhaes ’01] Application layer PSockets [Sivakumar ’00]

Recap 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 mention 3 characteristics first then target environment For more information: http://www.ece.gatech.edu/research/GNAN

Puzzle You have a chain consisting of 63 inter-linked gold links You have to stay at a motel where the charge per day is 1 gold link You do not trust the motel manager and neither does he trust you What is the minimum number of links you need to break in order to stay for 63 days? Clue: The manager will not sell the links till you check out