Wireless Data Tutorial

1. Wireless Data Tutorial Phil Karn Senior Staff Engineer Qualcomm karn@qualcomm.com http://people.qualcomm.com/karn

2. Introduction • "Data" really means packet data • Or more specifically, Internet access • could be a private net that uses TCP/IP • Everything else is an Internet application • e.g., CDMA asynch data & fax

3. Tutorial Topics • The Internet and its architecture • Generic considerations for IP over wireless • Adapting existing digital voice systems to packet data • IS-95 CDMA, Globalstar, GSM • Systems designed specifically for packet data • CDPD, HDR • Ad-hoc packet radio networks • IEEE 802.11

4. Introduction to the Internet • Evolved from DARPA-sponsored packet networking research begun in the 1960s • ARPANET begun in 1969 as first packet switched network • What became TCP/IP conceived in 1974 as means to interconnect ARPANET with ARPA packet radio networks

5. The Internet Problem • Given a variety of applications, transmission and networking technologies, including those not yet invented, how can we unify them into a single, seamless network? • Cerf & Kahn, A Protocol for Packet Network Interconnection, IEEE Transactions on Communications, May 1974 • describes the basic design of what became TCP/IP • TCP/IP was originally one protocol, later split • established Cerf & Kahn as the Internet’s “grandfathers”

6. Key Internet Concepts • End-to-end principle • push complexity and features to upper layers • I.e., out of network to user computers • Simplified, 4-layer reference model • Connectionless network layer • every packet contains full source & dest addresses • easy to implement on variety of physical networks • Flexible transport protocols • TCP and UDP meet virtually all needs

7. The End-to-End Principle • Saltzer, Reed and Clark, 1981: • Many traditional low-level network functions are better done at the endpoints, I.e., at higher protocol levels • Some functions can sometimes be justified within the network as a performance enhancement • IMHO, one of the most important CS papers of all time • http://people.qualcomm.com/karn/library.html has links

8. End-to-End in the Internet • The end-to-end principle is widely accepted, is fundamental to the Internet architecture, and largely explains its success • Nevertheless, some old-guard Bell-heads still refuse to accept it on ideological grounds • Sort of like the theory of biological evolution • Telcos don’t like being thought of as dumb bit pipe providers, even if that is their only real competence • The end-to-end Internet architecture is a powerful tool in the hands of end users • significant political and economic implications

9. The Internet Reference Model Application Host-to-Host (end-to-end) Internet Subnet

10. The Internet Reference Model • Application Layer • covers OSI application & presentation layers • HTTP, Telnet, FTP, SMTP, POP, DNS, etc • End-to-End Layer • OSI transport & session layers • TCP & UDP • Internet Layer • OSI network (upper part) • IP • Subnet Layer • OSI network (lower part), link, physical

11. How the Internet Model Differs from OSI • Fewer layers • Presentation merged into application • Session & transport layers merged into end-to-end • Single connectionless Internet layer • simple, least-common-denominator service • Subnetwork layer deliberately unspecified • may be a simple point-to-point link, a complete network with internal routing, or tin cans & string • Strong end-to-end emphasis • Put functions at endpoints whenever possible • Keep the network itself as simple as possible

12. HTTP POP UDP TCP PPP ARP Enet The Major Internet Protocols SMTP Telnet DNS FTP DHCP ICMP IP Other subnetworks Dial IS95 ISDN

13. Connectionless Networks • Similar to postal system • perhaps an unfortunate metaphor • Full addresses in every packet • network handles each packet independently • Any notion of a “connection” is strictly end-to-end; the network doesn’t know about them • facilitates scaling to very large networks • Service is usually best-effort • Far easier to implement • Standard examples: Ethernet, IP

14. The Internet Protocol (IP) - RFC791 • The protocol that defines “The Internet” • Datagram based (connectionless) • 32-bit address space (IPv4) • written as 4 bytes in “dotted decimal” format, e.g., 129.46.101.170 • Maximum datagram size: 64KB • Best-effort delivery service, optional QOS • Fragmentation/reassembly for subnets with smaller packet size limits

15. Internet Services • IP is best effort. Packets may be: • Lost (frequently, alas) • Corrupted (very rarely, thanks to link CRCs) • Delivered out of order (when routes change) • Duplicated (rarely) • Upper layer entities must anticipate and recover on an end-to-end basis

16. The IP Header 0 Ver IHL TOS Total Length M F D F Frag offset 0 Identification 4 8 TTL Protocol Header Checksum 12 Source Address 16 Destination Address

