1 TCP over Wireless (I) some slides adapted, notably from tutorial by Nitin Vaidya

2 Wireless Connectivity - Characteristics  Transmission errors  Wireless LANs , Hyperlan  Cellular wireless  Multi-hop wireless  Satellites  Low bandwidth  Cellular wireless  Packet radio (e.g., Metricom)  Long or variable latency  GEO, LEO satellites  Packet radio - high variability  Asymmetry in bandwidth, error characteristics  Satellites (example: DirectPC)

3 TCP/IP over Wireless  De facto standard for internetworking  Allows wireless devices to connect seamlessly to the Internet  TCP over wireless introduces some problems not faced in wired networks (transmission errors, mobility …)  We will overview these issues as well as existing solutions  What type of wireless network (cellular, last hop, ad hoc, satellite …)?

4 Quick review of Transmission Control Protocol / Internet Protocol TCP/IP

5 Internet Protocol (IP)  Packets may be delivered out-of-order  Packets may be lost  Packets may be duplicated

6 Transmission Control Protocol (TCP)  Reliable ordered delivery  Implements congestion avoidance and control  Reliability achieved by means of retransmissions if necessary  End-to-end semantics  Acknowledgements sent to TCP sender confirm delivery of data received by TCP receiver  Ack for data sent only after data has reached receiver

7 TCP Basics  Cumulative acknowledgements  An acknowledgement ack’s all contiguously received data  TCP assigns byte sequence numbers  For simplicity, we will assign packet sequence numbers  Also, we use slightly different syntax for acks than normal TCP syntax  In our notation, ack i acknowledges receipt of packets through packet i

Cumulative Acknowledgements  A new cumulative acknowledgement is generated only on receipt of a new in-sequence packet i dataack i

9 Delayed Acknowledgements  An ack is delayed until  another packet is received, or  delayed ack timer expires (200 ms typical)  Reduces ack traffic New ack not produced on receipt of packet 36, but on receipt of 37

10 Duplicate Acknowledgements  A dupack is generated whenever an out-of-order segment arrives at the receiver Dupack (Above example assumes delayed acks) On receipt of 38

11 Duplicate Acknowledgements  Duplicate acks are not delayed  Duplicate acks may be generated when  a packet is lost, or  a packet is delivered out-of-order (OOO) Dupack On receipt of 38

12 Number of dupacks depends on how much OOO a packet is Dupack New Ack 34 New Ack DupackNew Ack

13 Window Based Flow Control  Sliding window protocol  Window size minimum of  receiver’s advertised window - determined by available buffer space at the receiver  congestion window - determined by the sender, based on feedback from the network Sender’s window Acks receivedNot transmitted

14 Window Based Flow Control Sender’s window Sender’s window Ack 5

15 Ack Clock  TCP window flow control is “self-clocking”  New data sent when old data is ack’d  Helps maintain “equilibrium”

16 Window Based Flow Control  Congestion window size bounds the amount of data that can be sent per round-trip time  Throughput <= W / RTT

17 Ideal Window Size  Ideal size = delay * bandwidth  delay-bandwidth product  What if window size < delay*bw ?  Inefficiency (wasted bandwidth)  What if > delay*bw ?  Queuing at intermediate routers increased RTT due to queuing delays  Potentially, packet loss

18 How does TCP detect a packet loss?  Retransmission timeout (RTO)  Duplicate acknowledgements

19 Detecting Packet Loss Using Retransmission Timeout (RTO)  At any time, TCP sender sets retransmission timer for only one packet  If acknowledgement for the timed packet is not received before timer goes off, the packet is assumed to be lost  RTO dynamically calculated

20 Retransmission Timeout (RTO) calculation  RTO = mean + 4 mean deviation  Standard deviation  average of (sample – mean)  Mean deviation  average of |sample – mean|  Mean deviation easier to calculate than standard deviation  Mean deviation is more conservative   Large variations in the RTT increase the deviation, leading to larger RTO 22

21 Timeout Granularity  RTT is measured as a discrete variable, in multiples of a “tick”  1 tick = 500 ms in many implementations  smaller tick sizes in more recent implementations (e.g., Solaris)  RTO is at least 2 clock ticks

22 Exponential Backoff  Double RTO on each timeout Packet transmitted Time-out occurs before ack received, packet retransmitted Timeout interval doubled T1 T2 = 2 * T1

23 Fast Retransmission  Timeouts can take too long  how to initiate retransmission sooner?  Fast retransmit

24 Detecting Packet Loss Using Dupacks Fast Retransmit Mechanism  Dupacks may be generated due to  packet loss, or  out-of-order packet delivery  TCP sender assumes that a packet loss has occurred if it receives three dupacks consecutively dupacks are also generated if a packet is delivered at least 3 places beyond its in-sequence location Fast retransmit useful only if lower layers deliver packets “almost ordered” ---- otherwise, unnecessary fast retransmit

25 Congestion Avoidance and Control Slow Start  initially, congestion window size cwnd = 1 MSS (maximum segment size)  increment window size by 1 MSS on each new ack  slow start phase ends when window size reaches the slow-start threshold  cwnd grows exponentially with time during slow start  factor of 1.5 per RTT if every other packet ack’d  factor of 2 per RTT if every packet ack’d  Could be less if sender does not always have data to send

26 Congestion Avoidance  On each new ack, increase cwnd by 1/cwnd packets  cwnd increases linearly with time during congestion avoidance  1/2 MSS per RTT if every other packet ack’d  1 MSS per RTT if every packet ack’d

27 Slow start Congestion avoidance Slow start threshold Example assumes that acks are not delayed

