Semi-Connected TCP/IP in a Mobile Computing ... - CiteSeerX

Semi-Connected TCP/IP in a Mobile Computing Environment Master's Thesis in Computer Science

Jrgen Svrke Hansen E-mail:[email protected]

Torben Reich

E-mail:[email protected]

Department of Computer Science, University of Copenhagen (DIKU) Universitetsparken 1, 2100 Copenhagen, Denmark

DIKU Project no. 95-6-11 June 10, 1996

Abstract We present the design, implementation and evaluation of a communication layer for mobile computing, that hides the complexity of using and switching between dierent means of communication, supports semi-connected operation, and makes scheduling of data possible on low bandwidth communication channels. Mobile hosts may either be attached directly to a LAN, or be connected by a dial-up serial connection (using GSM data adapter or Public Switched Telephone Network (PSTN) modem) to a Mobility Support Gateway (MSG) on the LAN. When the mobile host is directly attached to the LAN, regular TCP/IP communication is used. When a mobile host disconnects from the LAN, a TCP connection splits into two separate connections - one on the serial link from the mobile host to the MSG and one on the wired network from the MSG to the peer host. This provides the mobile host with the possibility of remaining disconnected for an extended period of time, as the MSG acts as a proxy host for the mobile host. The various means of communication vary greatly in bandwidth, cost, and latency. Ecient link usage at all times is provided by a system level data scheduling mechanism based on quality of service parameters. Furthermore, application level adaption is supported by allowing applications to be informed of changes in communication media. Our system performs well under normal working conditions, where virtually no reduction in performance is experienced, when a mobile host is directly attached to the LAN, and only a low increase in round-trip times are experienced when serially connected. When suciently stressed, the data scheduling mechanism may introduce a substantial overhead.

Preface The authors of this master's thesis are Jrgen Svrke Hansen and Torben Reich from the Department of Computer Science at the University of Copenhagen (DIKU). The work described in the thesis has taken place in the period from February 1995 to June 1996. In order to fully appreciate this report, the reader should have a knowledge of computer networks in general and the TCP/IP protocol stack in particular. Especially the later, implementation oriented chapters require some insight into the workings of TCP. Readers not familiar with computer networks may consult Appendix A for a brief introduction to computer networks. If a thorough introduction is required, the book [Tan89] is an excellent coverage of computer networks. We would like to thank our two advisors Birger Andersen and Klaus Hansen for their advice and comments, Eric Jul for reading and commenting the late draft, and all the members of Distlab for providing comments on our numerous presentations. Furthermore, thanks to our fellow students Jens Hynne Petersen and Jesper Larsen for taking the time to read and provide comments on the late drafts of this report. During the long hours of work we have taken great pleasure in the delicious and nutritious Mexican meals from \The Taco Shop 2" at sterbrogade. Finally, many thanks and hugs to our spouses, Camilla Falberg and Nina Frederiksen, for their support and tolerance in the many months passed since we started this project. An extra thank you to Nina for breaking the copyright laws and bringing us the two cartoon strips from the series \Bloom County" appearing in Chapters 1 and 7. We promise to visit you in jail.

1

Contents 1 Introduction

1.1 Background : : : : : : : : : : : : : : : : : : 1.2 Mobile Computing : : : : : : : : : : : : : : 1.2.1 Challenges in Mobile Computing : : 1.2.2 The AMIGOS Project : : : : : : : : 1.3 Supporting Internet Access of Mobile Hosts 1.3.1 The Environment : : : : : : : : : : : 1.3.2 The Problems : : : : : : : : : : : : : 1.4 Project Goals : : : : : : : : : : : : : : : : : 1.4.1 Design : : : : : : : : : : : : : : : : : 1.4.2 Implementation : : : : : : : : : : : : 1.4.3 Performance : : : : : : : : : : : : : 1.4.4 Evaluation : : : : : : : : : : : : : : 1.5 Our Contribution : : : : : : : : : : : : : : : 1.6 Terminology : : : : : : : : : : : : : : : : : : 1.7 Road Map of Thesis : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

2.1 Host Migration : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.1.1 IP Naming and Routing : : : : : : : : : : : : : : : : : : : : 2.1.2 IP Host Migration Support : : : : : : : : : : : : : : : : : : 2.1.3 IP and Serial Link Communication : : : : : : : : : : : : : : 2.1.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.2 Semi-Connected Operation of Communication Protocols : : : : : : 2.2.1 TCP Performance on Wireless Networks : : : : : : : : : : : 2.2.2 Disconnected Operation of TCP : : : : : : : : : : : : : : : 2.2.3 Semi-Connected Operation of Application Layer Protocols : 2.2.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.3 Adaption : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.3.1 Fair Queueing : : : : : : : : : : : : : : : : : : : : : : : : : : 2.3.2 Class Based Queues : : : : : : : : : : : : : : : : : : : : : : 2.3.3 Partially Connected Operation : : : : : : : : : : : : : : : : 2.3.4 Application-Aware Adaption : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

2 Mobile Host Support Issues

i

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

1

1 1 2 4 5 5 6 6 6 7 7 8 8 8 9

10

10 11 13 19 20 20 21 26 27 28 28 28 30 31 32

2.3.5 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 33 2.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 33

3 Design

3.1 Semi-Connected Operation of Communication Protocols : 3.1.1 Semi-Connected TCP : : : : : : : : : : : : : : : : 3.1.2 Protocol for Serial Link Communication : : : : : : 3.1.3 Triple Point Connections : : : : : : : : : : : : : : 3.1.4 Applications and Disconnected Operation of TCP 3.1.5 Summary : : : : : : : : : : : : : : : : : : : : : : : 3.2 Adaption : : : : : : : : : : : : : : : : : : : : : : : : : : : 3.2.1 Resource Monitoring : : : : : : : : : : : : : : : : : 3.2.2 System Level Adaption : : : : : : : : : : : : : : : 3.2.3 Scheduling Strategies : : : : : : : : : : : : : : : : : 3.2.4 Application Level Adaption : : : : : : : : : : : : : 3.2.5 Summary : : : : : : : : : : : : : : : : : : : : : : : 3.3 Host Migration : : : : : : : : : : : : : : : : : : : : : : : : 3.3.1 Single Local Mobility Support Gateway : : : : : : 3.3.2 Multiple Wide Area Mobility Support Gateways : 3.3.3 Summary : : : : : : : : : : : : : : : : : : : : : : : 3.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : :

4 Semi-Connected TCP

4.1 Triple Point TCP Connection : : : : : : : : : : : : : : : : 4.1.1 Establishing a Connection : : : : : : : : : : : : : : 4.1.2 Data Exchange : : : : : : : : : : : : : : : : : : : : 4.1.3 Closing a Connection : : : : : : : : : : : : : : : : 4.1.4 Connection Abortion : : : : : : : : : : : : : : : : : 4.1.5 Suspended TCP Connections : : : : : : : : : : : : 4.1.6 Summary : : : : : : : : : : : : : : : : : : : : : : : 4.2 Change of TCP Connection Mode of Operation : : : : : : 4.2.1 Inserting the Central Point : : : : : : : : : : : : : 4.2.2 Removing the Central Point : : : : : : : : : : : : : 4.2.3 Summary : : : : : : : : : : : : : : : : : : : : : : : 4.3 Implementation Notes : : : : : : : : : : : : : : : : : : : : 4.3.1 Kernel Changes : : : : : : : : : : : : : : : : : : : : 4.3.2 Limitations in TCP Connection Reset Processing : 4.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : :

5 Adaption

5.1 System Overview : : : : : : : : : : : : : : 5.1.1 Support for Adaption in MH : : : 5.1.2 Support for Adaption in MSG : : 5.2 Issues Concerning System Level Adaption ii

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : : : : : : : : : : : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

35

35 36 38 42 44 44 45 45 49 52 58 58 59 59 65 66 67

68

68 69 71 72 76 76 77 77 77 84 85 86 86 88 89

90

90 90 92 92

5.2.1 Providing QOS Parameters : : : : : : : : : : : : 5.2.2 Handling System Communication : : : : : : : : : 5.2.3 QOS Database and Scope of QOS Requirements 5.2.4 Buered Data and Lifetime of CFD : : : : : : : 5.2.5 Performance Improvements : : : : : : : : : : : : 5.2.6 API to the QOS Database : : : : : : : : : : : : : 5.3 Issues Concerning Application Level Adaption : : : : : : 5.3.1 Link Handler : : : : : : : : : : : : : : : : : : : : 5.3.2 API to Support Application Level Adaption : : : 5.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : :

6 Evaluation

6.1 Test Con guration : : : : : : : : : : : : : : : : : : : 6.2 Performance Evaluation : : : : : : : : : : : : : : : : 6.2.1 Testing Methodology : : : : : : : : : : : : : : 6.2.2 TACO Ethernet Overhead : : : : : : : : : : : 6.2.3 TACO Serial Link Overhead : : : : : : : : : 6.2.4 Quality of Service : : : : : : : : : : : : : : : 6.2.5 Eects of Disconnects During Data Transfer : 6.3 Using Standard Applications : : : : : : : : : : : : : 6.4 Conclusion : : : : : : : : : : : : : : : : : : : : : : :

7 Conclusion

7.1 Conclusions : : : : : : : : 7.1.1 Design : : : : : : : 7.1.2 Implementation : : 7.1.3 Performance : : : 7.2 Future Work : : : : : : : 7.2.1 Host Migration : : 7.2.2 Link Management 7.2.3 Data Reduction : : 7.3 Summary : : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: 93 : 95 : 96 : 96 : 98 : 98 : 99 : 99 : 99 : 100

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: 102 : 103 : 103 : 104 : 104 : 106 : 106 : 107 : 108

102

110

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: 110 : 110 : 111 : 111 : 111 : 111 : 111 : 112 : 112

A.1 Protocol Design : : : : : : : : : : : : : : : : : : : A.1.1 Connection-Oriented vs. Connection-Less A.1.2 Packet vs. Stream : : : : : : : : : : : : : A.1.3 Reliable vs. Unreliable : : : : : : : : : : : A.1.4 Flow Control : : : : : : : : : : : : : : : : A.1.5 Naming, Addressing and Routing : : : : : A.1.6 Congestion Control and Avoidance : : : : A.2 TCP/IP Protocol Suite : : : : : : : : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: 113 : 113 : 114 : 114 : 114 : 114 : 115 : 115

A A Brief Introduction to Computer Networks

iii

: : : : : : : : :

: : : : : : : : :

: : : : : : : : : :

113

B Ethernet Address Resolution Protocol (ARP) Protocol : : : : : Packet Format : Proxy ARP : : : Gratuitous ARP

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

118

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: 118 : 118 : 119 : 119

C.1 Evolution of the GSM System : : : : : : : C.2 Services Provided by GSM : : : : : : : : : C.3 System Architecture : : : : : : : : : : : : C.3.1 Mobile Station : : : : : : : : : : : C.3.2 Base Station Subsystem : : : : : : C.3.3 Network Subsystem : : : : : : : : C.4 Mobility Management : : : : : : : : : : : C.4.1 Handling of Location Information : C.4.2 Connection Handos : : : : : : : : C.5 Communication Management : : : : : : : C.5.1 Call Routing : : : : : : : : : : : : C.6 Authentication and Security : : : : : : : : C.7 GSM Data Services : : : : : : : : : : : : : C.8 Performance of GSM Data Service : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: 121 : 122 : 122 : 124 : 124 : 124 : 125 : 125 : 125 : 126 : 126 : 127 : 127 : 128

B.1 B.2 B.3 B.4

C The GSM System

121

D TCP/IP Header Compression

131

Bibliography

135

D.1 Algorithm : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 131 D.2 Design : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 132 D.3 Compressed Header Format : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 134

iv

List of Figures 1.1 One problem of mobile computing : : : : : : : : : : : : : : : : : : : : : : : : : : : 1.2 System overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

IP Addresses : : : : : : : : : : : : : : : : : : : : : : : : Subnet identi er : : : : : : : : : : : : : : : : : : : : : : Overview of Internet routing protocols : : : : : : : : : : Wireless network : : : : : : : : : : : : : : : : : : : : : : Mobile*IP on wireless network : : : : : : : : : : : : : : LSRR IP route short-circuiting : : : : : : : : : : : : : : Mobile IP short-circuiting : : : : : : : : : : : : : : : : : Growth of TCP congestion window : : : : : : : : : : : : Principle of de cit round robin : : : : : : : : : : : : : : Principle of class based queueing (obtained from [FJ95])

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