17. End-to-End Protocols • User Datagram Protocol (UDP) • defined in RFC 768 • Transmission Control Protocol (TCP) • defined in RFC793 • Internet Control Message Protocol (ICMP) • defined in RFC792 • error reporting, diagnostic testing • Others exist, but are rare • because TCP and UDP cover nearly all needs

18. The UDP Header 0 Source Port Destination Port Checksum Length 4

19. UDP Applications • Short transactions • Domain Name System (DNS) • Network File System (NFS) • Real-time applications • Voice over IP • Multicasting • Conferencing, broadcasting

20. TCP • Connection-oriented • Reliable • sequence numbering, retransmission • Bi-directional • though many applications are unidirectional • Featureless byte stream • records, messages, etc, imposed by application

21. TCP vs UDP • Many applications could use TCP or UDP • TCP tends to be easier to use • UDP tends to be more efficient and robust • especially if application protocol is idempotent

22. Connections • A socket is an {IP address, port} pair • A connection is defined by a pair of sockets, I.e, the 4-tuple:{{IP source address, source port},{IP destination address, destination port}} • Note that many different connections can share the same socket on one end • I.e., the analogy to a hardware outlet isn’t exact • This permits “well known ports” for servers

23. TCP Connection Management • 3-way handshake opens bi-directional point-to-point connection • Either side can issue a close and continue to receive data indefinitely • Designed to handle simultaneous opens • though rarely used in practice • Great care taken to detect and recover from lost, duplicated or reordered packets • When both sides close, the connection terminates

24. The TCP Header 0 Source Port Destination Port 4 Sequence Number 8 Acknowledgement Number offs Window flags 12 16 Checksum Urgent Pointer

25. Wireless IP Considerations • Performance • Reliability/availability • usually much lower than wired links • Cost • Routing/mobility • Addressing • Security

26. Wireless Performance Issues • Lower speeds and higher packet loss rates than wired networks • Connectivity usually not continuous • incomplete wireless coverage • cost • limited battery energy • Transport protocols (e.g., TCP), applications and users must all adapt to these properties

27. Transport Performance • TCP adapts to variable throughput and delay • already deals with many wireless performance issues • High loss rates, intermittent connectivity more problematic • Research ongoing • IETF Performance Implications of Link Characteristics (PILC) working group

28. Transmission Control • TCP - not the application - packetizes user byte stream, deciding how much to send and when • TCP’s name (“Transmission Control Protocol”) emphasizes the importance of this function • TCP’s rules: • A few big packets are better than many tinygrams • Assume most timeouts are congestion-related

29. Nagle Algorithm • Early TCPs sent every application write in a separate packet • This was death for character-at-a-time logins over slow links • link header + 40 bytes TCP/IP header + 1 byte data • Nagle algorithm (RFC896, Jan 1984) applies simple heuristic: • If data avail for a max packet, send it • Else, send only if no unacked data in flight • I.e., stop-and-wait until requested throughput > 1 packet/round trip time

30. TCP Retransmissions • The Internet can drop packets • As a “reliable” protocol, TCP detects lost packets with timers and retransmits them • Congestion is the main cause of packet loss • Ergo, overly aggressive TCP retransmission strategies can cause congestion collapse! • links are busy, but little useful work being done because few packets reach their destinations

31. Round Trip Time Estimation • TCP must adapt to changing Internet propagation delays due to queuing delays, changing routes, speed-of-light delays, etc • Packets are also lost occasionally • It is hard to tell whether an overdue packet has been lost or is simply delayed longer than usual • TCP doesn’t have enough info in the header to reliably distinguish ACKs for successive retransmissions of the same data

32. TCP Network Delay Modeling • TCP models Internet delay as a gaussian RV with a slowly varying mean and standard deviation • Retransmission Timeout (RTO) set to mean delay + 4 standard deviations • This is a tradeoff between: • maximizing throughput with packet loss • minimizing unnecessary retransmissions • Round trip time (RTT) measurements made by timer started when certain sequence number sent, stopped when it is acked

33. Estimating Round Trip Times • Mean and standard deviation estimates made with exponential smoother: • mean’ = (7/8)*mean + (1/8)*(rtt) • sdev’ = (3/4)*sdev + (1/4)*abs(rtt-mean) • RTO = mean + 4*sdev • If rtt has low variance, then RTO will be only a little greater than the mean round trip time • If rtt has high variance, then RTO will be much greater than the mean round trip time • combination of high loss and variable delay is bad for throughput