28 Congestion Control  On detecting a packet loss, TCP sender assumes that network congestion has occurred  On detecting packet loss, TCP sender drastically reduces the congestion window  Reducing congestion window reduces amount of data that can be sent per RTT  throughput may decrease

29 Congestion Control -- Timeout  On a timeout, the congestion window is reduced to the initial value of 1 MSS  The slow start threshold is set to half the window size before packet loss  more precisely, ssthresh = maximum of min(cwnd,receiver’s advertised window)/2 and 2 MSS  Slow start is initiated

30 ssthresh = 8 ssthresh = 10 cwnd = 20 After timeout

31 Congestion Control - Fast retransmit  Fast retransmit occurs when multiple (>= 3) dupacks come back  Fast recovery follows fast retransmit  Different from timeout : slow start follows timeout  timeout occurs when no more packets are getting across  fast retransmit occurs when a packet is lost, but latter packets get through  ack clock is still there when fast retransmit occurs  no need to slow start

32 Fast Recovery  ssthresh = min(cwnd, receiver’s advertised window)/2 (at least 2 MSS)  retransmit the missing segment (fast retransmit)  cwnd = ssthresh + number of dupacks  when a new ack comes: cwnd = ssthreh  enter congestion avoidance Congestion window cut into half

33 After fast retransmit and fast recovery window size is reduced in half. Receiver’s advertized window After fast recovery

34 TCP Reno  Slow-start  Congestion avoidance  Fast retransmit  Fast recovery

35 Fast Recovery Fast recovery can result in a timeout with multiple losses per RTT.  TCP New-Reno [Hoe96]  stay in fast recovery until all packet losses in window are recovered  can recover 1 packet loss per RTT without causing a timeout  Selective Acknowledgements (SACK) [mathis96rfc2018]  provides information about out-of-order packets received by receiver  can recover multiple packet losses per RTT

36 Does IEEE Work Well in Multi-hop Wireless Network? Author: Shugong Xu, Tarek Saadawi City University of New York

37 Overview of The Paper  This paper is about TCP over multi-hop networks, but its also about cross-layer interactions  Conclusion: Cross Layer interactions between Protocol, routing and TCP can be destructive.  Experimental Scenario:  A Static String Topology  TCP as Transport Layer Protocol  Problems:  Instability Problem  Unfairness Problem

38 Simulation Environment  Simulator: ns-2 with wireless extensions  MAC Layer: IEEE MAC Distributed Coordination function(DCF).  Transport Layer: TCP connections carrying bulk transfers (always have data)  Network Scenario  A Static String Network Topology  Interference range is a little more than two times of the communication range Interference Range Communication Range

39 Instability Problem—Experiment Setup Source Destination  A single TCP connection, with node 1 as the source and node 5 as the destination.  Three sets of experiments with Maximum Window Size(window_) 32, 8, and 4 respectively.

40 Instability Problem—Experiment Result  When window_=32 or 8, serious oscillation of throughput is observed.  When window_4, throughput is stable.

41 Instability Problem—Trace Analysis(1) Data Ack RTS CTS Interference Range of Node 2

42 Instability Problem—Summary  Collision and exposed terminal problem prevent node 2 from receiving RTS from or sending CTS to node 1.  The random back-off, big data packet, and sending back-to-back packets worsen the above problems.  When window_ = 4, the chance to send back a CTS is greatly increased, so the throughput becomes stable.  After node 1 fails seven times to receive CTS, node 1 believes there is a route failure and starts a route discovery.  Before a route is available, node 1 can not send out a data packet. This period usually is long enough to cause a timeout at the TCP sender.  For TCP, timeout triggers Slow Start, which significantly reduces the throughput.

43 Unfairness Problem—Experiment Setup Source Destination Source First SessionSecond Session  In the first session, data flow from 6 to 4. In the second session, data flow from 2 to 3.  The first session starts at 10.0s. The second session starts at 30.0s.

44 Unfairness Problem (1)  The first session has a throughput of about 450kbps from 10s to 30s, and 0kbps after 30s.  The second session has a throughput of about 900kbps from 30s to 130s.

45 Unfairness Problem (2)  The first session never succeeds to send out packet with sequence number 2164.

46 Unfairness Problem—Trace Analysis(1) RTSData CTS Interfering Range of Node 5 Ack Interfering Range of Node 4 Data No Route

47 Unfairness Problem—Trace Analysis(2) RTSData CTS Interfering Range of Node 5 Ack Interfering Range of Node 4 Data No Route

48 Unfairness Problem—Summary  In one-hop TCP connections, the interval between packet transmission is larger than that of the multi- hop TCP connections, which gives the one-hop connection more chances to transmit data.  Random back-off is actually advantageous to the last succeeding host.  Problem called “One-hop unfairness problem”  Authors argue that since one-hop connection is common in a wireless network problem must be addressed

49 Discussion?  Problems Shown:  Instability Problem  Unfairness problem  Conclusions:  IEEE does not work well in multi-hop wireless networks.  It may be inappropriate to take IEEE as the MAC layer to simulate routing or transport protocols for multi- hop wireless networks.  Are Cross Layer Solutions needed?  Maybe a different set of protocols that play nicer together?

50 More discussion  Rooted in IEEE MAC?  TCP is not designed with wireless networking in mind.  Timeout  Slow Start  Interfering range and communication range  If interfering range is the same as the communication range, the two problems presented in this paper will disappear.  Is the configuration of the interfering range simply an engineering issue?  Only a simple topology is considered  What happens if more complex scenarios are considered?  Different traffic?  Multiple connections?  Different spacing between nodes?  More realistic wireless channel?  Can you relate to other stuff we have discussed so far?