Special socket layer : : : : : : : : : : : : : : : : : : : : : Extra TCP endpoint : : : : : : : : : : : : : : : : : : : : TACO layer below IP layer : : : : : : : : : : : : : : : : Overview of the dierent forms of connection : : : : : : The triple point connection : : : : : : : : : : : : : : : : A xed MH : : : : : : : : : : : : : : : : : : : : : : : : : A roaming MH : : : : : : : : : : : : : : : : : : : : : : : Link-sharing problem among competing contenders (obtained from [FJ95]) Example of priority based scheduling : : : : : : : : : : : : : : : : : : : : : : Example of ow based scheduling : : : : : : : : : : : : : : : : : : : : : : : : IP packet redirection using ARP : : : : : : : : : : : : : : : : : : : : : : : : Detach protocol { mobile host part : : : : : : : : : : : : : : : : : : : : : : : Detach protocol { mobility support gateway part : : : : : : : : : : : : : : : Attach protocol { mobile host part : : : : : : : : : : : : : : : : : : : : : : : Attach protocol { mobility support gateway part : : : : : : : : : : : : : : :

4.1 4.2 4.3 4.4

Legend of message exchange diagrams : : : : : : : : : : : : : : : : Three way handshake in regular TCP : : : : : : : : : : : : : : : : Three way handshake in triple point TCP : : : : : : : : : : : : : : State transition diagram for triple point connection establishment :

: : : :

: : : :

: : : :

: : : :

: : : :

v

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

2 5 11 12 13 14 15 17 18 23 29 30 40 41 42 43 44 49 50 51 54 56 60 62 63 63 64 69 69 71 72

4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 5.1 5.2 5.3 5.4 5.5 5.6 A.1 B.1 B.2 C.1 C.2 D.1 D.2 D.3

Data exchange with triple point TCP : : : : Simultaneous close in regular TCP : : : : : : Non-simultaneous close in regular TCP : : : Simultaneous close in triple point TCP : : : : Non-simultaneous close in triple point TCP : State transition diagram for triple point close Legend of TCP sequence variable illustrations TCP sequence variables : : : : : : : : : : : : Inconsistent MSG point : : : : : : : : : : : : Data received by MH after state transfer : : :

: : : : : : : : : : Overview of the adaption subsystem in the MH : The QOS database : : : : : : : : : : : : : : : : : TCP request/reply scenario and QOS bindings : UDP request/reply scenario and QOS bindings : The QOS database|extended to comprise MSG : Example program using link handlers : : : : : : : TCP/IP protocol suite : : : : : : : : : : : : : : : : ARP packet processing : : : : : : : : : : : : : : : : ARP packet format : : : : : : : : : : : : : : : : : : General architecture of the GSM network (obtained from [Rah93]) : Call routing for a mobile terminating call (obtained from [Rah93]) : TCP/IP Header (obtained from [Jac90]) : : : : : : : : : : : : : : : : Header Compression Model (obtained from [Jac90]) : : : : : : : : : Compressed Header (obtained from [Jac90]) : : : : : : : : : : : : : :

vi

: : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : :

: 73 : 73 : 74 : 74 : 75 : 75 : 79 : 79 : 81 : 81 : 91 : 93 : 94 : 95 : 97 : 101 : 116 : 119 : 120 : 123 : 127 : 132 : 133 : 134

List of Tables 2.1 Examples of generic resources : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 32 3.1 Actions related to change in communication interface in MH : : : : : : : : : : : : 50 4.1 TCP sequence variable summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : 78 4.2 Mapping from MH TCP protocol state to proxy TCP protocol states : : : : : : : : 83 4.3 New ioctl commands : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 88 5.1 Responsibilities of daemons in the adaption subsystem : : : : : : : : : : : : : : : : 90 5.2 API to QOS database : : : : : : : : : : : : : : : : : : : : : : : : : : : 99 5.3 API to the link handler linkd : : : : : : : : : : : : : : : : : : : : : : : 99 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9

Comparison of round-trip time on Ethernet - MH with and without TACO Comparison of throughput on Ethernet : : : : : : : : : : : : : : : : : : : : Concurrent UDP round-trip time measurements on modem : : : : : : : : : Concurrent TCP round-trip time measurements on modem : : : : : : : : : Multiple UDP throughput measurements on modem : : : : : : : : : : : : : Multiple TCP throughput measurements on modem : : : : : : : : : : : : : Active interactive and pending bulk transfer connections concurrently : : : Active and pending bulk transfer connections concurrently : : : : : : : : : : Eects of disconnects on throughput on TCP connections using GSM : : :

C.1 C.2 C.3 C.4 C.5

Connect time and fault rate for GSM : : Round-trip times for GSM : : : : : : : : Bulk data transfer for GSM : : : : : : : Round-trip times for GSM { own data : Bulk data transfer for GSM { own data

vii

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: 104 : 104 : 105 : 105 : 105 : 106 : 107 : 107 : 108 : 128 : 129 : 129 : 130 : 130

Chapter 1

Introduction In this thesis we present the design and implementation of a system providing mobile computers with automatic and transparent access to TCP/IP based networks using available forms of communication. Users of mobile computers may easily change between using a modem on a Public Switched Telephone Network (PSTN), GSM data link adapter and Ethernet connections, and are able to dierentiate the use of the various links based on quality of service requirements.

1.1 Background Our work has been motivated by the following key factors: In recent years, as the size and cost of mobile computers have decreased, the number of people using these has increased. Furthermore, more and more people use mobile computers as their only computer, connecting it to their corporate network in the morning, and taking it with them home in the evening. The mobile computers of today have the ability to connect by the traditional forms of network technology, and recently, through the extended coverage of cellular phone systems, to connect by a wide area wireless communication system. Finally, the tremendous growth of the Internet in the last couple of years indicate, that there is a huge interest in using such a network, and that the Internet in some form will be the network of the future. The main goal is thus to provide users of mobile computers with easy access to the Internet at any time, any place using available forms of communication, or expressed in more technical terms, to explore the possibilities of providing mobile computers with access to a xed network while hiding the complexity of using and switching between dierent means of communication.

1.2 Mobile Computing Basically mobile computing is the ability of a user to carry with him a computer which may be used at dierent locations. From an operating system design point of view, the support for using 1

CHAPTER 1. INTRODUCTION

2

Figure 1.1: One problem of mobile computing mobile computers becomes interesting only when the mobile computer is (at least intermittently) part of a computer network. Otherwise, when the mobile computer is used isolated, the only problem dierent from stationary computers is to reduce power consumption, which is primarily a hardware design matter, although support from the operating system can be advantageous. In our view, the characteristics of mobile computing are the following: The performance and availability of hardware resources is limited. The hosts commonly move between dierent physical networks with dierent characteristics. The hosts commonly move between dierent administrative domains. When looking at the devices used for mobile computing, there are two main directions; mobile terminals and mobile computers. Mobile terminals have very limited capabilities and relies heavily on accessing stationary computers, whereas the mobile computer is able to perform many of the computing tasks of stationary computers, at the expense of the size and power consumption. Thus the two dierent approaches of mobile devices emphasize on respectively continuous network access and caching.

1.2.1 Challenges in Mobile Computing

In the following we describe the main problems in mobile computing arising from the limitations in hardware, the physical movement of host and user, and the movement between dierent administrative domains. These problems are also present in todays distributed systems, but in mobile computing they are central problems as opposed to unlikely occurrences or error conditions. For a more thorough description of the issues of mobile computing, see [Duc92], [MDC93], and [IB94].


3

1.2.1.1 Host Migration The fact that a mobile host may actually migrate from one network to another, complicates the network related matters of locating a speci c host and determining the optimal route of a packet to a speci c host. There exists solutions to these problems for static con gurations of networks, but most of these are based on geographically determined hierarchical structures in order to be ecient. If only local movement and a limited number of hosts are considered, acceptable designs exist [IDJ91, IDJ93], but to provide wide area movement of a large collection of hosts, these solutions are less than optimal, depending on a host in the \home" network of the hosts to perform redirection [Per95, IDJ93]. Also the high level naming systems used in todays networks (e.g., DNS) have either geographically or administrative domain information embedded in the naming structure. Thus moving a mobile host or user to a new administrative domain requires a new name. Another problem of moving between administrative domains is security. A host trusted in one administrative domain may not be trusted in another, and likewise may the user of a mobile host not trust all administrative domains. Thus both authentication and encrypted data transfer are necessary to provide secure mobile computing. Authentication Services like Kerberos [SNS88] already provide both authentication for hosts and users, and encrypted communication. Also the Mobile IP design [Per95] addresses security issues, allowing an administrative domain to restrict the actions of foreign mobile hosts.

1.2.1.2 Disconnected Operation

Due to the limited availability of hardware resources, a mobile host may experience periods of disconnectivity. These may result from, e.g., limited wireless coverage, low power of wireless transmitter, to save battery life, or because the available service is too expensive. The common way of supporting disconnected operation is by using replication of objects. A cache of objects needed from other hosts is maintained on the mobile host, and during periods of disconnectivity the user works on these replicas. The two major problems with this approach are, that it is not possible to maintain consistency if several users, of which at least one is disconnected, are allowed to update an object at the same time, and that it is dicult to determine, which objects should be cached. The approach taken to replicate objects may be either pessimistic, in which case all objects, that the user wants to update, must be exclusively locked, or optimistic, in which case several users are allowed to update the same object, requiring that reintegration is performed if update con icts are detected. An example of a le system, that supports disconnected operation using optimistic replication, is the CODA le system [SKM+ 93]. A less strict model is semi-connected operation (also know as weakly or partially connected), in which it is assumed possible to establish a connection (possibly of a very low quality) to a network, but that voluntary or involuntary periods of disconnectivity are common. Two examples of designs using semi-connected operation are an extension of the CODA le system [MES95], and the Bayou system [JKW95].


4

1.2.1.3 Adaption Available resources may change due to hardware limitations (e.g., limited coverage of wireless communication systems) or available resources may change due to entering a dierent administrative domain, where the status of the mobile user/mobile host is dierent (e.g., the user may have to pay for using a wireless LAN). It is therefore important for the mobile host to be able to adapt to changes in its environment (disconnected operation could be viewed as a special case of adaption). In cases, where a change in resources is related to hardware of the mobile host, local monitoring is enough to detect the changes, but in cases where the changes occur when entering a new administrative domain, resource discovery must be supported both by the mobile host and the administrative domain. Furthermore, accounting should be provided, allowing an administrative domain to bill and possibly limit the resource usage of a foreign mobile host.

1.2.2 The AMIGOS Project

This thesis is part of the Advanced Mobile Integration in General Operating Systems (AMIGOS) project, which aims at providing transparent support for semi-connected operations on mobile computers running a standard operating system. The project is a collaboration between Departamento de Informatica/INESC at Universidade do Minho, Braga, Portugal, and DIKU, Department of Computer Science, University of Copenhagen, Denmark. It consists of the following ve phases:1 1. A transparent communication layer, which is an extension of TCP/IP with support for disconnected operation, and which|based on availability|transparently selects either an Ethernet, a telephone line, or a cellular phone line. 2. A NFS caching layer, where the mobile host maintains a large (10MB - 100MB) cache of les, to enable the user to access les while disconnected or weakly connected. The contents of the cache is determined by a user pro le and a dynamic replacement strategy. 3. A reexecutable transaction scheme with support for semi-connected operations. This dier from traditional transactions in that the mobile host|while disconnected|may be unable to obtain locks for an extended period of time. 4. An object-oriented resource management system, in which all resources of the distributed system will be made available as objects. These objects may be used for semi-connected operation by extending the transaction scheme to cover these objects. 5. A complete object-oriented environment, where distributed object-oriented languages like Emerald and Ellie will be extended with support for transactions. 1

A description of the AMIGOS project may be found at


5

1.3 Supporting Internet Access of Mobile Hosts The goal of providing users of mobile computers with easy access to the Internet is a very uy one. In order to get more meat on the bones, we will in the following specify, what computing environment we will consider, which problems we will address, what goals we have and how we will evaluate these goals.

1.3.1 The Environment

The type of system we are considering consists of a number of mobile hosts (notebooks), and a stationary gateway, which is used by the mobile hosts, when they connect via serial links. An example of such a system is given in gure 1.2. At present three means of communication are being considered; LAN, PSTN modem, and GSM adapter. The GSM adapter acts like a PSTN modem, but with higher latency, higher cost, and lower bandwidth than most modems used today. We assume the mobile host is predominantly used as a normal workstation, but that the ability

ink

Ml

GS

r

Modem link Mobile Host Mobility Support Gateway

Mobile Host

Ethernet

Mobile Host

Internet

Mobile Host

Stationary Host

Figure 1.2: System overview to be disconnected, or be connected by a serial link, for periods of varying length (from hours to days) is attractive to the user. As one of the most widely used network communication protocol systems today is the TCP/IP protocol suite and as it is the standard protocol suite of the Internet, we have chosen to solely support systems using TCP/IP, but many of the elements in our design regarding communication protocols are applicable to other protocol families too. The development will take place in the Unix like operating system Linux.2 Linux is chosen, because it is a general purpose operating system and because the source code is freely available. 2

A description of the Linux operating system can be found at .


6

1.3.2 The Problems

With a focus on the communicational aspects of mobile computing and the challenges presented in Section 1.2.1, the use of mobile hosts in an environment as described in Section 1.3.1 gives rise to the following problems:

Semi-Connected Operation Applications may not survive long periods of disconnected opera-

tion, as the existing TCP/IP implementations are not designed to handle this. Performance of TCP may be degraded due to retransmission and congestion control mechanisms, and TCP connections may even terminate due to connection time-outs. Applications building reliable protocols on top of UDP may also suer from these problems. Adaption The available forms of communication vary greatly in both cost, bandwidth, and latency. Existing TCP/IP implementations do not allow the system to adjust to changes in communication media. It does not provide for neither regulating the trac on the link through system level data scheduling nor does it provide applications with a facility enabling them to detect changes in the communication media and make proper adjustments. A system unadjusted to its environment pose a serious threat to ecient link usage and overall system performance. Host Migration The current routing mechanisms used in TCP/IP are not able to handle a mobile host migrating between dierent networks without disrupting the running applications.

1.4 Project Goals The purpose of this project has been to design and build a system supporting semi-connected operation and adaption. The project can be split up into three phases; design, implementation, and evaluation. For each of these phases we have a set of goals, that serve as guidelines. As the performance of the system must be in mind, both when designing and implementing it, we also have a set of performance goals. In the following we present these four sets of goals.

1.4.1 Design

Our main design goals are: Hide complexity of using and switching between dierent means of communication from both user and applications Support semi-connected operation Allow for eective use of available bandwidth/communication medium Allow for incorporation of support for host migration In our design we will focus on the three rst items, as there has already been devoted a substantial eort to supporting IP routing to mobile computers (see Section 2.1). In order to limit the scope of this project, we restrict the design to the case where a mobile host is either


7

connected to its home LAN or one speci c gateway in the home LAN, but our design should allow for an extension to make possible for mobile hosts connecting to dierent LANs and dierent gateways. Furthermore, we restrict ourselves from considering problems concerning security. The transparent use and switching between dierent media will be supported through the provision of a uniform device interface, such that details on which communication media to use and dierences on how to use the various media available will be hidden from applications. Support for semi-connected operation will be obtained through the introduction of a mobility support gateway . When a mobile host is physically disconnected from the local net, the mobility support gateway of the mobile host will maintain the connections to the peers, which may or may not be aware of the mobile host being disconnected. Eective use of available bandwidth/communication interface will be accomplished by providing support for system and application level adaption to changes in the computing environment. System level adaption will be supported by providing users with means to specify the link requirements of a given type of communication through either con guration les or system calls. The communication layer will use this information to schedule communication in a way that ensures eective use of available bandwidth. Application level adaption is provided through system calls, making it possible for applications to request noti cation from the communication layer, when changes occur in the computing environment related to communication. Due to huge size of the Internet, it is not viable to require changes to all hosts connected to the Internet, so we impose the following constraint on our design in order to make it acceptable: No changes of the communication layer in stationary hosts should be required except for the mobility support gateway

1.4.2 Implementation

As in any experimental project, the implementation is as important as the design, and our main implementation goal is to prove that our design is viable. This we intend to do by implementing our design on the Linux operating system.

1.4.3 Performance

Our performance goals are: Moderate overhead for mobile hosts operating semi-connected Negligible overhead for mobile hosts directly attached to a LAN We expect the system to operate with negligible overhead, when a mobile host is attached to a LAN, as a minimum of system intervention is required to support xed mobile hosts. However, substantial system intervention is required to support mobile hosts operating semi-connected, and in this situation we expect noticeable overhead. As the focus of the implementation is to establish whether or not our design is viable, some performance degradation is acceptable for mobile hosts operating semi-connected.


8

1.4.4 Evaluation

In order to evaluate the system support for semi-connected operation and adaption, we will study the behaviour of existing applications running in a mobile computing environment. Applications must be able to survive long periods of disconnectivity as well as mobile hosts switching between being semi-connected and xed to the LAN. To evaluate our performance goals, we will perform measurements of the two main performance characteristics of network connections; packet round-trip times and throughput. These measurements will be obtained on both serial links and LAN, using system con gurations with and without our system.

1.5 Our Contribution Previous work has focused on providing support for either semi-connected operation (see [BB94], [YB94] and [KRA94]) or adaption to changes in the environment of a mobile host (see [HH95] and [NPS95]). Our main contribution is providing the design and implementation of a system that integrates support for semi-connected operation with support for adaption. Furthermore, we have enhanced the support for semi-connected operation and adaption. The enhancements can be characterised as follows:

Semi-connected operation { Disconnected operation is supported, allowing applications to survive longer periods

of disconnectivity. { Transparent switch of communication interface, without breaking existing connections, allowing the best interface available to be used at all times. { No performance penalty when a mobile host is LAN connected, reducing the penalty for supporting mobile computing to mobile hosts operating semi-connected. Adaption { Provision for both application and system level adaption. This allows for applications to adjust individually as well as providing system level support to those applications, that are unable to adjust to their environment.

1.6 Terminology A mobile host (MH) has three modes of operation: attached to the LAN, connected to the Mobility Support Gateway (MSG) via serial link, and disconnected. In the rst case, we refer to the mobile host as a xed mobile host (FMH), and in the latter two cases, the mobile host is referred to as a roaming mobile host (RMH). Thus, a RMH may be either connected or disconnected. The mobile host may communicate with other hosts in the network, and these may be either stationary hosts (SHs), which are hosts always located in the same network, or other mobile hosts. In situations, where the type of the other host is not important, we will refer to it as the peer host (PH).


9

1.7 Road Map of Thesis The thesis is organized as follows: Chapter 2 describes in detail the issues of host migration, semi-connected operation, and adaption, covering related work in these areas. Chapter 3 is an overview of our design. Chapter 4 provides a detailed description of the support for semi-connected operation of TCP. Chapter 5 covers the implementation oriented aspects of our data scheduling. Chapter 6 is an evaluation of performance and functionality. Chapter 7 contains an overall evaluation of our goals, and a description of future work. Have a nice trip.

Chapter 2

Mobile Host Support Issues In this chapter, we give a more in depth discussion of the problem areas already introduced: Host migration Semi-connected operation of communication protocols Adaption For each area we provide an introduction to the main problems, an overview of the work already done in the area, and a summary evaluating the usefulness of this work with regards to our main goals.

2.1 Host Migration As mentioned in Chapter 1, one of the key properties of mobile computing is the ability of mobile hosts to migrate between dierent networks and dierent administrative domains. In this section we take a closer look at the problems of location management and routing in this context. The goal is to provide a location independent way of identifying mobile hosts, and at the same time provide an ecient way to determine the present location of a mobile host in order to allow a route to be constructed. In the design of computer networks up till now it has been an underlying assumption, that a host is stationary. This has been used to provide ecient solutions for locating hosts and for routing, but this also means that the introduction of migrating hosts is a problem. An area, where mobile objects actually have been considered, is that of distributed operating systems, and experience from that eld tells us, that it is very hard to provide an ecient location service for mobile objects. The general idea is to provide a two-level naming system, where the top level name (often called the symbolic name) is location independent, but can be mapped to a low level location dependent name (this could also be viewed as the address of the object). The problems mainly arise from providing a fast, scalable mapping from name to address. That is, ecient mapping even with a large number of mobile objects and wide area movement. The problem of routing (ie., choosing a path in the network to a given host) relies heavily on ecient location management. After all, without a proper knowledge of the location of a given 10

CHAPTER 2. MOBILE HOST SUPPORT ISSUES

11

host, it is hard to provide a correct, less to say an optimal route to a given host. Host migration may of course complicate matters, as this may change the (optimal) route to the host. In the following the IP naming and routing mechanisms are explained, and previous work in the area of supporting host migration in TCP/IP is reviewed.

2.1.1 IP Naming and Routing

In TCP/IP the location management and routing is part of the IP layer, as this has the responsibility of host to host delivery of packets. IP uses a two-level naming scheme, where the symbolic names (called domain names) are mapped to one or several IP addresses, that are used for routing. Both domain names and IP addresses are structured hierarchically with each administrative domain having the authority to assign names and addresses within a subtree of these hierarchical structures. The routing protocols of IP are made more ecient by using only the network identi er of the hierarchical structure of IP addresses. As the networks are often con ned to a single administrative domain or a limited geographical area, the routing is to a certain extent based on the administrative or geographical location of a host. Below is a more detailed description of both IP addresses, domain names and IP routing, and we explain why host migration is not possible using the current IP facilities.

2.1.1.1 IP Addresses Class A 0

netid

hostid

Class B 1 0

netid

hostid

Class C 1 1 0

netid

hostid

Class D 1 1 1 0

multicast address

Class E 1 1 1 1

Figure 2.1: IP Addresses Each interface attached to the Internet must be assigned a unique IP address. The general IP address is 32 bit long, and consists of a class identi er, a network identi er and a host identi er. By splitting the IP address in a network and a host identi er, it is possible to limit the size of the routing tables in the Internet, as normally only the network identi ers are used for routing, when


12

the routers are located outside the destination network. There are ve classes of IP addresses, where classes A, B and C are of the general form, class D is used for group multicasting, and class E is reserved for future use. The ve classes are shown in Figure 2.1. Within each network, an extra hierarchical level may be added. This is called subnetting, and allows the administrator of the network to partition it into smaller nets (called subnets). The extra level is made by using part of the host identi er as a subnet identi er (see Figure 2.2). This subnet identi er is only used internally in the network, thus not aecting the size of other routers in the Internet. The Internet Class B 1 0

netid

hostid

Class B with subnet 1 0

netid

subnetid

hostid

Figure 2.2: Subnet identi er Network Information Center (the InterNIC) is a central authority, which has the responsibility of assigning network identi ers. The host identi ers are assigned locally within each network.

2.1.1.2 Domain Names As mentioned above, the use of symbolic names in the Internet are provided by the hierarchically structured domain names. The mapping between IP addresses and domain names is made by implementing a distributed database (called the Domain Names System or DNS), where each administrative domain must provide a DNS server, that is able to perform the mapping of the hosts belonging to that administrative domain. The actual name resolution is done at the application level, and thus the lower layers know nothing about the symbolic names. To see how this con icts with host migration, we need to consider how applications use TCP/IP. When using an interface like BSD Sockets [Ste90], the application will obtain the IP address of the peer host by resolving the domain name before any communication takes place. Thereafter the application will use that IP address for all communication to the peer host. If the peer host migrates while this communication takes place, and thus changes IP address, all IP packets subsequently sent to that host will be lost. The problem is, that the IP addresses are not isolated at a low level, where they may be easily updated in case of host migration, but that they are instead used as names on an equal level of the symbolic names.

2.1.1.3 IP Routing The routing protocols of the Internet may be viewed as a hierarchy. At the top level we have the protocols taking care of routing between dierent administrative domains (in this context called Autonomous Systems or ASes). These protocols are called Exterior Gateway Protocols (EGPs) and the current standard EGP is the Border Gateway Protocol. The next level of the hierarchy are the Interior Gateway Protocols (IGPs), which take care of routing internally in an


13

AS. The AS may itself decide on which IGP to use, but the current standards are the Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), where OSPF is the more advanced. Both the EGP and the IGPs are distributed, adaptive protocols, and thus take care of both collecting information about the network state and actually selecting routes. The lowest level of the hierarchy is the static routing protocols, as these are commonly used only in LANs. The hierarchy is depicted in Figure 2.3. Exterior Gateway Protocols

Interior Gateway Protocols

Static Routing Protocols

GW AS GW

Legend:

H

H

H

AS AS

Autonomous system

GW

Gateway

GW H

H

H

AS

AS

GW GW

Host

Figure 2.3: Overview of Internet routing protocols The IP routing is done on a hop-by-hop basis, meaning that each host locally decides what the next destination of the IP datagram should be. If the host is directly connected to the destination host, it sends the IP datagram directly to that host. Otherwise the datagram is forwarded to a router, which is assumed to be \closer" to the destination host. These routing decisions are based on a local routing table, which is either statically assigned or updated by one of the adaptive routing protocols mentioned above. When trying to decide the next destination of an IP datagram, the routing table is searched in the following order: 1. Try to nd an entry matching the destination IP address perfectly. 2. Try to nd an entry matching the (sub)network identi er of the destination IP address. 3. Use the default entry. Even though the routing protocols used may allow changes in the routes to a given host, this cannot be used to support host migration, as the routing mechanism is based on the (sub)network identi ers. A solution based on inserting the full IP addresses of mobile hosts in routers is not feasible, as this both would require a tremendous number of updates to routing tables on host migration and an explosion in the size of the routing tables.

2.1.2 IP Host Migration Support

The goal of the IP host migration support is to provide transparent host migration between dierent networks. As described in the previous section, the IP address change is undesirable, as both applications and transport layer protocols assume that the same IP address is used during


14

their whole lifetime. The main research has thus concentrated on routing designs, that allow the hosts to keep their IP address when migrating to a dierent network. In general this research is hampered by the huge size of the Internet { in order to be acceptable a design should not require changes to any hosts, routers or gateways belonging to networks, which are not actively committed to support host migration. In the following we take a closer look at some of the current designs for IP mobility support. As these designs are in uenced by the common design of wireless networks, a few words about this is in place. Each MH has a wireless communication device. The area, in which the MHs have access to the wireless network, are comprised by cells, where each cell is de ned by the area covered by a wireless transceiver unit. These units are connected to or act as a stationary host (called a base station) in a wired network, and these base stations take care of data communication between a MH and other hosts. When a MH moves from one cell to another, it will often also change base station although several wireless transceiver units could be connected to the same base station. The base station change is called a hand-o, and may result in a pause in the communication due to, e.g., redirection of data from old to new base station or areas uncovered by the wireless network. An example of a wireless network is given in Figure 2.4. As an example of how the wireless network works, let us assume, that MH H1 wants to transmit a packet to MH H2. H1 rst transmits the packet to base station B1, which forwards the packet to base station B2. B2 then transmits the packet to H2. The process of locating the base station, which a packet for a given MH is to be transmitted to, is the main task of supporting wireless networks.

Cell C1

Cell C2 MH H1

base station B1

MH H2

base station B2

LAN

Legend: Wireless transceiver

Figure 2.4: Wireless network Another important concept of these designs is the home IP address and the home network of a MH. The home IP address is an IP address which remains unchanged, even though the MH migrates, and the home network is the network identi ed by the net id of the home IP address or in other words, the home network is the network, which an IP packet for the MH is routed to by the conventional IP routing mechanisms when using the home IP address. A general use of the home network is to let a stationary host in the home network of a MH have the responsibility of intercepting and forwarding packets destined for that MH to a temporarily assigned IP address in another network.


15

2.1.2.1 Mobile*IP The Mobile*IP design [IDJ91, IDJ93] was designed to support \campus-wide" mobility in a single wireless network. The main idea is to create a logical subnet, called the Mobile Subnet, in which all MHs are assigned an IP address. The base stations of the wireless network, which in this design are called Mobility Support Routers (MSRs), act as gateways to this Mobile Subnet, and each MSR has the responsibility for one or more cells in the Mobile Subnet. This involves keeping track of the MHs, that are currently located in one of it's cells, and routing IP datagrams to and from these MHs. When a datagram destined for a MH enters the network, which the Mobile Subnet is part of, it is routed to the nearest MSR. This is done by making the nearest MSR the default router for the Mobile Subnet in all routers and hosts in the network. When a MSR receives a datagram, it has the following options: If the MH is handled by the MSR, the IP datagram is sent directly to the MH. If the MSR knows of another MSR, that it believes handles the MH, it forwards the IP datagram to that MSR by encapsulating it in a new IP datagram with the other MSR as the destination. If the MSR does not know the location of the MH, it queries the other MSRs, and drops the datagram. If a reply is received from a MSR handling the MH, the location information is updated, and any subsequently received IP datagrams for the MH are forwarded to the other MSR. In Figure 2.5, we have a network N, and a mobile subnet SN of N. There are two MSRs M1 and M2 and two MHs H1 and H2, which belong to the mobile subnet SN, and furthermore there is a stationary host and a gateway, which are only members of net N. All packets from other networks are routed to the gateway, which then forwards the packets to for example MSR M2. If M2 receives a packet destined for H1, it forwards it to M1, which then transmits it to H1 Net N Mobile subnet SN Cell C2

Cell C1

MH H2

MH H1

SH

MSR M1

MSR M2 LAN

Legend: Wireless transceiver

Figure 2.5: Mobile*IP on wireless network

Gateway


16

When a MH moves from one cell to another, it informs the new MSR of its presence and the new MSR then informs the old MSR. The old MSR creates a forwarding pointer to the new MSR, and all datagrams received for the MH thereafter are forwarded. Furthermore the old MSR sends a redirect message to any MSR, that sends it an IP datagram for the moved MH. From the point, where the MH has changed to the new MSR, until the new MSR informs the old MSR of the change, IP datagrams may be lost. The design also includes support for a pop-up host, which is a MH connecting to a network outside the Mobile Subnet. On connect a pop-up must obtain a temporary IP address, and then register with a MSR in the home net. Internally the pop-up uses it's original IP address when sending datagrams, but all IP datagrams to and from the pop-up are routed through the MSR in the Mobile Subnet using the IP in IP encapsulation. This kind of routing may result in a rather poor performance, as the IP datagrams always must pass through a MSR in the MHs Mobile Subnet. This approach is suitable only for localised mobility due to the following three design choices; the MHs must belong to the same subnet, the pop-up support uses an inecient routing mechanism, and the location mechanism is based on broadcasting. The IP in IP encapsulation used for forwarding IP datagrams (also called tunneling) increases the size of a datagram by 20 bytes. This can result in increased fragmentation, which together with the added overhead may degrade performance. Furthermore, the network trac is increases by the forwarding.

2.1.2.2 Loose Source Routing Approach To avoid using new protocols like the IP in IP encapsulation, Bhagwat and Perkins [BP93] have made a mobile IP support design, where the Loose Source and Record Route (LSRR) option of IP has been utilised to provide IP datagram route short-circuiting. The LSRR option lets an application specify a list of IP addresses, which must be traversed by the IP datagram in the speci ed order. The IP datagram is allowed to pass through other hosts, hence the loose routing. This list is limited to 9 IP addresses due to the limited size of the options part. When an application receives a datagram with the LSRR option, it should retrieve the speci ed route, and use the reversed route when sending replies. In this design the MHs are also grouped in subnets, and each subnet has a Mobile Router (MR), which keeps track of the current position of the MHs belonging to that subnet. A MH connects to the wired network via a Mobile Access Station (MAS), which act as the gateway between the wired and the wireless networks. This MAS may be located in any network, but a MH may use at most one MAS at any given time. Thus, the MR keeps track of the current MAS of the MH. When a MH sends datagrams to a SH, it inserts a LSRR option with the MAS as an intermediate host. When the SH receives the datagram, it uses the reverse route when sending datagrams to the MH. These datagrams will then be routed to the MAS, which then forwards the datagrams to the MH. This makes the route as optimal as possible when using normal IP routing mechanisms. If the SH is the initiating part, the datagrams will be routed to the reserved (sub)net of the MH, where they are intercepted and forwarded by the MR. This is done by inserting the MAS as an intermediate host using LSRR. When the MH replies, the LSRR routing happens as above, and further datagrams should use the optimal route. This situations are depicted in


17

Figure 2.6(a). SH

MAS

MR

MR

MAS

MAS

MH

MH

Legend: Route when LSRR is not used by the sender Route when LSRR is used by the sender

MH (a)

(b)

Figure 2.6: LSRR IP route short-circuiting When sending from one MH to another, there are two possibilities. Either the MHs use the same MAS, in which case the datagrams are sent directly from the MAS to the receiving MH, or the MHs use dierent MASes, in which case the rst datagram from the initiating host is sent to the MR of the receiving MH, which then forwards the datagram to the receiving MH. Subsequently the optimal route between the two MASes is used by making both MASes intermediate hosts. This situation is depicted in Figure 2.6(b). When a MH changes MAS, an message is sent to the MR of the MH updating the location of the MH. The MH uses the address of the new MAS in the LSRR option, thus making replies follow the (new) optimal route. This approach should provide optimal routing of IP datagrams without using encapsulation, and without requiring changes to existing routers and stationary hosts. Currently it is only TCP, which provides reversal of the route speci ed by the LSRR option, and therefore UDP datagrams from an SH are always routed via the MR. Furthermore, several existing TCP/IP implementations (4.3 BSD, SUN OS 4.1) incorrectly process the route reversal, so TCP segments from the SH must be routed through the MR as well. Thus, the realisation of the scheme would require upgrades to many stationary hosts. This scheme may also introduce fragmentation, as the LSRR option will increase the header size of the IP datagrams with minimum 8 bytes. Although the overhead is smaller (8 - 12 bytes) than IP in IP encapsulation, the LSSR option may increase the processing time at routers, which are optimized for IP datagrams without options.

2.1.2.3 Mobile IP The Internet Engineering Task Force is currently working on a protocol [Per95], which should become the standard mobility support for IP version 4. Each MH has an IP address belonging to a real network (wired or wireless) called the home network. In the home network, one or more home agents are located. They have the responsibility of forwarding IP datagrams to the MHs of the home network, which are currently located outside the home network. The Mobile IP scheme also introduces the concept of a foreign agent. This agent provides IP datagram routing to foreign MHs connecting to the network, where the foreign


18

agent is located. The foreign agent also allows an administrative domain to control the acceptance of foreign MHs. This is illustrated in Figure 2.7. home agent

foreign agent

MH

Legend: Regular IP routing

PH

IP in IP encapsulation

Figure 2.7: Mobile IP short-circuiting When a MH connects to a network, it tries to locate a mobility agent. This may be done either by link-layer identi cation or by using ICMP router discovery and solicitation [Dee91]. When the MH has located one or several agents, it rst examines whether one of them should be one of it's home agents. If this is the case, the MH is located in it's home network and it may use it's ordinary IP address. If no home agent is discovered, the MH may either be assigned a transient IP address and be connected directly to the network, or it may be required to relay all messages through a foreign agent. In the rst case, the MH registers the transient IP address with one of it's home agents, causing that home agent to intercept and forward all IP datagrams destined for the MH to the transient IP address. The IP address, which the home agent forwards IP datagrams to, is called a care-of address. When the MH connects via a foreign agent, all IP datagrams are relayed through that foreign agent. In this case the foreign agent forwards the registration request to the home agent of the MH, and the IP address of the foreign agent will be the care-of address of the MH. The datagram forwarding is done using IP in IP encapsulation. This scheme does not try to obtain route optimality, as datagrams destined to a MH are always routed to the home network of that MH, but as IP datagrams originating from a MH are routed as normal, these datagrams will follow the optimal route. The Mobile IP design diers from the other mobility support solutions by also focusing on authentication and security requirements. A MH is required to authenticate itself, when it registers with a home agent. Foreign agents may require authentication from both a MH and it's home agent.

2.1.2.4 Virtual Internet Protocol In an attempt to introduce a two-level naming scheme, the concept of a Virtual Network (VN) on top of an existing Physical Network (PN) was introduced by [TYT91]. The idea behind the VN is to provide each host with a xed address in the VN, and then let the network layer provide a mapping between the VN address and the current PN address of a host, such that the transport across the PN still is based on the PN addresses. In this way a host can migrate to another network, and be assigned a new PN address without aecting the higher layers of the protocol stack. The main problem of this approach is to distribute and update the VN to PN address mappings, and in [TYT91] this is done using a ooding approach. Timestamped mappings ow through the network, allowing routers and hosts update their mappings, if they receive a new or newer one.


19

Each host has a home network in the physical network, and the host's VN address is also a physical address in it's home network. Each home network contains a router, which has the newest VN to PN mapping of all hosts belonging to that home network. All hosts and routers should have an Address Mapping Table (AMT), which contains all VN to PN mappings known to that host or router. The datagrams transmitted by a hosts contain a timestamped VN to PN mapping of both itself and the receiver. If a PN address of the receiver is not known, the VN address is used as the PN address, which causes the packet to be routed to the home network, where the newest PN address is known. When a host or router receives a datagram, it updates it's AMT with the senders VN to PN mapping. A router also updates the destination PN address of the datagram, if it has a newer VN to PN mapping entry. In this way, the route of the datagram may be changed, if a router has more up to date location information. Thus, when a datagram travels from sender to receiver, all intermediate host and the receiving host update their address mappings if necessary. As it is always the host itself, which timestamps it's VN to PN mapping, there are no problems deciding which mapping is the newest, as long as each host has a local clock, that is monotonously increasing. When a host moves from one net to another, it broadcasts an invalidate message on the net it leaves. This causes the routers, which currently hold an entry for that MH, to remove the entry, and forward the invalidate message to the other nets attached to that router. If no entry is found, nothing is done. In this way, the invalidate message is only propagated to networks, where routers may actually know the MH. This scheme has been implemented with IP as the network layer protocol, and is known as Virtual IP (VIP). It is not required, that all hosts support VIP, but if optimal or near optimal routing is to be obtained, it is necessary that most routers support VIP. The header containing the VIP addresses and the timestamps is implemented as an IP option. This, as the IP encapsulation, may increase fragmentation, and it also results in extra processing overhead at most routers, even if they do not support VIP, because many existing routers are optimized for processing IP datagrams without options. Furthermore the sizes of the AMTs may grow to a considerable size, when large scale mobility is considered.

2.1.3 IP and Serial Link Communication

A rudimentary form of mobility can be obtained by using serial links to connect to the xed network from dierent geographical places. There exists two standard protocols for transmitting IP packets over serial links; SLIP [Rom88] and PPP [Sim94], where PPP is intended to be the TCP/IP standard serial link protocol of the future. This allows the user to move around and connect to a gateway in the xed network when the possibility arises, and in this way gain access to the xed network. When a host connects to a gateway, it may either request to be assigned a speci c IP address or it may let the gateway assign it an IP address dynamically (this is only supported by PPP). As packets still need to be routed to the mobile host through the gateway, these addresses must be part of one of the IP subnets, that the gateway is part of. Thus, as PPP is designed primarily to provide stationary host with a way to eciently use point-to-point connections, such as dial-up PSTN modem links, it does not provide support for hosts changing between dierent networks and at the same time keeping their address.


20

2.1.4 Summary

Host migration requires, that the mobile host is able to move between dierent networks and dierent administrative domains. In order to provide this transparently, it should not be required that the host or the running applications are restarted on migration. Migration is not currently supported by the TCP/IP protocol stack, as location independent naming of hosts is not fully supported. It is required, that a host changes address, when it migrates to a new network, and this means both recon guration of the host and a restart of network applications. This is caused by the fact, that the existing network routing mechanisms are designed for static hosts, as this provides simple and ecient solutions. Due to the problems of tting into an existing network, all the proposed solutions to support IP host migration are based on introducing a level of indirection, where the mobile host has both a xed and a temporary address. Packets destined for the mobile host are routed to the xed address, where they are intercepted and forwarded to the temporary address of the mobile host. This level of indirection results in additional overhead and longer paths when communicating with mobile hosts. The future standard for support for mobile hosts in TCP/IP based networks is called Mobile IP [Per95], and is based on this indirection approach.

2.2 Semi-Connected Operation of Communication Protocols In the environment we are considering, periods of disconnected operation and intermittent, low quality connections as, e.g., the unstable GSM links, will be common. On the static hosts of today, periods of disconnected operation are generally an error condition, which occurs rarely and which is only of concern to systems supposed to provide high availability. When using mobile hosts, periods of disconnected operation are common and it would be unacceptable if applications doing network communication terminated due to error conditions at the occurrence of such a period. Furthermore, todays wired networks are much more reliable than the wireless networks used to provide mobile hosts with network access. As these wireless networks have only become widespread recently, many communication protocols are made with the more reliable wired networks in mind, and this causes suboptimal performance when the same protocols are used on wireless networks. These problems are mainly the concern of protocols, that use packet loss as an indicator of error condition in a typical wired network. Thus, it is mainly protocols supporting reliable data transfer, connection oriented data transfer, or congestion avoidance and control. E.g., when data remains unacknowledged for a longer period of time due to disconnected operation, these protocols waste bandwidth retransmitting data, and the protocol may terminate the data transfer entirely due to the repeated data loss. When looking at TCP/IP, these problems apply to both the reliable transport level protocol TCP and various application level protocols, but as TCP has a well documented behaviour, and is part of the system software, much work has been done on improving this part of the protocol stack, as a large collection of existing applications will bene t from this. The research has focused on improving the performance of TCP when a host has continuous access through a wireless networks as this is currently one of the most widespread uses. Especially are there no


21

past experience with supporting longer periods of disconnectivity using TCP, but the solutions provided for continuous wireless access may still provide insight into how semi-connected operation of TCP may be accomplished. In the following we rst discuss the problems and solutions related to TCP, and we then consider the problems related to application level protocols.

2.2.1 TCP Performance on Wireless Networks

When looking at TCP performance on wireless networks, the areas of main interest are the handling of retransmissions and congestion control. This is primarily due to the work presented in [CI94], which were the rst to analyze the eect of wireless networks on TCP. In the following we give a description of how retransmissions and congestion control is handled by TCP, and we review a selection of dierent approaches to improve the performance by changing these parts of TCP. By improving performance we mean either achieving higher throughput or lower packet delay or both.

2.2.1.1 TCP Reliability and Retransmission Strategy The reliable data transfer of TCP is provided by using sequence numbers and acknowledgements. The bytes in the stream are assigned consecutive sequence numbers (modulo 232), which ensure in order, no duplicate, reliable data transfer in conjunction with a sliding windows protocol which also provides end-to-end ow control. The acknowledgement strategy used by the sliding windows protocol is without selective or negative acknowledgement. An acknowledgement acknowledges all bytes numbered less than the speci ed acknowledgement sequence number. Even though TCP provides a byte stream service, it still transmits data in chunks called segments, and if an acknowledgement of a segment is not received within a certain amount of time (called the retransmission time-out or RTO for short) the segment is retransmitted. Ideally the RTO should be a bit larger than the actual time it takes for the segment to reach the destination and the acknowledgement to return to the sender (called the round trip time or RTT), in order to avoid retransmitting segments, which have been successfully received, but not so large that a considerable delay is introduced in case a segment actually is lost. The RTO is calculated after each successful RTT measurement as described by the formulas 2.1 to 2.4, where M is the round trip time measurement, A is the smoothed mean RTT and D is the smoothed mean deviation. The values g and h are used to control how fast changes in the RTT measurements aect A and D. The usual value for g is 81 and for h it is 14 .

Err = M ? A A A + g Err D D + h (jErrj ? D) RTO = A + 4 D

(2.1) (2.2) (2.3) (2.4)

The RTT estimates are obtained from the time it takes before an acknowledgement of a segment is received. Only acknowledgements of segments, which have not been retransmitted are considered in order to avoid ambiguous measurements (it is impossible to decide which segment caused the


22

acknowledgement) [KP87]. In case of retransmissions, exponential back-o is used (the current RTO is doubled) unless an implementation dependent maximum RTO is reached, and this RTO is used until either a new successful RTT measurement is made or another retransmission time-out occurs. In the measurements made by [CI94], the eects of hand-os on TCP throughput in the Mobile*IP system were examined. Hand-os of varying length and cell overlapping were examined, and the measurements showed, that small pauses (0 - 1 seconds) in communication during hando could cause much longer delays (1 - 3 seconds) in data transmission. The main reason for this delay was identi ed as being the loss of a full window of segments, thus halting the transmit window until the rst segment is retransmitted and acknowledged. The retransmission was delayed mainly because of the coarse grained resolution of the retransmit timers (500 msec), but as the RTT of for example GSM links is considerably larger (approximately 1 second), the delay on such a connection could be considerably larger.

2.2.1.2 TCP Congestion Avoidance and Control The receiver may control the amount of data it receives by the advertised receive window, but this only covers overloading at the receiving endpoint. The networks on the paths used by the TCP connection may experience congestion too, and to alleviate or avoid this, the sending side may either reduce or limit the amount of unacknowledged data. There are two types of congestion avoidance and control mechanisms commonly used by TCP implementations today. One is know as Nagle's rule [Nag84], and is primarily a congestion avoidance mechanism. The idea behind Nagle's rule is to reduce the number of small packets on the network, and this is done by allowing only one unacknowledged packet per TCP connection. The other mechanism is designed to both detect and alleviate congestion on the network [Jac88]. As the primary reason for segment loss in today's wired networks is network congestion, segment loss is used as a network congestion indicator. When a segment loss (or a possible segment loss) is detected a reduction in the amount of unacknowledged data allowed is made in order to reduce network congestion. This is done letting the sender calculate a congestion window on the basis of the measured packet loss. Thus the two factors deciding the senders window size are the advertised window of the receiver and the congestion window of the sender, and the actual send window size used is the smallest of the two. The congestion window is changed due to either a successful segment transmission or segment retransmissions. When a segment is successfully delivered, the congestion window is increased. This can be done in two ways; either by using slow start or linear growth. Slow start means, that the number of unacknowledged segments allowed is exponentially increased (doubled per successful transmission), and linear growth means, that the maximum number of unacknowledged segments is increased by a xed amount per successful transmission { usually one segment. The slow start is performed as long as the congestion window is less than or equal to the slow start threshold, and after that linear growth is used. This slow start threshold is made in order to avoid congestion (the exponential increase used by the slow start will easily result in a large congestion window rather quickly). It's initial value is dependent on the implementation, but it is adjusted in case of segment loss. If a segment loss is detected, the slow start threshold is set to one-half of the current window size in order to avoid congestion in the future. Also the congestion window is


23

adjusted on segment loss. If the segment loss is detected by a RTO, the congestion window is set to one segment and slow start is initiated. In the other case, where the segment loss is detected by a duplicate acknowledgement, the congestion window is set to be three segments larger than the slow start threshold. The adjustments of the congestion window are illustrated in Figure 2.8. segment retransmission

20

Segments

15 send window

10 slow start threshold

5

5

10 Round-Trip Times

Figure 2.8: Growth of TCP congestion window As the primary reasons for segment loss on wireless networks are hand-os between cell boundaries and high error rates, the behavior of the congestion mechanisms degrades performance on wireless networks as rst described by [CI94]. They showed, that the congestion control slowed the progress of the data transmission for approximately 1 second after each hand-o. As with the retransmissions the longer latency of GSM systems will make the eects of the slow-start and linear growth more dominant.

2.2.1.3 Fast Retransmission As mentioned above, [CI94] identi ed the main cause of network latency increase and throughput degradation as being caused by the long RTOs. They focused on improving the usability of interactive applications by reducing the data transmission pauses introduced by the hand-os. This was done by forcing the TCP layer to retransmit the IP packets as soon as the hand-o was completed. They used the Mobile*IP system, and this was modi ed together with the TCP layer, so that the TCP layer was signalled each time a hand-o to a new MRS was completed. This signal triggered the fast retransmission procedure, which is a part of most TCP implementations today. The fast retransmission procedure is usually triggered by the receipt of duplicate acknowledgements, and it promptly retransmits the earliest unacknowledged TCP segment, and employs congestion control as described above. The fast retransmission on a stationary host was triggered by letting the MH sending triplicate acknowledgements of the last segment received


24

from the stationary host. This approach reduced the pause after a hand-o was completed from as much as 1650 msec to about 50 msec. This is a simple solution, which only requires moderate changes to the communication layers of the mobile host, and which reduces the latency at hand-os substantially. However, it does not remedy the erroneous instigation of congestion avoidance. Furthermore, only packet loss caused by hand-os are considered. As hand-os need to be signalled to the TCP layer, the solution is not applicable to communication systems, where hand-os are transparent to the communication software, such as the GSM cellular phone system.

2.2.1.4 Split Connections In order to isolate the troublesome wireless link, several projects [BB94, KRA94, YB94] have used a split connection (also called indirect connection) approach. The TCP connection is split into two parts, one covering the wired network, and one covering the wireless network, such that the data transfer may proceed independently on the two parts of the connection. On the wired part, the ordinary TCP protocol is used, allowing communication with stationary hosts using a regular TCP/IP stack. On the wireless part, either a modi ed TCP protocol or a special purpose protocol optimized for wireless data transfer may be used, in order to improve the performance on the wireless link. The main issue to consider here is whether this splitting of the TCP connection violates the TCP end-to-end semantics. It is clear that as data transfer may proceed independently on the two parts of the connection, the TCP protocol at the sender may believe that data has successfully reached it's destination, when in fact it has only traversed part of the connection. The question is, whether this in any way changes the application's view of the connection. As the application expects a reliable data transfer, this may as well be supported by a two part reliable connection as a one part. The extra host participating may result in a more vulnerable connection, as it introduces an extra point susceptible to crashes and data errors introduced above the transport layer (as for example bit errors caused by faulty memory), but the basic functionality of the TCP connection is the same. Both I-TCP [BB94] and [YB94] are implemented on top of Mobile*IP splitting the connections at the MSR. In I-TCP the TCP connection between the stationary host and the MSR is an ordinary TCP connection. The TCP connection between the MSR and the mobile host is modi ed such that a slow start is performed immediately after each change of MSR. The throughput measurements of [BB94] indicates, that the throughput is improved with 7 to 53 percent compared to regular TCP, when LAN connections are used, and when using WAN connections the gain is 200 to 300 percent. The large gain in WAN connections is accredited to the larger RTTs, and thus the impact of slow start and exponential back-o is more severe. The impact of I-TCP on the use of interactive applications is not examined, as no measurements of latency are conducted, but it is reasonable to expect an increase in latency caused by the extra overhead. In the implementation made by [YB94], the connection between the MSR and the mobile host may be either an ordinary TCP connection or a special purpose protocol. In most cases the special purpose protocol yields slightly better throughput than TCP. A new session-layer is added to the protocol stack of the mobile host, which handles the transfer of the wireless link part of the TCP connections from one MSR to another.


25

In the Mowgli project [KRA94], the same idea is used, but the environment is somewhat dierent. The system uses cellular phones as the wireless communication media, and the Mobile IP proposal [Per95] is used as the IP layer mobility support. A Mobile-Connection Host (MCH) act as the endpoint of the xed net part of the TCP connections of a mobile host. The mobile host connects to this MCH using a special protocol optimized for the low bandwidth, wireless link. The MCHs act as Mobile IP agents, such that a mobile host may connect to any MCH, as the Mobile IP will take care of redirecting the IP packets. Mowgli uses a special virtual socket layer, that chooses the appropriate protocol stack for the available communication media. This requires, that applications must be relinked for use on the mobile host. The split connection protocols are able to separate the troublesome wireless link, thus making it possible to improve throughput due to special designed protocols on the wireless link. An added bene t is that retransmissions over the slower and unreliable links are kept at a minimum, since retransmissions due to failure in the xed network only cover the wired network part. This is done at the expense of more vulnerable TCP connections and an increased latency due to the extra overhead caused by the forwarding at the point of the split. Furthermore, this approach may require relinking of applications used at the mobile host.

2.2.1.5 IP Packet Caching Another approach to isolating the data transfer on the wired part of a TCP connection from the eects of packet loss in the wireless part is the insertion of an IP layer caching mechanism at the base station of the wireless network [BSAK95]. As the majority of packets are lost on the wireless part of a connection, IP packet caching is most useful, when the data ow is directed from a stationary host to a mobile host. The main idea behind the IP packet caching at the base station is to be able to make local retransmissions on the wireless part of the connection without aecting the sender. In this way the packet loss on the wireless part, which is not caused by congestion, does not trigger the congestion avoidance and control mechanism at the sending host. The caching implemented by [BSAK95] is done by a snoop module, which works as follows: When a new IP packet is received, it is forwarded to the mobile host, and cached. This forwarding and caching is done without copying data to avoid introducing extra overhead. When a new acknowledgement is received from the mobile host, the corresponding packets are removed from the cache. If duplicate acknowledgements are received from the mobile host, indicating that a packet has been lost, the lowest numbered packet is retransmitted. The duplicate acknowledgements received from the mobile host are not forwarded to the stationary host, and thus short periods of low transmission quality and temporary disconnects are hidden from the stationary host. A local RTT estimate of the wireless part of the link is also maintained and used for local retransmissions. To improve the transmission of data from mobile host to stationary host, [BSAK95] chose to let the snoop module at the base station monitor the arriving packets from the mobile host. When packet loss is detected, the snoop module sends negative acknowledgements (NACKs) to the mobile host. This reduces the time before packets are retransmitted, especially if several


26

packets are lost. The NACKs are implemented using the Selective Acknowledgement (SACK) TCP option, which was originally designed for use on long fat networks (high bandwidth, high latency networks). In order to reduce the eects of hand-os between base stations, packets are routed to both the old and the new base station, when either a hand-o is requested by the mobile host, or a hand-o is expected by the base station. This enables the new base station to build a cache of packets before the mobile host switches to it, thus reducing the impact of packet loss during hand-o. Measurements in [BSAK95] show increased throughput, when compared to regular TCP, on bulk transfers to the mobile host at high bit error rates. When bit error rates are higher than 5 10?7 the snoop module may increase the throughput by as much as factor 20. On lower bit rates no dierence is measured. No estimates of latency are listed. This approach is simple to implement, yet it may substantially improve performance when bit error rates are high, and it is a good alternative to the split connection protocols.

2.2.1.6 Data-Link Level Protocols To decrease the bit error rate experienced by users of wireless links, some systems employ data-link level retransmissions (this is the case with the Radio Link Protocol used by the GSM data transmission). The interaction between these reliable data-link level protocols, and reliable transport level protocols (such as TCP) has been investigated by [DCY93]. The transport level protocols experience retransmissions at the data-link level as an increase in the RTT. This delay may cause additional retransmissions at the transport level, thus possibly degrading throughput. [DCY93] show, that this degradation occurs, when the bit error rate of the wireless link is below a certain point. For TCP the throughput is higher without data-link level retransmissions, when the bit error rate is below 10 percent. At higher error rates the throughput is much higher, when data-link level retransmission is used. It would be interesting with to know the bit error rate of an ordinary GSM link, but currently this is not available.

2.2.2 Disconnected Operation of TCP

Protocols providing a connection-oriented service are designed to detect error conditions, that aect the usability of the provided connections. One such error condition is network failures hindering data transfer on the connection. In most cases, such a network failure will cause a connection time-out, thereby forcing the connection to close. In TCP this network failure is detected, when data remains unacknowledged for an extended period of time. Today most TCP implementations uses a time-out period of nine minutes. This has implications for supporting disconnected operation of TCP connections|if a host transmits a packet to a mobile host while it is disconnected, it causes a TCP connection time-out if the mobile host does not reconnect, receive and acknowledge the segment within nine minutes. So here the con ict between what is a correct assumption in a xed network and what is correct when using semi-connected operation surfaces again.


27

The TCP segments remaining unacknowledged are detected by TCP by using the retransmission timer. If the retransmission timer expires a sucient number of times, a connection time-out is declared. But even when an application does not use a TCP connection, there is a possibility of a connection time-out. This can be caused by the transmission of a TCP segment initiated by either the persist timer or the keep alive timer: Persist timer When the send window size is 0, the sender sends window probes to avoid a situation, where both endpoints are waiting for an acknowledgement.1 These probes are sent with the same intervals as the retransmissions, and the connection is reset, if the probes are not acknowledged. Keep alive timer The keep alive timer is used to detect whether the peer is still up. This is primarily used by servers, where crashed clients otherwise may use resources. The keep alive probe is sent after 2 hours of idle time on the connection. If the probe is acknowledged, the keep alive timer is reset. If a reply is not received within 75 seconds, a new probe is sent - a maximum of ten probes is sent. If, after ten probes, no reply has been received, the connection is reset.

2.2.3 Semi-Connected Operation of Application Layer Protocols

Many applications have slightly (or vastly) dierent requirements for the functionality of network communication, than the ones provided by the services of the transport layer protocols. Thus many applications implement additional protocols on top of the existing transport level ones, trying to detect for example idle connections or lost packets (when using UDP). When considering disconnected operation and wireless networks, this is a problem. The current applications are totally unaware of these very dierent working conditions, and they may thus provide suboptimal performance As these applications level protocols are as diverse as the applications, and as the lower layers has no knowledge of them, it is virtually impossible to support semi-connected operation of these existing application level protocols in a general and ecient way. The few solutions providing semi-connected support for application level protocols are tailor made to a speci c protocol. An example of this is the support for using HTTP on semi-connected mobile computers in the Mowgli project [LAK+ 95], where the addition of an extra agent process on each side of the wireless link is used to enhance the performance of HTTP and to support disconnected operation. To support existing application level protocols the communication layer could thus allow for application speci c \plug-in" agents. Still, the most ecient solution to this problem is to allow the application layer protocols to adapt to the changing working conditions by provide them with information about the currently available communication media. This is further described in Section 2.3. If one end has a full send window, and the acknowledgement of the data in that window is lost, and the other has a sending window with size 0, then both parts may wait forever. 1


28

2.2.4 Summary

The use of reliable and connection-oriented communication protocols pose the following problems: Suboptimal performance of reliable protocols on wireless or intermittent links, as congestion avoidance and control and retransmission strategies are optimized for xed networks, where packet loss due to transmission errors is low. Long periods of disconnected operation causes connection-oriented, reliable protocols to terminate connections. Many dierent solutions have been proposed to improve the performance of TCP connections on wireless networks, but the split connection approach is the only one able to isolate the xed network for longer periods of disconnected operation, and thus allowing TCP connections to survive such periods. The other solutions aim more directly at easing out the eects of packet loss on the wireless part of the network. From our point of view, the split connection is the most interesting solution, although the other solutions may be combined with extra support for disconnected operation in order to provide better performance during intermittent connections. Semi-connected operation of existing application level protocols can be supported by allowing application speci c agents on each side of the intermittent link, but this is not a feasible long term solution due to the large variation in application protocols and the resulting large number of agents. Instead support for forthcoming, more intelligent application protocols should be provided. This will be discussed further in the next section.

2.3 Adaption As the MH is faced with a changing environment in terms of available resources, it is required to be able to adapt to its environment in order to ensure optimal usage of available resources (see Section 1.2.1.3). Adaption can be handled at two levels; the system level and the application level. System level adaption will almost always ensure good overall utilization of a resource (e.g., bandwidth), but will not in general be able to consider the individual needs of applications. Application level adaption allows the applications to adjust to their environment as they see best. However, since resources still have to be divided among applications some system intervention still is required. In this section we will give an overview of work related to adaption. Sections 2.3.1 and 2.3.2 deals with how to address the problem of ensuring a fair sharing of a resource among competing contenders. Section 2.3.3 deal with system level adaption and Section 2.3.4 deal with application level adaption.

2.3.1 Fair Queueing

The work of [Nag87], [DKS89], [McK91] and [SV95] is founded in the requirement for resource management in the Internet. The approaches presented here addresses the problem of how to ensure a \fair" allocation of available bandwidth among competing contenders in routers and gateways.


29

According to [SV95] most routers use a First Come, First Served (FCFS) principle for allocating bandwidth. In order for this scheme to work properly, congestion control must be implemented by the sender. One ill-behaved sender will be able to continuously increase its share of bandwidth at the expense of well-behaved. [Nag87] proposed an approximate solution to this problem for datagram networks. He suggested to have routers/gateways discriminate ows and then provide round robin service to ows for every output link. With each ow a data queue would be associated, causing ill-behaved senders to merely increase the length of their own queues. The problem with this approach is that packet size is not taken into consideration. Unless the packet size on all ows is identical at any given time, there could be a substantial imbalance in the distribution of bandwidth among ows. The approaches given by [DKS89], [McK91] and [SV95] also works by discriminating ows. They all address the weakness of Nagle's approach, but the algorithms proposed by [DKS89] and [McK91] both require O(log (n)) time to select the next packet to send, where n is the number of

ows. Therefor in the remainder of this section we will focus on the de cit round robin approach given by [SV95], which will select the next packet to send from in constant time. De cit Round Robin is really nothing but a simple modi cation to the original round robin proposed by [Nag87]. The approach diers in two ways. Flows are assigned to queues using Stochastic Fair Queueing [McK91] to bound the number of queues. This means that one queue may contain data from more than one ow. To service queues regular round robin servicing is used with a quantum of service assigned to each queue. If the quantum of service associated with a queue does not suce for the packet in the queue in one round, the quantum is transfered to the next and added to this rounds quantum of service. time t

time t

0

1

Round Robin Pointer Deficit Counter

Packet Queues

#1

20

#2 #3 #4

750

200

500

200

50

Round Robin Pointer

500

#1

0

#2

0

#3

0

#4

500

600

700

100

180

Deficit Counter

Packet Queues 20

750

500

200

50

300

200

500

600

700

0

100

0

0

180

Quantum Size

Quantum Size

500

500

Figure 2.9: Principle of de cit round robin The principle in De cit Round Robin is illustrated in Figure 2.9. At time t0 all de cit counter variables are set to zero. The round robin pointer refers to the rst packet queue. When the rst


30

queue is serviced the quantum size is added to its de cit counter . After servicing the queue the remainder is left in the de cit counter . At time t1 after sending a packet of 200 bytes queue #1 has a de cit counter of 300 bytes. Next time the queue is serviced, it will be allowed to send up to 800 bytes.

2.3.2 Class Based Queues

The work of [FJ95] is|like the work presented in the previous section|concerned with the need for resource management in the Internet. As opposed to the fair queue approaches, [FJ95] recognises the necessity of making a distinction between the bandwidth requirements of dierent trac types. They propose a hierarchical class based approach, in which classes of communication may be allocated bandwidth individually|Figure 2.10 illustrates the idea of a hierarchical scheduling structure. Classes may consist of trac types (e.g., the Telnet and FTP classes) or they may comprise entire sets of subclasses (e.g., the agency and the link classes). Packets are assigned to leaf classes (a queue is associated with each leaf class). Interior nodes are used to guide allocation of excess bandwidth (e.g., if the Telnet class has exceeded its share of bandwidth, any excess bandwidth within the Agency A class could be allocated to Telnet class.

Link

30%

Agency A

20%

ftp

telnet

video

ftp

15%

3%

7%

10%

Agency B

telnet

7%

50%

video

4%

ftp

15%

Agency C

telnet

5%

Legend: Connection class Physical Link Collection of outbound connections

Figure 2.10: Principle of class based queueing (obtained from [FJ95])

video

6%


31

The approach is based on four functional units:

Classi er The classi er determines which leaf class a packet should be associated with. Estimator The estimator estimates the bandwidth used by each class over an appropriate time interval.

General Scheduler The general scheduler schedules packets from leaf classes without regard

to link-sharing guidelines. Link-sharing Scheduler The link-sharing scheduler schedules packets from classes, that have exceeded their link-sharing allocation in times of congestion. The approach place no restrictions on how general scheduling and link-sharing scheduling should be conducted. Simulations conducted by [FJ95] suggests that a priority based approach to scheduling signi cantly reduces delay of moderately bursty interactive trac, without seriously hurting the throughput of bulk transfer, assumed that link bandwidth is signi cantly greater than the average bandwidth allocated to the interactive trac class. With a priority based general scheduler the function of the link-sharing scheduler could be to reduce priorities of overbandwidth-limit classes, causing these classes to be scheduled less frequently.

2.3.3 Partially Connected Operation

In [HH95] the problem of providing system performance in a MH operating semi-connected2 to those operating fully connected is addressed. As the bottleneck in a MH operating semi-connected is the slow link used for interconnection, the focus here is on how to:

Limit trac without hurting system performance. Enforce a bandwidth distribution among dierent trac types leading to the best overall system performance.

The problem has been solved by introducing priority queueing in the network driver. The scheme used is an extension of the one included in Van Jacobsen's Compressed SLIP [Jac90]. In the Van Jacobsen approach two levels of priority is used, one for interactive trac and one for other network trac. The queue containing interactive trac is always serviced rst. In [HH95] three levels of queueing are used; interactive trac , other network trac and replay trac 3. Since the Van Jacobsen approach does not preclude starvation, here Lottery Scheduling [WW94] is used to guarantee a minimum of service to all trac types. Lottery scheduling works by assigning a number of lottery tickets to each priority queue. Every time the network driver is ready to transmit a packet a drawing is held. The queue holding the winning ticket will be the one from which transmission is done. This gives probabilistic division of access to the link based on the number of tickets allocated to each priority queue. Semi-connected corresponds to Partially Connected in [HH95] corresponds to our notion Semi Connected The replay trac comprises the network trac that does not necessarily have to be transmitted while the MH is operating semi-connected 2

3


32

2.3.4 Application-Aware Adaption

The environment of mobile clients, that is clients running on a MH, tends to be very dynamic in nature. The purpose of the work done by [NPS95] has been to develop an adaptive data access approach, which dynamically conforms to the limitations of individual clients and their current environment.4 It is argued that adaptive data access is best achieved through a collaborative eort between the applications and the underlying system, since applications contains knowledge of how best to adapt their data access patterns and the system contains information on changes in resources. The approach of [NPS95] is termed Application-Aware Adaption . As the term suggests the applications are made aware of changes to their environment by the underlying system and are then expected to adjust their data access patterns according to these changes. A similar idea has been presented in [Bak94]. In the environment of an application a distinction is made between generic resources and type-speci c resources . Generic resources have meaning for all applications. Monitoring of such resources will be supported by the underlying system. Examples of generic resources are given in Table 2.1. Type-speci c resources only makes sense to applications of a particular type. Monitoring of such resources are not inherently supported by the underlying system.

Resource

Network bandwidth Network latency Disk cache space CPU Power Money

Unit

Bits per second Micro seconds Kilobytes SPECints Minutes of computation Currency

Table 2.1: Examples of generic resources For the system to be able to monitor the environment of an application it requires the application to notify the underlying system the of resources it wants monitored. In case of type speci c resources the application will also have to provide the system with a description of how to monitor the resource. The underlying system will then notify the application when interesting changes occur in its environment occurs. It is of course not desirable for the system to notify an application with every change in a monitored resource. For insigni cant changes the application should be left alone. Therefor the application when registering resources for monitoring, provides with every resource a set of bounds specifying the tolerance to associate with the resource. E.g. if an application wants to monitor the network bandwidth, it could specify that it only wants noti cation if the bandwidth drops below 1 Mb/s or increases above 5 Mb/s. To support application aware adaption [NPS95] has devised an API providing system calls for requesting and cancelling resource monitoring. 4 An applications environment is de ned in terms the resources. A change in the environment indicates a change in the resources available to the application


33

2.3.5 Summary

The work described in Section 2.3.1 deals with the link-sharing problem of ensuring a fair distribution of available bandwidth among competing contenders|here fair distribution is to be taken as an equal distribution. As opposed to this approach the work described in Section 2.3.2 allows for any distribution of bandwidth among dierent trac types, providing greater exibility in adapting the link-sharing policy to trac pattern on the link. The work described in Sections 2.3.1 and 2.3.2 is based on a system with xed bandwidth, xed cost communication interface, and as such does not contain an element of adaption. We believe it to be relevant in the context of adaptive data scheduling however, as this work reveals fundamental problems in how to approach link-sharing when designing a data scheduling mechanism - adaptive or not. Section 2.3.3 presents a semi-adaptive approach to data accessing and data scheduling. It is adaptive in the sense that data access patterns and data scheduling is dependent on whether the MH is fully or partially connected. It is non-adaptive in the sense that no changes are made in data access patterns or data scheduling policy once the MH is partially connected no matter the environmental changes. In this semi-adaptive approach all adaptive actions are handled by the system. This allows for better performance in a system, where applications does not explicitly support adaption of behaviour to environmental changes. As most applications that will be running in a mobile computing environment today do not support application level adaption, providing for system level adaption is required to enhance performance of hosts running in a mobile computing environment. The work presented in Section 2.3.4 deals with fully adaptive approaches to data accessing. This approach allows for good performance only if the applications support adaption to environmental changes. The overall performance enhancements of application level adaption will depend on how well individual applications handle adaption. Application level adaption however, has the potential to ensure a better adapted system than system level adaption. Application speci c knowledge required to provide optimal adaption will in general not be available at system level.

2.4 Summary The three major issues in supporting communication of semi-connected mobile hosts are: Host migration Transparent host migration is not possible in TCP/IP based networks due to the lack of a location independent naming scheme. Thus, the migration of a host to a new network cannot be hidden from applications and users, as it requires a recon guration in order to use a new address. Semi-connected operation of communication protocols The unreliable and intermittent nature of the links used by semi-connected mobile computers degrades performance of reliable protocols and may cause connection-oriented protocols to shut down connections. This is due to the fact, that these protocols are designed with the more reliable xed networks in mind. Furthermore, periods of disconnected operation may cause the shutdown of a connection.


34

Adaption The environment of a mobile host is less static than for stationary hosts. When

changes in the environment results in a change of available resources, the MH should adapt to the new situation in order to ensure optimal usage of available resources. In the area of host migration support for TCP/IP based networks, a number of solutions exists. In order to make these solutions acceptable, they must function together with regular hosts in the IP based networks, and this constraint reduces the eectiveness of the proposed designs. They all provide migration support by using packet indirection, which increases both bandwidth usage and packet delay. The newly emerged Internet standard for host migration support is called Mobile IP [Per95]. Many dierent solutions have been proposed to improve the performance of TCP connections on wireless networks, but none have considered supporting disconnects of longer duration. Of the proposed solution only the split connection approach, which isolates the part of the connection in the xed network from the other part, can be extended to provide support for disconnected operation. The major part of the research in adaption and data scheduling in networks has been concerned with providing a number of contending hosts with a prede ned distribution of the available bandwidth, but new approaches include both system level [HH95] and application level adaption [NPS95]. The proposed system level adaption is very limited, as it only considers two modes of operation; partially connected and fully connected. The application level adaption allows the applications to continuously monitor the system resources and adapt to any changes. This requires that all applications cooperate, as one ill-behaved application may degrade overall system performance. Thus, a combination of an extended system level and application level adaption is recommendable.

Chapter 3

Design In this chapter we combine support for semi-connected operation, system and application level adaption, and host migration in a design, that ful ls our design goals: Hide complexity of using and switching between dierent means of communication from both user and applications Support semi-connected operation Allow for eective use of available bandwidth/communication medium Allow for incorporation of support for host migration As our system must be able to function as a part of regular TCP/IP based networks, no changes must be required on stationary hosts (except for the MSG). Furthermore, the users of mobile hosts are not likely to accept degraded performance while directly attached to a LAN (as this is the normal working situation), the performance penalty in this case must be negligible. The presentation of the design is organized as follows; rst we establish the general properties of our support for semi-connected operation, then the adaption related problems of the changes between dierent means of communication are treated, and nally the problems of host migration are considered.

3.1 Semi-Connected Operation of Communication Protocols When supporting semi-connected operation of communication protocols the two main problems are protocol performance and connection time-outs. These problems apply both to the reliable transport level protocol TCP and to various application level protocols. This has already been mentioned in Section 2.2. In this section we will concentrate on TCP, as this is the most widespread protocol and as changes can be con ned to the system software, thus allowing both existing and new applications to take advantage without modi cations.

35

CHAPTER 3. DESIGN

36

3.1.1 Semi-Connected TCP

As described in section 2.2 only one of the previously employed techniques is to support periods of disconnectivity, namely the split connection approach. The other solutions may be combined with a new approach allowing disconnected operation in order to enhance performance, thus also providing a viable solution. In the following we look at two possible designs; an approach based on the split connections presented in section 2.2 and an approach using the sliding windows ow control mechanism of TCP to halt data transmission during disconnects.

3.1.1.1 Split Connection Approach

The split connection approach is based on splitting the TCP connections of the MH into two parts and letting the data transfer happen independently on the two parts (see Section 2.2.1.4). In our case the split should be made at the MSG as this is the place where the link changes characteristics and where disconnections may be detected. In section 2.2.1.4 the main advantages (improved performance) and disadvantages (added protocol overhead, vulnerable to host errors) of the split connection approach were covered, so here we will concentrate on the support for disconnected operation. In our case, where the MH may be disconnected for a long period of time, the impact of the buering of data at the point of the split is more important than when the disconnects are of a more transient nature. Furthermore we need to provide a way to handle the periods of disconnectivity. As the data transfer is independent on the two parts of the connection, it is necessary for the MSG to buer the data, which has been received and acknowledged by the MSG but not yet received and acknowledged by their destination. As the serial link is often either not present or magnitudes slower than the xed network, the requirements for buer space may be large. In order to evaluate the seriousness of this, we distinguish between bulk and interactive network trac. If large bulk transfers are conducted, a considerable amount of data may be received within a short period of time. In this case it is possible to reduce buer usage by using the conventional ow control mechanism of TCP. The MSG may reduce the receive window size to zero, and thus halt the data transmission. On connections, whose use is interactive, the trac will typically consist of request and reply messages. When disconnected, these connections will transmit a single request or reply message, and then wait for the peer to respond. These connections will therefore become idle when a small amount of packets have been buered. In this way, the buering minimizes the network usage of interactive applications to disconnected RMHs. This leads us to believe, that the buering should be manageable. Another concern is the complexity of managing hosts detaching from or attaching to the LAN. Regular TCP connections should be used while the MH is attached to the LAN in order to avoid wasting bandwidth and decreasing performance, as using split connections while attached to the LAN would both increase packet delay, and double the network trac of the MH. Thus we need to allow the TCP connections to switch between using split TCP connections and regular TCP connections. As the part of the connection covering serial link is isolated from the part covering the xed network, the periods of disconnected operation only aects the connection between the MSG and

CHAPTER 3. DESIGN

37

the MH. On this part of the connection, either a special purpose protocol or TCP may be used to provide reliable data transfer. In both cases the periods of disconnectivity can be handled; if a special purpose protocol is used, the protocol can be designed such that the disconnects do not jeopardize the connections, and if a regular TCP connection is used, it can be modi ed (as we have access to the system software of both MSG and MH) to be able to survive the periods of disconnects by for example making it possible to deactivate the timers of a connection. The main advantages of this approach is that both the TCP performance problems related to congestion avoidance and control and retransmissions are alleviated, and that disconnected operation can be supported easily. This is obtained at the cost of buering and of applying changes to the TCP/IP protocol stack in order to make it possible to switch between regular and split TCP connections and to allow the MSG to maintain TCP endpoints of a collection of MHs.

3.1.1.2 Zero Window Approach

As the cause of TCP connection time-outs is the inability of the receiver to acknowledge the data transmitted, another way to keep the TCP connections alive is to use the ow control mechanisms of TCP to hinder the sender in transmitting any data during disconnects (or transmitting data on connections whose data transfer has been postponed by the scheduling mechanism). TCP uses a sliding window protocol to provide ow control, where the amount of data transmitted by the sender is controlled by letting the receiver announce a window size informing the sender of the amount of data the receiver is willing to accept. By dropping the window size to zero, the sender is not allowed to transmit any data. When a receiver has announced a window size of zero, the sender periodically transmits a window probe in order to discover, whether the window size has changed. In case this was not done, the sender might never discover, if the window had been enlarged, as these window announcements are piggy-backed on the acknowledgements, and if the sender does not transmit anything the receiver will not send any acknowledgements. In order to keep the TCP connections alive, a host in the xed network must send these zero window announcements on the TCP connections requiring it, and it must repeat the last acknowledgement transmitted by the connections, when it receives a window probe. With the zero window approach there is no need for buering, so the memory requirements of this solution are very limited, but at the same time this means that restarting the data transmissions on the TCP connections is more complicated as window announcements must be transmitted, and especially the usage of free bandwidth on the serial link may require several expands and shrinks of the receive windows. There are two ways of letting the receive window become zero: Each time a new segment is acknowledged, the size of the window announced in the acknowledgement is reduced with the size of the segment. In this way the window will never drop below any data currently not acknowledged by the receiver, but for the window size to reach zero an amount of data equal to the size of the receive window when the process was started must be received. By announcing a window of size zero without any regard to the current amount of unacknowledged data. This will force a sender with unacknowledged data to remove data from it's transmit data queue, and is know as shrinking the window.

CHAPTER 3. DESIGN

38

In the rst case the receive window is slowly reduced in conjunction with data being acknowledged. For the MSG this is not a usable solution, as this would require that the MSG acknowledged new data in case of a disconnect. The only solution is thus to have the MSG shrinking the window of the TCP connections. This is a serious drawback of this approach, as not all TCP implementations are able to handle this [Ste94] (Shrinking the window was strongly discouraged in the TCP speci cation [Pos81b]). The main advantages of this approach is that buering is not required, and that it is possible to implement it by snooping at the IP packets transmitted thus not requiring changes to the TCP/IP layer. The disadvantages are rst of all that it may not work with all TCP implementations, and secondly that the TCP performance problems describe in section 2.2.1 are not addressed. This last problem could be alleviated by combining the zero window approach with one of the simpler techniques described in section 2.2.1, as for example the Snooping approach.

3.1.1.3 Conclusion Both solutions requires that the state of the TCP connections are know at the MSG (the host which provides the access to the xed network via serial links), so neither are stateless, and as such both designs are vulnerable to system failures. This dependence on knowing the state of the TCP connections is unavoidable, as a correct reply to any TCP protocol must contain the correct sequence numbers. As the data scheduling mechanism described in section 3.2.3 may require that the transmission on speci c connections is postponed in order to use the available link eciently, there may be situations where the serial link is idle, and where postponed data may be transmitted in order to exploit the available bandwidth. This is easier using the split connection approach due to the buering. As the split connection approach also handles the TCP performance problems as opposed to the zero window approach, which requires extra support, we have chosen the split connection approach, even though it requires changes in the TCP/IP protocol stack.

3.1.2 Protocol for Serial Link Communication

Two dierent approaches are worth considering when adding the protocol for communication over serial links into the model: A special purpose protocol layer optimized for wireless/serial link communication, which replaces the TCP/IP protocol stack at the MH. TCP/IP with an extra protocol layer below the IP layer with extensions for data scheduling and disconnected operation. In both cases we will refer to the introduced protocol layer as the Transparent AMIGOS Communication (TACO) layer. The most important design issues, when choosing the serial link protocol, are: Switching between LAN and serial link communication

CHAPTER 3. DESIGN

39

Performance on serial link Furthermore, the placement of the new protocol layer also aects where it is practical to do the data buering needed to support data scheduling

3.1.2.1 Special Purpose Protocol Using a special purpose protocol may improve performance on serial links, as congestion control and retransmission schemes may be optimized for serial or wireless links. Furthermore TCP/IP protocol overhead in form of headers may be reduced1 in communication over the serial links, which is an important factor in communication over a low-bandwidth high-cost medium. Still some overhead is unavoidable since the protocol for serial line communication has to oer basically the same reliable service as TCP. Studies made by [YB94] show, that special purpose protocols actually may yield slightly better throughput compared to ordinary TCP. The data buering is done at a single location in the protocol stack. This avoids duplicates, and makes optimisations like collapsing small packets on the same TCP connection into larger ones easier. The special purpose protocol may be included either by using a modi ed socket layer at the MH or by inserting a TCP endpoint at the MH, such that data sent is acknowledged locally and then sent using the special purpose protocol. Below we present these two alternatives.

Special Socket Layer The normal socket layer is replaced by a special socket layer with the

same user interface (see Figure 3.1). The major problem is to allow switching between LAN and serial link, as processes may be blocked and data may be buered in the TCP and UDP layers. Either the TCP and UDP layers must be rewritten to allow the sending of data by the TCP/UDP protocols and the special purpose protocol, or it should be possible to transfer blocked processes and queued data between the TCP and UDP layers and the TACO layer. The advantages are: No performance problems with TCP, since the TACO layer can accommodate for the fault pro le of serial-line connections. Buering is done at one location in the protocol stack. The disadvantages are: It requires relinking of all applications using sockets. It is complicated to allow the switch between LAN and serial links. The point-to-point nature of the serial link make the routing information in the IP and TCP/UDP headers super cial, as the socket information is stored both at the MH and MSG, and a single socket identi er can be used instead of the TCP/IP headers. 1

CHAPTER 3. DESIGN

40

packets Application Sockets

Application TCP

Sockets

UDP

TCP

UDP

TACO

TACO

IP

IP

Data Link Layer

Data Link Layer

Data Link Layer

Data Link Layer

Mobile host

Mobility Support Gateway

Stationary host

Legend: Data entity Data path

Figure 3.1: Special socket layer

Extra TCP Endpoint The data sent via the TCP connections are acknowledged at the MH, as if it was a local TCP connection (see Figure 3.2). A special purpose protocol is used between the MH and the MSG. In this way the same TCP/IP protocol stack can be used when connected to the LAN and connected via serial link. The advantages are: No performance problems with TCP, since the TACO layer can accommodate for the fault pro le of serial-line connections. Buering is done at one location in protocol stack. No changes are required in the TCP/IP protocol stack at the MH. The disadvantages are: Extra protocol overhead introduced. The data is passed through six protocol stacks between the MH and the peer. Extra complexity introduced by the extra TCP endpoint. 3.1.2.2 TCP/IP with TACO Layer below IP Layer The TCP/IP protocol is used on both the LAN and the serial link. To split each TCP connection into two, an extra set of TCP endpoints are inserted at the MSG, as illustrated in Figure 3.3. It requires, that the TCP layer is modi ed to handle disconnected operation. The connection time out problem can be solved by disabling the TCP retransmission timers at both endpoints of the serial link, when a MH is disconnected, and letting the IP packets be buered at the TACO layer. This has the following advantages: Requires a small set of changes to TCP layer at the MH and MSG.

CHAPTER 3. DESIGN

41

packets

packets

Application

Application

Sockets TCP

Sockets UDP

TCP

UDP

TCP

UDP

TCP

UDP

IP

IP

TACO

TACO

IP

IP

Data Link Layer

Data Link Layer

Data Link Layer

Data Link Layer

Data Link Layer

Data Link Layer

Mobile host


Stationary host


Figure 3.2: Extra TCP endpoint

Potential protocol overhead of TCP/IP in form of headers can be reduced to an 6-9 bytes

through use of header compression [Jac90]. The serial link protocol PPP [Sim94] already support both header compression and error detection. Handling of data scheduling can be placed below the IP layer thereby reducing the implications on the TCP/IP protocol stack. The major disadvantages are: TCP degrades performance since this protocol suite is designed for a reliable network with a totally dierent fault pro le than a serial-line-connection. By changing the congestion control mechanism on the point-to-point serial line, this problem may be substantially reduced or eliminated. Data is buered at several levels|both at TCP and below IP level.

3.1.2.3 Conclusion We have decided on pursuing the approach in which the TACO layer is placed beneath the IP layer. This choice is based primarily on the fact, that standard Internet protocols can be used and that the changes of the socket interface are limited, thus simplifying the implementation. The two special purpose protocol solutions may have better bandwidth utilization, but with header compression and a tuning of the TCP data exchange parameters, the dierence will probably not be big enough to warrant the more complex implementation. Furthermore, the more complex switch between LAN and serial link of the special purpose protocol solutions, is regarded as a

CHAPTER 3. DESIGN

42

TCP packets

Application

IP packets

Sockets TCP

UDP IP

Application

TCP

Sockets IP

TCP

TCP

UDP

TACO

TACO

IP

IP

PPP

PPP

LAN

LAN

Mobile host


Stationary host


Figure 3.3: TACO layer below IP layer greater hazard than the extra data buering done by the other solution. We will refer to the collection of TCP connections of a MH on the MSG as the proxy host of the MH. When the MH is connected to the LAN directly, it should use the normal TCP/IP protocol stack. The dierent means of connection are summarized in Figure 3.4.

3.1.3 Triple Point Connections

In our split connection approach, a TCP connection requires that three hosts process the TCP messages, the two endpoints and the MSG. The MSG may therefore be viewed as a central point containing two proxy endpoints, one for each real endpoint. Thus the connection is not a point-to-point connection, but what we will name a triple point connection (see Figure 3.5). How should the relationship be between the data on the two parts of the connection; should the central point just act as a simple copier, should it be able to perform data reduction tasks like data compression and ltering, or should it be possible to install software agents in order to take care of tasks that can be automated ? In the rst case there would be a one to one correspondence between the data transmitted on the two parts, and as the sequence numbers used for the same data on the two parts could be the same the real and proxy endpoints would be instances of the same endpoint which are just temporarily out of synchronization due to deferred communication. This makes the switch from split TCP connection to regular TCP connection relatively simple, as the two instances can be made consistent by emptying the buers of the central point. In the other cases, there is no one to one correspondence between the data transmitted on the two parts, and the switch from split TCP connection to regular TCP connection becomes

CHAPTER 3. DESIGN

43

MH1

MHn

Application

Application

Sockets TCP

Sockets

UDP

TCP

UDP IP

IP TACO

TACO

Ether

Ether

PPP

PPP

Mobility Support Gateway Data packets

MH’

Data packets

SH

Application TCP

TCP

IP

IP TACO

TACO Ether

PPP

IP

IP

TACO Ether

PPP

Application

Sockets

TCP

TCP

TCP

TACO Ether

TCP

IP

MH1

Sockets

UDP

Ether PPP

PPP

MHn

TACO

Ether

PPP

UDP IP Ether

Legend: MH : Mobile Host disconnected from network MH’ : Mobile Host connected to local network SH : Stationary Host : Serial Link : LAN connection : LAN : Protocol not used in this host

Figure 3.4: Overview of the dierent forms of connection extra hard. If data reduction is performed, the switch would require that the central point buers are emptied and that the MH proxy endpoint is used to update the real MH endpoint with the sequence numbers used on the connection to the PH. This would also require, that all TCP segments in the TCP/IP protocol stack of the MH are updated to use the new sequence numbers. The use of an agent may complicate matters even more, as the agent also must be brought in a state where it can be removed. In order to keep our implementation simple, we have chosen to use the central point as a simple copier, although the other solutions would be interesting.

CHAPTER 3. DESIGN

44 endpoint

central point

M

P’ M’

endpoint

P

Legend: M The endpoint at the mobile host M’ The proxy endpoint of the mobile host P The endpoint of the peer host P’ The proxy endpoint of the peer host

Figure 3.5: The triple point connection

3.1.4 Applications and Disconnected Operation of TCP

When disconnected operation is supported, it should be possible for a MH to remain disconnected for a long time. In all this time, applications, which are waiting to receive data, on both PHs and the MH, will be suspended. On the MH side the user can control which applications are allowed to continue, but on a SH an application could occupy resources in a way not intended by the designer of the application as it's design may rely on connection time-outs to release these resources. We view this as the price which must be paid for obtaining support for disconnected operation, and we will provide a way to let a system administrator abort TCP connections from the proxy host of a MH at the MSG, if there is a need for it.

3.1.5 Summary

We have presented a solution called triple point connections, which solves the problems of handling semi-connected operation of TCP. The solution is based on the split connection approach, where TCP connections are split at the MSG. This gives us the possibility of implementing easy support for disconnected operation, it allows buering that will help perform data scheduling, and it is possible to avoid the performance reduction caused by retransmissions and congestion avoidance and control. The split connection uses TCP on both the wired network and on the serial link, where PPP is used to provide serial link transfer of IP datagrams. As the performance of MHs attached to the LAN should not be sacri ced, the MHs switch between two modes of operation, regular TCP connection when attached to the LAN and triple point connections when the MH is detached. In order to limit the scope of our implementation, we have deferred from supporting data reduction and agents at the central point. Instead we maintain a one to one correspondence between data and sequence numbers on the two parts of the connection, thus providing a simpler switch between the two modes of operation.

CHAPTER 3. DESIGN

45

3.2 Adaption If we de ne the environment of a MH in terms of the resources to which it has access, the problem of how to support a MH adapting to environmental changes can be split into two subproblems: 1. How to identify environmental changes 2. Where to place the responsibility for adapting to changes The problem of how to identify environmental changes deals with monitoring of system resources and as such is a system management problem (see [ea96]). For monitoring network resources several protocols exists within both the framework of OSI and TCP/IP (see [ea96] and [Ste94]). The protocols establish how and what information should be communicated between manager and managee. The problem of where to place the responsibility for dealing with environmental adaption deals with the optimality of the adaption versus the versatility of the system. A system where the responsibility for adaption is placed at the system level will place no restrictions on the applications running with respect to providing support for environmental adaption. Obviously, the environmental adaption can only ensure an overall satisfactory system performance, since the system will contain no application speci c knowledge. For any one application, the adaption may be far from optimal. As opposed to this, placing the responsibility for adapting to environmental changes at the application level, will ensure applications better adapted to their environment. However, in order to ensure proper system performance under all possible environmental conditions, it is required that all applications support application level adaption. The majority of applications today do not support application level adaption, least to say application level adaption as we de ne it. Therefore it is required, that our system is capable of making the required environmental adjustments. However, since future applications most likely will come with built-in support for application level environmental adaption, the system should also provide support for application level environmental adaption (to ensure that these applications are optimally adapted to their environment). In the following sections we deal with the design aspects of resource monitoring, application level environmental adaption and system level environmental adaption.

3.2.1 Resource Monitoring

In monitoring network resources we wish to establish a picture of the resources available and their quality. How well the system is adapted to its environment depends on how accurate a picture is kept of available resources. With a MH the communication interfaces may change, at times an interface may not be available at all. We need to identify what interface is present if any, and in case the MH hold more than one interface, what interfaces are available for transmission. The quality of a link (expressed in terms of e.g., capacity, latency and cost) may vary. With some types of interfaces a link displays a higher degree of variation in quality than with others. To maintain an accurate picture of the link quality, frequent monitoring is required. In this section we will deal with monitoring of network resources. Section 3.2.1.1 contains a discussion on interface management and Section 3.2.1.2 deal with link management.

CHAPTER 3. DESIGN

46

3.2.1.1 Interface Management Interface management is responsible for identifying communication interfaces present at the MH and for detecting a change in the interfaces present. The interface manager will be dealing with several interfaces, since most notebooks today are capable of holding two or more PC Cards at the same time. In case the MH holds more than one communication interface, the interface manager should report back on the active interfaces present. An active interface is an interface on which communication is possible. With an Ethernet interface it is always possible to listen for activity on the net, to determine if the interface is active. It is most likely that if no activity is detected the interface is not connected to the net, however there is no guarantee. To make sure an Ethernet interface is active sending probe packets to the MSG is required. With serial interfaces the only one way to determine whether the interface is active or not is through transmission of probe packets. Probing on a serial interface is an time consuming operation, since a link has to be established. We will defer from dealing with the problem of detecting active interfaces in this context and simply assume, that if an interface is present it is also active. It is not the responsibility of the interface manager to rank the active interfaces present. The interface manager has no knowledge of the trac types comprised by data currently pending, and therefore have no way of determining which communication interface best suits the communication needs of the MH. As it so happens with the current types of communication interfaces supported there is a simple relation between bandwidth, latency and cost of communication which makes the following ranking valid at all times: 1. Ethernet 2. Modem 3. GSM adapter Ethernet ranked as most preferable interface, with the lowest cost of communication the lowest latency and the highest bandwidth, followed by the modem and the GSM adapter. Future interface types might cause this ranking not to be valid at all times (e.g. a satellite interface which might have high bandwidth, high latency and low cost of communication).

3.2.1.2 Link Management Link management is responsible for monitoring the transmission quality of the active links available at all times. The transmission quality of link can be expressed in terms of parameters such as:

Bandwidth Latency Transmission errors

CHAPTER 3. DESIGN

47

Involuntary disconnects Cost of communication The number of disconnects do indeed provide a statement on link quality. However it is fairly dicult if not to say impossible to segregate requested disconnects from involuntary disconnects. Therefor we will disregard disconnects as a quality parameter. The parameters of interest is thus bandwidth, latency, transmission error, and cost of communication. The transmission quality of serial links might vary considerably { especially when the transmission is partly wireless. Wireless transmission is highly sensitive to shape of landscape, atmospherical conditions, etc. Estimates of bandwidth and latency express average values within set time intervals. The uctuant nature of transmission quality has a negative impact on bandwidth and latency estimates, causing the estimates to be either to high or to low. Depending on the size of the uctuations the estimates might be misleading, not re ecting the current quality of the link. Fluctuations ideally should not aect estimates at all, but since it is hard to tell whether a measurement is to be taken as a uctuation or the beginning of a more long term change in transmission quality, they cannot be disregarded all together. Instead the estimating should be devised such that no single deviant measurement will aect the estimates. Van Jacobsen has developed an algorithm for estimating round trip times on a link, which deals with the problem of limiting the in uence of short term uctuations [Jac88]. This method could be applied to estimating both bandwidth and latency.

Bandwidth The capacity of a link can not be expressed in terms of the raw bandwidth mea-

sured, as this measure does not take into account neither the packets that are lost during transmission nor the packets received by the peer containing errors. The capacity should rather be expressed as the eective bandwidth, that is the amount of bytes transmitted free of error within a set interval of time. Equation 3.1 shows the relationship between transmission errors, packet loss and eective bandwidth, assuming there is no involuntary disconnects and no idle time on the link. eective bandwidth =

bytes sent ? (transmission errors + bytes lost ) t

(3.1)

Bytes sent refer to the total number of bytes transmitted within the time interval t, transmission errors refer to the number of bytes discarded by the peer because of transmission errors and bytes lost refer to bytes never reaching the peer. Equation 3.1 does not explicitly take the number of disconnects into account, but the number of disconnects naturally aects the number of bytes sent within a given period of time, and as such shows in the size of bytes sent . In case the link is idle within the period t, depending on the idle time, the bandwidth measure eective bandwidth does not give an accurate picture of the real bandwidth available, rather it will be a measure of how much of the available bandwidth have been used. Since the assumption that no idle time occur on the link is a bit unrealistic, it is necessary to correct eective bandwidth for idle time. It should be emphasised that idle time refers to the time then link in the sending direction is being idle. Equation 3.2 gives eective bandwidth corrected for

CHAPTER 3. DESIGN

48

any time the link has been idle within t, where idle time refers to the time the link is idle within t. eective bandwidth =

bytes sent ? (transmission errors + bytes lost ) t ? it

(3.2)

Latency Latency of a link can be expressed in terms of round trip time|how long does it take to send forth and back a single byte. The Van Jacobsen algorithm referred to at the beginning of this section, caters for round trip time estimates and can be applied here. The GSM net operators use the Radio Link Protocol (RLP) for transmission on the wireless link between the MH and the base station (see Appendix C). As the RLP guarantees error free transmission, uctuations in transmission conditions on the wireless link between the MH and the base station will have a signi cant impact on round trip times. During periods with poor transmission conditions it is likely that a major part of available bandwidth will be used by RLP for retransmission. Having the link manager identifying these periods and report back to the TCP layer will make it possible to defer TCP retransmissions. There is little point having TCP retransmit packets under these circumstances, as an acknowledgement might very well be under way. Cost of Communication For the time being it is not possible to get information on the

economic cost of communication for any of the interface types supported. With the upcoming phase II speci cation of the GSM standard however, net operators are expected to support advice of charge information (see Appendix C). For modem interfaces this information will probably never be available, since PSTN operators do not provide the advice of charge service and probably never will, as the future lies within digital networks such as ISDN. As advice of charge is not available yet, we will have to accept an implicit indication of cost of communication, by the type of interface used. GSM adaptors will be the most expensive in terms of cost of communication followed by modems and Ethernet interfaces.

Accounting Besides providing information on the transmission quality, it is also a task of the link manager to provide accounting information on link usage. As the advice of charge service is not generally available from net operators, accounting will be limited to registering the connect time on the various interface types. To allow for post processing of accounting information to asses resource usage, the physical connections made on each type of interface should possibly be registered by date, time and duration. To limit the scope of our implementation we have decided to defer from implementing the link management functionality. It is not central to our thesis how the transmission quality information comes about merely that it is available. Therefore we will simply take the technical speci cations of the various types of communication interfaces to express transmission quality of the link available.

CHAPTER 3. DESIGN

49

3.2.2 System Level Adaption

A MH might be either xed or roaming. A xed MH is attached to a LAN through an Ethernet interface. With a roaming MH the element of disconnectivity is introduced. A MH is considered disconnected if either no interface is present or in case of a serial interface if no link is established. A change in interface is normally associated with a change in link quality (e.g., change from using an Ethernet interface to a GSM adapter). At the system level we are dealing with the problems of:

How to adapt to changing communication interfaces, possibly to a situation with no interface present. Any change in interface should be transparent at the application level. How to divide available bandwidth.

In section 3.2.2.1 we treat issues concerning interface change, and in section 3.2.2.2 we treat issues on how to divide available bandwidth.

3.2.2.1 Pseudo Devices The TCP/IP layers do not support disconnectivity. When a link is taken down the device associated with the link is deleted and with that all entries in the IP routing table containing a reference to the device. In case a MH gets disconnected the IP layer will not know where to route IP packets destined for non-local processes. Transmission will fail and TCP connections will most likely be closed. To deal with disconnectivity we introduce a pseudo device. This device is not associated with a link but rather a process in the TACO layer. Whenever the MH is roaming all routing of IP packets to a non-local process is through the pseudo device. The ow of data between application, TCP/IP layers, the pseudo device and the interface device driver for a xed and a roaming MH respectively, is illustrated in Figure 3.6 and Figure 3.7. Legend: Flow of IP packets

Application

TCP/IP layers

Ethernet device

Program entity

Figure 3.6: A xed MH With the introduction of the pseudo device, the disconnectivity of a MH is hidden from the TCP/IP layers. Table 3.1 shows what adaptive actions are required to deal with disconnectivity and in what situations. As the table shows IP routing information only has to be updated when a MH is going from being xed to being roaming or vice versa. No changes are required as long as the MH is roaming. Routing to the pseudo device thus remains in eect even though a roaming MH has established a link. It is required that IP packets still be routed to the pseudo device in this situation in order to enable the TACO layer to schedule data for transmission on the serial link.

CHAPTER 3. DESIGN

Legend: Flow of IP packets

50

Application

Program entity Entity/flow not present when MH is diconnected

TCP/IP layers

TACO pseudo device

Serial device

Figure 3.7: A roaming MH

From

No Interface No Interface

To

Action

Serial Interface No actions Ethernet Interface Change IP routing from pseudo device to Ethernet device Serial Interface No interface No actions Serial Interface Serial Interface No actions Ethernet Interface No Interface Change IP routing from Ethernet device to pseudo device Table 3.1: Actions related to change in communication interface in MH

CHAPTER 3. DESIGN

51

3.2.2.2 Data Scheduling The basic problem of data scheduling is how to schedule access to the link among competing contenders, such that an appropriate distribution of available bandwidth is accomplished under congestion (as illustrated in Figure 3.8). This problem is by no means unique to a MH, any interconnected host will face the problem of how to manage the available bandwidth. Dealing with the problem for a MH however requires a somewhat dierent approach from that of a xed host. A MH is faced with varying bandwidth and varying cost of communication. Legend: Physical link

Link

Connection class

ftp

telnet

video

audio

realtime

Figure 3.8: Link-sharing problem among competing contenders (obtained from [FJ95]) The variation in available bandwidth and cost of communication means that no single set of rules can be applied to deal with the link sharing problem in case of congestion. In general we could say that three principles would govern the distribution of bandwidth: Importance of communication Cost of communication Performance of communicating processes There is a direct proportional relation between performance and the amount of bandwidth allocated|the less bandwidth the worse performance. If we de ne cost of communication as the price of completing a data exchange between processes, there is a direct reverse proportional relation between cost of communication and the amount of bandwidth allocated|the less bandwidth the higher the cost of communication. The importance of communication is xed, while the cost of communication and performance varies with the characteristics of the link present. Bandwidth will be allocated as long as importance outweighs cost and performance, otherwise communication will be deferred until cost and performance again is balanced against importance. If communication is ordered by importance, cost and performance it is obvious that a simple FCFS scheduling strategy will not ensure an optimal usage of available bandwidth.

CHAPTER 3. DESIGN

52

The decision to place the TACO layer beneath the TCP/IP layers (see Section 3.1) introduces a problem aecting the eective usage of available bandwidth|stale data. Any data received for scheduling on a TCP connection is part of a stream. If we loose the communication interface, the TACO layer will hold on to out bound data. The disconnect might be long enough for part of the data to go stale. Naturally we do not wish to waste bandwidth transmitting stale data, but since the data is part of a stream we cannot discard it. There seems to be little to do to alleviate this problem. At the IP level there is no information available regarding the data in a stream. Since a roaming MH might be disconnected for extended periods of time, it is not possible to bound the latency of data transmission. This has an impact on how to deal with guaranteed quality of service for connections. Conditions under which the guarantee was given might change on a minutes notice. We will not deal with this problem.

3.2.3 Scheduling Strategies

As has been pointed out above, it is not be desirable to schedule data for transmission based on a simple FCFS principle. Any scheduling strategy needs to take into account the importance of communication, the cost, and the performance of the involved processes. In this chapter two dierent strategies for doing data scheduling at the data link level, are investigated. The strategies are: 1. Priority based IP packet scheduling 2. Quality Of Service (QOS) based data ow scheduling In strategy 1 priorities are assigned to IP packets individually creating a global order on all outgoing IP packets. Packets are scheduled for transmission based on priority|highest priority rst. With each communication interface a priority threshold is associated. Only packets with a priority larger than the threshold are scheduled for transmission, unless unused bandwidth is available. As opposed to this, strategy 2 associates with each data ow, a set of parameters stating the minimum quality of service required for packets in this ow. Among ows scheduling is done round robin , dividing available bandwidth among ows having QOS parameters satis ed by the current communication interface. Within ows IP packets are scheduled for transmission on a FIFO principle. Any unused bandwidth is used transmitting packets from ows with QOS currently not satis ed. We have picked these strategies as representatives of two dierent approaches to data scheduling. Strategy 1 represents an approach ensuring a globally optimal solution, always sending the most urgent packet rst. Strategy 2 represents an approach ensuring only locally optimal scheduling of packets. Only within ows are packets scheduled optimally, based on time of arrival. Among

ows access to the communication interface is granted on an equal basis. Flows could be assigned priorities such that prioritised scheduling could be applied among ows with QOS requirements ful lled (much like what is proposed in [FJ95]). We will not deal with priorities in the ow based scheduling approach. Untill we have a clear picture of the overhead introduced by data scheduling we do not wish to introduce more complexity in the scheduling algorithm than necessary.

CHAPTER 3. DESIGN

53

In the following sections we will develop these strategies further, giving a thorough discussion of their advantages and disadvantages. We will conclude this discussion, arguing that the locally optimal strategy is more well suited for our purposes. Throughout the following sections we will use the term Communication Flow Descriptor (CFD) to mean a set of communication endpoints and a protocol de ning the way of communication. For the TCP and UDP protocols, connection endpoints are given by an IP address and a port number. Any TCP or UDP CFD is uniquely identi ed by a 5-tuple . For the IP protocols ICMP and IGMP, connection endpoints are given by an IP address alone, since these protocols are for communication between hosts, as opposed to TCP and UDP that are between processes. Any ICMP or IGMP CFD is uniquely identi ed by a 5-tuple .

3.2.3.1 Priority Based Scheduling With each CFD the application is required to specify a primary priority , a time limit for delivery of packets to the xed network and a factor , stating the importance of initialising transmission within the given time limit. The priority associated with a CFD is then set to:

p = primary priority + timelimit

(3.3) Each packet sent on the CFD will be given an initial priority p based on the initial value of time limit . As time limit decreases the priority of the packet might change. Whether the priority will increase or decrease depends on the sign of . The rate of change is determined by the size of

. Each type of communication interface is attached a priority boundary pb , such that data with a priority p is transmitted on communication interface with priority boundary pb if and only if p pb, unless the link is idle. Figure 3.9 illustrates how the priority queue is reordered from time t1 to time t2 , due to the dierences in the values speci ed for the two CFDs Sock1 and Sock3 . The primary priority speci ed by the application is supposed to re ect the communication interfaces the application is willing to accept initially for transmission of data - it is assumed

that the contribution from timelimit is insigni cant initially. The relationship between and time limit indicates the importance the applications places on data actually being sent within the time limit. As time goes by the application might be willing to accept the use of a more costly, less ecient communication interface. Advantages of the priority approach are: Selection of packet to transmit is simple, since there is a global order on all packets held for scheduling. Build-in aging of packets through the factor (see Equation 3.3). Disadvantages of the priority approach are: Unclear how dierent types of communication interfaces are assigned a priority boundary. E.g. how should priority boundary be set for an interface with high bandwidth and high latency compared to an interface with less bandwidth and less latency.

CHAPTER 3. DESIGN time t

1

time t

2

54

PQ

= t1 + 1

PQ

CFD #1 Primary priority 100.0 Timelimit 10.0 γ 1.0 Priority 100.1

CFD #2 Primary priority 95.0 Timelimit 2.0 γ 10.0 Priority 100.0

CFD #2 Primary priority 95.0 1.0 Timelimit 10.0 γ 105.0 Priority

#1 CFD Primary priority 100.0 Timelimit 9.0 γ 1.0 Priority 100.2

Legend: CFD PQ

Communication Flow Descriptor Priority Queue IP Packet

Figure 3.9: Example of priority based scheduling

Unclear how the priority boundary for a communication interface is adjusted in case exterior

circumstances causes the actual link quality to be substantially lower, than the one speci ed for the link. Maintaining the order in the priority structure, requires a substantial amount of work.

3.2.3.2 Flow Based Scheduling This approach to scheduling is based on the applications providing with each CFD a tuple characterising the quality of service (QOS) of the desired link to use for data sent on that CFD. The purpose of the service parameters is to provide the scheduler with information, that allows it to schedule data such that link utilization is maximised. Thus the parameters should re ect the characteristics of the link which is preferred to be used for transmission, and they should state how long the scheduler can hold onto data before transmitting it. A QOS tuple thus consists of: 1. Minimum required bandwidth (Kb/sec) 2. Maximal latency (msec) 3. Maximal cost per minute (units of cost/min) 4. Minimal idle time before disconnect 5. Preferable time before connect Interface pro les with respect to service parameters 1 through 3 are speci ed for dierent communication interfaces (GSM modem, ordinary modem, Ethernet) based on technical speci cations of the interfaces.

CHAPTER 3. DESIGN

55

The scheduling approach is based on three data structures, a wait queue , an active set and a pending set . Each active CFD will be represented by a data queue in one of these structures. Any data sent on a CFD handled by the TACO layer will be appended to the corresponding CFD data queue. If no data queue is associated with the CFD in any of the data structures, a new queue will be created an placed in either the wait queue , the active set or the pending set according to the requirements tuple of the CFD.

Wait Queue Any new CFD data queue will be placed here, whenever Preferable time before connect > 0. It will remain here until the timer value reaches 0. When a timeout occurs, the corresponding CFD data queue is moved to either the active set or the pending set depending on whether or not items 1 through 3 of the requirements tuple matches the interface pro le. In case of a match the data queue is moved to the active set structure otherwise it is moved to pending set . Active Set Any CFD data queue where the related Preferable time before connect = 0 will

appear in the active set as long as the queue is non-empty and the related Minimal idle time before disconnect > 0. When a timeout occurs, the corresponding CFD data queue is deleted from active set . In case a change in interface pro le occurs any data queues where items 1 through 3 of the related requirements tuple does not match the new interface pro le, will be moved to the pending set structure.

Pending Set Any CFD data queue where the related Preferable time before connect = 0 and

the items 1 through 3 of the related requirements tuple does not match the interface pro le, will appear in pending set . In case a change in interface pro le occurs any data queues, where items 1 through 3 of the related requirements tuple does match the new interface pro le, will be moved to the active set structure. Figure 3.10 gives an example of how the CFD structures are moved between Active set , Pending set and Wait q . Between time t1 and time t2 the idle timers of CFD1 and CFD3 has expired, but only the QOS parameters of CFD3 are ful lled by the current communication interface. A physical link is established whenever the active set becomes non-empty. The scheduling of data to transmit is based on a round robin principle, dividing available bandwidth equally among active connections. A physical link is brought down whenever the active set becomes empty. Involuntary disconnects causes an attempt to reconnect whenever at least one of the CFDs in either the active set or the pending set have its requirements matched by the interface pro le (the reason for the disconnect might be a change of interface). Unused bandwidth will be utilised transmitting data from any CFD from either the wait queue or the pending set . Since all CFDs within the pending set have link requirements not matched by the interface pro le, data related with these connections is only send if no CFDs from the wait queue match the interface pro le. Any transmission initiated to utilize spare bandwidth leaves the idle timer unaected. The advantages of this scheduling approach are: Packets eligible for transmission are easily determined.

CHAPTER 3. DESIGN time t1

56

AS

PS (Empty)

time t2

AS

WQ (Empty)

PS CFD 3

CFD 1

CFD 2

CFD 3

WQ CFD 1

CFD 2

Legend: AS PS WQ CFD

Active Set Pending Set Wait Queue Communication Flow Descriptor Dataqueue associated with a CFD

Figure 3.10: Example of ow based scheduling

Correspondence between link quality of communication interfaces and requirements tuples

is clear. No need for aging, since all packets will be send when the preferred time to connect is up or as soon after as possible. The disadvantages of this approach are: The round robin scheduling among active connections does not re ect the sequence in which the packets have been handed over to the TACO layer. The round robin scheduling is coarse grained, since all virtual connections with matching requirements are given bandwidth on an equal basis. This problem could be alleviated either by applying one of the fair queueing approaches described in Section 2.3 or through priorities, at the cost of introducing more complexity in the scheduling algorithm.

3.2.3.3 Choice of Scheduling Strategy

We have chosen to pursue the approach, where QOS parameters are assigned to transmission endpoints. Our choice have been based primarily on the simplicity of maintaining scheduling structures using this approach as well as its ability to adapt the link speci cation dynamically to changes in actual link quality.

3.2.3.4 Static Versus Dynamic Assignment of QOS When assigning QOS parameters to CFD it seems natural to ask whether it should be allowed to do so dynamically or if assignment should be static. In the next two paragraphs we will look at the eects of allowing dynamical QOS assignment to CFDs for TCP and UDP respectively.

CHAPTER 3. DESIGN

57

TCP is a connection-oriented, reliable byte stream service. The byte stream property has several consequences for the dynamical assignment of QOS: When changing the QOS associated with a connection, this may aect data already handed over to the transport layer, as the data may be buered. Should the data already delivered to the transport layer be aected by the change, or should the socket routines start a new buer with the new requirements when a change occurs? As the user has no way of knowing, what data is actually sent, the rst alternative would strike at random. The second alternative seems to be somewhat easier to use and the more useful. Changing the QOS requirements of a socket aects the data handed over to the transport layer from that point on. Data must be delivered in a FIFO manner, so changing the QOS associated with a connection must not change the order in which data is received by the peer. UDP is a connection-less, unreliable datagram service. Each datagram is delivered independently, and it is therefore possible to assign each datagram a dierent priority. Changing the priority of a socket must not aect datagrams already handed over to the transport layer. Given the eects of dynamic assignment of QOS on TCP connections and the action needed to be taken to alleviate them, we will only allow static assignment of QOS to CFDs.

3.2.3.5 Scope of QOS requirements

Both when using connection-oriented and connection-less communication, it is necessary to decide on the scope of the speci ed link requirements. There are two possibilities: The requirements are the same for both the sending and receiving part. The scope of the requirements is the entire path of the data. This corresponds to that the transport level connection is assigned a priority, and that|when using connection-less communication| each datagram is assigned a priority. This has the nice property, that there is an exact knowledge of, how data is transferred from peer to peer. The communicating parties are allowed to specify the requirements individually. This means that each end-point (here socket) would have its own requirements. The scope of the priorities is the link between the MH and the xed network, and priorities therefore specify, when and by what the data is transferred to the xed network. We have decided on the end-point priority scheme for the following reasons: The links are normally established and payed for by the MH. It would therefore be unsatisfactory if another host could force the MH to receive something that it either do not want or need. The usage pattern may variate greatly between dierent MHs, so that on type of link may be inadequate for one but necessary for another. E.g., a MH, which never is connected by Ethernet communicates with a MH, which is never disconnected from the Ethernet|except during the lunch break. It is still possible for applications to agree on a common priority of a given connection.

CHAPTER 3. DESIGN

58

3.2.4 Application Level Adaption

Application level adaption allows individual applications to adapt to their environment. There seems to be much to gain in allowing applications to perform their own adaption. The data transfer rates of individual applications could be reduced to match the available link, thereby lessening the burden on the system level data scheduler (if not making it super uous). The amount of data actually transmitted could be reduced, since applications may prevent stale data from being transferred to the communication layer. If, e.g., no communication interface is present and an application wants to send a series of updates to a server, later updates may overwrite earlier ones. Sending the invalidated updates would clearly waste bandwidth|if instead the application waits until the updates actually can be delivered only the valid ones has to be transmitted. Much like [NPS95] we propose an approach to application level adaption, where applications may request noti cation of when a certain link quality is available. The application speci es through a system call the link quality threshold that should generate a noti cation. When the quality either rise above or drops below the threshold the application is noti ed. Providing support for application level adaption in this manner has some aws. A number of applications may be noti ed that the availability of some resource has risen above a certain threshold. If all applications try to acquire the resource, the availability of the resource as seen by the individual application possibly no longer exceeds the speci ed threshold|the application will be left unadapted to its environment. We will not deal with this aspect of supporting application level adaption.

3.2.5 Summary

In Sections 3.2.1 through 3.2.4 we have been dealing with how a MH should adapt to its environment, more precisely the part of the environment related to communication. The resources of interest are the communication interface and the link quality. In Section 3.2.1 we have been treating resource monitoring. The issues of concern are interface and link management. The problems related to interface management are how to detect what interfaces are available for transmission, and how to decide on what interface to use in cases where more than one interface is available for transmission. We have decided to deal with the problems in the easiest possible way|simply assume they do not exist. We assume that if an interface is present it is available for transmission and we assume that it is possible to rank interface from most to least preferable. In relation to link management we have argued that the parameters necessary to describe link quality are eective bandwidth , round-trip time and cost of communication . As advice of charge is not supported by network operators yet, the cost parameter can not be maintained. We have deferred from discussing the design of network resource monitoring within the framework of SNMP (the network management protocol associated with the TCP/IP protocol suite), as we nd this to be outside the scope of this project. At this point we are merely interested in devising a rudimentary resource monitoring scheme. In Section 3.2.2 we have handled the adaption required at the system level. The issues of concern here are hiding switch of interface and disconnectivity from applications and provide a strategy for scheduling of access to the link. We have introduced pseudo devices to support

CHAPTER 3. DESIGN

59

transparency with respect to interface switch and disconnectivity. We have presented two dierent approaches to data scheduling: one priority based and one

ow based. The priority based approach assigns with each IP packet buered for scheduling a priority, and packets are scheduled highest priority rst. The ow based approach separates IP packets into ows identi ed by the tuple . With each ow a set of QOS parameters is associated. Flows with QOS requirements below or equal to the QOS of the link available, are scheduled for transmission on a round robin basis. We have decided on using the ow based scheduling strategy to keep the approach simple, although simulations done by [FJ95] suggest that priority based scheduling among ows might improve performance under certain conditions, without seriously penalising performance in general. In Section 3.2.4 we have been dealing with application level adaption. We have presented an approach to supporting adaption, that allows applications to receive noti cations from the system, when the link QOS rises above or drops below a threshold speci ed by the application.

3.3 Host Migration When considering host migration, we must solve two problems; providing host migration without changing the IP address of a host (as discussed in section 2.1), and supporting the shift between the two modes of operation of the TCP connections (regular and triple point operation). We need to consider two ways that a MH may connect to the xed net; directly attached to the LAN or connected by serial link (GSM link or ordinary PSTN modem link) via MSG. In the following we rst describe, how this migration between the two modes of connectivity is performed in the case where the MH and MSG belong to the same LAN and where the MH always connects to the same MSG. In that case the routing problem is trivial, and we concentrate on describing how to move between the two modes of operation of the TCP connections. After that, we describe how this design can be extended to allowing the MH to connect to any MSG in any network by using Mobile IP [Per95], and there we need to consider a more complex problem of IP routing. When moving between the two modes of operation, we need to bring the TCP connections of the MH into a well de ned state (hereafter called freezed), such that the central point may either be inserted or removed. A more thorough description of how TCP states are captured, and how the central point of a triple point TCP connection is inserted or removed is given in section 4.2.1. For the discussion in this section, please accept that this is possible and that there is a need for synchronising the central points when moving from the roaming to the xed state.

3.3.1 Single Local Mobility Support Gateway

In the following we will rst take a look at how IP packets may be redirected between a MH and the MSG, when they are connected to the same LAN. We will then present protocols for inserting and removing the central point of the triple points connections, and provide a discussion of how to deal with possible packet loss on disconnect.

CHAPTER 3. DESIGN

60

3.3.1.1 Local Redirection of IP Packets When a MH disconnects from the LAN, it moves the administration of its TCP/IP connections to the MSG. This MSG must receive all IP packets destined for the MH, while the MH is disconnected (from the LAN). In the case where the MH and MSG are connected to the same LAN, we actually have a two-level naming scheme as described in section 2.1; the top level is the IP addresses and the bottom level is the hardware addresses of the network adapters. Furthermore there is a possibility of updating the bindings between the names of the two levels by using the (Ethernet) Address Resolution Protocol (ARP) (see Appendix B). By sending a gratuitous ARP reply with the IP address of the MH and the hardware address of the network adapter of the MSG, all other hosts connected to the LAN should update their ARP caches, as speci ed in [Plu82], such that all packets for the MH are directed to the MSG. Of course the IP packets can be directed back to the MH in the same manner. The situation, where IP packets are redirected to the MSG, is illustrated in Figure 3.11, where (a) is before the gratuitous ARP reply and (b) is after. There are two MSG

MSG

ARP cache IPMH HWMH

ARP cache IPMH HWMSG

IPMSG HWMSG

IPMSG HWMSG

LAN

LAN

SH

MH

SH

MH

ARP cache IPMSG HWMSG IPMH HWMH

ARP cache IPMSG HWMSG

ARP cache IPMSG HWMSG IPMH HWMSG

ARP cache IPMSG HWMSG

IPSH HWSH

IPMH HWMH

IPSH HWSH

IPMH HWMH

Legend:

(a)

(b)

IP datagram route

MSG ARP cache IPMH HWMH

IPMSG HWMSG

Hostname Arp cache IP address to hardware address mapping

Host IP address Host hardware address

Figure 3.11: IP packet redirection using ARP problems with this approach|ARP packets may get lost and many TCP/IP implementations do not update the ARP caches as speci ed in [Plu82] (as stated in [Ste94]). The eects of the rst problem can be reduced by sending multiple ARP replies. The second problem is more severe| the only authorized way to change the association between an IP address and a physical address is not supported by all TCP/IP implementations. Either the machines on the LAN must support the ARP cache updates or it is necessary to introduce an indirection, such that all messages sent to MHs are delivered through the MSG by using for example IP in IP encapsulation to provide tunneling|even when the MH is connected to the same LAN. The rst limits the use of the mobile

CHAPTER 3. DESIGN

61

communication system, and the second doubles the bandwidth requirements of MHs connected to the LAN|both solution seems unacceptable. But as we have chosen to use Mobile IP as the general IP migration support mechanism, and as the Mobile IP suggestion uses the ARP cache update, the support of this feature will possibly become more widespread in the future, and we therefore choose the ARP cache update solution.

3.3.1.2 Protocol for Detachment When a MH moves from the xed to the roaming state, it must perform the following two steps: Freeze and transfer TCP states from MH to MSG. Redirect IP packets from MH to MSG. The MH part of the protocol for performing these two steps is given in Figure 3.12 and the MSG part is given in Figure 3.13. The MH establishes a TCP connection to the connection server at the MSG (we will refer to this TCP connection as the control connection). In order to allow a system administrator to restrict the number of proxy hosts at the MSG, the MH must rst send a leave request (REQ LEAVE message) to the MSG, which then either grants the leave (GRANT LEAVE message) or denies it (NO LEAVE message). In case the MH is denied the leave, it must either try another MSG, stay connected or detach without the MSG support. If the MSG accepts creating the proxy host of the MH, the MH freezes all but one of its TCP connections. The control connection is not frozen, as it has to be used for the TCP state transfer. This is no problem, as the control connection is only used during detachment, so it need not be transferred to the MSG. When the MSG has received all TCP states from the MH, it may initialize and start the central point and the proxy host of the MH. As the TCP connections at the MH are frozen, they do not interfere with the central points. When the proxy host is successfully started, the MSG closes the control connection. When the MH detects this, it may safely redirect the IP packets to the MH by the procedure in section 3.3.1.1. If the user physically detaches (detection of interface change is described in section 3.2) while the MH is at one of the steps before 5 in Figure 3.12, the TCP connections are brought back to the regular TCP mode of operation. At the MSG the detachment will cause a time out of the TCP connection, and any information about the MH will be deleted. These actions are taken in order to bring the system in a well de ned state, where the user may reattach and reexecute the detachment protocol. If the MH remains detached, the TCP connections may abort in case of timeouts.

3.3.1.3 Protocol for Attachment

When the MH moves from the roaming state to the xed state, the three following steps must be performed: 1. Synchronize TCP states of MH at the MSG (as described in section 4.2.2). 2. Transfer the relevant information to the MH. 3. Redirect IP packets from MSG to MH.

CHAPTER 3. DESIGN 1. 2. 3. 4. 5. 6. 7. 8.

62

The user requests a detachment A TCP connection C is established to the connection server at the MSG. An REQ LEAVE message is sent to the connection server. On the receipt of an GRANT LEAVE message, all TCP connections except C are frozen, and the states are transferred to the connection server. The MH receives an acknowledgement of the TCP states, and the connection C is closed. Wait for C to be closed by MSG. IP packets are redirected from MH to MSG. When the physical detachment is detected, the TCP connections are thawed. Figure 3.12: Detach protocol { mobile host part

The part of the attach protocol executed by the MH is given in Figure 3.14 and the part executed by the MSG is given in Figure 3.15. When a MH attaches to the LAN, the proxy host at the MSG must be emptied in order to be removed. During this phase, the MH should use a mode of operation which is akin the one used when connected by serial link. In order not to bring either MH, PH or proxy endpoints into a false state, the MH is it not allowed to send or receive any TCP segments directly on the LAN. To allow the MH to exchange TCP segments with the MSG, the TACO layer is brought into a synchronization state, where all IP packets, except UDP datagrams for a speci c UDP port, are encapsulated in a UDP datagram and transmitted to speci c UDP port at the MSG. Here they are treated as if they were received by serial link. As the UDP datagrams sent from the MSG to the MH cannot be routed conventionally due to the IP redirection, the link-layer packet is updated with the link-layer address of the MH. In order to avoid that the MH changes the ARP caches of any hosts during this phase, the ability of answering ARP requests is disabled. In this way the MH acts as if it was attached by serial link until the proxy host is synchronized, and thus can be removed. When the MH detects, that it has been attached to the network, the TACO layer enters this synchronize state, and the MH establishes a TCP connection to the MSG (from now on called the control connection). It sends a REQ ATTACH message to the MSG thus starting the synchronization of its proxy host. The MH now awaits the PROXY SYNCHED message, telling it that the MSG has removed its proxy host. When the MSG receives the REQ ATTACH message, it starts to synchronize the TCP connections of the proxy host of MH except the control connection. If all TCP connections are synchronized within a time limit speci ed by the system administrator, the MSG sends a PROXY SYNCHED message to the MH, and otherwise the TCP connections not yet synchronized are reset, and a PROXY SYNCHED message is still sent to the MH.

CHAPTER 3. DESIGN

63

1. A REQ LEAVE message is received on TCP connection C. If it is possible to create a new proxy host, an GRANT LEAVE message is sent to the MH. Otherwise a NO LEAVE message is sent, and this is aborted. 2. The connection server receives the frozen connection states, converts them to its native form, and inserts the new central points of the connections of the MH. 3. An acknowledgement of the connections is sent to the MH. 4. The connections are thawed, and the store and forward mechanism is started. 5. Close TCP connection C. Figure 3.13: Detach protocol { mobility support gateway part If the user physically detaches, while the attach protocol is before step 4 in Figure 3.14, the MH reverts to disconnected TCP operation. After this step a physical disconnect will cause the MH to use normal TCP operation, as with the disconnect protocol. Likewise the MSG will resume supporting disconnected operation of the MH, if a physical detachment is detected before step 4 in Figure 3.15. Otherwise the proxy endpoints and the state information of the MH has been deleted, and no action is taken. 1. When a physical attach to the LAN is detected, the synchronization mode of the TACO layer is entered. 2. A TCP connection is established to the connection server at the MSG, and a REQ ATTACH message is sent. 3. Wait for the PROXY SYNCHED message. 4. On the receipt of the PROXY SYNCHED message, the MH closes the connection to the connection server. 5. IP packets are redirected from MSG to the MH. Figure 3.14: Attach protocol { mobile host part

3.3.1.4 IP Packets Arriving During Detachment or Attachment Both when connecting and disconnecting IP packets may be lost due to the freezing or synchronization. This loss will cause retransmission of TCP packets and loss of UDP packets. When detaching IP packets may be lost from step 4 in Figure 3.12|where the connections are frozen| to step 7|where the IP packets are redirected. When attaching IP packets are lost from step 2

CHAPTER 3. DESIGN

64

1. A REQ ATTACH message is received from a MH. 2. Wait for the data queues of the MH's proxy TCP endpoints to be emptied, as described in section 4.2.2. 3. A PROXY SYNCHED message is sent to the MH, 4. MH state information and proxy endpoints are deleted. Figure 3.15: Attach protocol { mobility support gateway part in Figure 3.15|where the MSG starts emptying the data queues of the central points|to step 5 in Figure 3.14|where the IP packets are redirected from MSG to MH. It may be possible to remove packet loss due to transfer by either buering the packets or by using ow control messages, but it may not be very important to do so, as the disconnects and connects from the LAN are infrequent with normal usage patterns.2 Thus a simple solution with the possibility of packet loss may be preferable as opposed to a complex protocol with buering and forwarding. The transfer of the connection states should not be a costly aair|the size of state information saved when freezing the connections is quite small, as described in section 4.2.1. Thus the actual time used to transfer the connection states should not amount to much, and the solution which involves packet loss is chosen for the sake of simplicity.

3.3.1.5 Connect by Serial Links When using a serial link|either GSM or wired links|the MH establishes a connection to a MSG. The identity of the MH is determined during connection establishment by the login procedure performed when connecting via PPP, by assigning each MH a unique login and password. When a connection is established between a MSG and a MH via a serial link, there can arise one of the following situations: 1. The MH connects to the MSG for the rst time and has been restarted since it detached, and in this case there are only local TCP connections on the MH, as it has not been connected to the xed network before). The possible con gurations are: (a) The MH has not detached from the network using the detach protocol or the MSG has been restarted since the MH detached, and there is no proxy host for the MH at the MSG. (b) The MSG has a proxy host for the MH, which means that MH has correctly detached from the xed network before it restarted. In this case the proxy host is not consistent with the TCP connections of the MH. 2

The MH usually connects/disconnects a couple of times a day|but for a long period of time.

CHAPTER 3. DESIGN

65

2. The MH connects to the MSG and has not been restarted while detached. In this case the following two scenarios are possible: (a) The MSG has been restarted since the MH detached. In this case there is no proxy host for the MH at the MSG. (b) The MSG has not been restarted since the MH detached, in which case there is a correct proxy host If the case 1a described above occurs, a new proxy host for the MH is created. This is easy, as there are no TCP states to be transferred, and the MSG just needs to create an empty proxy host for the MH, and perform the IP datagram redirection. In the case 1b an error situation has occurred. To get a consistent state of the proxy host, the old proxy host is deleted, and a new proxy host is created as described above. In order to detect if this case occurs, each proxy host receives a timestamp delivered by the MH at the time, where the proxy host is created. When MH subsequently connects to the MSG, the timestamp of the MH is compared to the timestamp of the proxy host at the MSG, and if these two are not equal, the error situation has occurred. In the case 2a the MH has lost its proxy host, and it makes no sense to create a new proxy host, as acknowledged data may have been lost. In this case the MH should be restarted, and this case is converted to the case 1a. In order to distinguish this case from case 1a, the MH must remember whether it should have a proxy host or not. The last case (2b) is the normal mode of operation.

3.3.2 Multiple Wide Area Mobility Support Gateways

Although this is not part of our implementation goals, we still need to provide a viable way to support Multiple MSGs in a WAN in the future. We will describe the extension in two steps; one covering how to use MSGs placed in any part of a WAN, and one covering how to use dierent MSGs during the same roaming session.

3.3.2.1 Non-local MSG Using a MSG in a non-local network complicates the matters of IP redirection, as described in section 2.1. It is only the redirection of IP packets that must be changed in order to support this, and below we present an IP redirection scheme using the Mobile IP support.

Detachment In order to redirect IP packets during detachment, we assume that a foreign

agent is present at the MSG, which is to be used. The connection server should receive enough information form the MH in order to fake a connect of the MH through the foreign agent. In this way, the IP packets will be redirected from the home agent of the MH to the foreign agent at the MSG. The foreign agent decapsulates the IP datagrams and forwards them on a device speci ed in the local routing table. As the MH need not deregister with the home agent, it may detach from the network, when it is sure the MSG has received the necessary information in order to provide the fake registration. By routing the decapsulated IP packets to a pseudo device, which

CHAPTER 3. DESIGN

66

passes these IP packets through the IP layers as if they were received from the xed network, the functioning of the MSG may remain the same as described in section 3.1.2.2.

Attachment As described in section 3.3.1.3, there is a period of time during attachment, where

the MH is unable to send and receive IP packets in the ordinary fashion, as they are redirected to the MSG. With a single local MSG, this could be solved by using the link-layer addresses, but when the MSG may be located in another network, that is not an option. In order to allow the MH to communicate with the MSG, the network, which the MH attaches to, must provide the MH with a temporary address. After that, the IP packets may be tunnelled between the MH and the MSG in order to synchronize the proxy host of the MH. The nal redirection of packets may be done by letting the MSG cheat on the foreign agent, and then letting the MH register with its home agent.

3.3.2.2 Multiple MSGs It is clear, that only one MSG can have the responsibility of administering the proxy host of a MH. In the following we will refer to this MSG as the home MSG of a MH. In a setting, where it is possible for a MH to connect to several MSGs, it should always inform the MSG it connects to of the name of its home MSG. In the case, where the MH is connected to a MSG dierent from its home MSG we look at two dierent situations: 1. The MH has a collection of MSGs all located in the same geographical area. In order to obtain access to the xed network, the MH will connect to any of these MSGs, depending on which one is available, but it will always prefer to connect to its home MSG. 2. The MH has moved so far away from its home MSG, that it is more pro table to connect to a MSG (or a collection of MSGs) in a dierent geographical area. In the rst case the MSG which the MH connects to should establish a connection to the home MSG of the MH, and provide tunneling of the IP packets of the MH to the home MSG. The home MSG should regard this as if the MH was connected directly to the home MSG via a serial link. This scheme may increase the packet delay experienced by the MH, but as the use of a speci c non home MSG is intermittent, the hassle of moving the responsibility of the proxy host to a new MSG is not worthwhile. In the second case the approach above may be used if the use of the MSG is of an intermittent character. If the users expects to be located in the area for a longer period of time, he/she may request that the new MSG becomes the home MSG of the MH. By using a protocol akin to the detach protocol (Figures 3.12 and 3.13) this could be done without interaction of the MH. In this way the MH could connect and request that the home MSG should be changed, and then later reconnect to the new home MSG.

3.3.3 Summary

In our case host migration involves two problems:

CHAPTER 3. DESIGN

67

redirection of IP packets moving between regular point-to-point and triple point mode of operation In an environment, where MHs and MSGs belong to the same subnet, the redirection of IP packets is performed by using ARP cache updates. In the case where MHs and MSGs may belong to dierent networks, Mobile IP can be used to provide IP packet redirection. When a mobile host detaches from the LAN, the switch to the triple point mode of operation is done in two phases: 1. The TCP connections of the MH are synchronized and frozen 2. The states of the TCP connections are transferred to the MSG, where they are thawed. When a mobile host attaches to the LAN, the central points of its TCP connections (placed at the MSG) are brought into a state, where no data is buered, and at this point they may be removed. This completes the switch from triple point to point-to-point mode of operation.

3.4 Summary Semi-connected operation is supported by splitting the TCP connections of the RMHs into two parts. The split is made at the MSG, that is thus able to maintain the connections of the MHs during periods of disconnected operation. Both parts of the split connections use TCP, and as the sequence numbers assigned to the data transferred on the two parts are consistent, we view the split connections as a single triple point connection. This consistency also provides a simple way of changing between using regular TCP connections (when a MH is xed), and triple point connections (when a MH is roaming). By allowing the mobile host to change between using regular point-to-point and triple point TCP connections, virtually no performance penalty is introduced by the system, when a mobile host is xed. The shift between the roaming and xed state of a mobile host is fully supported, when the MH and the MSG belong to the same LAN. This is done using ARP cache updates. In the case, where MHs and MSGs belong to dierent LANs (subnets), the shift may be supported in the future by using Mobile IP. System level support for adaption to changes in media of communication is supported by data scheduling of IP packets based on quality of service parameters. Application level adaption is supported by allowing applications to get noti cations, when a change in the network resources occur.

Chapter 4

Semi-Connected TCP The idea behind the triple point connection is to split the TCP connections into two parts; one covering the intermittent part of the connection and one covering the part in the xed network. This allows for providing special support for semi-connected operation on the intermittent link. By keeping the sequence numbers of the data transferred on the two parts consistent, it is simple to change between the regular point-to-point and the triple point mode of operation. In this chapter, the general workings of a triple point TCP connection, and the problems of moving between point-to-point and triple point TCP connections, are described. Furthermore, a brief overview of the implementation of the support for semi-connected TCP is provided.

4.1 Triple Point TCP Connection As described in section 3.1.3, a triple point connection consists of two regular TCP connection endpoints and a central point. The central point consists of two proxy endpoints|one for each of the real endpoints|such that data transfer is allowed to continue independently on the two parts of the connection. As the two real endpoints are regular TCP endpoints, the mode of operation of the central point should allow these endpoints to function normally in all the phases of a TCP connection: Establishing a new connection Data exchange Closing a connection Connection abortion In the following we describe how these phases are supported by triple point connections, such that the functionality of the two endpoints is unaected. Furthermore, we describe how the part of the triple point connection between the MH and MSG can be suspended to provide support for disconnected operation. Apart from the usual messages exchanged between the endpoints, we also use proxy events, which are messages from one of the proxy endpoints to the other. With respect to packet loss, 68

CHAPTER 4. SEMI-CONNECTED TCP

69

the two proxy endpoints use the same retransmission strategy as conventional TCP. The message diagrams presented below are inspired by the diagrams in [Ste94]. A legend covering Figures 4.2 through 4.9 is given in Figure 4.1. Host X XXX

Endpoint at host X starts in state XXX, but switches to state YYY as time progresses.

YYY Ordinary message occupying the sequence numbers from N to M and with tag XXX. Ordinary message occupying the sequence number N and with tag XXX. Proxy event with tag YYY. A message with tag ZZZ, which may or may not be sent.

Figure 4.1: Legend of message exchange diagrams

4.1.1 Establishing a Connection

The establishing of a TCP connection is normally done using a three way handshake, as seen in Figure 4.2, where the SYN messages synchronize the sequence numbers. The message exchange consists of an active host (e.g., a client) and a passive host (e.g., a server). Active host CLOSED SYN_SENT

Passive host LISTEN

SYN_RCVD ESTABLISHED ESTABLISHED

Figure 4.2: Three way handshake in regular TCP When adopting this procedure for the triple point TCP connections, two issues must be considered: Handling of disconnected operation Initialisation of the central point


70

4.1.1.1 Disconnected Operation What should be the behaviour of connection establishment, when the MH is disconnected ? We consider the following two possibilities: A \fake" connection is established by the MH proxy endpoint, such that the two parts of the connection are able to perform the three-way handshake independently. A forwarding approach, where the SYN segments are passed through the central point, such that connection establishment is only possible during periods, where the mobile host is connected. Using the \fake" connection establishment has the advantage, that applications trying to establish a connection to or from the MH may complete the three-way handshake, even if the MH is disconnected. When the MH is disconnected, the three-way handshake, where a PH is the active part, may be completed by letting the MH proxy endpoint decide the initial state of the endpoint, and send the synchronization and acknowledgement segment to the PH. When a link to the MH is established, the connection establishment must be completed, bringing all endpoints in a consistent state. One way to do this, is to transfer the state of the MH proxy endpoint to the MH and use it to initialize the real MH endpoint. When the MH is the active part, the connection establishment may be faked by allowing the application to return from the connect call prior to connection establishment, and letting the SYN segment be buered in the TACO layer. This will allow the application to proceed, and it may start transmitting data, that will be queued after the SYN segment. These solutions introduces the following disadvantages. When a PH is the active part, it is necessary to perform a synchronization of the two real endpoints, thus adding to the complexity of the solution. Furthermore, connection establishment may be faked, only to discover, that it is not possible to complete the establishment. This situation will change the semantics of the TCP layer, as the application is in a state where it believes, that the peer host has accepted its connection request. Thus the application is not able to distinguish between a rejected connection attempt and an unreachable host. It is possible for the MH to inform the MSG of, what ports it will accept connection requests on, but this information may become outdated when the MH is disconnected, again leading to erroneously established or rejected connections. Using the forwarding approach, the messages of the three-way handshake will be forwarded to the other part of the triple point connection without being acknowledged (see Figure 4.3). In the case, where the MH is the passive part, a connection request from a PH may be received while the MH is disconnected, in which case the SYN segment may either be buered in the TACO layer or discarded, or a reset may be sent to the sending PH. Buering the message in the TACO layer allows this layer to detect, that a connection request has been made, and it may forward the SYN segment, if a link is established within reasonable time. This will cause the PH to retransmit connection request, but eventually it will either timeout or receive an acknowledgement. The solution using connection resets requires, that the TCP layer has knowledge of whether the MH is disconnected or not. As this may change rather abruptly, it may not be possible to react correctly in all situations. When the MH is the active part, the SYN segment will be buered in the TACO layer at the MH, causing the calling process to block until a suitable link is established.

CHAPTER 4. SEMI-CONNECTED TCP Active host

71

MSG

CLOSED

WAIT_SYN

WAIT_SYN

Passive host LISTEN

SYN_SENT

WAIT_ACK_P_1 WAIT_ACK_P_2 SYN_RCVD

WAIT_ACK_A_2 WAIT_ACK_A_1 ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED

Figure 4.3: Three way handshake in triple point TCP As the MH predominantly will function as a client in a client/server relationship, the MH will usually be the active part of the connection establishment. We therefore sacri ce the transparency of the connects to disconnected MHs for the sake of simplicity, and use the solution, where connection attempts are forwarded by the MSG, even if the MH is disconnected at that time. This means, that a connection attempt from a PH may time out, if the MH does not connect to the MSG within the connection time-out period of a regular TCP connection. On the MH, an application will block until a suitable link is established, as the timers of the connection endpoint at the MH are disabled. The state transition diagram for the proxy endpoints is depicted in Figure 4.4.

4.1.1.2 Initialisation of Central Point The proxy endpoints can be initialised by looking at the messages being forwarded, so that at the completion of the message exchange, all points are ready for the data exchange. As required, the two real endpoints proceed through the TCP states as if there was no central point.

4.1.2 Data Exchange

Each proxy endpoint must acknowledge and send data, as a conventional TCP connection. The only dierence is, that received data is copied to the transmit queue of the other proxy endpoint. Thus the data exchange is done, as if the TCP connection was two separate connections. In cases, where the available buer space at the MSG is limited, conventional TCP ow control is used.


72

WAIT_SYN

RECV:SYN PROXY EVENT:SYN_RCVD TIME-OUT

WAIT_ACK_P_1

WAIT_ACK_P_2

PROXY EVENT:ACK_P_RCVD SEND:SYN;ACK TIME-OUT

WAIT_ACK_A_1

TIME-OUT

PROXY EVENT:ACK_A_RCVD SEND:ACK

ESTABLISHED

Legend:

UUU

TIME-OUT

RECV:ACK,SYN PROXY EVENT:ACK_P_RCVD WAIT_ACK_A_2

RECV:ACK PROXY EVENT:ACK_A_RCVD

SSS:AAA TTT:BBB

PROXY EVENT:SYN_RCVD SEND:SYN

State transition caused by event SSS:AAA, which triggers event TTT:BBB. The state UUU.

Figure 4.4: State transition diagram for triple point connection establishment The window advertised to the sender is never larger than the available buer space. As required, the two real endpoints send and receive data, as if there where no central point. An example of a data exchange is given in Figure 4.5. The support for disconnected operation during data exchange is described in section 4.1.5.

4.1.3 Closing a Connection

When an endpoint has sent its last byte of data, the closing of the connection is initiated by sending a FIN byte to the peer. When this FIN byte is acknowledged, the endpoint waits for the peer to send a FIN, or the connection is closed if a FIN byte has already been received. There are two dierent kinds of message exchanges, the simultaneous close , where the FIN messages cross each other, as depicted in Figure 4.6, and the non-simultaneous close , where the rst FIN message is acknowledged before the second FIN is sent,1 as shown in Figure 4.7. When closing a triple point connection, the FIN message is acknowledged as soon as possible, so that the sender will enter the FIN WAIT 2 state, thus remaining passive until either data or a FIN message is received. In the simultaneous close the central point will receive both FIN messages, and acknowledge both of them before sending the FIN to the endpoints. Thus the message exchange for each endpoint will be the same as in the non-simultaneous close for two hosts with the local endpoint as the initiating part (this is depicted in Figure 4.8). In the nonsimultaneous close the message exchanges for the endpoints are the same as in the two host Between the acknowledgement and the second FIN, additional data may be sent from the endpoint not nished. This is known as a half-close. 1


Host A ESTABLISHED

73

MSG

Host B

ESTABLISHED ESTABLISHED

ESTABLISHED

Figure 4.5: Data exchange with triple point TCP

Host A

Host B

ESTABLISHED

ESTABLISHED

FIN_WAIT_1

FIN_WAIT_1

CLOSING

CLOSING

TIME_WAIT TIME_WAIT

CLOSED

CLOSED

Figure 4.6: Simultaneous close in regular TCP


74

Host A

Host B

ESTABLISHED

ESTABLISHED

FIN_WAIT_1 CLOSE_WAIT FIN_WAIT_2

LAST_ACK TIME_WAIT CLOSED CLOSED

Figure 4.7: Non-simultaneous close in regular TCP scenario. A possible non-simultaneous close is shown in Figure 4.9. Thus the endpoints function without any change. The state transition diagram of the three node close is depicted in gure 4.10. This is akin to the state transition diagram of a two node close, except for the proxy events. The support for disconnected operation is obtained by timer disabling as described in section 4.1.5. Host A ESTABLISHED

Host B

MSG ESTABLISHED ESTABLISHED

FIN_WAIT_1

FIN_WAIT_1

FIN_WAIT_2

ESTABLISHED

P_CLOSE_WAIT P_CLOSE_WAIT

P_LAST_ACK

FIN_WAIT_2

P_LAST_ACK TIME_WAIT

TIME_WAIT

CLOSED CLOSED

CLOSED

CLOSED

Figure 4.8: Simultaneous close in triple point TCP


Host A

75

MSG

ESTABLISHED

Host B

ESTABLISHED ESTABLISHED

ESTABLISHED

FIN_WAIT_1 P_CLOSE_WAIT P_FIN_WAIT_1

FIN_WAIT_2

CLOSE_WAIT P_FIN_WAIT_2

LAST_ACK

P_LAST_ACK

TIME_WAIT CLOSED

TIME_WAIT CLOSED

CLOSED

CLOSED

Figure 4.9: Non-simultaneous close in triple point TCP ESTABLISHED PROXY_EVENT:FIN SEND:FIN

RECV:FIN SEND:ACK P_CLOSE_WAIT

P_FIN_WAIT_1 RECV:ACK

RECV:FIN,ACK SEND:ACK PROXY EVENT:ACK

P_LAST_ACK

P_FIN_WAIT_2 RECV:FIN SEND:ACK PROXY EVENT:ACK

SSS:AAA TTT:BBB UUU

RECV:ACK TIME-OUT TIME_WAIT

Legend:

PROXY EVENT:FIN SEND:FIN

CLOSED

State transition caused by event SSS:AAA, which triggers event TTT:BBB. The state UUU.

Figure 4.10: State transition diagram for triple point close


76

4.1.4 Connection Abortion

In conventional TCP a connection may by aborted in two cases|either the application issues an abort command or a valid segment with the RST ag set is received. In both cases the abortion of a connection results in the discarding of all data buered in send, receive, and retransmit queues. When a proxy endpoint of triple point connection receives a valid reset segment from a real endpoint, a reset segment is sent to the other real endpoint, and both parts of the connection are aborted. In the triple point connections, like in usual TCP connections, all buered data is discarded, when a connection is aborted. It is possible for the MSG to abort a triple point connection by sending a reset to both real endpoints. This abortion may be necessary in case of error conditions on the MSG or if a system manager of the MSG decides to remove a triple point connection.

4.1.5 Suspended TCP Connections

The part of a triple connection connecting the MH and the MSG must be able to survive periods, where it is not allowed to transmit data. These periods can either be caused by disconnected operation or by unful lled quality of service requirements (see Section 3.2.3.2). If a TCP connection attempts to transmit a TCP segment in any of these cases, it will be placed in one of the suspended queues (the pending set, the wait queue or the unresolved set). To avoid TCP connection time-outs (see Section 2.2.2) of these suspended TCP connections, we disable their timers. This is done by the following rules: When a TCP connection endpoint is created (prior to any data transmission), the timers of the endpoint are enabled. At this point the endpoint is not registered in any of the data scheduling queues. When a segment is transmitted by a TCP connection, the connection will either be associated with a connection ow descriptor in the active queue or one of the suspended queues. In the rst case the timers remain enabled, and in the second case the timers are disabled. When a connection is either moved from a suspended queue to the active queue or deleted from a suspended queue, the timers of the connection are enabled. When these rules are followed, we are sure that all idle or active TCP connections have their timers enabled, and that all suspended TCP connections have their timers disabled. Thus we know that only the TCP connections present in one of the suspended queues have their timers disabled. In this way we avoid deadlock-like situations, as for example where a TCP connection endpoint needs to retransmit a lost segment in order to become active, but is unable to do so because of a disabled retransmission timer. Using the above rules, such connection endpoints will be activated by the data scheduling mechanism, when they leave one of the suspended queues. Another concern of the suspended TCP connections is the buered TCP segments. The TCP speci cation proscribes, that TCP sequence numbers are not reused within the Maximum Segment Lifetime (MSL), in order to avoid situations where outdated segments are accepted as valid by a TCP connection.2 As our data scheduling mechanism uses FIFO queues, the only time where 2

In the TCP speci cation, the MSL is taken to be two minutes.


77

an outdated segment may be sent is, when a previous connection with the same connection ow descriptor still has buered packets. This situation can not occur, as the scheduling mechanism only buers the TCP segments of a TCP connection endpoint while that connection endpoint still exists. This is due to the fact, that a TCP connection endpoint is removed either by a connection reset or after a period of time in the TIME WAIT state. On the transmission or receipt of a reset segment, all other TCP segments for the reset connection are removed from the data scheduling queues, and when the TIME WAIT phase is completed, the TCP connection must have been active for the time required to transmit all buered TCP segments, as the timer controlling the TIME WAIT period is disabled when the connection is suspended. Thus we have that a TCP segment is not able to survive its origination TCP endpoint, and the sequence number lifetime restriction is kept.

4.1.6 Summary

The design of the triple point TCP connections allows them to function together with ordinary endpoints in all phases of a TCP connection. The timer disabling of TCP connections in the suspended queues of the data scheduling mechanism removes the possibility of connection time-outs during disconnected or suspended operation of TCP connections, while the TCP connection is in either the established, closing, or resetting phase. In the connection establishment procedure it is not suitable to hide the unavailability of the suspended or disconnected part of the TCP connection, as this may give rise to falsely established connections. Instead a forwarding approach is used, where the TCP segments of the connection establishment procedure are passed through the central point, using these segments to initialize the central point. This may result in connection establishment timeouts, when a PH attempts to establish a connection to a disconnected MH. The resulting state transition diagrams show, that including support for triple point connections does not add substantial complexity to the TCP layer.

4.2 Change of TCP Connection Mode of Operation As already described in section 3.3, the TCP connections must be able to change between two modes of operation; regular point-to-point operation and triple point operation. In this section we describe how to insert and remove a central point, such that a TCP connection can move between the point-to-point and triple point mode of operation.

4.2.1 Inserting the Central Point

In order to insert a central point in a TCP connection, the proper con guration of the two proxy endpoints of the central point must be determined. As these proxy endpoints are endpoints of a TCP connection, we need to determine a valid TCP state for the two proxy endpoints. The state of the TCP connection endpoint at the MH can be obtained by the MH, so the problem is to determine the peers endpoint state, as this cannot be retrieved from the peer endpoint (this requires access to the TCP layer information of the PH). In the following we will describe how


78

to make a usable approximation to the peer endpoint state based on the TCP state of the MH endpoint. The parts of the state, that have our interest, are those directly used in the data exchange. Various socket options, that control lingering, buer space, synchronous/asynchronous, and internal administrative information like owner process ID, socket I-node, etc., do not need to be transferred, as these are unimportant with regards to impersonating the peer endpoint. Furthermore, the administration of buer space, lingering, etc., may be dierent at the MSG. The items directly connected to data transfer at the endpoint of a TCP connection are: TCP protocol state (LISTEN, ESTABLISHED, : : : ) Sequence variables Data queues The timers used by TCP Data exchange parameters, such as the TCP maximum segment size, send window size and retransmission time-out value It is those we refer to as the state of a TCP connection endpoint. In the following sections we will examine the dierent parts of the state in more detail. We will refer to the real and proxy endpoint state of the MH as M and M0, and the real and proxy endpoint state of the PH as P and P0.

4.2.1.1 TCP Sequence Variables In this section we provide a brief introduction to sequence variables in TCP, as the next section requires some knowledge of these.

SND.UNA SND.NXT SND.WND SND.UP ISS RCV.NXT RCV.WND RCV.UP IRS

The lowest sequence number of any unacknowledged byte sent Sequence number of the next byte to send The size of the send window This marks the end of the most recently sent urgent data The initial send sequence number The expected sequence number of the byte to receive next The size of the receive window This marks the end of the most recently received urgent data The initial receive sequence number Table 4.1: TCP sequence variable summary

The reliable data transfer of TCP is implemented using a sliding windows protocol without selective acknowledgements. The bytes in each of the two data streams between the endpoints of a TCP connection are assigned consecutive sequence numbers.3 A number of sequence variables 3

This is done modulo the size of the TCP sequence number space, which is currently 232 .


79

are used to keep track of sent, unsent, received, high priority, acknowledged, and unacknowledged data. The sequence variables de ned by the TCP speci cation [Pos81b] are summarised in table 4.1. To allow applications to send data with dierent priorities on the same connection, TCP has two kinds of data, normal data and urgent data. If the recipient receives urgent data, the application is noti ed and informed of the end position of the urgent data. It is thus possible to skip through the bulk of data in front of the urgent data. Urgent data is sometimes referred to as out of band data, but this is somewhat misleading, as the stream property of the TCP connection is maintained even with urgent data. The SND.UP speci es the end of the most recent urgent data at the sender, and RCV.UP speci es the end of the most recent received urgent data. New segments with urgent data will thus overwrite the old SND.UP and RCV.UP. Legend: Current window position X

Acknowledged segment X

Y

Unacknowledged segment Y

Z

No data in segment Z u

Segment contains urgent data Data path Data path not established

Figure 4.11: Legend of TCP sequence variable illustrations The dierent sequence variables involved in data transfer are summarised in Figure 4.12. A legend for this and the following illustrations of sequence variables (Figures 4.12, 4.13, and 4.14) is given in Figure 4.11. SND.WND

1

u

SND.UP

2

3

SND.UNA

4

RCV.WND

5

6

SND.NXT

7

8

1

u

RCV.UP

2

3

4

5

6

7

8

RCV.NXT

Figure 4.12: TCP sequence variables

4.2.1.2 Initial Sequence Variables in Proxy Endpoints In this section, we explore the possibility of bringing the two endpoints in a state, where a usable approximation of the variables of endpoint P can be determined from endpoint M. It is


80

very important to provide a set of valid values for P0 , as it otherwise could leed to erroneously accepted or discarded data. The starting point is the following equations describing the bounds on the sequence variables, which is derived from the general workings of TCP data exchange (P.XXX and M.XXX refer to variable XXX at the PH and the MH):

M:SND:UNA P:RCV:NXT M:SND:NXT P:RCV:NXT + P:RCV:WND P:RCV:NXT M:SND:NXT P:SND:UNA M:RCV:NXT P:SND:NXT M:RCV:NXT + P:RCV:WND M:RCV:NXT P:SND:NXT

(4.1) (4.2) (4.3) (4.4) (4.5) (4.6)

By adjusting the amount of data sent and received at the MH endpoint, it is possible to control the value of the variables M.SND.NXT and P.RCV.WND. By letting M.SND.NXT remain xed, that is not sending any new data, M.SND.UNA will eventually equal M.SND.NXT, and by

M:SND:UNA = M:SND:NXT ) P:RCV:NXT = M:SND:NXT

(4.7)

we can determine P.RCV.NXT. By shrinking the receive window size (M.RCV.WND) to zero, we may accomplish, that both P.SND.NXT and P.SND.UNA equal M.RCV.NXT, and thus all necessary values of the PH sequence variables are determined. There are however a few problems connected with shrinking the receive window at the MH: It is strongly discouraged in the TCP speci cation [Pos81b], as it may force the sending part to move data between dierent queues, and should therefore be avoided. It may not be possible to verify, that the send window actually is shrunk at the peer. In the case where the MH endpoint has no data ready to send, the TCP packet which changes the window size to zero does not occupy any sequence numbers, and therefore an acknowledgement of the packet is impossible. We therefore abstain from this. Instead M.RCV.NXT is used as an approximation of P0 .SND.NXT and P0 .SND.UNA (equations 4.3 and 4.6), when P0 is initialised. When the state of a MH endpoint has been captured, there may arrive TCP packets from the PH to the MH. If these packets contain unacknowledged data, this data must not be acknowledged. Otherwise the receive window of the MH proxy endpoint will never move past the TCP packets acknowledged after the state capturing. This is shown in Figure 4.13, where segment 1 is never received by the MH proxy endpoint. Likewise it is disastrous to accept acknowledgement of previously unacknowledged data after the MH endpoint state has been captured. There is no problem, when data is sent or received without a piggy backed acknowledgement of previous unacknowledged data. An example of this is given in Figure 4.14, where segment 1 has been accepted by the MH, but the acknowledgement has not been delivered to the PH. At the MSG point, segment 1 has not been acknowledged, so this will get transmitted to the MH,


81

Other Host Send Queue

1

2

Mobile Host

MSG Send Queue

2

3

3

Receive Queue

Receive Queue

1

Legend: Current window position X

Acknowledged segment X

Y

Unacknowledged segment Y Empty space in sequence space

Figure 4.13: Inconsistent MSG point

1

Other Host

MSG

Send Queue

M’ Receive Queue

2

3

4

5

6

1

2

3

Mobile Host

4

5

6

O’ Send Queue 1

2

3

4

5

Receive Queue 6

1

2

3

Figure 4.14: Data received by MH after state transfer

4

5

6


82

when a link is established. This is no dierent from a situation, where an acknowledgement has been lost, and it does not give rise to any problems. During the synchronization phase of the TCP endpoints, the TCP connection is brought in a state, where there are no unacknowledged packets from MH to the peer, ie. M.SND.UNA = M.SND.NXT, and where incoming packets are ignored. Unfortunately the time taken to reach this state depends on how fast the data is acknowledged by the PHs. If the connection to an PH endpoint is very slow, or if the PH endpoint of a connection has terminated without being detected by the MH endpoint, the synchronized state may not be obtainable within a reasonable amount of time. Currently this situation is handled by letting the synchronization phase time out, and then revert to regular TCP operation, but it would be desirable to terminate the troublesome connections in case of a timeout. After a successfully completed synchronization phase, the sequence variables may be transferred, and the proxy state M0 is initialised as a copy of the state M, and the proxy TCP state P0 is initialised as follows:

P 0 :SND:UNA P 0 :SND:NXT P 0 :SND:WND P 0 :SND:UP P 0 :RCV:NXT P 0:RCV:WND P 0 :RCV:UP

= = = = = = =

M:RCV:NXT M:RCV:NXT M:RCV:WND M:RCV:UP M:SND:NXT M:SND:WND M:SND:UP

(4.8) (4.9) (4.10) (4.11) (4.12) (4.13) (4.14)

The proxy endpoints will both have empty transmit and receive queues initially. Although it would be possible to copy unacknowledged packets from the receive queue of state M to the receive queue of state M0 , this is not done for the sake of simplicity.

4.2.1.3 TCP Protocol State

We must use the TCP protocol state of the MH endpoint to determine the state of the peer endpoint. As the state of both proxy endpoints may dier from the real endpoints, as seen in section 4.1, a function, that maps a MH endpoint state to the two proxy endpoint states, is needed. This function is depicted in table 4.2, and is derived from the description in section 4.1, and from the fact, that the endpoint M is synchronized resulting in that its send queue contains no unacknowledged data.

4.2.1.4 Timers As described in section 2.2.2, a TCP endpoint uses the following three timers: The retransmission timer The persist timer The keep alive timer


M state CLOSED LISTEN

M0 state NOT MAPPED NOT MAPPED

P0 state NOT MAPPED NOT MAPPED

83

Comments Closed sockets are not transferred. As connection establishment are done by forwarding, endpoints in the LISTEN state are not transferred. SYN RCVD NOT MAPPED NOT MAPPED As the SYN ag counts as a byte, the proxy endpoint is not synchronized when in the SYN RCVD state (see Section 4.1.1). Therefore this state will not occur. SYN SENT NOT MAPPED NOT MAPPED SYN SENT is not mapped for the same reason as SYN RCVD ESTABLISHED ESTABLISHED ESTABLISHED As long as no FIN or RST segments have been received, the proxy peer is in the ESTABLISHED state. FIN WAIT 1 NOT MAPPED NOT MAPPED The FIN ag counts as a byte, and therefore must have been acknowledged. The FIN WAIT 1 state will therefore newer occur. FIN WAIT 2 P FIN WAIT 2 P CLOSE WAIT Both proxy sockets wait for the peer to send its FIN segment. CLOSING NOT MAPPED NOT MAPPED CLOSING is not mapped for the same reasons as FIN WAIT 1. TIME WAIT TIME WAIT CLOSED As the MH endpoint has received the ACK of its FIN byte, the PH proxy endpoint is CLOSED, but the MH proxy endpoint must stay in TIME WAIT state in case the ACK of the PH's FIN byte was lost. CLOSE WAIT P CLOSE WAIT P FIN WAIT 2 The proxy sockets must wait for the MH to send the last FIN LAST ACK NOT MAPPED NOT MAPPED LAST ACK is not mapped for the same reasons as FIN WAIT 1. Table 4.2: Mapping from MH TCP protocol state to proxy TCP protocol states


84

When the proxy endpoints are created, they contain no unacknowledged data, and therefore the retransmission timer is not initially active. The state of the persist and keep alive timers of M0 are initialised with the values of the timers of M. The persist timer of P0 is activated if the M endpoint has advertised a receive window of size 0.

4.2.1.5 Data Exchange Parameters The data exchange parameters can be divided into two groups: 1. Global parameters|parameters agreed upon by both endpoints (e.g., maximum segment size). 2. Local parameters|parameters used only locally (e.g., round trip time estimate, retransmission time-out, congestion window, : : : ) The real and the proxy endpoint, that exchange messages directly, must use the same set of global parameters. As M0 endpoint can be initialised with the values from the MH endpoint, both the global and local parameters are the same. The P0 endpoint should be initialised with default values used for communication via serial links, and the real MH endpoint must change global parameters to re ect the serial link too.

4.2.2 Removing the Central Point

The removal of the central point is rather simple, when the data queues at the proxy endpoints have been emptied (synchronized). This synchronization may be accomplished by sending data to the real endpoints, but only look at the acknowledgement section of the incoming TCP segments, discarding any data. As with the synchronization during insertion of the central points, there is a problem if the acknowledgements are not received within reasonable time. Again we cancel the whole synchronization phase, but as before it would be a better solution to just terminate the unsynchronized connections. When the proxy endpoints have empty transmit and receive queues, and there is no unacknowledged data, the endpoints can be removed without further action. In the following we will examine the same areas as in section 4.2.1, and argue that the two endpoints are in a consistent state, and that no data will be lost. To avoid degraded performance, the data exchange parameters of M0 may be transferred to M.

4.2.2.1 Sequence Variables As no data is accepted at the central point, no TCP packets pass through the MSG during the synchronising phase. This gives the following properties of the data in transit. The data in transit from PH to MH is in the range from P.SND.UNA up to P.SND.UNA+P.SND.WND, and at the MH the M.RCV.NXT is larger than or the same as P.SND.UNA (P.SND.UNA may be less as ACKs from the proxy endpoint to the PH may be lost). No packets will therefore get lost, if the central point is removed entirely. The same is true for data in transit from MH to PH. Thus the sequence variables of the two real endpoints are in a consistent state.


85

4.2.2.2 TCP Protocol States TCP protocol states are no problem, as one of the following con gurations will arise: Both proxy endpoints are in the ESTABLISHED TCP protocol state. In this case, as there is no buered data at the central point, the central point can be removed without any trouble. One proxy endpoint is in the P CLOSE WAIT state, the other is in P FIN WAIT 2 state. As one of the real endpoints will be in the CLOSE WAIT state, the other in FIN WAIT 2 TCP state, the states of the real endpoints may occur in regular TCP, and as there is no data buered at the central point, the central point may be removed without any trouble. One proxy endpoint is in the TIME WAIT state, the other is in the CLOSED state. Thus one of the proxy endpoints is either in the CLOSED or LAST ACK state, the other is in the TIME WAIT. Thus the TCP protocol states of the two real endpoints are in a consistent state.

4.2.2.3 Timers The value of the timers in the proxy endpoints have no relation to the state of the real endpoints, so they pose no problem and need not be transferred.

4.2.2.4 Data Exchange Parameters

The data exchange parameters may be transferred to the MH to make the switch from serial link to LAN more smooth, as there otherwise may be a period with degraded throughput while the data exchange parameters are adapted to the LAN. Especially the round trip time estimate (RTT), the Maximal Segment Size (MSS) and the Retransmission Time Out (RTO) values are likely to dier substantially from serial link to LAN. The MSS, which is usually determined at connection establishment, speci es the upper limit of the Maximal Transfer Unit (MTU). The MSS may be smaller on the serial link than on the LAN, and as such may result in increased overhead in the rest of the connections lifetime. The RTT and RTO adapt to the link characteristics, and may have reached reasonable values after ten to fteen round trip time measurements, which may take from tenth of milliseconds to several minutes. The discrepancies of the RTT and RTO will degrade throughput in case of packet loss, but as the RTT/RTO of the serial links maximally dier with a couple of seconds [AKL+ 94], the impact of the discrepancies are negligible. The MSS at M0 should be transferred to M to avoid extra overhead, and even though the RTT and RTO values of M0 can be ignored, they are transferred too, as the amount of extra work required to do so is very limited.

4.2.3 Summary

To support the change in mode of operation of TCP connections, it is necessary to be able to both insert and remove the central point of a triple point TCP connection. Both insertion and removal


86

consists of two phases; rst the connection is brought into a well de ned state (synchronized), and then the actual insertion/removal is done. The insertion of the central points consists of initialising the TCP state of the two proxy endpoints of central points based on the TCP state of the MH endpoint. As the TCP state of the peer endpoint is unavailable, an usable approximation of the peer endpoint based on the TCP state of the MH proxy endpoint is used to initialize the peer proxy endpoint. The removal of the central point is simple, due to the consistent sequence number space of the two parts of the triple point connection. The central point may thus be removed, when it contains no buered data.

4.3 Implementation Notes This section contains an overview of the implementation of the support for semi-connected TCP connections. The implementation has taken place at two levels; the kernel level and the user level. At the kernel level the major changes have been made to the kernel of the MSG in order to support the central points and proxy hosts. At the user level two daemons have been added, the mobid daemon at the MH and the sctcpd at the MSG. mobid takes care of the attach and detach procedures described in section 3.3. sctcpd has two functions; it receives request to detach from and attach to the network as described in sections 3.3.1.2 and 3.3.1.3, and it does the actual forwarding of data on the central points of the currently registered proxy hosts. In the following we will brie y describe the major changes needed in the kernel in order to support semi-connected TCP, and a limitation concerning the processing of TCP connection resets.

4.3.1 Kernel Changes

The kernel changes comprises three areas: Handling of proxy hosts and central points Timer disabling Synchronization The handling of proxy hosts is speci c to the MSG, but the two other areas apply to both the MHs and the MSG.

4.3.1.1 Proxy Hosts The kernel was extended with a new data structure containing information about the proxy hosts. The primary information contained in these proxy host structures are the current central points of a proxy host.


87

4.3.1.2 Central Points In order to be able to use the existing TCP routines and data structures almost unchanged, we implemented the central points using the existing kernel socket data structures and routines. The actual forwarding of data was delegated to user processes. The kernel just provides two le descriptors per central point|one for each proxy endpoint of the central point. In this way, the user process just receives data on one socket, and forwards it by sending it on the other. Thus, each central point is comprised of two ordinary socket structures, and they are treated as ordinary sockets by the TCP implementation except in a single case|during the creation of new TCP connections, as the TCP segment processing was extended to include the connection establishment procedure as described in section 4.1.1. If a central point is successfully created, the user process is noti ed via a socket le descriptor, that the user process assigns to the proxy host when it is created. By making two accept calls to this socket, the user process obtains the central point. In the case, where a central point is inserted, the user process creates a new central point based on a TCP state, and in this case the user process itself hands over the socket le descriptors, that are to be used by the central point. The only complication introduced by this strategy is that of determining which kernel level socket structure is to receive a TCP segment. Due to the proxy endpoints the connection identi er of a TCP segment may refer to several socket structures. An example of this is the case, where we have two proxy hosts; ProxyA and ProxyB , and where the real mobile hosts; MHA and MHB are communicating with each other. In this case both ProxyA and ProxyB will contain the proxy endpoints identi ed by and . When a TCP segment must be delivered to the socket identi ed by , it should be delivered to the proxy endpoint of ProxyA , if the segment originates from the real MHA , and to the proxy endpoint of ProxyB , if it originates from proxy host MHA . This problem was solved by looking at the device used to transmit the TCP segment|if it is received on the loop-back device (used to transmit IP datagrams internally on a host), the datagram should be handed over to proxy host of the destination IP address and otherwise to the the proxy host of source IP address. This problem also applies to communication between the MSG and a MH, whose proxy host is at that MSG. In this case the routing of the TCP segment is based on the type of socket it is originating from (proxy endpoint or real endpoint) In order to let the IP datagrams containing TCP segments for the proxy hosts reach the TCP layer, it was necessary to change the forwarding mechanism of the IP layer to pass these IP datagrams on to the TCP layer, instead of either discarding or forwarding them as is the normal operation.

4.3.1.3 Timer Disabling The timer enabling and disabling was made possible by extending the kernel socket structure with a ag indicating, whether the socket is frozen or not, and a record of the stopped timers of the socket.


88

4.3.1.4 Synchronization In order to perform the necessary synchronization for the central points during attachment and detachment, the kernel level socket structure was extended with states indicating whether the socket was allowed to accept new segments, send new data or only accept new acknowledgements. Furthermore, the TCP segment processing was extended to handle these dierent states.

4.3.1.5 New ioctl Calls To provide the user level daemons with access to the new kernel functionality, we have expanded the number of commands available for use with the ioctl call of the BSD Unix socket library. The functionality of the new commands is summarised in Table 4.3. The access to these new commands is restricted to processes with root privileges. command SIOCSMOBFLAG

Command description Sets the mobile ags of a socket. These ags indicate either that the timers of a mobile host are disabled, or that the mobile host is in a synchronising state. SIOCGMOBFLAG Returns the mobile ags of a socket SIOCGMOBTCPSTAT Retrieves the current TCP state of a socket. SIOCUMOBTCPSTAT Updates the current TCP state of a socket. SIOCAMHPROXY Creates a new mobile host proxy. SIOCDMHPROXY Deletes a mobile host proxy. SIOCGMHPROXY Retrieves a list of the current mobile host proxies in the kernel. SIOCACENTRALPOINT Creates a new central point of a mobile host proxy based on a TCP state. SIOCDCENTRALPOINT Deletes a speci ed central point of a mobile host proxy. SIOCGCENTRALPOINT Returns a list of the current central points of a mobile host proxy ioctl

Table 4.3: New ioctl commands

4.3.2 Limitations in TCP Connection Reset Processing

When a TCP reset segment is received by either proxy endpoint of a central point, this reset should be forwarded on the other proxy endpoint. As this is handled by the user process sctcpd, it requires the use of the shutdown call, that may be used to reset a connection according to [Ste90]. In the Linux TCP implementation, this call merely results in a FIN segment being sent, and thus our implementation is not able to fully support a TCP connection reset.


89

4.4 Summary The design of the triple point TCP connection allows the central point to be inserted into and removed from existing TCP connections, as the TCP segment processing of the central point is compatible with regular TCP operation. Disconnected and suspended operation of TCP connections are provided by using timer disabling, and covers data transfer, connection reset, and connection shutdown. The establishing of connections does not support disconnected operation, as the hiding of disconnectivity during this phase is not desirable due to the risk of falsely establishing a connection. This may result in time-outs, when a PH attempts to establish a connection to a disconnected MH.

Chapter 5

Adaption In this chapter we will deal with the implementation of the subsystem supporting application and system level adaption (from hereon called the adaption subsystem). A system overview including description of the various components and their interaction, will be followed by sections treating non-trivial implementational aspects of supporting adaption at system and application level.

5.1 System Overview The subsystem responsible for adaption is constituted by a number of daemon processes, each with their distinct responsibilities (see table 5.1). Except for pppd and cardmgr we have implemented

Daemon Responsibility cardmgr agentd linkd pppd tacod

Detection of interface changes Managing QOS retrievals and updates, as described in Section 5.2 Notifying applications of signi cant changes in link quality, as described in Section 3.2.4 Physical link establishment and PPP device setup Resource monitoring and system level adaption as described in Sections 3.2.1.2, 3.2.2.1 and 3.2.3.2

Table 5.1: Responsibilities of daemons in the adaption subsystem the entire range of components comprising the adaption subsystems in the MH and the MSG.

5.1.1 Support for Adaption in MH

Figure 5.1 gives an overview of the subsystem in an MH. The central process is tacod .1 It controls the system level adaption and interacts with linkd to provide application level support The design of the daemon has been inspired by diald , developed by Erik Schenck in 1994, a daemon process providing on-demand dialing using PPP as serial line protocol 1

90

CHAPTER 5. ADAPTION

91

for adaption.

linkd

cardmgr

tacod

agentd APPL. transmit pppd

Dev. Drivers

IP

TCP/UDP

Physical Device Legend: entity

Adaption entity

Flow of control information

entity

User entity

Flow of data

entity

Kernel entity

Figure 5.1: Overview of the adaption subsystem in the MH tacod receives information on changes in available link from the cardmgr , based on which it schedules data, establishes and closes physical links. When a physical link is requested up, the daemon spawns a transmitter process to handle the transmission. This frees up the tacod to handle incoming IP packets. The transmitter passes on the packets directly to a device in the IP layer, bypassing IP routing (otherwise the packets would have been routed back to the tacod ). The tacod starts a pppd process to handle actual link establishment and setting up a PPP device to interface with the physical link. When a physical link is closed the tacod is noti ed by the pppd .

CHAPTER 5. ADAPTION

92

5.1.2 Support for Adaption in MSG

Support for adaption at the MSG is required for somewhat dierent reasons than those at the MH. At the MH tacod has to make best usage of the available data link resource, according to some set of QOS parameters associated with IP packets. At the MSG the tacod has to ensure that the data link resource is utilized as intended by the MH (see Section 3.2.3.5). In order for the tacod at the MSG to schedule IP packets it is required to have access to the same set of QOS parameters as the corresponding MH. Whenever the tacod at the MSG receives an IP packet for which it cannot resolve the QOS, it will have to request the QOS from the MH. The purpose of the agentd daemons is to conduct this QOS retrieval and updating to free up the tacod to handle incoming IP packets (the problem of how QOS parameters are made available to the tacod is treated in full detail in Section 5.2). The setting of an MSG too diers somewhat from that of a MH. The dierences can be characterised as follows:

The MSG does not have to deal with changing interface. The MSG does not have to support application level adaption. The MSG has to deal with incoming IP packets for a number of MHs. The MSG should be able to handle scheduling for a number of host simultaneously (it is not unlikely that the MSG is equipped with a modem pool in case it handles a large number of semi-connected MHs). MSG does not do dial-up to semi-connected MHs.

The MSG subsystem is very much like the system depicted in Figure 5.1. Due to the dierences mentioned above the cardmgr is super uous as is the linkd . However since the MSG deals with multiple MHs, the MSG might have to to control a number of pppd daemons and transmitter processes concurrently, depending on the number of communication interfaces present.

5.2 Issues Concerning System Level Adaption Implementing interface management and data scheduling as described in Sections 3.2.1.1 and 3.2.3.2 is fairly straight forward (but not necessarily easy :-). We will therefore treat these issues no further here. Instead we will focus our attention on how to make QOS parameters available to the data schedulers in the MH and the MSG, especially how to achieve consistency between the QOS parameters used at the MH and the MSG. In our design of the data scheduling mechanism we have been assuming that QOS parameters were readily available. In reality we will rely on the tacod having access to a database of QOS parameters.

CHAPTER 5. ADAPTION

93

5.2.1 Providing QOS Parameters

The QOS database contains bindings between QOS parameter sets and CFDs. Because of its uniqueness, the 5-tuple representing a CFD is used as the key by the database administrator. The CFDs need not be fully speci ed, wild cards may replace any number of elds in the 5-tuple. The wild cards allows speci cation of default QOS for entire classes of CFDs. The QOS database really consists of two separate databases, one containing entries for CFDs alive (CFD alive ), and one containing default entries (CFD def ). The CFD alive database is dynamic, changing with the birth and death of CFDs. The CFD def is more or less static. It is typically setup at boot-time, based on a con guration le stating default QOS for a number of dierent services (e.g., Telnet , FTP , etc.). Figure 5.2 illustrates the structuring of the database.

tacod

Applications

CPD_Alive

CPD_Defaults

QOS Database Legend: Database Flow of data (db queries and db updates)

Figure 5.2: The QOS database Applications interact with the database when setting up, administering, and bringing down CFDs. The type of interaction depends on the CFD life cycle as follows:

Applications insert items in the database when binding a QOS to a new socket. 2 Applications query the database to get the QOS associated with some socket. Queries are performed throughout the lifetime of the CFD. Applications delete entries from the database to remove the free binding of QOS to a socket that no longer exists.

tacod interacts with the QOS database, when dealing with out bound IP packets in general, and in bound IP packets in some special cases. For every out bound packet, if a CFD structure is already allocated the packet is simply queued here. If no CFD structure currently exists, a new 2

When a socket is opened, a 5-tuple is allocated to hold a description of the CFD associated with the socket

CHAPTER 5. ADAPTION

94

one is allocated, and the QOS database is queried for a QOS to associate with the structure. To understand how tacod interacts with the QOS database in some special cases, we will take a closer look at how a client/server request-reply scenario is played out using TCP and UDP respectively. Initially both client and server binds their local addresses and ports to a socket, calling bind(), and associates their respective CFDs with a QOS in the database, calling set qos(). We will term these CFDs client descriptor and server descriptor .

5.2.1.1 TCP Request/Reply Scenario The request/reply scenario under TCP consists of connection establishment and exchange of request and reply. The scenario is illustrated in Figure 5.3 Actions on Client Side bind() set_qos()

Communication Induced

Actions on Server Side bind() listen() set_qos()

connect() - call

accept() connect() - return send() receive() send() receive()

Figure 5.3: TCP request/reply scenario and QOS bindings From the servers point a SYN packet is received containing a CFD . If the connection is accepted (server calls accept()), a SYN,ACK packet is send containing the CFD (termed connection descriptor ). This descriptor is the one identifying the connection between client and server process. When the connection has been established we want the QOS associated with the server descriptor to be also associated with the connection descriptor , so that out bound IP packets are scheduled using this QOS. Having the connection descriptor there obviously is no way that we can nd the server descriptor in the QOS database| SA, CA and CP gives no indication of what SP is. Therefore it is necessary to make an entry in the database, associating the CFD from the SYN packet with the QOS from the server descriptor . With this entry in the QOS database, it is now possible, having the connection descriptor , to locate the QOS of the server. So the tacod is required to update the database, when it sees the incoming SYN packet, and when it schedules the outgoing SYN,ACK packet. From the clients point of view a SYN packet is send containing a CFD (client calls connect()). If the connection is accepted (client returns from connect()), a SYN,ACK packet is received containing the CFD (termed connection descriptor ). This

CHAPTER 5. ADAPTION

95

descriptor is the one identifying the connection between client and server process. When the connection has been established we want the QOS associated with the client descriptor to be also associated with the connection descriptor , so that out bound IP packets are scheduled using this QOS, and the CFD is therefore inserted in the QOS database.

5.2.1.2 UDP Request/Reply at Server The request/reply scenario under UDP consists solely of exchange of request and reply. The scenario is illustrated in Figure 5.4 Actions on Client Side

Communication Induced

bind() set_qos()

Actions on Server Side bind() set_qos()

sendto() recv_from() sendto() recv_from()

Figure 5.4: UDP request/reply scenario and QOS bindings Any reply from the server or if the server has spawned a process to process the request and reply, will have the server address SA and server port SP as local address and port. In case a spawned process handles request and replies, it will have had to go through the steps of calling bind() and set qos() before a reply can be made. In any case the out bound packet will be scheduled based on the QOS associated with the CFD of the serving process. The tacod will need to do nothing to assure that the right QOS is associated with out bound packets from the serving process. Any out bound packet on the client will always have the clients address CA and client port CP as local address and port and will therefore match the client descriptor . So any out bound packet will be scheduled based on the QOS associated with the client descriptor . The tacod will need to do nothing to assure that the right QOS is associated with out bound packets from the client.

5.2.2 Handling System Communication

In a number of occasions it is necessary for the daemon processes in the TACO layers of the MH and MSG to exchange information in order to provide the desired mobility support. System information has to be exchanged in the following three occasions: 1. During the authentication procedure performed when a MH connects to a MSG (see Section 3.3.1.5).

CHAPTER 5. ADAPTION

96

2. To evaluate the quality of the link available (see Section 3.2.1.2). 3. To ensure the consistency of the QOS databases on the MH and the MSG (see Section 5.2.1). To ensure that system communication is always exchanged prior to user communication, we associate special data structures with system communication. Still the dierent types of system communication are not equally important. The listing above re ects how system communication should be prioritised. To make scheduling simple we will associate a distinct data structure with each type of communication. The authentication structure will then be given priority over the link information and QOS structures, as will the link information structure over the QOS structure. The ranking of the dierent types of system information should be pretty obvious. When a MH connects to a MSG no data what so ever should be exchanged until the connecting MH has been authenticated. In order to get as accurate a picture as possible of the given link quality, it is important that link information packets are sent without delay (the time between a packet is sent and a packet received is used to estimate latency of the link). Therefore link information packets should always take precedence over packets regarding QOS database consistency.

5.2.3 QOS Database and Scope of QOS Requirements

Because we have chosen to de ne the scope of QOS parameters for the link between the MH and the MSG to be within the domain of the MH (see Section 3.2.3.5), everything send from the MSG to the MH has to be scheduled according the QOS parameters speci ed by the MH. This implies that the QOS database at the MSG has to be a mirror of the database at the MH. The only way to update the QOS database at the MSG is through either explicit update noti cations from the MH, or QOS requests from the MSG. Since the MH may be disconnected for longer periods of time this leaves room for considerable discrepancies in the database at the MSG. Any CFD, for which no QOS is currently present, will be marked as Unresolved . IP packets send on such CFD will not be scheduled until the QOS of the CFD has been resolved. Figure 5.5 illustrates how the MH and the MSG interacts to keep the QOS database at the MSG up to date. As the gure shows a qos agent has been introduced to handle communication between the hosts. The QOS messages exchanged between MH and MSG are done using the unreliable UDP service. Some overhead is expected to ensure that no messages are lost. To avoid the overhead degrading the performance of the tacod we have introduced an agent to handle the exchange of messages between hosts. In this section we have brought up the notion of an unresolved CFD . As mentioned earlier, it is required that the MSG keeps track of unresolved CFD for each MH registered. Therefore the scheduling structures allocated for each MH should be extended to comprise a list of unresolved CFDs.

5.2.4 Buered Data and Lifetime of CFD

A MH might be disconnected for an extended period of time, possibly causing buered data to exceed the lifetime of the CFD to which they are related. The problem arise because we are trying to schedule IP packets below the TCP/IP layer|in the TACO layer we have no explicit knowledge of when CFDs are created and removed. We will investigate here how big a problem

CHAPTER 5. ADAPTION

Applications

97

MH QOS agent

MSG QOS agent

MH tacod

MSG tacod

MH QOS Database

Applications

MSG QOS Database

Legend: Database Flow of data within host (db comm. and QOS comm.) Flow of data between hosts (QOS comm.)

Figure 5.5: The QOS database|extended to comprise MSG this is for TCP and UDP respectively. But before we do so let us give a small example to clarify the problem. Suppose data related to a CFD V1 is buered in the TACO layer. Before the MH gets reconnected V1 is removed. If an identical CFD V2 is sometime later associated with a dierent QOS, data send on V2 would still be buered together with the data send on V1, meaning that data related to V2 would be scheduled using the QOS associated with V1|clearly not the intention.

5.2.4.1 TCP For TCP connections the problem will actually never arise. Since we only allow static binding of QOS to a CFD, for a CFD to be bound to some other QOS, the TCP connection related with the CFD has been closed or aborted. No data can be pending on a closed TCP connection due to the protocol speci cation of connection closure (see [Ste94]). A connection is aborted by the transmission of a RST packet. This packet does not have to be acknowledged, so from the point of the TCP protocol the aborted as soon as the packet has been send. This could cause a problem if not for our performance enhancing feature to drop all packets queued on a TCP connection when a RST message is generated (see Section 5.2.5).

5.2.4.2 UDP For UDP the situation is quiet dierent. Looking at IP packets we have no way of detecting whether a CFD has been removed and new identical one created with a dierent QOS. By having

CHAPTER 5. ADAPTION

98

the QOS database manager check the scheduling structures every time the database is updated, we will be able to detect these situations. The question now is what to do with the IP packets already buered. At the MSG packets will always be discarded. If a new binding between a certain CFD and dierent QOS appears in the database at the MSG, an update has been made from the MH (see Section 5.2.3). This implies that the endpoint at the MH, for which the buered data is destined, does no longer represent the same process. Therefore data can safely be discarded at the MSG.3 At the MH packets should be send. Even if the process that sent the packets does no longer exist the recipient on the MSG might still live and await the packets. E.g., a process is started at regular intervals at the MH to send updates of some sort to a process in the xed net.

5.2.5 Performance Improvements

During a period of disconnection, events outside of the MH might have caused some buered data to go stale. From an eciency point of view, we are not interested in wasting bandwidth transmitting packets that will be discarded when reaching the receiver. This might be the case if e.g.:

The host housing the receiver has gone down and come up again while the MH has been disconnected A connection has been aborted by the receiver while the MH has been disconnected

We seek to detect situations where data can safely be discarded, freeing up bandwidth. We are interested only in situations that can be detected with a minimum of eort, so as not to increase the complexity of the TACO layer unnecessarily. Aborted TCP connections can be detected easily by looking for RST packets in the in bound as well as out bound IP packet streams. There really is no extra cost doing this, since we have to look at IP packets anyway when doing scheduling. In these cases if any data is already buered in a CFD structure, they can be replaced by the RST packet. Otherwise, there is no easy way of detection if packets can be discarded TCP connections. For UDP packets we have no easy way of detecting whether they can be discarded or not. Since UDP is a connection-less service, the packets carries no state information, that could give a hint as to the state of the sender/receiver, so we have no way of detecting abnormalities and safely discard packets. As for detecting whether a host has been down, this is done when the MH connects to the MSG to ensure that the hosts are properly synchronized (see Section 3.3.1.5).

5.2.6 API to the QOS Database

The application programmers interface to the QOS database is provided through the three functions presented in table 5.2. There is a small risk, that the same process might if continually opening and closing a socket when transmitting, e.g. request, cause us to discard the replies wrongly. Still this seems unlikely enough that we will disregard it. Anyway it is hardly an error to discard the packets, since UDP is an unreliable service 3

CHAPTER 5. ADAPTION

99

int m set qos(int sfd, struct m qos * qos); int m del qos(int sfd); int m get qos(int sfd, struct m qos *qos);

Table 5.2: API to QOS database An entry in the QOS database is created calling m set qos and deleted calling m del qos. The QOS of any entry in the database can be retrieved through calling m get qos. The QOS parameters are passed between the application and the system in the structure m qos.

5.3 Issues Concerning Application Level Adaption The implementation of the link handler as described in Section 3.2.4 is straight forward, disqualifying it for further treatment here. We will however brie y sketch how the link handler interfaces with the system and the applications.

5.3.1 Link Handler

The link handler linkd receives information on link quality changes from the tacod . Link information is passed between tacod and linkd on interface changes and in case of heavy variation in link quality of the present link. Processes are noti ed of changes in link quality through a SIGIO signal. The process can then request the QOS parameters associated with the link from linkd .

5.3.2 API to Support Application Level Adaption

The application programmers interface to linkd is provided through the four functions presented in table 5.3. int int int int

assign link notification(struct qos if *if qos); remove link notification(int un sfd, struct qos if *if qos); accept link notification(struct qos if *if qos); current link(struct qos if *if qos);

Table 5.3: API to the link handler linkd An application registers with the system for noti cation of link quality changes (from hereon called link noti cations), through the call assign link notification and deregisters through

CHAPTER 5. ADAPTION

100

the call remove link notification. When an application is signaled that a signi cant change in link quality has occurred, the link noti cation is received calling accept link notification. An application may at any time request information on the quality of the available link through the call current link. Information on link quality is passed on between the application and the system in the structure qos if. To illustrate how the link noti cation routines are applied to obtain information on changes in link quality, Figure 5.3.2 gives an example on how link noti cation is activated and handled. The application speci es the link quality threshold that should generate noti cations, when registering with linkd (done at 1 ). linkd noti es applications of a change in link quality through the SIGIO signals. Thus applications are required to set up a signal handler to receive link noti cations (done at 2 ). Upon receiving a SIGIO, the signal handler is called, reading the updated link quality through calling the link noti cation routine accept link notification (done at 3 ). The application then may take whatever precautions necessary to deal with the change in link quality.

5.4 Summary The subsystems supporting adaption diers at the MH and the MSG. The subsystem at the MH is provided to allow ecient usage of the MHs link resource, whereas the subsystem at the MSG is provided to ensure that the link resource of the MSG is used as intended by the MH. QOS parameters are made available through a QOS database. The database at the MH is mirrored at the MSG to ensure, as mentioned above, that the link resource of the MSG is used as intended by the MH. Updates at the MH are passed on to the MSG, and retrievals failing at the MSG are forwarded to the MH. An API has been provided to allow applications to manipulate the QOS databases. Application level noti cation of changes in link quality is provided through a linkd , which interfaces with the tacod and the applications. An API has been provided to allow applications to request services from linkd .

CHAPTER 5. ADAPTION

#include #include #include #include

void io sa handler(int sig f struct qos if cur qos;

g

101

no) 3

accept link noti cation(&cur qos); printf("Current link has maximum

,cur qos.min bandwidth);

bandwidth %dnn"

void setup sio signal() 2 f struct sigaction sa;

sa = (struct sigaction ) malloc(sizeof(struct sigaction)); sa!sa handler = &io sa handler; sigemptyset(&(sa!sa mask)); sa!sa ags = 0; g

sigaction(SIGIO,sa,NULL);

void main() f int ln sfd = 0; struct qos if iface

qos;

iface qos.max cost = 5; 1 iface qos.min bandwidth = 100; iface qos.max latency = 400; ln sfd = assign link noti cation(&iface qos1); 1 setup sio signal(); 2 do f

pause();

g

g while(1);

Figure 5.6: Example program using link handlers

Chapter 6

Evaluation This chapter is an evaluation of the performance and functionality of the TACO layer and its daemons (known as the TACO system). As stated in Chapter 1, our main performance goals are: Virtually no overhead should be introduced by the TACO layer when attached to LAN. The overhead introduced by the TACO layer when using serial links should be moderate compared to ordinary TCP/IP serial link protocols. The performance goals will be evaluated by conducting a number of comparative measurements between a system with TACO layer support, and a system without, under the three forms of communication supported, and at dierent stress levels. Furthermore we will evaluate the TACO layer support for semi-connected operation by examining the behaviour of a collection of standard applications on a MH, when the MH goes through the dierent modes of operation (attached to LAN, disconnected, serial link connected, reattached to LAN).

6.1 Test Con guration The tests were conducted using two Olivetti PCs, a stationary Olivetti M4-82 serving as MSG, that is con gured with a 60 MHz Pentium processor, 16 MB of RAM, a 1 GB SCSI Quantum hard disk and an Adaptec 2940 (PCI Bus) hard disk controller, and a portable Olivetti Echos P75, that is con gured with a Pentium 75 MHz processor, 16 MB ram, 420 MB IDE hard disk and a Fast IDE hard disk controller. The portable furthermore has two PC Card type II slots. In our test con guration, the three following types of communication media were available to the notebook: Ethernet The Ethernet connection is provided using a D-Link DE650 PC Card 10 Mb Ethernet card. Wired serial connection The wired serial connection is provided using a 14.400 bps Hotline PC Card modem with MNP5 and v.42bis data compression enabled. Wireless serial connection The wireless serial connection is provided using a 9600 bps PC Card Nokia GSM datalink adapter and a Nokia 2110i cellular phone. The GSM net operator has been Sonofon. 102

CHAPTER 6. EVALUATION

103

6.2 Performance Evaluation Our performance evaluation seeks clari cation of the following points: How does the TACO layer aect the performance of a xed MH and a MSG? How does the performance of the TACO layer compare with regular serial link protocols? What are the eects on TCP connections caused by involuntary disconnects of a serial link? How well are applications with ful lled quality of service requirements separated from applications with unful lled quality of service requirements?

6.2.1 Testing Methodology

The major part of network applications can be categorised as either interactive or bulk transfer applications. The two most important characteristics of network connections for these types of applications are round-trip time and throughput. In the performance evaluation we therefore focus on the these two characteristics: Round-trip time Measurements for round-trip times are obtained measuring the time taken for a packet to travel to a peer host and back again. This is done by using a test program having a server and a client mode of operation. When operating as a client, it periodically transmits a packet, and when the packet is received, the round-trip time of the packet is measured. Our tests are conducted with 1 second intervals and with the packet sized (without TCP/IP headers) 4 bytes, 64 bytes and 512 bytes. These sizes where chosen to re ect dierent uses of interactive applications, which are the most dependent on round-trip times. The connections used for conducting round-trip time measurements will be referred to as interactive connections. Throughput Measurements of throughput were obtained using the program ttcp, which is able to perform bulk transfer between two instances of the program. Packet sizes (without TCP/IP headers) used where 536 bytes, 1436 bytes and 4096 bytes. The rst was chosen as the packet size usually used for WAN trac, the second is the packet size used for local transfers across Ethernet, and the last was chosen in order to introduce fragmentation (using UDP). The connections used for conducting throughput measurements will be referred to as bulk transfer connections. In all measurements using TCP, the TCP NODELAY ag was set, meaning that Nagle's Rule [Nag84] was not used. This allows the TCP connection to have more than one unacknowledged segment. Due to the high economic cost of using GSM data links, we have refrained from using the GSM adapter for measurements, except in cases where the problems examined are directly related to the characteristics of a GSM link (especially the involuntary disconnects). As the GSM adapter behaves like an ordinary modem with longer round-trip times, this is not a serious limitation, as the purpose of this part of the evaluation is to estimate the overhead of the TACO system.


104

6.2.2 TACO Ethernet Overhead

The overhead introduced by the TACO system when using regular Ethernet should be very small. In order to evaluate this, measurements of TCP and UDP throughput and round-trip times are conducted for the con gurations: MH with TACO system and MSG without TACO system (TACO MH) MSG with TACO system and MH without TACO system (TACO MSG) Both MH and MSG without TACO system (Standard) The throughput measurements for these con gurations are summarised in Table 6.2 and the round-trip times in Table 6.1. As can be seen from these tables, there is no mentionable overhead caused by the TACO system regarding Ethernet operation. Packet Size Standard 4 2.01 ms 64 2.11 ms 512 4.22 ms

Round-trip time with Ethernet on MH TCP UDP TACO MH TACO MSG Standard TACO MH TACO MSG 1.92 ms 1.89 ms 1.30 ms 1.30 ms 1.31 ms 2.12 ms 2.12 ms 1.55 ms 1.55 ms 1.56 ms 4.24 ms 4.24 ms 3.67 ms 3.67 ms 3.66 ms

Table 6.1: Comparison of round-trip time on Ethernet - MH with and without TACO

Packet Size 536 1436 4096

Standard 398 KB/s 651 KB/s 648 KB/s

Throughput with Ethernet on MH TCP UDP TACO MH TACO MSG Standard TACO MH TACO MSG 390 KB/s 398 KB/s 589 KB/s 597 KB/s 590 KB/s 648 KB/s 651 KB/s 795 KB/s 795 KB/s 792 KB/s 643 KB/s 648 KB/s 742 KB/s 746 KB/s 746 KB/s Table 6.2: Comparison of throughput on Ethernet

6.2.3 TACO Serial Link Overhead

To clarify, how buering, scheduling and TCP forwarding aects the throughput and round-trip times when a MH is connected by serial links, we will compare the performance of the TACO system with the performance of regular PPP, using the modem link. To examine the behaviour of the TACO system both when stressed and running multiple applications, measurements with 1, 4 and 16 concurrent test applications have been conducted. When only one applications is used, the performance of PPP and TACO are almost equal. When looking at 4 and 16 concurrent applications it becomes clear, that the overhead induced by


105

the TACO layer increases, when several connections transmit packets at the same time. There is a need for a thorough pro ling of the TACO daemons in order to establish, what is the main cause of this overhead and what can be done to reduce it. The TACO system was unable to handle the pressure of 16 applications transmitting 512 bytes per second, so these measurements are not available. This is partly due to the fact, that the TCP connections started timing out due to very high round trip times, and as the handling of resets from these TCP connections is not fully supported (see Section 4.3.2), the measurements could not be completed. Furthermore, the TACO system was slightly unstable when suciently stressed (during the 16 applications TCP round-trip time measurements). UDP round-trip time - 14400 bps modem Packet Size Number of applications 1 4 16 PPP TACO PPP TACO PPP TACO 4 151 ms 158 ms 225 ms 247 ms 179 ms 293 ms 64 226 ms 230 ms 245 ms 338 ms 305 ms 455 ms 512 713 ms 716 ms 18,381 ms 18,965 ms 204,810 ms 181,140 ms Table 6.3: Concurrent UDP round-trip time measurements on modem TCP round-trip time - 14400 bps modem Packet Size Number of applications 1 4 16 PPP TACO PPP TACO PPP TACO 4 115 ms 123 ms 123 ms 130 ms 248 ms 198 ms 64 191 ms 201 ms 215 ms 230 ms 620 ms 1628 ms 512 688 ms 695 ms 16,245 ms 31,743 ms 100,027 ms -1 Table 6.4: Concurrent TCP round-trip time measurements on modem UDP throughput - 14400 bps modem Packet Size Number of applications 1 4 16 PPP TACO PPP TACO PPP TACO 536 1.72 KB/s 1.71 KB/s 0.53 KB/s 0.47 KB/s 1.72 KB/s 0.22 KB/s 1436 1.79 KB/s 1.78 KB/s 0.53 KB/s 0.51 KB/s 1.79 KB/s 0.16 KB/s 4096 1.80 KB/s 1.66 KB/s 0.59 KB/s 0.25 KB/s 1.80 KB/s 0.39 KB/s Table 6.5: Multiple UDP throughput measurements on modem


106

TCP throughput - 14400 bps modem Packet Size Number of applications 1 4 16 PPP TACO PPP TACO PPP TACO 536 1.80 KB/s 1.79 KB/s 0.45 KB/s 0.36 KB/s 0.12 KB/s 0.09 KB/s 1436 1.78 KB/s 1.80 KB/s 0.43 KB/s 0.46 KB/s 0.12 KB/s 0.09 KB/s 4096 1.78 KB/s 1.79 KB/s 0.43 KB/s 0.46 KB/s 0.12 KB/s 0.10 KB/s Table 6.6: Multiple TCP throughput measurements on modem

6.2.4 Quality of Service

The purpose of providing dierent connections with dierent quality of service parameters is to provide an ecient utilization of the available link. To evaluate how pending connections (connections with unful lled quality of service requirements) aect active connections (connections with ful lled quality of service requirements), we have made an experiment, where one pending TCP connection used for bulk transfer exists concurrently with active connections, which are either used interactively or for bulk transfer. The packet size used for the bulk transfer on the pending connection is 532 bytes. The results of this experiment are summarised in Tables 6.7 and 6.8, and as can be seen, they are a bit discouraging|only the throughput of the UDP bulk transfer has an acceptable level. The round-trip times are extremely high, and the main reason for this is that the pending connection is allowed to transmit data in between the echoing packets of the interactive connections. We anticipated, that the average delay caused by this would amount to half of the time taken to transmit a packet from the bulk transfer connection (approximately 300 ms), but as can be seen the delay is much longer. As it turns out, the device driver for the serial device buers data, and this buer gets lled with packets from the pending connection during the idle time of the active connections. The signi cant dierences in round trip times for TCP and UDP is due to TCP using ow control. The ow control may result in longer pauses between packets are transmitted, thereby increasing the delay. When TCP connections are used for bulk transfers, the ow control may also result in pauses, resulting in the same eect as above, which also shows in the average throughput of these connections. The UDP bulk transfer uses no ow control, so all packets are quickly buered in the TACO layer, and this results in almost the same performance as with no pending applications. Although this is a problem, it could be solved by being more critical about when the link is de ned idle. A small delay of a couple of seconds could probably remove the worst of the eect described.

6.2.5 Eects of Disconnects During Data Transfer

The primary use of the TCP timer disabling mechanism is to remove the possibility for TCP connection time-outs during periods of disconnected operation, but a side eect of the disabling of the retransmit timer is that the retransmission time-outs and the exponential back-o of the


107

Active Interactive and Pending Bulk Transfer Connections Packet UDP TCP size 1 pending 0 pending 1 pending 0 pending 4 7039 ms 158 ms 26193 ms 123 ms 64 6456 ms 230 ms 46994 ms 201 ms 512 10862 ms 716 ms 44183 ms 695 ms Table 6.7: Active interactive and pending bulk transfer connections concurrently Packet size 536 1436 4096

Active Bulk Transfer Connection UDP TCP Connections pending Connections pending 1 0 1 0 1.71 KB/s 1.72 KB/s 0.39 KB/s 1.79 KB/s 1.78 KB/s 1.79 KB/s 0.74 KB/s 1.80 KB/s 1.71 KB/s 1.80 KB/s 0.52 KB/s 1.79 KB/s

Table 6.8: Active and pending bulk transfer connections concurrently retransmission timer are avoided thus making the data transfer proceed faster when a connection is reestablished. As disconnects happen rarely on modem links, but regularly on GSM data links, we tested the eects of disconnects on bulk transfer connections on a GSM data link. The GSM link was forced to disconnect two times during a data transfer, a bulk transfer, which should take approximately 3 minutes to complete without disconnects, was interrupted twice by forcing the GSM data link to disconnect (after 1 and 3 minutes). It took between 60 and 90 seconds to reconnect after the forced disconnects. As can be seen from Table 6.9, the timer disabling in general provides a slight improvement compared to regular TCP. The regular TCP connection using 1436 bytes packets exempli es how bad the retransmission time-outs can aect the throughput. During this particular data transfer, nothing was transmitted during the second period of connectivity and the was a pause of approximately 2 minutes after the connection was established for the second time. The reason for this is probably, that a retransmission time-out occurred just before the rst reconnect and then again just before the second reconnect. As the maximum value of the retransmission timeout in the Linux implementation of TCP is 120 seconds, this explains the long delay after the second reconnect.

6.3 Using Standard Applications In order to evaluate how the TACO system behaves under normal working conditions, we have performed a sample work procedure using the three standard network applications; FTP, telnet and X windows. The chain of events was as follows:


108

Eects of disconnects on throughput using GSM Packet Size Standard TACO 536 0.68 KB/s 0.72 KB/s 1436 0.27 KB/s 0.73 KB/s 4096 0.70 KB/s 0.74 KB/s Table 6.9: Eects of disconnects on throughput on TCP connections using GSM 1. During normal LAN operation an FTP and a telnet session was established to the MSG. In the telnet session, the display environment was set to the display of the MH, and the emacs editor was started. At this point there are three established TCP connections between the MH and the MSG. 2. After using the three applications for a short while, the MH was detached from the LAN. Attempts to use all three applications were made, but as there was no possible physical connection, nothing happened. 3. After a couple of minutes the modem card was inserted, and the TACO system automatically established a connection to the MSG. Shortly after the successful connect to the MSG, all actions initiated on the applications when disconnected, were executed. 4. The applications were used while connected via modem, and after a short while the modem card was ejected in order to simulate a connection loss. 5. Attempts were made to use the applications, but as the MH was disconnected nothing happened. The MH was now left disconnected for 30 minutes. 6. After this the MH was attached to the LAN, and the actions initiated on the applications were executed. The only problem was that the FTP session had timed out and dropped the connection. This is due to an application level timer in FTP, that after 15 minutes of idle time closes the connection. The other applications behaved normally. This attempt to simulate a normal working procedure using semi-connected operation was successfully completed. The only problem was that of application level timers, and that was anticipated.

6.4 Conclusion With a low work load the performance of the system is acceptable, as only a moderate delay is introduced (below 10 %), but when the number of concurrently running applications is increased the performance of the system drops dramatically. The system obviously does not handle stress situations very well, and a slight instability problem was discovered. However, we believe that improvements could be obtained through restructuring and optimising the TACO code, bringing down both system overhead and allowing for better handling of stress situations. This will require though a thorough pro ling of the TACO code.


109

We are a bit disappointed with the eects of concurrent use of active applications and pending bulk transfers. We had expected the TACO system to handle separation of connections with QOS requirements ful lled from those with requirements unful lled more elegantly. However, we believe the problem could be easily solved being more conservative when deeming a link idle. On the other hand was it encouraging, that the disabling of timers TCP timers proved to be an improvement to the standard serial link support of TCP/IP. The standard applications were able to survive both detach from LAN, periods of disconnected operation, serial link communication by modem, and the attachment to the LAN. Thus the basic functionality of our design has been provided.

Chapter 7

Conclusion This thesis has shown how to provide users of mobile computers with easy access to the Internet, hiding the problems associated with disconnectivity, semi-connected operation, and adapting to varying link quality. Our goal has been to build a system providing support for semi-connected operation and adaption in a mobile computing environment. We have designed, implemented, and evaluated a system on a small Ethernet consisting of one desktop computer and a number of notebooks running Linux. In the following sections we will describe our conclusions and give directions for possible future work with this system.

7.1 Conclusions We have designed and built a system hiding the complexity of switching between dierent means of communications from both user and applications, supporting semi-connected operation and allowing for eective use of available bandwidth. In the following sections we will review our design, our implementation, and the system performance with respect to the goals speci ed in Section 1.4.1.

7.1.1 Design

Switching between dierent means of communication is eectively hidden from applications through the provision of a pseudo device. The pseudo device acts as stand-in for a physical device, when no interface is present. Support for semi-connected operation has been accomplished by splitting TCP connections. This approach eciently deals with the problems of congestion control and avoidance and retransmission timeouts, as the serial link part of a TCP connection is isolated from the LAN part of the connection. By combining the split connection approach with data buering at the central point of the split TCP connection, applications can survive long periods of disconnectivity. Providing support for system and application level adaption to changes in link quality allows for ecient link usage. At the system level, adaption is realized through data scheduling based on Quality Of Service parameters. At application level, adaption is realized by allowing applications to request noti cation of signi cant changes in link quality from the system. 110

CHAPTER 7. CONCLUSION

111

7.1.2 Implementation

The implementation of the design has been a complex and long stretched task. Although there are still areas where our implementation could be more user friendly, we feel that we have reached our main objective|providing a usable tool for supporting semi-connected mobile computing.

7.1.3 Performance

Our performance evaluation shows, that the system adds only negligible overhead when used under normal working conditions. Unfortunately, if the scheduling mechanism is suciently stressed, it may add considerable overhead. Especially applications using UDP, which provides no ow control, are able to ll up the buers with UDP packets. This is a minor problem, that could be solved by implementing a simple throttle mechanism in the TACO layer. Sadly, the performance evaluation also showed that our system is slightly unstable when suciently stressed.

7.2 Future Work In the design of our system, several restrictions where made in order to limit the scope of the project, and thus there are areas where the system could be enhanced. In the following we discuss these areas.

7.2.1 Host Migration

The TACO layer does not support mobile hosts moving between networks. When a mobile host is physically disconnected from its home network, it is only allowed to connect to the Internet through an MSG in the home network. This impose a severe constraint on mobility, as roaming mobile hosts are forced to use slow serial links for communication. Much eort has been put into coming up with a design for supporting host migration across networks (see Section 2.1). We believe the work conducted by the Internet Engineering Task Force (IETF) on Mobile IP is most likely to become a de facto standard, as this work will be an integrated part of the TCP/IP protocol suite. Eorts to integrate support for host migration should thus be directed towards Mobile IP . 1

7.2.2 Link Management

The quality of serial links varies considerably, especially wireless links, which are prone to atmospherical disturbances and variation in topography. Even the quality of an Ethernet link

uctuates with the load of the net. Link management in the TACO layer is very rudimentary, in fact it is limited to reporting the theoretical bandwidth of a link. No monitoring of the active link is performed. We believe this lack of link management results in a less optimal adaption at both the system and the application level. In our implementation, adaption will only take place at the moments 1

Recently an implementation of Mobile IP has been released for Linux

CHAPTER 7. CONCLUSION

112

of interface change. However, as pointed out above, link quality is not a constant factor. With a static adaption scheme, as the one implemented in the TACO layer, there is a real risk that the system of a mobile host will be poorly adapted to its environment|causing an unnecessary drop in system performance. Implementing link management will allow a dynamic adaption to signi cant changes in the link quality, avoiding any unnecessary drop in system performance.

7.2.3 Data Reduction

As the bandwidth of especially GSM data links is considerably lower than what is expected by todays networking applications, a good possibility of improving performance is to provide a more intelligent central point of our triple point connection (or the middle host in split connections), that is able to handle for example various data reduction techniques or that may even be capable of performing more complex tasks (agents). An extension of our system with such functionality would require a more complex attach/detach protocol.

7.3 Summary The main goal of this thesis was to design and build a system, that provides support for semiconnected operation of mobile hosts. We have accomplished this goal by building a system, that through the usage of pseudo devices, split TCP connections, and data scheduling, hides the complexity of switching between dierent means of communications from both user and applications, supports semi-connected operation and allow for eective use of available bandwidth. Still there is room for improvement in the areas of host migration, link management and data reduction.

Appendix A

A Brief Introduction to Computer Networks This is a brief introduction to the general terminology and concepts of computer networks. For more information, an excellent coverage of computer networks is given in [Tan89]. This coverage is based on the OSI reference model|a standardized 7 layer model for all parts of a computer network. A computer network consist of a collection of computers, which are connected to each other. The computers in a network are often referred to as hosts or nodes. The entity called a network is often con ned to a single administrative domain (e.g., a company or a department at a university), and when several networks are connected to each other, an internet is created. The hosts providing the connection to other networks are called gateways. Depending on the area covered by a network, it may either be classi ed as a Local Area Network (LAN) (e.g., covering a oor or a building), a Metropolitan Area Network (MAN) (e.g., connecting dierent places in a town), or a Wide Area Network (WAN) (any network covering more than a town).

A.1 Protocol Design When two hosts are communicating with each other, they have to agree to a set of rules for the data exchange. These rules are known as protocols. In the following we describe some of the basic properties of the services oered by protocols.

A.1.1 Connection-Oriented vs. Connection-Less

In a connection-oriented protocol, a virtual connection is established between the two communicating parties prior to any data exchange. Any data exchange uses this virtual connection without the need to specify any additional information about the receiver, and data delivery is guaranteed to be in-order. As opposed to this, on a connection-less protocol, each datagram transmitted is treated independently and the receiver has to be speci ed in each datagram. With 113

APPENDIX A. A BRIEF INTRODUCTION TO COMPUTER NETWORKS

114

a connection-less protocol no guarantee of in-order delivery is given. A couple of examples from everyday life; telephone conversation is connection-oriented, and mail is connection-less.

A.1.2 Packet vs. Stream

Another issue is, whether the protocol keeps the structure of the data handed over to it. If the protocol is packet-oriented, it delivers data in the same chunks, as was handed over to it by the transmitter. On the other hand, if the protocol is stream-oriented, data exchange is like a stream of octets, owing from the sender to the receiver without any explicit structuring made by the protocol.

A.1.3 Reliable vs. Unreliable

As data may get lost, duplicated, or corrupted when transferred, some protocols oer reliable data transfer. In this case, the protocol will detect missing, corrupted, or duplicated data, and either retransmit or discard the data. In some cases, reliable protocols also ensure in-order delivery of data meaning that data is delivered to the receiver in the exact same order as it was handed over to the protocol by the sender. In case the protocol oers a connection-oriented service, the reliability also covers the connection. In this case, the protocol will also try to detect permanent failures of the connection (e.g., it is not possible to transfer any data through the connection due to a network failure). If a protocol does not ensure that data reach their destination in uncorrupted form, it is said to provide unreliable data transfer.

A.1.4 Flow Control

In some cases, the sender may be able to transmit data much faster than the receiver is able to process them, and therefore protocols often allow the receiver to control the rate, at which data is transmitted to it. This is know as ow control.

A.1.5 Naming, Addressing and Routing

When a host wants to transmit data to another host, three basic services are used; naming, addressing and routing. A Name is used to identify a host, an address gives the location of the host, and a route speci es how to get the data to the location. As a name is used to identify a speci c host (or a speci c group of hosts), it should be be unambiguous (refer to only one host) to be useful. Names can be assigned either centralised or distributed. If a centralised assignment of names is used, it is simple to keep names unambiguous, but the approach is vulnerable to failures and does not scale well. When distributed name assignment is used, it is often based on a hierarchical naming structure, where each of the entities allowed to assign names have control over a speci ed part of the name space. This provides an ecient way to ensure unambiguous names. The location of a host is called an address. The address must contain enough information to locate the host exactly. In order to provide an ecient way of locating the host from an address,


115

the addresses are also structured hierarchically (e.g., like ordinary mail, where country, city, and street are used by dierent levels of the postal system). In order to locate a host with a given name, the name must be mapped to an address (this process is called name resolution). This often involves interrogating either a centralised or a distributed database. Routing is the process of deciding, which path through the network is to be used when data is transferred. The criteria for selecting routes are to minimize delay and to maximize throughput. As the trac on a network link is stochastic and as the topology of a network may change due to ,e.g., network failures, the links comprising the best route may change in time too. This fact has let to the design of adaptive routing protocols, which are protocols able to respond to changes in the trac load on dierent paths in the network. Furthermore, they are able to change the routes in case of host or network link failures. To be able to adapt to changes in the network, information about the state of the network must be collected continuously. The processing of this information may be either centralised or distributed. A much simpler type of routing is static routing, in which the routing protocols use static routing information. They are only able to respond to host and network link failures. In large networks, where multiple paths exist, and where the network may cover multiple administrative domains, adaptive routing protocols are useful, but in small (local area) networks, where there is often only one path between any two hosts, static protocols are used.

A.1.6 Congestion Control and Avoidance

Both the data links and nodes used when transferring data, may suer from congestion (overloading). In cases of congestion, the amount of data successfully transferred may drop way below the actual capacity of the network, because several hosts ood the network with data. In order to recover from these situations, protocols use congestion control, where they detect that the network is congested, and subsequently reduce the amount of data they are transmitting. Protocols may also try to avoid congestion altogether by being conservative about the amount of data transmitted.

A.2 TCP/IP Protocol Suite In order to reduce the complexity of designing and implementing protocols, they are often structured as a stack of layers, each layer covering a certain functionality. Such a collection of protocol layers are often called a protocol stack. An example of such a protocol stack is the TCP/IP protocol stack. In the following we will describe the TCP/IP protocol suite, as this is the standard protocol suite of the Internet. The TCP/IP protocol suite is organized as a four layer stack (see Figure A.1); the applications layer, the transport layer, the network layer, and the link layer. The applications layer consists of the user level applications. The transport layer provides the applications with two types of services, the unreliable, connection-less packet service User Datagram Protocol (UDP) [Pos80], and the reliable, connection-oriented, stream service Transmission Control Protocol (TCP) [Pos81b]. The primary protocols of the network layer are the Internet Protocol (IP) [Pos81a]|an unreli-


Applications Layer user process

user process

user process

Transport Layer

TCP

UDP

Network Layer

ICMP

IP

IGMP

Link layer

ARP

device driver

RARP

Figure A.1: TCP/IP protocol suite

116


117

able datagram service, which provides the transport layer with host to host data delivery,1 the Internet Control Message Protocol (ICMP), which is used to exchange control information such as routing error conditions, and the Internet Group Management Protocol (IGMP), which is used to provide group multicasting. The link layer includes the Address Resolution Protocol (ARP), which provides a mapping from IP addresses to hardware addresses, and the Reverse Address Resolution Protocol (RARP), which enables hosts to determine their IP address from their hardware address. For more information about the TCP/IP protocol suite consult books like [Ste94] and [Com88].

1

The hosts in a network using TCP/IP all have a unique address called an IP address.

Appendix B

Ethernet Address Resolution Protocol (ARP) In most protocols (including the TCP/IP protocol suite) the protocol address assigned to hosts are dierent from and incompatible with the Ethernet hardware addresses. When a host S wants to transmit to a host T, the Ethernet hardware address of host T must be determined from T's protocol address. The Ethernet address resolution protocol is designed to dynamically determine an Ethernet hardware address given a higher level protocol address.

B.1 Protocol ARP [Plu82] is designed to be able to handle dierent types of protocols. The entity, which must be converted to an Ethernet hardware address, is the tuple < protocol type, protocol address >. The mechanism, which has the responsibility of converting these tuples into Ethernet hardware addresses, is the Address Resolution module. This module maintains a cache of tuples to Ethernet hardware address bindings. When an address conversion is requested, the Address Resolution module tries to nd the binding of the tuple in the ARP cache. If the binding is found, the protocol address is converted. In the case, where the binding is not found, a request is broadcasted on the Ethernet, where the host with the protocol address should be located. This host should then receive the request, recognize it's own protocol address, and send a reply containing it's protocol and Ethernet hardware address. On receipt of the reply, the Address Resolution module updates the cache, and is then able to convert the tuple. The processing of received packets is summarized in Figure B.1.

B.2 Packet Format The packet format used by ARP is summarized in Figure B.2. As ARP is designed to be able to encompass several hardware types, a hardware address space is speci ed (Ethernet, Packet Radio Net, : : : ), and of course the protocol address space is speci ed (Internet, DECnet, : : : ). The opcode is set to either request or reply. 118

APPENDIX B. ETHERNET ADDRESS RESOLUTION PROTOCOL (ARP)

119

if(I have the speci ed type of hardware) if(I speak the speci ed protocol)

merge ag = false < protocol type, sender protocol address > is in ARP cache) update tuple binding with the received sender hardware address merge ag = true if(I am the target protocol address) if(merge ag == false) add binding of < protocol type, sender protocol address > to sender hardware address to ARP cache if(packet is a request) Swap hardware and protocol elds, putting the local addresses in the sender elds Mark the packet as a reply Send the packet to the target hardware address on the same device on which is was received

if(

Figure B.1: ARP packet processing

B.3 Proxy ARP A host on an Ethernet may act as a gateway for another host, which is connected by other means to the host (e.g., a serial link). It may be convenient pretend, that this other host is connected directly to the Ethernet. This may be done by letting the gateway answer ARP requests addressed to the other host. This is called proxy ARP, and is done as follows. The host connected to the Ethernet binds the address of the other host to it's own hardware address, and when a request for the protocol address of the other host is received, a reply is sent containing it's own hardware address.

B.4 Gratuitous ARP There may arise situations, where the hardware address of a host changes. This could be when an Ethernet card is replaced, or when the host changes from being directly connected to the Ethernet to being connected to a another host on the Ethernet via a serial link as described in section B.3. As the Address Resolution modules at other hosts may contain bindings of the host in the ARP caches, these caches must be updated. As can be seen from Figure B.1, the Address Resolution module is required to update the cache entry of the sending host, when it receives an ARP packet. This is done by using the new binding supplied as sender information. Thus the host wishing to update it's hardware address may send a gratuitous ARP packet, where the

APPENDIX B. ETHERNET ADDRESS RESOLUTION PROTOCOL (ARP)

120

Protocol address of target Hardware address of target (if known) Protocol address of sender Hardware address of sender Opcode Byte length of protocol address Byte length of hardware address Protocol address space Hardware address space

Figure B.2: ARP packet format sender information contains the new hardware address.

Appendix C

The GSM System C.1 Evolution of the GSM System A principal decision to develop a common standard for mobile communication was taken in 1979 at the World Administrative Radio Conference [Hil95]. But it was not until 1982 that the development of GSM started, when the Conference of European Posts and Telegraph formed a special study group called Groupe Special Mobile .1 The group was to develop a pan European public cellular system. The basic design criteria for the proposed system were [Sco95]:

Good subjective speech quality Low terminal and service cost Support for international roaming Ability to support hand held terminals Support for range of new services and facilities Spectral eciency ISDN compatibility

In 1989 the responsibility for developing the GSM system was transferred to the European Telecommunication Standards Institute and in 1990 the Phase I recommendations for the GSM system were published. The rst commercial GSM networks were operating in the mid-1991 in European countries. By the beginning of 1995 there were 60 countries with operational or planned GSM network throughout Europe, the Middle East, the Far East, Australia, Africa and South America. The total numbers of subscribers had by then exceed a total of 5.4 million. In the following sections we will give rst a brief description of the services provided by GSM, then sketch the system architecture of GSM and brie y cover mobility management and nally we will look more into the data service provided by GSM. For those interested in a more thorough This was the initial meaning of the GSM, but the acronym now more aptly stands for Global System for Mobile communication 1

121

APPENDIX C. THE GSM SYSTEM

122

treatment of GSM we refer to [MP95], [Rah93] and [Sco95]. For a historical overview of mobile telephony in general, [Hil95] is a good starting point.

C.2 Services Provided by GSM GSM was designed to be compatible with ISDN in terms of services oered and signalling used. The services provided by GSM, which are a subset of the standard ISDN services, are:

Speech Data communication supporting bit rates up to 9600 Kbps 2 allowing connection to PSTN,

ISDN, Packet Switched and Circuit Switched Public Data Networks using synchronous as well as asynchronous transmission Group 3 facsimile, teletex and videotex A cell broadcasted service, where messages are broadcast to users in a particular cell Short Message Service (SMS), allowing users to send and receive point-to-point alphanumeric messages of sizes up to 160 bytes The SMS service is unique to GSM. It resembles a paging service, but is far more comprehensive, allowing bi-directional messages, store-and-forward delivery3 and acknowledgement upon successful delivery. In the Phase I speci cations of GSM, which was released by the European Telecommunication Standards Institute (ETSI) in 1990, a set of supplementary services have been included, which are call forwarding and call barring of outgoing or incoming calls. In the upcoming Phase II speci cation many more services will be included such as multiparty calls, advice of charge, call waiting and calling line identi cation presentation.

C.3 System Architecture The GSM system consists of various functional entities, whose functions and interfaces are speci ed in the GSM recommendations. Figure C.1 illustrates the architecture of a generic GSM network. The network architecture can roughly be divided into the following three parts: Mobile Station Base Station Subsystem Network Subsystem Radio transmission limitations such as bandwidth and cost, do not allow the standard ISDN B-channel bit rate of 64 Kbps to be practically achieved 3 If the recipient of a SMS message cannot be reached, the GSM system will hold on to the message until it can be delivered. 2


123

The Mobile Station (MS) is carried by the user, the Base Station Subsystem (BSS) controls the radiolink with the MS and the Mobile services Switching Center (MSC) deals with switching between mobile and other xed or mobile users and manages the roaming MSs. The communication between the MSs and the BSS is speci ed by the interface Um, the communication between the Base Transceiver Station (BTS) and the Base Station Controller (BSC) is speci ed by the interface Abis and nally communication between the BSC and the MSC is speci ed by the interface A. The Um interface is a radio link interface whereas Abis and A are wired link interfaces.4

HLR

VLR

BSC

PSTN ISDN,PSPDN CSPDN

MSC SIM

BTS

ME

BSC EIR

AuC

BTS

Mobile Station

Um

Abis

A

Base Station Subsystem

Legend:

Network Subsystem Abbreviations:

Wireless communication

SIM

Subscriber Identity Module

Wired communication

ME

Mobile Equipment

BTS

Base Transceiver Station

BSC

Base Station Controller

MSC

Mobile services Switching Center

HLR

Home Location Register

VLR

Visitor Location Register

EIR

Equipment Identity Register

AuC

Authentication Center

Communication interface

Figure C.1: General architecture of the GSM network (obtained from [Rah93]) For further information on the interfaces between the functional entities in the GSM network we refer to the ETSI GSM recommendations. 4


124

C.3.1 Mobile Station

The MS comprise the mobile equipment (e.g., a terminal) and a smart card called Subscriber Identity Module (SIM). The SIM card contains among other things an International Mobile Subscriber Identity (IMSI) and a secret key used for authentication. This information provides for unique identi cation of the subscriber to the system, allowing personal mobility. The user is able to access subscribed services independently of the speci c terminal used. The SIM card is protected against unauthorized use by a password. The mobile equipment is likewise identi ed by an International Mobile Equipment Identity (IMEI).

C.3.2 Base Station Subsystem

The Base Station Subsystem consists of a number of Base Transceiver Station (BTS) and a Base Station Controller (BSC). The BTS contains the radio transceivers that de ne a cell and handles the radio link communication over an Um compliant interface with the MS. The BSC manages radio resources for one or more BTSs across a Abis compliant interface. It handles among other things radio channel setup, tear down, and handos, as described in Sections C.4 and C.5.1. On top of this, the BSC is the connection between the MS and the Mobile services Switching Center. The BSC communicates with the MSC across an A compliant interface.

C.3.3 Network Subsystem

The primary component of the Network Subsystem is the Mobile services Switching Center (MSC). Besides acting like a normal switching node of the PSTN and ISDN it additionally provides the functionality needed to handle mobile subscribers such as registration, authentication, location updating, handovers and call routing to a roaming subscriber. The services related to handling of mobile subscribers are provided through interaction between the MSC and the following four databases:

Home Location Register (HLR) Visitor Location Register (VLR) Equipment Identity Register (EIR) Authentication Center (AuC)

Together these ve functional entities form the Network Subsystem (see Figure C.1).

HLR contains information on each subscriber registered in the corresponding GSM network. The HLR among other things holds the current location of subscribers to assist routing of incoming calls to the mobile. Theres is one HLR for every GSM network.


125

VLR registers all non-resident subscribers roaming in the geographical area covered by the VLR. The register contains information on roaming mobiles necessary for call control and providing the mobiles with the services to which they subscribe. Typically there will be one VLR for every MSC, so that the area covered by the MSC corresponds to that of the VLR, thus speeding up the MSC's access to information needed for call administration. EIR contains information on mobile equipment valid for use in the corresponding GSM network. As mentioned previously mobile equipment is identi ed by its IMEI. The EIR contains a list of all valid IMEIs. An IMEI is marked as invalid in case it has been reported stolen or if it has not been type approved.

AuC is a protected database holding copies of the secret keys stored in the SIM cards in

the mobile equipment. The secret keys are used for authentication and ciphering on the radio channels. There is one AuC for every GSM network.

C.4 Mobility Management Mobility Management deals with keeping track of roaming mobiles, registering the location information in the proper location registers (HLR and VLR) and handling connection handos for roaming mobiles communicating. Besides Mobility Management is concerned with authentication and security.

C.4.1 Handling of Location Information

Location information is maintained and used by the GSM network for call routing purposes. Each BSS broadcast at regular intervals the cell identities of the cells under it's coverage. The mobiles keeps monitoring this information. As changes in location is detected by the mobiles it send a location update message. The BSS receiving the location update message will route it to the VLR of its associated MSC. The VLR passes on the update noti cation the mobiles HLR where it is recorded. The HLR now instructs the old VLR to delete its entry on the mobile and at the same time passes on a service pro le for the mobile to the new VLR.

C.4.2 Connection Handos

In a cellular network the radio and xed links required for a call are not permanently allocated for the duration of the call. Hando is the switching of an on-going call to a dierent cell or channel. In the GSM system there are four dierent types of handos, which involves transferring a call between: 1. Channels within the same cell (BTS) 2. Cells under under the control of the same BSC 3. Cells under the control of dierent BSCs belonging to the same MSC


126

4. Cells under the control of BSCs belonging to dierent MSCs Handos 1 and 2 can be handled within the the BSC controlling the aected cell(s), since the location information in the associated MSC is limited to the BSC level. This type of hando is termed internal hando . When the hando has taken place is the associated MSC informed. Handos 3 and 4 are termed external handos since they require involvement of the associated MSC(s). In case of inter-BSC handos, when a BSC indicates to the MSC that an external hando should take place, it is the MSC that determines when and to which BSC the MS should be handed o. The MSC uses signal quality measurement information gathered by the MS 5 to govern the external hando. Besides being initiated by a roaming MS, handos may be initiated by the MSC as a mean of trac load balancing.

C.5 Communication Management Communication Management deals with call control, supplementary service management and Short Service Management. In this section we will focus solely on call control, describing how call routing is done in the GSM system.

C.5.1 Call Routing

Check the routing scheme - speci cally check how packets are routed on an open connection (are they always routed via the home network of the caller) As opposed to routing in a xed network, where terminals are permanently wired to a central oce, a GSM subscriber can roam nationally as well as internationally. The number dialled to reach a GSM subscriber is called the Mobile Subscriber ISDN (MSISDN). This number contains a country code and a national destination code, which identi es the GSM service provider. In this section we will use the terms mobile terminated calls and xed terminated calls to mean that the callee is mobile respectively xed. For a mobile terminated call, routing the call to the GSM subscriber requires the MS of the GSM subscriber to be located rst, unlike a xed terminated call, where routing of the call to the xed subscriber is fairly straightforward. An incoming mobile terminating call is directed to the Gateway MSC (GMSC). The GMSC is basically a a MSC with extra functionality to interrogate the GSM subscribers HLR to obtain routing information. The GMSC thus hold bindings between MSISDNs and HLRs. The routing information returned to the GMSC is the Mobile Station Roaming Number (MSRN). The MSRN is a temporary number which identi es the MSC currently servicing the MS. The most general routing scenario, which is depicted in Figure C.2, starts with the GMSC querying the called GSM subscribers HLR for an MSRN. The HLR typically only stores an address of the subscribers current VLR not the MSRN. The HLR therefor needs to query the subscribers current VLR for a MSRN. The VLR allocates an MSRN, from an associated pool, for the call, creating at the same time a binding between the called subscribers IMSI and the allocated MSRN. This MSRN is returned to the HLR and from here passed on back to the GMSC. The MS continually perform measurements of signal strengths from up to 16 neighboring cells, and forms a list of the 6 best candidates for a hando. 5

APPENDIX C. THE GSM SYSTEM Fixed Subscriber

PSTN/ISDN Exchange

MSISDN

127

Gateway MSC

MSISDN

Home Location PSTN/ISDN Register Exchange

MSISDN MSRN

MSC/VLR

Mobile Station

IMSI MSRN

MSRN

MSRN

TMSI

Legend: Switching node

Figure C.2: Call routing for a mobile terminating call (obtained from [Rah93]) The GMSC can now route the call to the MSC servicing the called subscriber. At the MSC the IMSI corresponding the MSRN is looked up, and the MS associated with the IMSI is paged in it's current location area.

C.6 Authentication and Security Since the radio medium can be accessed by anyone, authentication of users to prove that they are who they claim to be, is an important issue in mobile networks. Authentication involves to functional entities, the SIM card in the MS and the AuC in the subscribers home network. Each subscriber is given a secret key, one copy of which is stored in the SIM card and one the AuC of the home network. Both the MS and the AuC then use a random number, in conjunction with the subscribers secret key and a ciphering algorithm to generate a signed response. Only if the random number sent by the MS as a reply to the AuC's authentication request, does contain the same random number as the one calculated by the AuC, is the MS authenticated.

C.7 GSM Data Services The bit rates oered for data transmission in the GSM system are ranging from 300 bps up to 9.600 bps. The GSM speci cation de nes two types of data services: 1. Transparent mode 2. non-transparent mode


128

In the transparent mode no error correction beyond Forward Error Correction (FEC) is employed. To the end-user throughput and delay appears xed, while the error-rate will be variable. The delay experienced depends on the network load and the network implementation. The error rate depends on the reception conditions and the amount of FEC employed.6 Non-transparent mode oers a virtual circuit quality connection. In addition to user data, control information and FEC, an additional automatic repeat request protocol is being applied, improving the quality of service dramatically. Error rate is now xed at a level bounded by the error rate of the PSTN/ISDN.7 The price payed for the improved quality of service is variable throughput (below that of the transparent service) and variable delay. The minimum delay is the same as for transparent mode , but may grow due to retransmissions. As with the transparent mode data service the exact quality service depends on the data rate chosen, with lower data rates leaving more bandwidth for error correction/protection.

C.8 Performance of GSM Data Service Research have been conducted at the Department of Computer Science, University of Helsinki by [AKL+ 94] to evaluate the performance of the GSM data service. The emphasis of this research has been performance as experienced by application programs - standard TCP/IP protocols have thus been used in their experiments. Performance is evaluated using the following three basic operations: 1. Dial-up connection establishment 2. Exchange of request-reply messages 3. Bulk transfers The experimental settings have been a "normal" oce environment, where the eld strength of the cellular link has been good or fairly good. The experimental settings could be characterised as the best possible situation 8 a user of mobile equipment may experience. Thus the results presented here should be taken to indicate an upper bound on the performance of the GSM data service. Connect time Percentiles Fault rate 99% Max Min 32 sec 35 sec 28 sec 12 %

Table C.1: Connect time and fault rate for GSM 6 Depending on the bit rate chosen the bandwidth available for FEC lies between 10.8 Kbps and 19.2 Kbps [Hil95]. 7 The virtual connection service is only being applied to the radio link part of the connection. 8 Stable reception conditions, no handos due to roaming, etc.

APPENDIX C. THE GSM SYSTEM Request/Reply packet sizes 1/1 32/512 32/1024 32/2048 1024/32

129 RTT Percentiles 99% Max Min 1.10 1.15 0.77 1.65 1.70 1.37 2.25 2.31 1.98 3.35 4.56 3.13 4.15 4.56 2.09

Table C.2: Round-trip times for GSM Receive Conditions Eective Transfer Rate Good 80 - 100 % Poor 10 - 50 %

Table C.3: Bulk data transfer for GSM Tables C.1 through C.3 presents an extract of the results obtained by [AKL+ 94]. The results seems to indicate that running interactive applications over a GSM link cannot yet be done smoothly due to the high latency of the link, even under the best working conditions (according to [Jac90] response time in interactive applications should be less than 200 ms). Generally though the link seems to perform well for bulk transfers, allowing almost full utilization of available bandwidth under good working conditions. Tables C.4 and C.5 presents results from a small series of experiments we have conducted ourselves to establish a rough picture of the performance of a GSM link. The emphasis has been the raw performance of the GSM link - in all experiments the raw device has been read and written. Performance has been evaluated using the following operations: 1. Echoing 2. Bulk transfers The experimental setting has been a "fast" moving vehicle. We have wanted to test the GSM link in an environment with occasional handos, varying signal strength to get an idea of what performance to expect from a GSM link when on the move. The results obtained supports the conclusions made by [AKL+ 94]. The signi cantly larger variations in round trip times can be accounted for by handos and an increased number of retransmissions due to varying signal strength. When comparing the results obtained by [AKL+ 94] with the results from Tables C.4 and C.5, it should be remembered that our experiments have been conducted on the raw device, eliminating any overhead incurred by protocol stacks.


Request/Reply RTT Percentiles packet sizes 99% Max Min 1/1 1.53 7.80 0.60

Table C.4: Round-trip times for GSM { own data

Receive Conditions Eective Transfer Rate Varying approx. 80 %

Table C.5: Bulk data transfer for GSM { own data

130

Appendix D

TCP/IP Header Compression TCP/IP header compression is relevant when dealing with TCP/IP performance over low speed (typically 9.600 to 28.800 bps) serial links. The size of TCP/IP headers (typically 40 bytes) constitutes a severe threat to performance of interactive communication on slow serial links by reducing the experienced responsiveness of the interactive application. For bulk transfer the overhead of TCP/IP headers can be eliminated by increasing the packet size. Still with growing packet size the risk of transmission errors increases|with large packets an excessive amount of bandwidth is wasted with just a few retransmissions. In this appendix we will give a description of the algorithm used by PPP for TCP/IP header compression, including a brief review of the design and the compressed header format.

D.1 Algorithm The TCP/IP header algorithm described here was designed by Van Jacobsen in 1990 [Jac90]. The algorithm considers only compression of TCP/IP headers. It has proven infeasible to do compression on UDP/IP headers. Likewise it has been shown that separate compression of the TCP and IP headers in a datagram is less ecient than doing compression on the full TCP/IP header. The algorithm, which is based on dierential coding, utilises that over the lifetime of a TCP connection less than half the information contained in the TCP/IP header ever changes. Figure D.1 illustrates this|the shaded areas marks header information that never changes. Likewise the elds Total Length and Header Checksum in the IP header can be omitted. The framer in a serial link module will notify receiver of the length of the packet received making Total Length redundant, and Header Checksum is super uous since it now protects a header that is not transmitted (the checksum can be generated at the receiving end). So far the TCP/IP header has been reduced to 16 bytes (if we disregard any additional options), that do change over the lifetime of a TCP connection. Still they do not all change at the same time. Van Jacobsen gives an example of a FTP data transfer. In the sender/receiver direction only Packet Id , Sequence No and Checksum changes, whereas in the receiver/sender direction only Packet Id , Ack , Checksum and possibly Window changes. Van Jacobsen suggests keeping a copy of the header of the last packet sent, the sender will be able to gure out which 131

APPENDIX D. TCP/IP HEADER COMPRESSION Byte

0

0

8 Protocol Version

24

Type of Service

Total Length D M F F

Packet ID

Time to Live

Protocol

12

Source Address

16

Destination Address

Source Port

20

Destination Port

Sequence Number

28

36

fin

rst

Checksum

syn

psh

urg

Data Offset

ack

Acknowledgement Number

Window

TCP Header

24

32

Fragment Offset

Header Checksum

IP Header

4

8

16

Header Length

132

Urgent Pointer

Legend: Header field changing over the lifetime of a TCP connection

Header field that does not change over the lifetime of a TCP connection

Figure D.1: TCP/IP Header (obtained from [Jac90]) header elds have changed and send a bit mask indicating what have changed followed by the changes. At this point the TCP/IP header has been reduced to about 10 bytes. The compression scheme relies on sending the bytes that have changed. If however we would send only the dierences in the elds that have changed, an additional 3 - 4 bytes could be saved. This brings the compressed TCP/IP header down to 5 bytes. The algorithm further recognises two common cases; interactive typing trac and bulk transfer, where 3 bytes of compressed header will do, thereby further improving the overall performance of the compression scheme.

D.2 Design Figure D.2 illustrates the model for doing TCP/IP header compression. The IP layer hands over an IP packet to the PPP device. The compressor module decides if it is possible to compress the header, if not the packet is marked appropriately and passed to the framer module. Only packets generated under the TCP protocol are prone for compression 1. For compressible TCP packets a search is made in the array of packet headers, for a header containing a matching connection descriptor. If a matching descriptor is found the TCP/IP header of the incoming packet is compressed and handed over to the framer module along with an appropriate packet type speci cation. The uncompressed TCP/IP header of the incoming packet substitutes the header found in the array. If no match is found the TCP/IP header of the Except for a few special cases all packets generated under the TCP protocol will be subject to header compression (see [Jac90]) 1

APPENDIX D. TCP/IP HEADER COMPRESSION

133

Simplex serial link (1/2 of real full link)

PPP Output

TCP/IP packet

PPP Input

Compressor

framming and error detection

framming and error detection

saved packet headers for n connections ,,,

Decompressor

TCP/IP packet

saved packet headers for n connections ,,,

Legend: PPP device

Figure D.2: Header Compression Model (obtained from [Jac90]) incoming packet is copied into an available slot of the array (if no slots are available, the oldest entry is replaced by the new packet header). The packet is handed over to the framer module uncompressed along with an appropriate packet type speci er. In the TCP header of the packet, the number in the protocol eld is replaced by the index in the array holding the packet header. At the receiving end in the PPP device, the framer module hands over to the decompressor an entire IP packet along with a packet type speci er. In case of a transmission error the decompressor will receive a pseudo packet along with a packet type speci er indicating that a transmission error has occurred (for a description of the error handling refer to[Jac90]). For uncompressed TCP packets the connection number will be extracted from the TCP header protocol eld, and the original protocol value is restored. The connection is used as in index into the array of packet headers and the TCP/IP header is copied into the packet header slot speci ed by the connection number. The IP packet is handed over to the IP layer. For compressed TCP packets the connection number contained in the compressed header (refer to gure D.3) is likewise used to retrieve the TCP/IP header of the previous packet received on this connection. The information in the compressed header is used to update the stored TCP/IP header. The compressed header is now replaced by the updated TCP/IP header, and the packet is handed over to the IP layer. In case of an uncompressible packet, the packet is simply passed on the IP layer directly from the framer module. The compression model leaves it up to the framer module to handle error detection, providing information of the packet type (compressed, uncompressed, uncompressible) as well as the packet size 2. Any serial device driver implementing the PPP protocol for serial communication, will provide these services (see [Sim94]). 2

The size of the IP packet is left out of the compressed header

APPENDIX D. TCP/IP HEADER COMPRESSION

134

D.3 Compressed Header Format Figure D.3 gives the format of a compressed TCP/IP header. The changemask indicates which of the header elds that can be expected to change, actually have changed. The connection number allows the receiver to locate the header of last packet received on this connection. The eld is optional. It can be omitted whenever a stream of packets related to the same connection are sent uninterrupted. If the connection number is omitted the C bit of the change mask is set. The TCP checksum is always contained unmodi ed in the compressed header to ensure the end-to-end data integrity. This checksum cannot, as opposed to the IP header checksum, be generated at the receiving end, since a TCP packet might consist of several IP packets. For every bit set in the changemask, the change in the associated header eld is contained in the compressed header.

Byte 0 1

C

I

P

S

A

W

U

connection number (C)

2 TCP checksum 3 4

urgent pointer (U)

,

∆ window (W)

,

∆ ack (A)

,

∆ sequence no. (S) ∆ IP ID (I)

Legend: Information always present in header

Information possibly omitted from header

Figure D.3: Compressed Header (obtained from [Jac90]) The compression as stated in section D.1, exploits that changes in eld values are relatively small. As gure D.3 shows, for all elds (except the TCP header checksum) only one byte has been set aside to hold the change. If changes exceeds what can be held within one byte, the packet is considered uncompressible and sent uncompressed with a packet type speci er, that indicates that the TCP/IP header arrays at both the sending and receiving side should be updated to match the header values of this uncompressed packet.

Bibliography [AKL+ 94] Timo Alanko, Markku Kojo, Heimo Laamanen, Mika Liljeberg, Marko Moilanen, and Kimmo Raatikainen. Measured Performance of Data Transmission Over Cellular Telephone Networks. Computer Communication Review, 1994. [Azi93] Ashar Aziz. A Scalable and Ecient Intra-Domain Tunneling Mobile-IP Scheme. Computer Communication Review, pages 12{20, august 1993. [Bak94] Mary G. Baker. Changing Communication Environments in MosquitoNet. In Proceedings of the 19994 IEEE Workshop on Mobile Computing Systems and Applications, December 1994. [BB94] Ajay Bakre and B. R. Badrinath. I-TCP: Indirect TCP for Mobile Hosts. Technical Report DCS-TR-314, Rutgers University, October 1994. [BG87] Dimitri Bertsekas and Robert Gallager. Data Networks. Prentice-Hall, 1987. [BP93] Pravin Bhagwat and Charles E. Perkins. A Mobile Networking System based on Internet Protocol(IP). In Proceedings of the rst USENIX Symposium of Mobile and Location-Independent Computing, pages 69{82. USENIX, 1993. [BSAK95] Hari Balakrishnan, Srinivasan Seshan, Elan Amir, and Randy H. Katz. Improving TCP/IP Performance over Wireless Networks. In Proceedings of the 1st ACM International Conference on Mobile Computing and Networking. ACM, November 1995. [CI94] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE JSAC Special issue on Mobile Computing Networks, 1994. [Com88] Douglas Comer. Internetworking with TCP/IP { Principles, Protocols and Architecture. Prentice-Hall International, 1988. [DCY93] Antonio DeSimone, Mooi Choo Chuah, and On-Ching Yue. Throughput Performance of Transport-Layer Protocols over Wireless LANs. In Proceedings of the IEEE Global Telecommunications Conference - Globecomm '93, pages 542{549, 1993. [Dee91] S. Deering. Router Discovery. RFC 1256, September 1991. . 135

BIBLIOGRAPHY [DKS89] [Dro93] [Duc92] [ea96] [FJ95] [HH95] [Hil95] [IB94] [IDJ91] [IDJ93] [Jac88] [Jac90] [JKW95] [KP87]

136

A. Demers, S. Keshav, and S. Shenker. Analysis and Simulation of a Fair Queuing Algorithm. In Proceedings of ACM SIGCOMM '89, volume 19, pages 1{12, September 1989. R. Droms. Dynamic Host Con guration Protocol. RFC 1541, October 1993. . Daniel Duchamp. Issues in Wireless Mobile Computing. In Proceedings of the Third Workshop on Workstation Operating Systems, pages 1{7. IEEE, April 1992. Erik Andersen et al. Kommunikation mellem abne systemer - OSI lagene 5-7 - DSh andbog 108. Dansk Standard, 1996. ISBN 87-7310-181-8. Sally Floyd and Van Jacobsen. Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, 3(4), August 1995. L. B. Huston and P. Honeyman. Partially Connected Operation. In Proceedings of the Second USENIX Symposium on Mobile and Location-Independent Computing, volume 8. The USENIX Association, Fall 1995. Stefan Hild. A Brief History of Mobile Telephony. Technical Report 372, University of Cambridge Computer Laboratory, April 1995. Tomasz Imielinski and B. R. Badrinath. Wireless Computing - Challenges in Data Management. Communications of the ACM, 37(10):19{28, October 1994. John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. IP-based Protocols for Mobile Internetworking. In Proceedings of SIGCOMM'91, pages 235{245. ACM, September 1991. John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. The Design and Implementation of a Mobile Internetworking Architecture. In Proceedings of the 1993 Winter USENIX Technical Conference, pages 491{502. USENIX, January 1993. Van Jacobsen. Congestion Avoidance and Control. Computer Communication Review, 18(4):314{329, August 1988. V. Jacobsen. Compressing TCP/IP Headers for Low-Speed Serial Links. RFC 1144, February 1990. . Kirk L. Johnson, M. Frans Kaashoek, and Deborah A. Wallach. Managing Update Con icts in a Weakly Connected Replicated Storage System. In Proceedings of the 15th ACM Symposium on Operating Systems Principles. ACM, December 1995. Phil Karn and Craig Partridge. Improving Round-Trip Time Estimates in Reliable Transport Protocols. Computer Communication Review, 17(5):2{7, August 1987.

BIBLIOGRAPHY [KRA94]

137

Markku Kojo, Kimmo Raatikainen, and Timo Alanko. Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network. Technical Report C-1994-39, University of Helsinki , Department of Computer Science, September 1994. [LAK+ 95] Mika Liljeberg, Timo Alanko, Markku Kojo, Heimo Laamanen, and Kimmo Raatikainen. Optimizing World-Wide Web for Weakly Connected Mobile Workstations: An Indirect Approach. In Proceedings of SDNE '95, June 1995. [McK91] P. McKenny. Stochastic Fairness Queuing. Internetworking: Research and Experience, Vol. 2:113{131, January 1991. [MDC93] Brian Marsh, Fred Douglis, and Ramon Caceres. System Issues in Mobile Computing. Technical Report MITL-TR-50-93, Matsushita Information Technology Laboratory, February 1993. [MES95] Lily B. Mummert, Maria R. Ebling, and M. Satyanarayanan. Exploiting Weak Connectivity for Mobile File Access. In Proceedings of the 15th ACM Symposium on Operating Systems Principles. ACM, December 1995. [MP95] Michel Mouly and Marie-Bernadette Pautet. Current Evolution of the GSM Systems. IEEE Personal Communications, October 1995. [MS93] Andrew Myles and David Skellern. Comparision of Mobile Host Protocols for IP. In Proceedings of 4th Joint European Networking Conference, pages 191{196, May 1993. [Nag84] John Nagle. Congestion Control in IP/TCP Internetworks. RFC 896, January 1984. . [Nag87] John Nagle. On Packet Switches with In nite Storage. IEEE Transactions on Computing, COM-35(4), April 1987. [NPS95] Brian D. Noble, Morgan Price, and M. Satyanarayanan. A Programming Interface for Application-Aware Adaption in Mobile Computing. Computing Systems, 8(4), 1995. [Per95] C. Perkins. IP Mobility Support. IETF draft, January 1995. Working draft . [Plu82] David C. Plummer. An Ethernet Address Resolution Protocol. RFC 826, November 1982. . [Pos80] Jon Postel. User Datagram Protocol. RFC 768, August 1980. . [Pos81a] Jon Postel. Internet Protocol. RFC 791, September 1981. .

BIBLIOGRAPHY

138

Jon Postel. Transmission Control Protocol. RFC 793, September 1981. . [Rah93] Moe Rahnema. Overview Of The Gsm System and Protocol Architecture. IEEE Communications Magazine, April 1993. [Rom88] J. Romkey. A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP. RFC 1055, June 1988. . [Sco95] John Scourias. Overview of the Global System for Mobile Communication. , May 1995. [Sho78] J. F. Shoch. Internetwork Naming, Addressing, and Routing. In Proceedings of the 17th IEEE Computer Society International Conference, pages 72{79, 1978. [Sim94] W. Simpson. The Point-to-Point Protocol(PPP). RFC 1661, July 1994. . [SKM+ 93] M. Satyanarayanan, J. J. Kistler, Lily B. Mummert, Maria R. Ebling, P. Kumar, and Q. Lu. Experience with Disconnected Operation in a Mobile Computing Environment. In Proceedings of the 1993 USENIX Symposium on Mobile and LocationIndependent Computing. USENIX, August 1993. [SNS88] Jennifer G. Steiner, Cliord Neuman, and Jerey I. Schiller. Kerberos: An Authentication Service for Open Network Systems. In Proceedings of the 1988 Winter USENIX Technical Conference, pages 191{201. USENIX, February 1988. [Ste90] W. Richard Stevens. UNIX Network Programming. Prentice Hall, 1990. [Ste94] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, 1994. [SV95] M. Shreedhar and Georg Varghese. Ecient Fair Queuing using De cit Round Robin. In Proceedings of ACM SIGCOMM '95, volume 25. ACM, October 1995. [Tan89] Andrew S. Tanenbaum. Computer Networks. Prentice-Hall International, 2nd edition edition, 1989. [TYT91] Fumio Teraoka, Yasuhiko Yokoto, and Mario Tokoro. A Network Architecture Providing Host Migration Transparency. In Proceedings of SIGCOMM'91, pages 209{220. ACM, September 1991. [WW94] Carl A. Waldspurger and William E. Weihl. Lottery Scheduling: Flexible Proportional-share Resource Management. In Proceedings of the First Symposium on Operating System Design and Implementation (OSDI), pages 1{11, November 1994. [Pos81b]

BIBLIOGRAPHY

139

[WYOT93] Hiromi Wada, Takashi Yozawa, Tatsuya Ohnishi, and Yasunori Tanaka. Mobile Computing Environment Based on Internet Packet forwarding. In Proceedings of 1993 Winter USENIX Technical Conference, pages 502{517. USENIX, January 1993. [YB94] Raj Yavatkar and Namrata Bhagawat. Improving End-to-End Performance of TCP over Mobile Internetworks. In Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994.

Semi-Connected TCP/IP in a Mobile Computing ... - CiteSeerX

Semi-Connected TCP/IP in a Mobile Computing ... - CiteSeerX

Suggest Documents

Mobile Cloud Computing - CiteSeerX

A Testbed for Mobile Networked Computing - CiteSeerX

MoCCA: A Mobile Communication and Computing ... - CiteSeerX

Mobile Agent Middleware for Mobile Computing - CiteSeerX

Context Awareness in Mobile Computing Environments - CiteSeerX

Location Management in Cellular Mobile Computing ... - CiteSeerX

Mobile Polymorphic Applications in Ubiquitous Computing ... - CiteSeerX

Mobile Polymorphic Applications in Ubiquitous Computing ... - CiteSeerX

Adaptive Service Provision in Mobile Computing ... - CiteSeerX

Locating Objects in Mobile Computing - CiteSeerX

Information Access in Mobile Computing Environments - CiteSeerX

Mobile Computing CDPD Technology - CiteSeerX

Electronic Commerce Transactions in a Mobile Computing ... - CiteSeerX

A Pervasive View in Distributed Mobile Computing 1 ... - CiteSeerX

Security Issues in a Mobile Computing Paradigm. - CiteSeerX

A Pervasive View in Distributed Mobile Computing 1 ... - CiteSeerX

Mobile computing

Mobile Computing

Mobile Computing

Mobile Learning in Mobile Cloud Computing Environment

Mobile Learning in Mobile Cloud Computing Environment

Multimodality in Mobile Computing and Mobile Devices

Mobile cloud computing: A survey

On Mobile Cloud Computing in a Mobile Learning System - Academic ...