34. Filtering Round Trip Time Measurements • The TCP header has no way to distinguish a retransmitted segment from the original • If the sender gets an ACK for a retransmitted packet, there’s no way to know if it’s for the original transmission or a retransmission • I.e., the RTT measurement is unreliable • Therefore, only RTT measurements on segments that were ACKed the first time are used • Also, the RTO backoff is “clamped” for the next packet after a retransmitted one • avoids stable collapse state

35. Van Jacobson Congestion Control (1988) • Limit effective transmit window to lesser of advertised receive window or local congestion window (cwind) • Cwind starts @ 1 packet, expands 1 packet for every packet acked • called “slow start” - a misnomer since it’s exponential over time! • If a timeout occurs, assume congestion: • ssthresh = 1/2 cwind • cwind = 1 packet

36. VJ Congestion Control - 2 • After recovery, slow start continues until cwind = ssthresh • Then cwind increases by 1/cwind on every ack • this “tests the waters” to see if the path can support more traffic

37. Radio Link ARQ • TCP (and other Internet transport protocols) designed for relatively low packet loss rates • typically <1% or less than one packet/RTT • Most mobile wireless channels have higher loss rates even with coding and power control • A link-level RLP can lower the loss rate to a range that can be adequately handled by TCP • The RLP does not have to be perfect • just good enough!

38. Other Approaches • Proxying/spoofing • TCP ACK snooping/spoofing • Protocol translation (e.g., WAP) • All violate end-to-end principle • less robust • complicates security • Just say no!

39. Intermittent Connectivity • Already common on wired networks • dialups • roving laptops • Generally handled at the application layer • e.g., Post Office Protocol (POP) for email • Experimental proposals for TCP • ICMP “reachable” message

40. Mobility • Allowing a user to keep a fixed address (at some level) when changing attachment points to a topologically-routed network • both the PSTN and the Internet are topological • Roaming cell phones and Internet users are very similar in this respect

41. Mobility - Some Common Concepts • Home agents • stationary systems that “own” mobile user’s address and accept traffic on behalf of mobile user • analogous to cellular HLRs • Foreign agents • provide service to mobile user • analogous to cellular VLRs • Registration • mobile users communicate back through serving system to home agents to indicate current location

42. Multi-Layer Mobility • Mobility can be provided at several different layers with different advantages/disadvantages • IP level (Mobile IP) • Domain Name System (DNS) • Application-level • Post Office Protocol (POP) • various Internet telephony directory servers

43. Mobility at the IP Layer • Mobile user keeps fixed IP address • IP packets to the mobile user are received by the home agent and tunneled to his current location • The most transparent form of mobility • everything works as if the host were fixed • TCP connections stay open when host moves

44. IP-in-IP Tunneling Tunnel HA “owns” home net IP address block FA Internet User Rest of Internet ISP-assigned IP address Mobile user net FA and HA can be Linux, BSD, NOS, etc

45. Tunneled Packet Format Outer IP Header Src=HA Dst=FA Prot=IP Inner IP Header Src=CH Dst=User Prot=TCP (etc) TCP/ UDP header (etc) User data (if any)

46. Problems with Mobile IP • Mobile IP is elegant, but it comes at a price: • Increased per-packet overhead for tunneling • Non-optimum routing • increased delay, lowered reliability • can be serious over wide areas

47. Mobility in the DNS • The DNS provides a layer of indirection that can be used to provide mobility • When a mobile host moves, it obtains a new IP address and registers it with the server for his zone • Requires short DNS TTLs if the host moves frequently • Existing TCP connections break when moving • Advantage of much more efficient routing • no need to tunnel every user packet through home agent

48. Application Mobility • Certain important applications have protocols specifically designed to support mobility • Best example: email • SMTP implies ability to listen continuously at a fairly stable IP address for incoming mail • TURN command never implemented • POP allows user to pull mail from a relay server • mail server plays role of home agent • POP is the registration protocol

49. Is Mobile IP Really Needed? • Most mobile hosts function only as clients: • HTTP, SSH/Telnet, FTP • SMTP (for sending mail) • POP (for fetching mail) • Most couldn’t run servers anyway • intermittent operation on battery power • connectivity limits (e.g., air travel) • Most transactions are very short-lived • but not all… • Dynamic addressing has served the dialup ISP market well

50. Addressing • IP addresses are an increasingly scarce resource • 232 used to seem like such a large number • IP does use space more efficiently than PSTN • Long term solution: IPv6 • 2128 still less than number of atoms in universe… • Short-term fixes have been effective • dynamic address allocation (PPP, DHCP) • CIDR • NATs, private address blocks (e.g., 10.x.x.x)