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

2. 2 Wireless Connectivity - Characteristics  Transmission errors  Wireless LANs - 802.11, 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. 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. 4 Quick review of Transmission Control Protocol / Internet Protocol TCP/IP

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

6. 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. 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

8. 8 40393738 3533 Cumulative Acknowledgements  A new cumulative acknowledgement is generated only on receipt of a new in-sequence packet 41403839 3537 3634 3634 i dataack i

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

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

11. 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) 40393837 3634 41403739 36 Dupack On receipt of 38

12. 12 Number of dupacks depends on how much OOO a packet is 40393837 3634 41403739 36 Dupack 42413940 36 38 New Ack 34 New Ack DupackNew Ack

13. 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 23456789101113112 Sender’s window Acks receivedNot transmitted

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

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

16. 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. 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. 18 How does TCP detect a packet loss?  Retransmission timeout (RTO)  Duplicate acknowledgements

19. 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. 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. 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. 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. 23 Fast Retransmission  Timeouts can take too long  how to initiate retransmission sooner?  Fast retransmit

24. 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 128791011 3 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. 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. 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. 27 Slow start Congestion avoidance Slow start threshold Example assumes that acks are not delayed

28. 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. 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. 30 ssthresh = 8 ssthresh = 10 cwnd = 20 After timeout

31. 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. 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. 33 After fast retransmit and fast recovery window size is reduced in half. Receiver’s advertized window After fast recovery

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

35. 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. 36 Does IEEE 802.11 Work Well in Multi-hop Wireless Network? Author: Shugong Xu, Tarek Saadawi City University of New York

37. 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 802.11 Protocol, routing and TCP can be destructive.  Experimental Scenario:  A Static String Topology  TCP as Transport Layer Protocol  Problems:  Instability Problem  Unfairness Problem 01234567

38. 38 Simulation Environment  Simulator: ns-2 with wireless extensions  MAC Layer: IEEE 802.11 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 01234567 Interference Range Communication Range

39. 39 Instability Problem—Experiment Setup 12345 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. 40 Instability Problem—Experiment Result  When window_=32 or 8, serious oscillation of throughput is observed.  When window_4, throughput is stable.

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

42. 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. 43 Unfairness Problem—Experiment Setup 23456 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. 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. 45 Unfairness Problem (2)  The first session never succeeds to send out packet with sequence number 2164.

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

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

48. 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. 49 Discussion?  Problems Shown:  Instability Problem  Unfairness problem  Conclusions:  IEEE 802.11 does not work well in multi-hop wireless networks.  It may be inappropriate to take IEEE 802.11 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. 50 More discussion  Rooted in IEEE 802.11 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?