Unit-4 Mobile TCP

1. Unit-4Mobile TCP Mobile Communication

2. UNIT IV- MOBILE TRANSPORT LAYER Conventional TCP/IP protocols Indirect TCP Snooping TCP Mobile TCP TCP Layer Transmision Mobile Operating Systems • Palm OS • Windows CE • Symbion OS • Linux for Mobile Devices

3. Outline • Why Mobile IP? • Why Mobile TCP? • Types of Mobile TCP • Split-Connection Approaches • Link Layer Approaches • End-to-End Approaches • Comparisons

4. Why Mobile IP ?

5. Wireless Networking: Systems Issues • It’s not all about the hardware • Extensions to support mobility • Mobile IP • Wireless network protocols • Primarily hacking TCP • Brief review of TCP, then what breaks under wireless • Without mobility • With mobility • This sets the stage..

6. Why Mobile IP? • Need a protocol which allows network connectivity across host movement • Protocol to enable mobility must not require massive changes to router software, etc. • Must be compatible with large installed base of IPv4 networks/hosts • Confine changes to mobile hosts and a few support hosts which enable mobility • Just hacking DNS won’t work • DNS updates take time • Hooks for normal users to update DNS won’t be accepted by administrators • After DNS lookup, raw IP address is used by TCP, UDP, …

7. The Devil is in the Details... • How does the mobile host get a remote IP? • Router advertisements, DHCP, manual... • Agent advertisement if remote network is Mobile-IP enabled • How can a mobile host tell where it is? • Am I at home? • Am I visiting a foreign network? • Have I moved? • One way: by listening for advertisements from its home agents • Presence indicates home • Absence tends to indicate not home…

8. Devil (2) • Redundancy: What if the home agent doesn't answer a registration request? Or is dead? • Registration request to broadcast address of home network • All available home agents will hear and reply, but will reject service because message received via broadcast • Error in Registration Reply (a rejection) carries new home agent ID • Now can request help from a specific new home agent • "Ingress" filtering • Routers which see packets coming from a direction from which they would not have routed the source address are dropped

9. Why Mobile TCP ?

10. The Most Popular Transport Protocol: TCP • TCP (Transmission Control Protocol) • Connection-oriented • Byte stream-oriented • Slower setup • Consumes file handles: one per connection • Flow control, automatic retransmission • No packet reordering (delivery is FIFO) • No packet loss • No duplication • Theoretically “no” limit on size of objects that can be dumped into a TCP stream • In practice, limits exist

11. More Background on TCP • TCP developed for wired, low latency networks • Full-duplex, reliable, byte-oriented (stream) protocol • Highly optimized • Adaptive retransmission to deal with varying round trip times (RTTs), but max of 60 secs • Flow control and congestion control • Flow control: Don’t overwhelm receiver • Congestion control: Don’t overwhelm network • Sliding Window Protocol… • Window sizes are variable • Resources dedicated to a connection can vary on either side of the connection • Must negotiate to determine resources allocated • Don’t want to retransmit packets that are still in transit!

12. TCP Header Format • Source port/IP + Destination port/IP unique define TCP connection • Sequence number is for first byte of data carried in this segment • Flags: (S)YN, (F)IN, (R)ESET, (P)USH, (A)CK, (U)RGENT • PUSH == transfer w/o waiting for buffer fill (e.g., for telnet) • URGENT == allow sending urgent data “out of band” • RESET == “abort connection immediately” • Window is size of sliding window at sender of packet • Checksum provides error checking for the packet

13. TCP/IP Protocol Overview Provides a reliable, in-order abstraction • Recover lost packets and detect/drop duplicates • Detect and drop corrupted packets • Full-duplex: bi-directional data flow in same connection Flow and congestion control • Flow control: sender will not overwhelm receiver • Congestion control: sender will not overwhelm the network • Sliding window flow control • Send and receive buffers • Congestion control done via adaptive flow control window size • TCP/TP Model defined by IETF in RFC 1122 • TCP tries to trade off efficiency and being a “Good Network Citizen” Good Network Citizen: Judged by performance, reliability, availability • Vast majority of bytes transferred on Internet today are TCP based: Web, Mail, Peer-to-peer (Napster, Gnutella, FreeNet, KaZaa)

14. TCP Protocol Connection Establishment (3-way handshake) 1) Client sends SYN with initial sequence number ( ISN = X) 2) Server responds with its own SYN w/seq number Y and ACK of client ISN with X+1 (next expected byte) 3) Client ACKs server's ISN with Y+1

15. TCP: retransmission scenarios Host A Host B Host A Host B Seq=92, 8 bytes data Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 Seq=92 timeout timeout ACK=100 X Seq=100 timeout ACK=120 loss Seq=92, 8 bytes data Seq=92 ACK=120 ACK=100 premature timeout, cumulative ACKs lost ACK scenario

16. Sliding Window Protocols • Sliding Window Protocols are typically used to provide connection-oriented communication; they naturally provide: • Flow control • Retransmission capability • Buffering for out-of-order packets • Receive Window @ the receiver • Send Window @ the sender

17. ACK 2 tap..tap..tap.. 3 4 tap..tap..tap.. 5 tap..tap..tap.. 6 Sliding Window: Sender • Every packet has an associated sequence number (corresponding to first byte of data in TCP) • Send window: packets which have been transmitted but no ACK has been received; unacknowledged packets must be buffered

18. Msg # 2 2 tap..tap..tap.. 3 Msg # 4 5 tap..tap..tap.. tap... 6 Sliding Window: Receiver • Receive window: packets receiver is willing to receive; when the lowest numbered packet is received, then becomes willing to accept next packet in the sequence

19. Sliding Window: Thoughts • Flow control is guaranteed • Messages corrupted in transit are always available at the sender for retransmission • Lost packets are retransmitted • Out of order messages are handled correctly • In TCP, windows change size—our simplified view didn’t show this • Each ACK includes a window size advertisement, indicating how much data the sender can currently buffer

20. Naïve TCP SENDER RECEIVER Determine receiver’s window size, adjust & send SEND WINDOW RECEIVE WINDOW Receiver’s advertised window size This allows flow control: Don’t overwhelm the receiver

21. The Problem? SENDER RECEIVER Even after adjusting for receiver, data can still overwhelm intervening routers...packets dropped! SEND WINDOW RECEIVE WINDOW Router

22. Slow Start Start by sending just one segment, every time you get an ACK, increase cwnd by one segment SENDER RECEIVER SEND WINDOW RECEIVE WINDOW packet cwnd is initially 1 segment ACK Router Results in exponential increase, despite the name...

23. Slow Start == Exponential Increase SENDER 1 ACK 2 4 RECEIVER

24. TCP/IP, Slow Start Sender may not only overrun receiver, but may also overrun intermediate routers: • No way to explicitly know router buffer occupancy, so infer congestion from packet losses. • Assumption :losses is due to congestion, i.e. intermediate routers have no available buffers Sender maintains a congestion window: • Max CW size is un-acknowledged data outstanding. • Successive ACKs from receiver cause CW to grow. How CW grows based on which of 2 phases: • Slow-start: initial phase, CW exponentially grows • Continue up to threshold • Congestion avoidance: CW steady grows

25. The End of Slow Start... SENDER RECEIVER Send window cwnddoubles during each RTT until packets are lost or a threshold ssthresh is hit. SEND WINDOW RECEIVE WINDOW pa.c..ket ssthresh is initially 64K Router

26. Congestion Avoidance • When slow start is terminated because cwnd exceeds ssthresh, increase cwndby a smaller amounton each ACK • Congestion avoidance phase increases send window more slowly than slow start • When a packet is lost, TCP assumes it is caused by network congestion (!)… • Then set ssthreshto cwnd / 2, set cwnd to 1, restart slow start

27. Congestion Light traffic Arrival Rate << R Low delay Can accommodate more Congestion onset Arrival rate approaches R Delay increases rapidly Throughput begins to saturate Saturation Arrival rate > R Large delays, packet loss Useful application throughput drops R Throughput (bps) Arrival Rate Delay (sec) Arrival Rate R

28. TCP congestion control Congestion Avoidance phase Congestion thresholdssthresh When cwnd > ssthresh, increase cwnd slowly cwnd++ per round-trip-time (RTT) Each time an ACK arrives, cwnd is increased by 1/cwnd In one RTT, cwnd segments are sent, so total increase in cwnd is cwnd x 1/cwnd = 1 cwnd grows linearly cwnd ssthresh Time (expressed in RTTs)

29. TCP congestion control Congestion detection: Timeout or Receipt of duplicate ACKs(Fast Retransmit) Assumption: current cwnd corresponds to available bandwidth TCP Tahoe ssthresh = ½ cwnd cwnd = 1 Go back to Slow Start Over several cycles expect to converge to ssthresh equal to about ½ the available bandwidth Congestion Avoidance Time-out Congestion window ssthresh Slow Start 0 Time (expressed in RTTs)

30. Send another ACK for highestin-order packet when out-of-order received... SENDER RECEIVER SEND WINDOW RECEIVE WINDOW ACK, ACK, ACK!!! Router Fast Retransmit THREE duplicate ACKs received will result in retransmission— three to avoid possibility of just out-of-order packets

31. TCP congestion control Fast Retransmit mechanism If a segment is dropped, subsequent segments trigger duplicate ACKs Sender retransmits segment instantly (without waiting for a timeout) when duplicate ACKs are received (typically 3) Improves performance Faster reaction to packet loss Implemented in TCP-Reno (more recent than TCP-Tahoe) SEQ=1 ACK=1 SEQ=2 SEQ=3 SEQ=4 ACK=1 SEQ=5 ACK=1 ACK=1

32. Fast Recovery • Two ways to detect (possible) packet loss: • (1) Timeout • Result: restart slow start • (2) Duplicate ACKS • Data must still be flowing, because out-of-order packets are being received… • Receiver sends duplicate of last in-order ACK • Fast recovery enters congestion avoidance without re-starting slow start for case (2) • Attempt to keep the pipe full under moderate congestion

33. Wireless: What Breaks? • Packet loss in wired networks very low, so assumption that • packet loss == network congestion is valid • Not necessarily valid in wireless networks, where error rates are higher • packet loss can occur even when the network is only lightly loaded • resetting size of cwnd on packet loss seriously affects throughput • high latency makes this worse--even more time to ramp up (because cwnd size changes only on an ACK)!

34. What Breaks (2) • Problems with header compression techniques • Idea: Header compression allows sending only changes in, e.g., a TCP header • Less overhead than transmitting full header • Problems with wireless, tho: • Error rates higher—more likely to lose packets • Lost packet means differential header info in subsequent packets is unusable… • This causes many packets to be discarded, requires resynchronization of sender/receiver • Reduces the usefulness of header compression • Some recent work on fixing this problem

35. Concerns for TCP in Wireless • Major concerns: • Changes must be largely compatible with deployed TCP implementations • Infeasible to insist on changes to millions of installed TCP suites • (We saw these restrictions when considering Mobile IP) • Means: • Proxies on the base stations serving mobile hosts • Changes on the mobile end • Negotiable changes (use TCP options)

36. Concerns, Cont. • Can higher error rates be hidden from TCP? • Would allow assumption … packet loss == network congestion … to remain unchanged in TCP/IP stack • Problem: TCP timers may go off, causing spurious retransmission… • Now some formal solutions

37. Questions What can we do about… transmission errors? errors due to mobility? Which part of the system functionality should we modify… The sender? The receiver? An intermediate node? Some or all of the above?

38. Solutions • Modify TCP specifications • Infeasible • Cannot determine reason for packet loss • Indirect Protocol Model • Use a “split-connection” approach • Fixed Host (FH) and MSR - Regular TCP • Mobile Host (MH) and MSR – wireless TCP * MSR – Mobility Source Router/ Base Station

39. Types of Mobile TCP

40. Classification of Schemes End to End Split Connection Link layer Reno SACK AIRMAIL Snoop New-Reno I-TCP M-TCP

41. Classification of Schemes • End-to-End protocols • loss recovery handled by sender • Link-layer solutions • hide link-related losses from sender • TCP sender may not be fully shielded • Split-connection approaches • hide any non-congestion related losses from TCP sender • since the problem is local, solve it locally

42. antenna Split Connection Protocols • Split the TCP connection into two separate connections. • 1st connection: sender to base station • 2nd connection: base station to receiver • The base station simply copies packets between the connections in both directions.

43. Link-Layer Protocols • Hides the characteristics of the wireless link from the transport layer and tries to solve the problem at the link layer • Uses technique like forward error correction (FEC) • Snoop, AIRMAIL(Asymmetric Reliable Mobile Access In Link-layer)

44. End-to-End Protocols • Make the sender realize some losses are due to bit-error, not congestion. • Sender avoid invoking congestion control algorithms if non-congestion related losses occur. • E.g. Reno, New-Reno, SACK

45. Split-connection approaches

46. Indirect TCP (I-TCP) Split the TCP connection at the AP into two parts AP buffers and retransmits received segments AP sends ACKs for the received segments Standard TCP on the wire-line link On the wireless link: TCP optimized for wireless Even standard TCP benefits from shorter RTT Shorter timeout Faster retransmissions Internet Mobile Host Access Point (AP) Standard TCP “Wireless” TCP

47. I-TCP example Access Point Correspondent Host Mobile Host segment 1 segment 2 segment 1 segment 3 ack 1 segment 2 ack 1 segment 2 ack 2 ack 2 segment 3 ack 3 ack 3 segment 2 timeout (short timeout thanks to short RTT)

48. I-TCP summary I-TCP Advantages No changes in the fixed network or hosts (TCP protocol), all current TCP optimizations still work Potentially no changes in mobile hosts Wireless transmission errors do not “propagate” to the wire-line network I-TCP Disadvantages Loss of end-to-end semantics An ACK does not imply that the receiver got the segment For mobility support, all FAs need to be I-TCP compatible, and the state needs to be transferred to maintain end-to-end semantics Higher end-to-end delays due to buffering and forwarding to a new agent Problem with security mechanisms, e.g. IPsec FA needs to spoof ACKs 49

49. M-TCP - Overview TCP connection is split in two at the SH Maintains end-to-end TCP semantics “Persist mode” – keeps timer of sender SH (Supervisor Host) Maintains several MSS (Mobile Support Station) – reduces handoff overheads Serves function of gateway Bandwidth manager, local recovery SH FH (Fixed Host) MH MSS TCP M - TCP SH-TCP M-TCP

50. M-TCP Protocol • Also splits the connection into two • Unlike I-TCP, it maintains e2e TCP semantics • Under long disconnection pushes the sender into “persist mode” • It avoids frequent transferring of state information during handover • It’s appropriated for environment with high cells switching