An Investigation of the Datagram Congestion Control ... - CiteSeerX

University of South Australia

An Investigation of the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures

SOMSAK VANIT-ANUNCHAI B.Eng. (EE), MSEE, MA (Econ)

Computer Systems Engineering Centre School of Electrical and Information Engineering University of South Australia

A thesis submitted in total fulfilment of the requirements for the degree of Doctor of Philosophy in Computer Systems Engineering 20 November 2007

Contents I

Overview

1

1 Introduction

2

1.1

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.4

Scope

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.5

Organization of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.6

Reading guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2 Formal Methods and Coloured Petri Nets

7

2.1

Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2

Choosing Coloured Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3

Informal Introduction to CPNs . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1

The Running Example: Combined CPN Model of a FIFO/Reordering Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2

Net Structures for a Reordering Channel . . . . . . . . . . . . . . . 11

2.3.3

CPN model of a FIFO channel . . . . . . . . . . . . . . . . . . . . . 15

2.3.4

Combined CPN Model of a FIFO/Reordering Channel . . . . . . . 16

2.4

Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5

State space analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6

2.7

2.5.1

Analysis of the Channel Examples . . . . . . . . . . . . . . . . . . . 22

2.5.2

State space report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Related Analysis Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.1

The Sweep-Line Method . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6.2

Language Analysis and Protocol Verification . . . . . . . . . . . . . 30

Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

i

3 Definition of DCCP Connection Management

33

3.1

DCCP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2

DCCP Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3

3.4

3.5

3.2.1

DCCP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2

DCCP-Request, DCCP-Response and DCCP-Reset . . . . . . . . . 39

Sequence Number Parameters and Variables . . . . . . . . . . . . . . . . . 41 3.3.1

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.2

Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

DCCP Connection Management Procedures . . . . . . . . . . . . . . . . . 41 3.4.1

Typical Connection Establishment Procedure . . . . . . . . . . . . 42

3.4.2

Typical Close Down Procedures . . . . . . . . . . . . . . . . . . . . 44

3.4.3

Valid Sequence and Acknowledgement Number Intervals . . . . . . 45

3.4.4

Synchronisation Procedure . . . . . . . . . . . . . . . . . . . . . . . 46

3.4.5

Timeout Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.6

Reset Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4.7

Processing Unexpected Packets . . . . . . . . . . . . . . . . . . . . 49


4 Related Work

50

4.1

Modelling and Analysis of the OSI Transport Protocol using Petri Nets . . 51

4.2

Related Work using a Similar Methodology . . . . . . . . . . . . . . . . . . 54

4.3

Verification of TCP Connection Management . . . . . . . . . . . . . . . . . 56

4.4

Validation of DCCP Connection Management by IETF (Unpublished Work) 58

4.5


5 Summary of DCCP’s Verification 5.1

5.2

61

Development of the DCCP specification . . . . . . . . . . . . . . . . . . . . 61 5.1.1

DCCP version 5: the Initial CPN Model (Chapter 6) . . . . . . . . 61

5.1.2

Synchronisation Procedure . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.3

DCCP Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.4

DCCP version 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1.5

Racing toward RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1.6

Sequence number wrap (Chapter 9) . . . . . . . . . . . . . . . . . . 67

5.1.7

Modelling Methodology (Chapter 10) . . . . . . . . . . . . . . . . . 68

Sweep-line analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 ii

II

5.2.1

Deriving new progress measures (Chapter 11) . . . . . . . . . . . . 68

5.2.2

Verification against DCCP’s service on-the-fly (Appendix A) . . . . 69

Papers

71

6 Initial Result of a Formal Analysis of DCCP Connection Management 73 6.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2

DCCP Connection Management . . . . . . . . . . . . . . . . . . . . . . . . 75

6.3

CPN Model of DCCP Connection Management . . . . . . . . . . . . . . . 77

6.4

6.5

6.3.1

Modelling Assumptions and Interpretation of Specifications . . . . . 77

6.3.2

CPN model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Analysis of DCCP Connection Establishment

. . . . . . . . . . . . . . . . 80

6.4.1

Initial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.4.2

Investigation of Terminal States . . . . . . . . . . . . . . . . . . . . 80

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7 Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol

85

7.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.2

Datagram Congestion Control Protocol . . . . . . . . . . . . . . . . . . . . 88

7.3

7.4

7.2.1

DCCP Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.2.2

Connection Management Procedures . . . . . . . . . . . . . . . . . 89

7.2.3

Retransmission and Back-off Timers

7.2.4

Variables and Sequence Validity . . . . . . . . . . . . . . . . . . . . 93

7.2.5

DCCP-Reset Packets . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.2.6

Resynchronising Sequence Numbers . . . . . . . . . . . . . . . . . . 94

. . . . . . . . . . . . . . . . . 92

Modelling DCCP’s Connection Management Procedures

. . . . . . . . . . 95

7.3.1

Modelling Scope and Assumptions . . . . . . . . . . . . . . . . . . . 95

7.3.2

Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.3.3

DCCP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.3.4

Second, Third and Fourth Level Pages . . . . . . . . . . . . . . . . 98

7.3.5

Incompleteness in the Specification . . . . . . . . . . . . . . . . . . 98

Analysis of DCCP CPN Model . . . . . . . . . . . . . . . . . . . . . . . . 99 7.4.1

Initial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.4.2

State Space Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 iii

7.4.3 7.5

DCCP Chatter during Connection Establishment. . . . . . . . . . . 102

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

8 Chattering Behaviour in the Datagram Congestion Control Protocol 106 9 Effect of Sequence Number Wrap on DCCP Connection Establishment112 9.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

9.2

Overview of DCCP Connection Management . . . . . . . . . . . . . . . . . 115 9.2.1

DCCP packet format . . . . . . . . . . . . . . . . . . . . . . . . . . 115

9.2.2

DCCP connection management procedures . . . . . . . . . . . . . . 116

9.2.3

The need for the PARTOPEN state . . . . . . . . . . . . . . . . . . 117

9.2.4

Variables and sequence number validity check . . . . . . . . . . . . 118

9.3

Previous Work

9.4

CPN Model of DCCP Connection Management . . . . . . . . . . . . . . . 120

9.5

9.6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

9.4.1

Modelling assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 120

9.4.2

Model development . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

9.4.3

The top level page . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

9.4.4

Global declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

9.4.5

The second level page

9.4.6

An example of the third level page . . . . . . . . . . . . . . . . . . 125

. . . . . . . . . . . . . . . . . . . . . . . . . 125

Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 9.5.1

Terminal marking classification . . . . . . . . . . . . . . . . . . . . 128

9.5.2

Type D terminal markings . . . . . . . . . . . . . . . . . . . . . . . 128

9.5.3

State Space Size as ISS varies . . . . . . . . . . . . . . . . . . . . . 130

Conclusion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . 134

10 Modelling the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures

137

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 10.2 Overview of DCCP’s connection management procedures . . . . . . . . . . 140 10.2.1 DCCP packet format . . . . . . . . . . . . . . . . . . . . . . . . . . 141 10.2.2 DCCP connection management procedures . . . . . . . . . . . . . . 142 10.2.3 Synchronisation procedure . . . . . . . . . . . . . . . . . . . . . . . 143 10.3 CPN Model development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 10.3.1 Refinement of the hierarchical structure of DCCP-CM CPN model . 144

iv

10.3.2 Refinement of the data structures of the DCCP-CM CPN model . . 148 10.3.3 Illustration of folding and regrouping of transitions at the executable level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 10.4 Conclusion and future work . . . . . . . . . . . . . . . . . . . . . . . . . . 160 11 Analysis of the Datagram Congestion Control Protocol’s Connection Management Procedures using the Sweep-line Method

163

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 11.2 Overview of DCCP’s connection management procedure

. . . . . . . . . . 167

11.3 CPN model of DCCP connection management . . . . . . . . . . . . . . . . 170 11.3.1 Modelling assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 171 11.3.2 Model structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 11.3.3 The DCCP Overview page . . . . . . . . . . . . . . . . . . . . . . . 174 11.3.4 The third and fourth level pages . . . . . . . . . . . . . . . . . . . . 177 11.4 Sweep-line analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 11.4.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 11.4.2 Usual sources of progress . . . . . . . . . . . . . . . . . . . . . . . . 187 11.4.3 More subtle measures of progress . . . . . . . . . . . . . . . . . . . 189 11.4.4 Searching for a better progress measure . . . . . . . . . . . . . . . . 191 11.4.5 Progress mappings for the augmented model . . . . . . . . . . . . . 193 11.5 Experimental results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 11.5.1 Initial configurations . . . . . . . . . . . . . . . . . . . . . . . . . . 195 11.5.2 Analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 11.5.3 Terminal marking classification . . . . . . . . . . . . . . . . . . . . 198 11.6 Conclusions and future work . . . . . . . . . . . . . . . . . . . . . . . . . . 199 11.7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 12 Conclusions

215

12.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 12.1.1 Development of the DCCP-CM CPN model . . . . . . . . . . . . . 216 12.1.2 Ambiguities and Protocol Problems . . . . . . . . . . . . . . . . . . 218 12.1.3 Sweep-line Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 12.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 12.2.1 Extending the DCCP Model and its Analysis

v

. . . . . . . . . . . . 221

References

222

A Checking Safety Properties On-the-fly with the Sweep-line Method

247

A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 A.2 The Sweep-line Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 A.3 Proving Safety Properties On-The-Fly . . . . . . . . . . . . . . . . . . . . 255 A.3.1 Finite State Automata Representations of Safety Properties and Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 A.3.2 Checking Safety Properties . . . . . . . . . . . . . . . . . . . . . . . 260 A.3.3 A Simple Illustrative Example . . . . . . . . . . . . . . . . . . . . . 261 A.4 On-the-Fly Safety Property Checking with the Sweep-Line Method . . . . 264 A.4.1 Sweeping the Parallel Composition . . . . . . . . . . . . . . . . . . 265 A.4.2 Coping with Regress and Deletion of States . . . . . . . . . . . . . 267 A.4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 A.5 Validation using the Datagram Congestion Control Protocol . . . . . . . . 269 A.5.1 Language Inclusion Checking . . . . . . . . . . . . . . . . . . . . . 270 A.5.2 Datagram Congestion Control Protocol . . . . . . . . . . . . . . . . 271 A.5.3 DCCP-CPN Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 A.5.4 DCCP Service Model and Language . . . . . . . . . . . . . . . . . . 277 A.5.5 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . 279 A.6 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 283 B DCCP-CM Service CPN Model

286

B.1 Hierarchy Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 B.2 The Top Level Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 B.3 Global Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 B.4 The Connection Open Page . . . . . . . . . . . . . . . . . . . . . . . . . . 287 B.5 The Provider Abort Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 B.6 The User Abort Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 C CPN State Space to FSA

289

C.1 DCCP-CM Service CPN state space to FSA . . . . . . . . . . . . . . . . . 289 C.2 DCCP-CM CPN state space to FSA . . . . . . . . . . . . . . . . . . . . . 289 D Analysis Results

292

D.1 FIFO Channels without Loss . . . . . . . . . . . . . . . . . . . . . . . . . . 294 vi

D.2 FIFO Channels with Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 D.3 Reordering Channels without Loss . . . . . . . . . . . . . . . . . . . . . . . 298 D.4 Reordering Channels with Loss . . . . . . . . . . . . . . . . . . . . . . . . 299 E Additional Results relating to Chapter 9

300

E.1 Additional Results when Only Long Sequence Numbers are Allowed . . . . 300 E.2 Additional Results when Short Sequence Numbers are Allowed . . . . . . . 301

vii

List of Figures 2.1

A CPN model of a reordering channel with the initial marking. . . . . . . . 11

2.2

A CPN model of the reordering channel after transition Send has fired four times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3

A CPN model of a FIFO channel. . . . . . . . . . . . . . . . . . . . . . . . 16

2.4

A CPN model combining the FIFO and reordering channels. . . . . . . . . 16

2.5

The marking after the occurrence of BE5 (FIFO is false). . . . . . . . . . . 18

2.6

The marking after the occurrence of BE7 (FIFO is false). . . . . . . . . . . 18

2.7

The marking after the occurrence of BE8 (FIFO is true). . . . . . . . . . . 19

2.8

The marking after the occurrence of BE10 (FIFO is true). . . . . . . . . . 20

2.9

State space of the FIFO channel model when sending two messages. . . . . 23

2.10 State space of the combined channel model when sending two messages and FIFO is true. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.11 An example of state space report. . . . . . . . . . . . . . . . . . . . . . . . 26 2.12 Dead markings M7 and M8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1

DCCP packet format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2

DCCP packet header using short sequence and acknowledgement numbers.

3.3

a) DCCP-Request packet structure b) DCCP-Response packet structure . . 39

3.4

DCCP-Reset packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.5

DCCP state diagram redrawn from [124]. . . . . . . . . . . . . . . . . . . . 42

3.6

Typical connection establishment. . . . . . . . . . . . . . . . . . . . . . . . 43

3.7

Typical connection release. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.8

Connection release by client. . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.9

Connection release by server on active close. . . . . . . . . . . . . . . . . . 45

5.1

The chatter behaviour a) when the client in TIMEWAIT unsuccessfully

37

attempts resetting the connection; b) when the client in TIMEWAIT successfully resets the connection. . . . . . . . . . . . . . . . . . . . . . . . . . 66 viii

6.1

DCCP connection management finite state machine from [126] . . . . . . . 75

6.2

Typical message sequence for DCCP connection a) setup b) close down . . 77

6.3

Two alternative message sequences for DCCP connection close down . . . . 77

6.4

a) Hierarchy page b) Global Declarations . . . . . . . . . . . . . . . . . . . 79

6.5

The first level page (DCCP page) . . . . . . . . . . . . . . . . . . . . . . . 79

6.6

a) The DCCP CM page b) The Request page . . . . . . . . . . . . . . . . 81

6.7

Message sequence a) One scenario of class 3 b) class 4 . . . . . . . . . . . . 83

7.1

DCCP Packet Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.2

DCCP State Diagram [120]. . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.3

Typical Connection Establishment and Release Scenarios. . . . . . . . . . . 91

7.4

Alternative Close Down Procedures. . . . . . . . . . . . . . . . . . . . . . . 92

7.5

Hierarchy Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.6

The DCCP Overview Page. . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.7

Definition of DCCP PACKETS. . . . . . . . . . . . . . . . . . . . . . . . . 97

7.8

DCCP’s Control Block and User Commands. . . . . . . . . . . . . . . . . . 98

7.9

The Sync Rcv Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.10 Functions used in the Sync Rcv Page. . . . . . . . . . . . . . . . . . . . . . 100 7.11 Repeatedly Exchanged Messages for Case I with ISS=2. . . . . . . . . . . . 103 8.1

Typical Connection Establishment and Release Scenarios. . . . . . . . . . . 108

8.2

Repeatedly Exchanged Messages when ISS=2. . . . . . . . . . . . . . . . . 109

9.1

DCCP packet format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

9.2

DCCP state diagram [124]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

9.3

Typical connection establishment and release scenarios. . . . . . . . . . . . 117

9.4

The DCCP hierarchy page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

9.5

The DCCP overview Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9.6

DCCP CM page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9.7

Definition of DCCP PACKETS. . . . . . . . . . . . . . . . . . . . . . . . . 124

9.8

DCCP’s control block and user commands. . . . . . . . . . . . . . . . . . . 124

9.9

The IdleState Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

9.10 Two Scenarios when ISS = 248 − 76 a) no retransmission in PARTOPEN b) one retransmission in PARTOPEN. . . . . . . . . . . . . . . . . . . . . 129 9.11 Comparing the same scenarios when a) ISS = 0 b) ISS = 1. . . . . . . . . 131

ix

9.12 A scenario when ISS = 248 − 79. . . . . . . . . . . . . . . . . . . . . . . . . 132 9.13 The difference between two state spaces when ISS = 248 − 8 and ISS = 248 − 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 10.1 (a) DCCP state diagram redrawn from [124] (b) DCCP packet format. . . 141 10.2 Typical connection establishment and release scenarios. . . . . . . . . . . . 142 10.3 The top level page from [206]. . . . . . . . . . . . . . . . . . . . . . . . . . 145 10.4 (a) The hierarchy page from [206] (b) The second level page from [206]. . . 145 10.5 The hierarchy page from [128]. . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.6 The hierarchy page from [212]. . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.7 The hierarchy page of the final DCCP-CM CPN model. . . . . . . . . . . . 148 10.8 Definition of DCCP’s Control Block and PACKETS from [206]. . . . . . . 150 10.9 Definition of PACKETS from [128]. . . . . . . . . . . . . . . . . . . . . . . 150 10.10Definition of PACKETS from [212].

. . . . . . . . . . . . . . . . . . . . . 151

10.11Definition of DCCP PACKETS in the final CPN model. . . . . . . . . . . 152 10.12DCCP’s control block and user commands in the final model. . . . . . . . . 153 10.13The DCCP CM page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 10.14The CLOSED page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 10.15The LISTEN page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 10.16The TIMEWAIT page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10.17The IdleState page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10.18The RcvReset page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 10.19The Retransmission page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 11.1 DCCP state diagram redrawn from [124]. . . . . . . . . . . . . . . . . . . . 168 11.2 Typical connection establishment and release scenarios. . . . . . . . . . . . 168 11.3 Alternative close down procedures. . . . . . . . . . . . . . . . . . . . . . . 169 11.4 The DCCP hierarchy page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 11.5 The DCCP overview page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 11.6 DCCP CM page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 11.7 CommonProcessing page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 11.8 Definition of DCCP PACKETS. . . . . . . . . . . . . . . . . . . . . . . . . 175 11.9 DCCP’s control block and user commands. . . . . . . . . . . . . . . . . . . 177 11.10The UserCommands page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 11.11The IdleState page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 x

11.12The RcvInvalid page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 11.13The Request page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 11.14The Respond page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 11.15Function SyncSnd sending a Sync packet. . . . . . . . . . . . . . . . . . . . 181 11.16The PartOpen page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 11.17The DataTransfer page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 11.18The ClosingDown page.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

11.19The RcvSync page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 11.20The RcvReset page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 11.21The Retransmission page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 11.22Declaration for the Retransmission page. . . . . . . . . . . . . . . . . . . . 185 11.23The Unexpected page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 11.24Modified DCCP’s control block. . . . . . . . . . . . . . . . . . . . . . . . . 194 11.25Augmented model: the top level page. . . . . . . . . . . . . . . . . . . . . 195 A.1 Snapshots of sweep-line reachability graph exploration. . . . . . . . . . . . 253 A.2 The Generalised Sweep-line Algorithm, based on the algorithm from [137]. 254 A.3 Sweep-line unrolled RG for the example in Fig. A.1. . . . . . . . . . . . . . 255 A.4 (a) A simple Safety Property concerning sequences of Send and Receive events. (b) A simple Communication Protocol whose actions have been abstracted to the safety property actions. (c) A simple but erroneous Communication Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 A.5 Obtaining DF SASa from DF SASa. . . . . . . . . . . . . . . . . . . . . . . 263 A.6 The parallel composition of F SASys and DF SASa . . . . . . . . . . . . . . 263 A.7 The parallel composition of F SASysErr and DF SASa . . . . . . . . . . . . . 264 A.8 The Generalised Sweep-line Algorithm augmented for On-the-fly Safety Property Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 A.9 The DCCP Hierarchy Page. . . . . . . . . . . . . . . . . . . . . . . . . . . 272 A.10 The DCCP Overview Page. . . . . . . . . . . . . . . . . . . . . . . . . . . 273 A.11 DCCP CM page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 A.12 Definition of DCCP PACKETS. . . . . . . . . . . . . . . . . . . . . . . . . 274 A.13 DCCP’s control block and user commands. . . . . . . . . . . . . . . . . . . 275 A.14 The Request page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 A.15 DCCP’s Connection Management Service Language. . . . . . . . . . . . . . 278

xi

B.1 Hierarchy page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 B.2 The top level page: DCCP CM Service. . . . . . . . . . . . . . . . . . . . . 287 B.3 Declaration of DCCP service CPN model. . . . . . . . . . . . . . . . . . . 287 B.4 The Connection Open page. . . . . . . . . . . . . . . . . . . . . . . . . . . 287 B.5 The Provider Abort page. . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 B.6 The User Abort page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

xii

List of Tables 2.1

State space results for the two CPN models (FIFO channel). . . . . . . . . 24

2.2

State space results for the two CPN models (reordering channel). . . . . . 25

3.1

DCCP Packet Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2

Reset Code from [124]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3

Validity condition for sequence and acknowledgement numbers from [124]. . 47

3.4

Summary of timer values in the associated states. . . . . . . . . . . . . . . 48

4.1

Previous work on modelling and analysis of the OSI Transport Protocol . . 53

4.2

Comparison among PhD Thesis by CSEC students. . . . . . . . . . . . . . 55

4.3

Differences between TCP and DCCP. . . . . . . . . . . . . . . . . . . . . . 59

6.1

Terminal States for DCCP Connection Establishment . . . . . . . . . . . . 82

7.1

Validity Condition for Sequence and Acknowledgement Numbers. . . . . . 93

7.2

Initial Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.3

State Space Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.4

Growth of the State Space as a Function of ISS. . . . . . . . . . . . . . . . 102

9.1

Validity condition for sequence and acknowledgement numbers. . . . . . . . 119

9.2

State space size and terminal markings of connection establishment when varying ISS (W=AW=100). . . . . . . . . . . . . . . . . . . . . . . . . . . 127

11.1 An ordering and corresponding mapping for DCCP state. . . . . . . . . . . 188 11.2 Initial configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 11.3 Sweep-line analysis results of DCCP connection management. . . . . . . . 197 11.4 Terminal markings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 A.1 DCCP Service Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 A.2 Configurations of the DCCP Connection Management CPN model. . . . . 279

xiii

A.3 Conventional RG Generation Results. . . . . . . . . . . . . . . . . . . . . . 280 A.4 Conventional and Sweep-line results for On-The-Fly Language Inclusion Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 D.1 Initial configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 D.2 Sweep-line analysis results of DCCP connection management: FIFO channels with no loss (part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 D.3 Sweep-line analysis results of DCCP connection management: FIFO channels with no loss (part 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 D.4 Sweep-line analysis results of DCCP connection management: FIFO channels with loss (part 1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 D.5 Sweep-line analysis results of DCCP connection management: FIFO channels with loss (part 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 D.6 Sweep-line analysis results of DCCP connection management: reordering channels with no loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 D.7 Sweep-line analysis results of DCCP connection management: reordering channels with loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 E.1 Revised Results of Table 9.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 300 E.2 Analysis results when using both short and long sequence numbers (part 1).301 E.3 Analysis results when using both short and long sequence numbers (part 2).302

xiv

Acronyms ARA

Advanced Reachability Analysis

AW

Acknowledgement Number Validity Window Width

AWH

Acknowledgement Number Window High

AWL

Acknowledgement Number Window Low

CES

Capability Exchange Signalling Protocol

CM

Connection Management

CPN

Coloured Petri Net

CPN ML

Coloured Petri Net Meta Language

CSEC

Computer Systems Engineering Centre

DCCP

Datagram Congestion Control Protocol

DCCP-

Datagram Congestion Control Protocol’s Connection

CM

Management Procedures

DTR

Data Transfer Ready

ECMA

European Computer Manufacturer Association

Estelle

Extended State-Transition Language

FIFO

First-In-First-Out

FN

Feature Negotiation

FSA

Finite State Automaton

FSM

Finite State Machine

FTAM

OSI File Transfer, Access and Management

GAR

Greatest Acknowledgement Number Received

GSR

Greatest Sequence Number Received

GSS

Greatest Sequence Number Sent

ICP

Incoming Connection Pending

IESG

Internet Engineering Steering Group continued on next page

xv

IETF

Internet Engineering Task Force

IOTP

Internet Open Trading Protocol

ISO

International Organization for Standardization

ISR

Initial Sequence Number Received

ISS

Initial Sequence Number Sent

ITU

International Telecommunication Union

ITU-T

The Telecommunication Standardization Sector of ITU

LOTOS

Language Of Temporal Ordering Specifications

LTS

Labelled Transition System

LTSA

Labelled Transition System Analyser

ML

Meta Language

NPN

Numerical Petri Net

OCP

Outgoing Connection Pending

ODP

Open Distributed Processing

OG

Occurrence Graph

OGIVE

Outil graphique interactif de v érification

OSI

Open Systems Interconnection

PROTEAN PROTocol Emulation and Analysis RG

Reachabilty Graph

RSVP

Resource Reservation Protocol

RTP

Real-time Transport Protocol

RTT

Round Trip Time

SCC

Strongly Connected Component

SCG

Strongly Connected Graph

SCTP

Stream Control Transmission Protocol

SDL

Specification and Description Language

SML

Standard Meta Language

SWH

Sequence Number Window High

SWL

Sequence Number Window Low

TCB

Transmission Control Block continued on next page

xvi

TCP

Transmission Control Protocol

TRL

Telecom Australia Research Laboratories

UDP

User Datagram Protocol

W

Sequence Number Validity Window Width

WTP

Wireless Transaction Protocol

xvii

Summary Designing a new protocol has never been an easy task. Despite four decades of accumulated experience with protocol design, without formal methods it is difficult to design and specify a new protocol without any errors. Using a formal technique called Coloured Petri Nets (CPNs), this thesis investigates the connection management procedures of a new Internet transport protocol, the Datagram Congestion Control Protocol (DCCP), published as Request for Comments (RFC) 4340 by the Internet Engineering Task Force (IETF) in March 2006. This thesis follows the development of this Internet Standard since Internet Draft version 5. A Coloured Petri Net software package called Design/CPN has been used to construct, maintain and analyse a CPN model of DCCP’s connection management procedures. We iteratively refine the CPN model to incorporate DCCP’s detailed procedures including synchronisation. The research presented in this thesis has been published in 7 peer reviewed articles in international journals and conferences. These articles form the basis of the thesis. The development of the models and their analysis has revealed several subtle problems. Our early analysis results indicate that when DCCP version 5 or 6 operates over a reordering channel without loss, DCCP’s connection establishment procedures can fail resulting in deadlocks where the client is CLOSED but the server is OPEN. Although IETF succeeded in removing these deadlocks by modifying the procedures, the changes introduced a serious problem called “chatter”. Chatter comprises undesired (and possibly very long) exchanges of messages where no progress is made until finally the system corrects itself. Chatter creates unnecessary traffic which adversely affects congestion in the Internet, precisely the opposite intention of DCCP. In this case we show that if the problem occurred, then the probability of over 2 billion messages being needlessly exchanged was greater than .99999. This problem was reported to IETF in September 2005 and was corrected and re-analysed within 24 hours. A number of other problems were also reported to IETF in time for them to be rectified and the solutions incorporated before the final Internet Standard, RFC 4340, was published in March 2006. In April 2006 our further analysis of RFC 4340 shows that for a certain range of initial sequence numbers (when sequence numbers wrap), DCCP can fail to establish a connection, resulting in deadlock where the client is CLOSED but the server is OPEN. These deadlocks can be removed if the application on the server issues a close command. xviii

The state explosion problem encountered in brute force reachability analysis limits the analysis of DCCP to only one retransmission. We therefore decided to use the sweepline method to verify both general and specific properties of the protocol, in an attempt to extend the results to more than one retransmission. In order to use the sweep-line method efficiently, we derive monotonic progress measures so that only one sweep of the state space is required. This thesis shows that the performance of the sweep-line method can be significantly improved by introducing into the model new variables to track progress. When the sweep-line technique has previously been applied to industrial models, the reduction in the number of states stored (compared with the full state space) has never been greater than a factor of 10. Our results show that the proposed method can achieve a reduction of a factor of 270 and importantly the larger the state space, the more efficient the sweep-line technique is when using the new progress measure for DCCP. This thesis finally verifies DCCP by comparing the service language and protocol language on-the-fly using the sweep line method. Analysis results show that the protocol language is a subset of the service language which means we did not find any illegal protocol sequences.

xix

General Declaration In accordance with the Academic Regulations for Higher Degrees by Research of the University of South Australia, the following declarations are made:

I hereby declare that this thesis contains no material which has been accepted for the award of any other degree or diploma at any university or equivalent institution and that, to the best of my knowledge and belief, this thesis contains no material previously published or written by another person, except where due reference is made in the text of the thesis; all substantive contributions by others to the work presented, including jointly authored publication, is clearly stated.

This thesis comprises seven peer reviewed articles: three published international journal papers; one accepted international journal paper; and three published international conference papers. The core theme of the thesis is to formally model and analyse the Datagram Congestion Control Protocol’s connection management procedures. The ideas, development and writing up of six papers (chapters 6 - 11) and sections A.5.2-A.5.5 of Appendix A in the thesis were the principal responsibility of myself, the candidate working within the Computer Systems Engineering Centre, School of Electrical and Information Engineering under the supervision of Professor Jonathan Billington.

The inclusion of co-authors reflects the fact that the work came from active collaboration between researchers and acknowledges input into team-based research. The contributions of each author to the work are listed at the front of each chapter.

xx

The following are the publications included in this thesis:

Thesis Chapter

Publication title

Journal or

Publication

Conference

Status

Paper 6

Initial Result of a Formal Analysis of

Conference

Published

Journal

Published

Journal

Published

Conference

Published

Conference

Published

Journal

In Press

Journal

Published

DCCP Connection Management [206] 7

Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol [212]

8

Chattering Behaviour in the Datagram Congestion Control Protocol [208]

9

Effect of Sequence Number Wrap on DCCP Connection Establishment [207]

10

Modelling the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures [209]

11

Analysis of the Datagram Congestion Control Protocol’s Connection Management Procedures using the Sweep-line Method [211]

Appendix A

Checking Safety Properties On-the-fly with the Sweep-line Method [70]

Candidate’s Signature

Date

xxi

Acknowledgements My foremost thanks go to the institutions that financially supported my study. Without their generosity, this thesis would not have been possible. I am grateful to the University of South Australia for supporting me with a University President Scholarship (UPS) and a Division of Information Technology, Engineering and Environment Small Grant. I am thankful for the living allowances provided by the Australian Research Council and the Suranaree University of Technology during my study. I also wish to thank the Computer Systems Engineering Centre and the School of Electrical and Information Engineering for financially supporting my travel and attendance at several international conferences. The first person I wish to express my deepest gratitude to is my supervisor, Professor Jonathan Billington. I very much appreciate his kindness, patience, encouragement, devotion, guidance, suggestions and invaluable comments during the time I work on this thesis. He tirelessly teaches me so many things about research and academic life. He always shows us the highest quality of researchers with endless enthusiasm, thoroughness and dedication. His advice always amazes me lighting up my sights and blowing away my doubt. The above mentioned scholarships and grants could not be attained without his assistance thus I am very indebted indeed to him for providing me with those opportunities. It has been a great pleasure for me working at the School of Electrical and Information Engineering in the University of South Australia. They are the most dedicated and generous people. I wish to thank all staff members for their support and friendship. My loneliness during the time when I was far away from home disappeared because of my friendship with all members of CSEC. My special thanks go to Dr. Guy Gallasch who has never given up answering questions and helping others. Many thanks go to Dr. Lin Liu, Dr. Chun Ouyang, Tul Kongprakaiwoot, Cong Yuan, Dr. Jörn Freiheit and Dr. Nimrod Lilith for their companionship and support during my PhD journey. Despite sickness and being far away from my wife, living in Adelaide was one of the most memorable and peaceful periods in my life. Finally I am grateful to my wife for all her unconditional love and understanding. Without her sacrifice, I would not be able to finish this work. Time and distance never separate us.

xxii

Part I Overview

1

Chapter 1 Introduction 1.1

Background

The Transmission Control Protocol (TCP) [179] is currently used for transferring the majority of data over the Internet. However, TCP is not well suited to streaming media and Internet telephony applications. These applications, such as video on demand, teleconferencing, Voice over the Internet Protocol (VoIP) and on-line games [59, 114], are sensitive to delay and prefer timeliness over reliability. TCP can introduce an uncontrollable delay because of two main reasons [152]. Firstly, TCP retransmits packets until every packet is correctly received. Unfortunately, the delay introduced by retransmission may result in packets arriving at a time when they are no longer needed. Secondly, TCP’s congestion control algorithm assumes that loss of packets is due to congestion rather than transmission errors. When a packet is corrupted, the sender should keep transmitting at the same rate, but TCP’s congestion control algorithm reduces the sending rate leading to inefficiency and further packet delay. To solve this problem, many researchers have attempted to improve TCP [9,22] or have proposed new transport protocols such as the Real-time Transport Protocol (RTP) [187] and Stream Control Transmission Protocol (SCTP) [180]. Another simpler and tempting choice is to use the User Datagram Protocol (UDP) [176]. This is because UDP does not include retransmissions for transmission error recovery nor mechanisms for flow control and congestion control. Consequently we have seen a rapid increase of long-lived traffic using UDP in the Internet. Because there is no congestion control provided by UDP, some applications implement their own congestion control mechanisms often causing fairness problems when contending for the bandwidth with other TCP traffic. The growth of delay sensitive applications over UDP imposes a serious threat of congestion collapse on the Internet [59]. 2

Recently, the Internet Engineering Task Force1 (IETF) has published a set of standards for a new transport protocol, the Datagram Congestion Control Protocol (DCCP) [114] comprising Request for Comments (RFCs) 4336 [60]; 4340 [124]; 4341 [61] and 4342 [62]. RFC4336 discusses problems and disadvantages of existing transport protocols and the motivation for designing a new transport protocol for unreliable datagrams. RFC4340 specifies reliable connection management procedures; synchronisation procedures; reliable negotiation of features/options; acknowledgement and optional mechanisms used by congestion control procedures. As suggested by its name, DCCP has been designed to access different congestion control mechanisms suited to different applications. RFC4340 also provides an extension for modular congestion control, called “Congestion Control Identification” (CCID) but the congestion control mechanisms themselves are specified in other RFCs. Currently there are two published standards, RFC 4341, CCID2: TCP-like congestion control [61] and RFC 4342, CCID3: TCP-Friendly Rate Control [62] but more mechanisms are being developed for the standard.

1.2

Problem statement

Protocol design is difficult partly because of its inherent concurrency and non-deterministic behaviour. The experience of many other researchers [24,50,188,189,193,194] shows that a more formal and rigorous design methodology is required to gain more confidence that protocols behave correctly. Thus many formal methods and tools emerged during the last three decades to assist protocol designers. For example SDL (Specification and Description Language) [53,97,98] was adopted by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). LOTOS (Language of Temporal Ordering Specification) [25, 200] and Estelle [56, 93, 198] were adopted by the International Organization for Standardization (ISO). Recently, ISO has published a standard on High-level Petri Nets [95], that uses a Coloured Petri Nets semantic model. Unlike protocols developed by ITU-T or ISO, the DCCP definition, RFC 4340, provides an informal description comprising narrative, incomplete state diagrams and pseudo code for the connection management and feature negotiation procedures. Without formal specification and verification, it is highly likely that DCCP is prone to errors and misinterpretation. If the errors and ambiguities are discovered after it is widely deployed on 1

An open international community that develops and promotes Internet standards, in particular with

standards of the TCP/IP and Internet protocol suite.

3

the Internet, it will be difficult to rectify the problems and the cost of fixing the errors can be high. Thus it is important to formally verify the functional behaviour of the protocol. DCCP connection management is the first procedure that needs to be investigated since all other DCCP mechanisms depend upon its functional correctness.

1.3

Research Objectives

The primary goal of this thesis is to analyse DCCP’s connection management procedures (DCCP-CM) to ensure the correctness of DCCP. To achieve this goal we identify the following research objectives. 1. To develop a Coloured Petri Net (CPN) model of DCCP’s connection management and synchronisation procedures. 2. To validate this model against the DCCP Definition, to ensure it is a faithful representation of DCCP’s procedures. 3. To analyse the model using state space techniques using the methodology of [14,21], which includes the use of the sweep-line technique [37, 137, 155]. 4. To track the development of DCCP, consistently updating the model as new versions of DCCP are released. 5. To input our analysis results to IETF. 6. To quickly disseminate the results by publication.

1.4

Scope

Due to the complexity of DCCP, this thesis limits the scope of its investigation to DCCP’s connection management and synchronisation procedures. To meet the limits on the size of this thesis, a lengthy discussion of protocol verification, language analysis and the sweep-line analysis are omitted. Introductions to protocol engineering methodology and language analysis can be found in [14,78,81,146,169]. Introduction to sweep-line analysis can be found in [37, 70–72, 137, 155].

1.5

Organization of the thesis

This thesis comprises two parts and appendices.

4

Part I provides introductory material and an overview for the papers presented in Part II. In addition to this introductory chapter, Part I includes the following four chapters. Chapter 2 (Formal Methods and Coloured Petri Nets) presents an informal introduction to formal methods and Coloured Petri Nets together with relevant analysis techniques. Chapter 3 (Definition of DCCP Connection Management) reviews the DCCP specification defined in RFC 4340. It places emphasis on DCCP’s connection management and synchronisation procedures. Chapter 4 (Related Work ) summarizes previous research related to the modelling and analysis of DCCP connection management. Chapter 5 (Summary of DCCP’s Verification) aims to provide an overall picture of all papers included in Part II. Part II comprises six publications and conclusions. All references in each paper have been removed from the original paper and consolidated in the reference list of this thesis. Chapter 6 (Initial Result of a Formal Analysis of DCCP Connection Management) [206]. Chapter 7 (Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol ) [212]. Chapter 8 (Chattering Behaviour in the Datagram Congestion Control Protocol ) [208]. Chapter 9 (Effect of Sequence Number Wrap on DCCP Connection Establishment) [207]. Chapter 10 (Modelling the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures) [209]. Chapter 11 (Analysis of the Datagram Congestion Control Protocol’s Connection Management Procedures using the Sweep-line Method ) [211]. Chapter 12 (Conclusion and Future Work ) summarizes the contributions of the thesis and suggests directions for future research.

This thesis also contains seven appendices as follows. Appendix A (Checking Safety Properties On-the-fly with the Sweep-line Method ) [70]. Appendix B (DCCP Service CPN Model ) contains CPN diagrams of DCCP service model and global declarations. Appendix C (CPN State Space to FSA) contains ML codes for mapping binding elements in the OGs of DCCP service and protocol models into the numbers representing DCCP service primitives. Appendix D (Analysis Results) contains four cases of the analysis results when DCCP

5

connection management procedures operate over four different kinds of channels. Appendix E (Additional Results relating to Chapter 9 ) provides alternative analysis results to the one presented in Chapter 9 and the results when short sequence numbers are also allowed.

1.6

Reading guide

To understand Part I (Overview) of this thesis, knowledge about Coloured Petri Nets, the ML functional programming language, formal protocol verification and DCCP is not required. However, before reading Part II, readers without knowledge of Coloured Petri Nets are suggested to read “The Practitioner’s Guide to Coloured Petri Nets” [132] or “Coloured Petri Nets and CPN Tools for Modelling and Validation of Concurrent Systems” [108]. This thesis focusses on the application of Coloured Petri Nets to investigate the behaviour of DCCP connection management. Thus knowledge regarding the formal definition of Coloured Petri Nets and the Sweep-line method is not required. Even though the papers have been arranged in the order according to the development of the CPN model, readers with basic knowledge of CPNs can read the papers in any order.

6

Chapter 2 Formal Methods and Coloured Petri Nets Formal methods [26–28, 43, 80] are techniques based on mathematically defined syntax and semantics for the specification, development and verification of software and hardware systems. Formal specification are based on mathematics so that ambiguities in the informal specification are removed. Formal verification [159, 194] is the act of proving or disproving the correctness of the system against a certain formal specification using mathematics. Using formal methods, errors and incompleteness can be discovered early saving the cost of their rectification in a later phase of development. Many different formal methods exist [2, 38, 43] or are being developed based on a wide variety of mathematical formalisms. Each method has their own strengths and weaknesses. Some of them [2, 38, 43] are well-known to be suitable for modelling and analysing concurrent and non-deterministic systems. In the area of protocol engineering a wide range of different formal methods have been employed to specify and verify protocols. These include: Petri Nets [12, 14, 44, 107, 108, 132], Process Algebra [7, 38, 85, 164, 165], the Specification and Description Language (SDL) [53, 97, 98, 200], Z specification Language [144, 191], Estelle [56, 93, 198], Language of Temporal Ordering Specification (LOTOS) [52, 94, 200]. Comparison of strengths and weaknesses among them is beyond the scope of this thesis. Interested readers are referred to [2] for a comparison of various formal methods in protocol engineering. We use Coloured Petri Nets (CPNs) [105, 108, 132], an extension of Petri Nets, to formally model and analyse DCCP connection management and its synchronisation procedures. This chapter provides an informal introduction to Coloured Petri Nets and relevant analysis methods. Section 2.1 introduces Petri Nets. Section 2.2 discusses rea7

sons we choose to use Coloured Petri Nets. Section 2.3 informally introduces Coloured Petri Nets using simple examples. Section 2.4 discusses model simulation. Section 2.5 discusses the analysis of CPN models. Section 2.6 introduces related analysis techniques comprising the Sweep-line method and language analysis.

2.1

Petri Nets

Carl Adam Petri was one of the first researchers to present a theory of concurrency in his PhD Dissertation, “Kommunikation mit Automaten” [175] in 1962. Petri’s “communication with automata” became known as Petri Nets. Since then, various kinds of Petri Nets have emerged with enhanced features. These include Predicate Transition Nets [74], Algebraic Petri Nets [111], Fuzzy Petri Nets [34, 151], Possibilistic Petri Nets [32, 142], Stochastic Petri Nets [84, 157, 181], Coloured Petri Nets [105–107], Reference Nets [127] and Hybrid Petri Nets [48]. They have been successfully applied to a wide range of applications [12,48,107,181]. Their success is due to an easy-to-understand graphical representation and their well founded mathematic theory. Even now, forty-five years later, the attempt to develop new kinds of Petri Nets continues, for example Algebraic HigherOrder Nets [86] and Petri Nets Without Tokens [158]. A discussion of various kinds of Petri Net variants is beyond the scope of this thesis. For introductory publications readers are referred to [167, 174, 175, 182, 183].

2.2

Choosing Coloured Petri Nets

Kurt Jensen at Aarhus University defined Coloured Petri Nets (CPNs) [103, 105–107]. Since then they have been widely used to model and analyse a variety of applications including communication protocols [12, 14, 57, 107, 133, 134]. In this thesis we choose to use Coloured Petri Nets (CPNs) to model DCCP connection management for the following reasons. 1. Easy-to-understand and user friendly An important advantage of CPNs is its graphical notation with hierarchical structuring facilities and the inclusion of a rich set of data types providing a high level of user friendliness. This helps to facilitate model development. Hence using CPNs we can focus on refining the model and understanding how the protocol behaves. 2. Explicitly support both state based and event processing models

8

A protocol description often includes either a state table or a state diagram. The states of protocol entities can be represented directly using places in Petri Nets. Sometimes protocol specifications such as TCP and DCCP informally describe the protocol action in terms of event-processing. CPNs can explicitly capture events or actions of the protocol procedures using transitions. 3. Support for analysis To prove the correctness of protocol procedures, the Petri Net community has accumulated a vast knowledge of analysis techniques [183]. We choose to use state space analysis because exploring every possible state can reveal scenarios that cannot be discovered easily using intuition or simulations. 4. Already successfully applied to protocol verification CPNs has been widely applied to specify and verify protocols [12,14,57,107]. They have been used to verify industrial scale protocols such as the Wireless Application Protocol (WAP) [78], RSVP [214], the Internet Open Trading Protocol (IOTP) [169], Capability Exchange Signalling Protocol (CES) [146, 147], an edge router discovery protocol for mobile ad-hoc networks [133] and TCP [16,81]. Due to some similarity with DCCP, the CPN model of TCP [16, 81] provides us with an important example. 5. Industrial-strength supporting tools We use Design/CPN, a software tool developed by Meta Software Corporation in collaboration with the CPN group at Aarhus University. Design/CPN is an integrated software tool used for creating, editing, simulating, debugging and analysing CPN models. It includes CPN ML [46] which is a variant of Standard ML [166, 171, 192, 201]. CPN ML is used to declare (complex) data types, define functions and type variables. It allows us to manipulate complex data in the net inscriptions. CPN ML plays a significant role in modelling and analysing DCCP behaviour in this thesis. A successor of Design/CPN, CPN Tools [47, 108] being developed at Aarhus University also uses CPN ML. In 2003 the first model of DCCP connection management was actually created on CPN Tools (beta version). However during that time the software was unreliable and lacked many supporting facilities. Since then CPN Tools gradually became stable, reliable and integrated with a lot of supporting facilities. People are encouraged to use CPN Tools rather than Design/CPN. However this thesis still uses Design/CPN for two reasons. Firstly, CPN Tools does not include the colour set, Infinite Integer, which is used to model 48-bit sequence numbers. Secondly, it does not include the Sweep-line library.

9

2.3

Informal Introduction to CPNs

In this section, we use a simple example to informally introduce CPNs and their relevant analysis techniques. The formal treatment of CPNs can be found in [103, 105–107, 146].

2.3.1

The Running Example: Combined CPN Model of a FIFO/Reordering Channel

Protocol entities communicate via a communication medium known as a channel. Channel characteristics are an important consideration in protocol design. We can classify a channel according to four types: FIFO (First in First Out) without loss, reordering without loss, FIFO with loss and reordering with loss. According to the incremental approach proposed in [14], we need to progressively model and analyse the protocol when operating over each type of channel. This is important because loss or reordering could mask out errors or undesired states. Previous work With respect to the assumptions made about channel characteristics, Gordon [78] considers only reordering without loss for two reasons. Firstly because of the nature of the medium over which the Wireless Transaction protocol (WTP) operates, overtaking can occur. Secondly, loss makes the state space too complex. In contrast with Gordon’s work, Ouyang [169] and Liu [146] consider FIFO channels without loss because Internet Open Trading Protocol (IOTP) and Capability Exchange Signalling Protocol (CES) are expected to operate over the transport layer such as TCP which provides reliable delivery of messages without loss, duplication or reordering. However Liu [146] also investigates the case of the CES service over a lossy FIFO channel. Meanwhile Han [81] models and analyses TCP connection management only when operating over a reordering channel with loss and without loss. She does not consider the FIFO case. Difficulty While the difference between CPN models of lossless and lossy channels is rather simple, the CPN structure for reordering and FIFO channels is quite different. Hence during the process of transport protocol development normally one would need to construct and maintain two models: reordering and FIFO. Unfortunately protocol development is a time consuming and iterative process. Maintaining two models instead of one doubles the 10

amount of time required to update the model and can give rise to differences between the two models. A proposed solution All previous work mentioned above assumed that the channel was either reordering or FIFO and did not consider both. We propose to combine two channel models: FIFO and reordering, into a single union net structure for ease of model maintenance. We use this example to informally introduce Coloured Petri Nets with three simple models: a reordering channel; a FIFO channel ; and combined FIFO/reordering channel.

2.3.2

Net Structures for a Reordering Channel

Coloured Petri Nets (CPNs) are represented by an annotated directed bipartite graph comprising places (ellipses), transitions (rectangles) and arcs (arrows). CPNs use the programming language Standard ML to specify net inscriptions. Figure 2.1 illustrates a CPN model of a sender transmitting messages to a receiver via a reordering channel with global declarations in the middle of figure. The model comprises three places and two transitions. ["a", "place","has","a","name"] TXbuf LIST_PKT pkt::usr_buf

[]

(* Global Declarations *) color PKT = string; var pkt:PKT; color LIST_PKT = list PKT; var usr_buf:LIST_PKT;

RXbuf LIST_PKT

usr_buf Send

usr_buf pkt

Ch_S_R

pkt

usr_buf^^[pkt]

Receive

PKT

Figure 2.1: A CPN model of a reordering channel with the initial marking.

Places Each place has a name, a type (called a colour set) and a marking associated with it. A place’s name is written inside the ellipse. Figure 2.1 depicts three places: RXbuf, Ch S R and TXbuf. A place is typed by a colour set which is written below the ellipse. Places TXbuf (transmit buffer) and RXbuf (receive buffer) are typed by a colour set LIST PKT

11

which is a list of strings. The channel is represented by a place named Ch S R typed by PKT which is a string. These colour sets are defined in the global declarations. Markings Each place contains a collection of tokens known as the marking of the place. A token is a value taken from the place’s colour set. Written above a places, the initial marking is the collection of tokens that is initially in the place. When nothing is above a place, it means that the place (i.e. Ch S R) is initially empty and does not contain any token. The current marking is in a box adjacent to a small circle. The number in the small circle indicates the total number of tokens in the place. When no current marking appears next to a place, it means that the place is currently empty. A collection of all markings of individual places is called a marking of the CPN which represents a state of the system. Similarly, the collection of all initial markings of places is called the initial marking of the CPN which represents the initial state of the system. The initial marking of place TXbuf is an outgoing message represented by a list of strings, [“a”, “place”, “has”, “a”, “name”] where [ ] is used to delimit a list. The channel place is initially empty while place RXbuf contains [], an empty list, indicating that no message is stored. Transitions Each transition has a name and sometimes has a guard associated with it. Figure 2.1 shows two transitions named Receive and Send. A guard is a boolean expression enclosed by a pair of square brackets normally written above the transition. There is no guard in Fig. 2.1 but readers can see an example of a guard later in Fig. 2.4. Arcs Transitions and places are connected by directed arcs. An input arc connects a place to a transition. An output arc connects a transition to a place. An arc is annotated by an arc inscription which is an expression comprising constants, variables or function images. Variables are also defined and typed in the global declarations. For example in Fig. 2.1, the output arc from transition Send to place Ch S R is annotated with variable pkt typed by PKT representing a string. In addition to colour sets, variables are also defined in the global declarations. Arc inscriptions can be more complex expressions. For instance the input arc to transition Send is annotated with function image pkt::usr buf.

12

Bindings of Variables and Binding Elements Because variable pkt is the annotation of the arc associated with transition Send, pkt is also a variable associated with transition Send as is usr buf. An assignment of values to a set of variables associated with a transition is called a “binding”. A pair of a transition (t) and its binding (b), (t,b) is called a binding element of a CPN [105]. For example, a binding element of the CPN in Fig. 2.1 is (Send, ). The transition is Send, pkt is bound to “a” and usr buf is bound to [“place”, “has”, “a”, “name”]. Next we introduce the concept of transition enabling and firing (occurrence). Enabling A transition is enabled for a particular binding of its variables if both the following conditions are satisfied. 1. Each of its input places contains at least the tokens specified by the corresponding input arc inscription, when evaluated for the binding. 2. The guard expression of the transition evaluates to true. Absence of a guard corresponds to a guard which is always true. Firing After a transition becomes enabled, it may fire (occur). When a transition fires, it removes the tokens specified by the input arc inscriptions (evaluated for the binding in which it was enabled) from the input places and adds the tokens to the output places according to the evaluated expressions on the output arc. For example, in the initial marking of the CPN shown in Fig. 2.1 the only enabled transition is Send for the binding . When Send fires, two synchronous actions occur. Firstly, using the infix :: cons operator of Standard ML, it removes [“a”,“place”, “has”, “a”, “name”] from TXbuf and replaces it by [“place”, “has”, “a”, “name”]. Secondly, it deposits “a” into Ch S R. These two actions result in the sender transmitting “a” into the channel. After Send fires, the tokens “a” in Ch S R and [] (an empty list) in RXbuf enable transition Receive in the binding . If Receive fires, two synchronous actions occur. Firstly, it removes token “a” from Ch S R. Secondly it removes the token [] and puts []∧∧ [“a”] = [“a”] into RXbuf. The infix ∧∧ is the list append operator of Standard

13

ML. These two actions result in the receiver retrieving “a” from the channel and putting it into RXbuf. After transition Send fires twice from the initial marking, tokens “a” and “place” reside in Ch S R. Now there are two bindings, and , enabling transition Receive. Either binding can occur. If occurs, the message “place” has overtaken “a”. Thus this CPN model represents a reordering channel. Multi-sets Suppose transition Send fires four times from the initial marking. The markings of the CPN model after the fourth occurrence of Send are illustrated in Fig. 2.2. Tokens inside the channel place Ch S R are a multi-set. A multi-set is similar to a set but allows multiple appearances of any of its elements. ["a", "place","has","a","name"] 1 1‘["name"]

TXbuf

LIST_PKT pkt::usr_buf

RXbuf

pkt

Ch_S_R

1 1‘[] LIST_PKT

4 2‘"a"++ 1‘"has"++ 1‘"place"

usr_buf Send

[]

(* Global Declarations *) color PKT = string; var pkt:PKT; color LIST_PKT = list PKT; var usr_buf:LIST_PKT;

usr_buf pkt

usr_buf^^[pkt]

Receive

PKT

Figure 2.2: A CPN model of the reordering channel after transition Send has fired four times. Depicted in Fig. 2.2, there are four tokens in the channel place Ch S R: two “a” tokens, one “has” and one “place”. The double plus, “++”, represents multi-set addition, which provides a way to construct a multi-set. Concurrency and Conflict Considering the marking of the CPN in Fig. 2.2, the channel place Ch S R contains four tokens: two “a”, one “has” and one “place”. One [“name”] token resides in place TXbuf. Place RXbuf contains one [] token. In this marking, there are four different binding elements enabled as follows: BE1: (Receive, )

14

BE2: (Receive, )

BE3: (Receive, ) BE4: (Send, )

When there are enough tokens on the input places to simultaneously satisfy the demands of a set of binding elements without contention with other binding elements in the set, those binding elements in the set are “concurrently enabled ”. In Fig. 2.2, even though the variables associated with transitions Send and Receive are the same, the required tokens reside in different places. Thus the enabling of each transition does not require the same tokens. Transitions Send and Receive are concurrently enabled and can occur at the same time. To be more precise, the sets of concurrently enabled binding elements in the marking of Fig. 2.2 are: {BE1,BE4}; {BE2,BE4} and {BE3,BE4}. Because binding elements BE1, BE2 and BE3 are competing for the same token ([]) from RXbuf and only one of them can occur, we call these three binding elements in “conflict”. If there were four [] tokens on RXbuf, it would be possible for transition Receive to be concurrently enabled with itself using binding elements BE2; BE3 and using BE1 twice. The occurrence of concurrently enabled binding elements (e.g. BE1,BE4) in any arbitrary sequential order will result in the same marking. For example BE1 occurs either before or after BE4 will result in the same marking. Both concurrency and conflict properties are important to represent protocol behaviours. Illustrated in this section, the concurrently enabled binding elements represent the actions of the receiver and the sender that can occur concurrently. However due to the conflict property only one message can be received at a time.

2.3.3

CPN model of a FIFO channel

Figure 2.3 depicts a CPN model of a FIFO channel. The type of Ch S R is now a list of packets (LIST PKT ) instead of PKT with the initial marking [] (an empty list). A new variable, q, has been introduced. It is typed by LIST PKT and represents a FIFO queue in the channel. The transmission of a message into the FIFO queue is similar to when the Receiver puts a message into RXbuf. The receipt of a message from the FIFO queue is similar to when the Sender retrieves a message from TXbuf. We have already described those actions in section 2.3.2.

15

[]

["a", "place","has","a","name"] (* Global Declarations *) color PKT = string; var pkt:PKT; color LIST_PKT = list PKT; var usr_buf,q:LIST_PKT;

TXbuf LIST_PKT pkt::usr_buf

RXbuf LIST_PKT usr_buf

usr_buf

usr_buf^^[pkt]

[] q^^[pkt]

Send

Ch_S_R

pkt::q Receive q

q LIST_PKT

Figure 2.3: A CPN model of a FIFO channel.

2.3.4

Combined CPN Model of a FIFO/Reordering Channel

Figure 2.4 depicts a CPN model1 which combines the reordering and FIFO channels into one model. The channel can now operate as either a FIFO channel or a reordering channel depending on the value of a boolean constant parameter, FIFO, that is defined in the declarations with a val statement. val FIFO = true means that the channel will operate as a FIFO channel and val FIFO = false will cause the channel to be reordering.

["a","place","has","a","name"] TXbuf LIST_PKT pkt::usr_buf

1 1‘["a", "place", "has", "a", usr_buf "name" ]

(* Global Declarations *) val FIFO = false; color PKT = string; var pkt:PKT; color LIST_PKT = list PKT; var usr_buf,q:LIST_PKT; color PACKETS = union L:LIST_PKT + P:PKT; fun checkFIFO(a, []) = false | checkFIFO(a, la) = (a= hd(la)); fun enableFIFO(a, la) = if FIFO then checkFIFO(a,la) else true;

1‘L q Send if FIFO then 1‘L(q^^[pkt]) ++1‘P pkt else 1‘P pkt++1‘L []

1‘ L [] Ch_S_R

PACKETS 1 1‘L([])

if FIFO then 1‘L (tl(q)) else 1‘L []

1‘[] 1 1‘[]

RXbuf

LIST_PKT usr_buf

usr_buf^^[pkt]

Receive 1‘L q ++1‘P pkt

[enableFIFO(pkt,q)]

Figure 2.4: A CPN model combining the FIFO and reordering channels.

We use the data structure list (LIST PKT ), to represent a FIFO channel (Ch S R) in the CPN model of Fig. 2.3. On the other hand in the reordering channel model (Fig. 2.2) the tokens in Ch S R and arc inscription pkt are typed by PKT. As discussed in section 1

One of the examiners suggested that it might be possible to simplify this CPN model by using

singleton lists for packets, instead of multi-sets. This is a very promising approach that we shall follow up in future work.

16

2.3.2, in the CPN model of Fig. 2.2, only one of binding elements BE1, BE2 or BE3 can occur. Thus the message “a” can be overtaken by the occurrence of either BE2 or BE3. This represents a reordering channel. To be able to represent both situations the type of the channel place Ch S R is defined as a union of PKT and LIST PKT. We call the type of Ch S R, PACKETS (see the global declarations in the middle of Fig. 2.4). When forming the union of PKT and LIST PKT, ML distinguishes elements of type PKT or LIST PKT by a selector P or L. The initial marking of Ch S R is 1‘L[], which is an empty list, hence requiring the selector L. The arc inscriptions in the middle of Fig. 2.4 are different from the FIFO model in Fig. 2.3. There are if-then-else clauses on the two output arcs. These if-then-else clauses are used to select which output tokens are returned to Ch S R depending on the value of FIFO. Reordering Channel (FIFO is false) In the case of FIFO is false, q is always bound to []. We can think of 1‘L [] in Ch S R as a dummy token. Every time either transition fires, the dummy 1‘L[] is always removed and returned back in Ch S R. 1. From the initial marking in Fig. 2.4 the only enabled binding element is BE5: (Send, ) On the occurrence of BE5, there are two synchronous actions. Firstly [“a”,“place”,“has”, “a”,“name”] is removed from and [“place”,“has”,“a”,“name”] is returned to TXbuf. Secondly, 1‘L [] is removed from and 1‘L [] ++ 1‘P “a” is returned to Ch S R. Because q is always bound to [], the occurrence of Send results in a packet being transmitted into Ch S R. After the occurrence of BE5, we reach the markings shown in Fig. 2.5. 2. From the marking in Fig. 2.5 we have two concurrently enabled binding elements: BE6: (Send, ) BE7: (Receive, ) On the occurrence of BE7, there are two synchronous actions. Firstly, 1‘L[] ++ 1‘P “a” is removed from and only 1‘L [] is returned to Ch S R. Secondly, [] is removed from and [“a”] is returned to RXbuf. Because q is always bound to [], the occurrence of Receive results in taking “a” from the reordering channel. After the occurrence of BE7, the next marking is shown in Fig. 2.6.

17


1 1‘[ "place", "has", "a", usr_buf "name" ]


1‘ L []

1‘L q

Ch_S_R

Send if FIFO then 1‘L(q^^[pkt]) ++1‘P pkt else 1‘P pkt++1‘L []

PACKETS 2 1‘L([])++ 1‘P("a")


1‘[] 1 1‘[]

RXbuf

LIST_PKT usr_buf

usr_buf^^[pkt]


[enableFIFO(pkt,q)]

Figure 2.5: The marking after the occurrence of BE5 (FIFO is false).

["a","place","has","a","name"] 1 1‘[ TXbuf "place", "has", LIST_PKT "a", usr_buf "name" pkt::usr_buf ]



1‘ L [] Ch_S_R

PACKETS 1 1‘L([])


1‘[] 1 1‘["a"]

RXbuf

LIST_PKT usr_buf

usr_buf^^[pkt]


[enableFIFO(pkt,q)]

Figure 2.6: The marking after the occurrence of BE7 (FIFO is false). FIFO Channel (FIFO is true) In addition to the list-token used for the FIFO channel, because we can not use “if-thenelse” on the input arc inscription from Ch S R to Receive, the non-list part (1‘P pkt) of the arc inscription is needed for the case of the reordering channel (FIFO is false). In the case of the FIFO channel (FIFO is true), this non-list part acts like dummy tokens while the FIFO queue of the channel is still represented by a list resided in Ch S R. In the case of FIFO is true, the following actions can occur. 1. From the initial marking shown in Fig. 2.4 but FIFO is true, the only enabled binding element is BE8: (Send, )

18

On the occurrence of BE8, there are two synchronous actions. Firstly, similar to when FIFO is false, [“a”,“place”,“has”,“a”,“name”] is removed from and [“place”,“has”,“a”, “name”] is returned to TXbuf. Secondly, unlike when FIFO is false, 1‘L [] is removed from but 1‘L [“a”] ++ 1‘P “a” is returned to Ch S R. Note that the additional 1‘P “a” acts as a dummy token to fulfill the requirement of the input arc inscription from Ch S R to Receive. After the occurrence of BE8, the next marking is shown in Fig. 2.7.



(* Global Declarations *) val FIFO = true; color PKT = string; var pkt:PKT; color LIST_PKT = list PKT; var usr_buf,q:LIST_PKT; color PACKETS = union L:LIST_PKT + P:PKT; fun checkFIFO(a, []) = false | checkFIFO(a, la) = (a= hd(la)); fun enableFIFO(a, la) = if FIFO then checkFIFO(a,la) else true;


1‘ L [] Ch_S_R

PACKETS 2 1‘L(["a"])++ 1‘P("a")


1‘[] 1 1‘[]

RXbuf

LIST_PKT usr_buf

usr_buf^^[pkt]


[enableFIFO(pkt,q)]

Figure 2.7: The marking after the occurrence of BE8 (FIFO is true). 2. From the marking in Fig. 2.5 we have two concurrently enabled binding elements: BE9: (Send, ) BE10: (Receive, ) On the occurrence of BE10, there are two synchronous actions. Firstly, 1‘L [“a”] ++ 1‘P “a” is removed from and only the 1‘L [tl (“a”)]2 is returned to Ch S R. Secondly, [] is removed from and [“a”] is returned to RXbuf. However to get rid of the dummy tokens in Ch S R systematically, the occurrence of Receive happens only when the first element of q is equal to pkt. The guard [enableF IF O(pkt, q)] is used to fulfill this requirement. The occurrence of Receive causes a similar result to when Receive takes pkt from the FIFO channel in Fig. 2.3. After the occurrence of BE10, the next marking is shown in Fig. 2.8. The guard function enableFIFO(pkt,q) performs two main functions: 1. When FIFO is false, it returns true. This means that in the case of the reordering channel the guard expression is always true. 2. When FIFO is true, the guard expression enableFIFO calls function checkFIFO. The function checkFIFO(pkt,q) returns true when the first element of q is equal to pkt 2

function tl returns the list without the first element.

19



(* Global Declarations *) val FIFO = true; color PKT = string; var pkt:PKT; color LIST_PKT = list PKT; var usr_buf,q:LIST_PKT; color PACKETS = union L:LIST_PKT + P:PKT; fun checkFIFO(a, []) = false | checkFIFO(a, la) = (a= hd(la)); fun enableFIFO(a, la) = if FIFO then checkFIFO(a,la) else true;


1‘ L [] Ch_S_R

PACKETS 1 1‘L([])


1‘[] 1 1‘["a"]

RXbuf

LIST_PKT usr_buf

usr_buf^^[pkt]


[enableFIFO(pkt,q)]

Figure 2.8: The marking after the occurrence of BE10 (FIFO is true).

otherwise false.

2.4

Simulation

Each component of a Coloured Petri Net was informally introduced in section 2.3.2 which also illustrated how one transition can execute. Starting from the initial marking, transitions in a model may fire many times until no transition can fire or some transitions may continue firing forever. This means we can investigate or simulate how the system behaves by executing the transitions of its CPN model. A sequence of transition occurrences represents one possible scenario in which the system can behave. Various scenarios can be investigated to gain more insight and understanding of the system’s behaviour. Design/CPN supports two modes of simulation [132]: Interactive and automatic. In the interactive mode users can select an enabled transition and choose binding elements before firing the transition or let Design/CPN randomly select an enabled binding element and fire the transition. In both cases users can observe how the marking of the CPN changes when a transition occurs. Different options can be selected to speed up the simulation. In automatic mode, Design/CPN randomly executes enabled transitions until it stops because no more transitions are enabled or because of a user specified condition such as the maximum number of execution steps. Details of binding elements selected during simulation in both modes can be recorded in the simulation report as a text file. These simulations play an important role in identifying errors in the model during the debugging stage. This debugging process helps to gain insight and confidence in the

20

model. However to simulate a specific firing sequence one should know which particular scenarios you are looking for. Unfortunately for concurrent and distributed systems it is very difficult to use intuition to reason about system behaviour. The flaws in the design of a concurrent system are usually unexpected. Thus designers do not have prior knowledge about which specific scenario has problems. One way to gain confidence and ensure that the system is error free is to exhaustively simulate all possible sequences. This method is known as state space analysis.

2.5

State space analysis

The state space, sometimes called a reachability graph (RG) or an occurrence graph (OG), [106,108,131,132] is a directed graph comprising nodes and arcs. Nodes are markings and arcs represent binding element occurrences. One of the important advantages of the state space method is that it is easy to automate. Whenever possible, the whole state space can be automatically generated and stored in computer memory. From this generated state space we can use automatic tools (model checkers) to search the entire state space to reason about system behaviour and answer various questions. One of the most important questions in formal verification is whether or not the system satisfies a set of desired properties. Should undesired behaviour be detected, automatic tools can provide counter examples or error-traces. Thus design engineers can identify which fragments of the state space should be further investigated. Even when the entire state space is too large to be stored in computer memory due to the state explosion problem [204], there are a number of ways to counteract the problem. Firstly, the irrelevant part of the system can be ignored or abstracted away. Model simplification sometimes is intuitively obvious but sometimes requires a good understanding of the system and heavily depends on modellers’ experience. Secondly, we can restrict the size of state spaces using smaller values of the system’s parameters. By analysing a few configurations, errors tend to reveal themselves very quickly. Thirdly, a number of techniques to alleviate the state explosion problem have been proposed [131, 204]. We defer discussion on this topic to section 2.6. Fourthly, as a last resort, a partial state space can be generated for as many states as the user requires subject to the amount of memory available. Design/CPN allows the user to control state space generation via stop and branching options. The user can specify the limit when state space generation should stop using the stop option. The limitation can be execution time (in second), the number 21

of nodes, the number of arcs or specified conditions on which the generation should stop. The user can control the generation of successor nodes using the branching option so that only a specified part of the state space is generated. While Design/CPN generates a state space, it automatically provides a state space report [132]. It contains a summary of standard properties of system behaviour. An example of a state space report will be discussed in section 2.5.2. Besides the standard state space report, Design/CPN can be used to draw an occurrence graph and to query the state space. Both methods complement each other. When the size of the state space is large (> 100 nodes), it is not practical to draw the whole state space. Abnormal markings can be identified using a set of standard query functions [36]. Deadlocks can also be obtained from the state space report. After anomalies are identified, we can draw a part of the state space where the anomalous nodes are located. By identifying traces in occurrence graphs, the source of errors can be easily inspected and identified.

2.5.1

Analysis of the Channel Examples

In this section we use Design/CPN and its Occurrence Graph (OG) tools to analyse our three channel models. Our aim is to show that the combined model in Fig. 2.4 behaves the same way as the FIFO channel of Fig. 2.3 when FIFO is true, and as a reordering channel (Fig. 2.1) when FIFO is false. Occurrence graph In order to introduce occurrence graphs by simple examples, we reduce the size of the state spaces by allowing only two messages, (“a”,“place”) in the initial marking of TXbuf. After analysing the CPN models of a FIFO (Fig. 2.3), we draw Fig. 2.9 using OG tools. The figure depicts the state space of the CPN model. Similarly, we also analyse the combined model (Fig. 2.4) when FIFO is true and draw its state space in Fig. 2.10. Both state spaces have 6 nodes and 6 arcs. Figure 2.9 and Fig. 2.10 are used to compare the state spaces of the FIFO and combined channel models. In a visualized Occurrence graph (OG) like Fig. 2.9 or Fig. 2.10, rounded square nodes represent markings. Written inside the node is firstly a unique positive number used to identify each marking. Below this number, the number of incoming arcs and outgoing arcs associated with the marking are written, separated by a colon. The details of a marking (representing a global state) are shown in a solid box adjacent to the node. Inside the

22

1 0:1

1 FIFO’RXbuf 1: 1‘[] FIFO’Ch_S_R 1: 1‘[] FIFO’TXbuf 1: 1‘["a","place"]

1:1->2 FIFO’Send 1: {usr_buf=["place"], q=[],pkt="a"} 2 1:2 2:2->3 FIFO’Send 1: {usr_buf=[], q=["a"],pkt="place"}

3 FIFO’RXbuf 1: 1‘[] FIFO’Ch_S_R 1: 1‘["a","place"] FIFO’TXbuf 1: 1‘[]

2 FIFO’RXbuf 1: 1‘[] FIFO’Ch_S_R 1: 1‘["a"] FIFO’TXbuf 1: 1‘["place"] 3:2->4 FIFO’Receive 1: {usr_buf=[], q=[],pkt="a"} 4 1:1

3 1:1

4 FIFO’RXbuf 1: 1‘["a"] FIFO’Ch_S_R 1: 1‘[] FIFO’TXbuf 1: 1‘["place"]

5:4->5 FIFO’Send 1: {usr_buf=[],q=[], pkt="place"}

4:3->5 FIFO’Receive 1: {usr_buf=[], q=["place"],pkt="a"} 5 2:1

5 FIFO’RXbuf 1: 1‘["a"] FIFO’Ch_S_R 1: 1‘["place"] FIFO’TXbuf 1: 1‘[]

6 1:0

6 FIFO’RXbuf 1: 1‘["a","place"] FIFO’Ch_S_R 1: 1‘[] FIFO’TXbuf 1: 1‘[]

6:5->6 FIFO’Receive 1: {usr_buf=["a"], q=[],pkt="place"}

Figure 2.9: State space of the FIFO channel model when sending two messages. solid box, the number on the first line is the node identification number. The next three lines show the places and their tokens inside. A place is identified by a name of the CPN page, a place name and a page instance number. For example, “FIFO’TXbuf 1” is the place TXbuf in the page instance no.1 of the page FIFO. Adjacent to an arc, a dashed box contains the occurrence of a binding element which transits the state from the source node to its destination node. Inside the dash box, the numbers on the first line are used to identify the binding element. The next line shows a transition and its binding element. The transition is identified by a name of the CPN page, a transition name and a page instance number. For example, “FIFO’Send 1” represents transition Send in the page instance no.1 of the page FIFO. State Space Results We analyse these two models when the number of messages in TXbuf varies from one to five. Table 2.1 shows a comparison of the results of the FIFO and combined channel models when FIFO is true. The results are obtained from the state space reports. The “No. of TMs” column lists the number of terminal markings. 1[21] means one terminal marking with the node number 21. The results for each model are identical. Similar to 23

1 0:1

1 Combined’RXbuf 1: 1‘[] Combined’Ch_S_R 1: 1‘L([]) Combined’TXbuf 1: 1‘["a","place"]

2 1:2

2 Combined’RXbuf 1: 1‘[] Combined’Ch_S_R 1: 1‘L(["a"])++ 1‘P("a") Combined’TXbuf 1: 1‘["place"]

1:1->2 Combined’Send 1: {usr_buf=["place"], q=[],pkt="a"}

2:2->3 Combined’Send 1: {usr_buf=[], q=["a"],pkt="place"}

3 Combined’RXbuf 1: 1‘[] Combined’Ch_S_R 1: 1‘L(["a", "place"])++ 1‘P("a")++ 1‘P( "place") Combined’TXbuf 1: 1‘[]

3:2->4 Combined’Receive 1: {usr_buf=[], q=["a"],pkt="a"}

3 1:1

4 Combined’RXbuf 1: 1‘["a"] Combined’Ch_S_R 1: 1‘L([]) Combined’TXbuf 1: 1‘["place"]

4 1:1

5:4->5 Combined’Send 1: {usr_buf=[], q=[],pkt="place"}

4:3->5 Combined’Receive 1: {usr_buf=[], q=["a","place"],pkt="a"} 5 2:1

5 Combined’RXbuf 1: 1‘["a"] Combined’Ch_S_R 1: 1‘L(["place"]) ++ 1‘P("place") Combined’TXbuf 1: 1‘[]

6:5->6 Combined’Receive 1: {usr_buf=["a"], q=["place"],pkt="place"} 6 1:0

6 Combined’RXbuf 1: 1‘["a","place"] Combined’Ch_S_R 1: 1‘L([]) Combined’TXbuf 1: 1‘[]

Figure 2.10: State space of the combined channel model when sending two messages and FIFO is true. Table 2.1, Table 2.2 compares both OGs for reordering and combined channel models when FIFO is false. We also use the Occurrence Graph tools to draw and check the structure of each pair of state spaces (except case 5 in Table 2.2). Hence we are confident that our combined channel model works correctly.

2.5.2

State space report

Besides drawing occurrence graphs, Design/CPN provides a state space report which describes standard properties of a CPN model. An example of a state space report for FIFO

Combined (FIFO = true)

No of

No. of

No. of

No. of

No. of

No. of

No. of

messages.

Nodes

arcs

TMs

Nodes

arcs

TMs

1

3

2

1[3]

3

2

1[3]

2

6

6

1[6]

6

6

1[6]

3

10

12

1[10]

10

12

1[10]

4

15

20

1[15]

15

20

1[15]

5

21

30

1[21]

21

30

1[21]

Table 2.1: State space results for the two CPN models (FIFO channel).

24

Reordering

Combined (FIFO = false)

No of

No. of

No. of

No. of

No. of

No. of

No. of

message

Nodes

arcs

TMs

Nodes

arcs

TMs

1

3

2

1[3]

3

2

1[3]

2

8

8

2[7,8]

8

8

2[7,8]

3

24

28

6[24,23,...]

24

28

6[24,23,...]

4

59

78

12[59,58,...]

59

78

12[59,58,...]

5

230

283

60[230,229,...]

230

283

60[230,229,...]

Table 2.2: State space results for the two CPN models (reordering channel).

the CPN model of Fig. 2.1 with two messages in TXbuf is shown in Fig. 2.11. The state space report comprises the size of the state space (the number of nodes and arcs) and its SCC-graph; integer and multi-set bounds of every place; home markings; dead markings; dead transitions; and live transitions. Detailed discussion and formal definitions of these standard properties can be found in [81, 106, 108, 132, 146]. Livelocks Livelock [146] is a situation in which the system keeps repeating the same actions forever without progress and without the possibility of escaping from this behaviour. A system exhibits livelock if its state space contains a cycle that once entered there is no escape. It is desirable that transport protocols such as TCP or DCCP have no livelocks. Livelocks can be detected by generating the graph of Strongly Connected Components from the full state space. A Strongly Connected Component (SCC) is a maximal subgraph in which each node is reachable from each other [105,146]. If the full state space and its SCC graph are isomorphic, the state space contains no cycles [105,106]. This is a sufficient condition for there being no livelock. Figure 2.11 shows that the SCC graph has the same number of nodes and arcs as the Occurrence Graph. Because the SCC graph is generated from the full state space, they are isomorphic. Thus there is no livelock in our example. Boundedness properties The upper and lower integer bounds are the maximum and minimum number of tokens (respectively) that may reside in each place. TXbuf and RXbuf always have one token because the messages are stored in one list. Even when there is no message, they still contain an empty list. In Fig. 2.11 the maximum number of messages in Ch S R is two. The minimum number is zero when the channel is empty. The smallest multi-set which is larger than or equal to the markings of place p in any 25

Statistics -----------------------------------------------------------------------Occurrence Graph Nodes:

8

Arcs:

8

Secs:

0

Status: Full Scc Graph Nodes:

8

Arcs:

8

Secs:

1

Boundedness Properties -----------------------------------------------------------------------Best Integers Bounds

Upper

Lower

DCCP’Ch_R_S 1

2

0

DCCP’RXbuf 1

1

1

DCCP’TXbuf 1

1

1

Best Upper Multi-set Bounds DCCP’Ch_R_S 1

1‘"a"++ 1‘"place"

DCCP’RXbuf 1

1‘[]++ 1‘["a"]++ 1‘["a","place"]++ 1‘["place"]++ 1‘["place","a"]

DCCP’TXbuf 1

1‘[]++ 1‘["a","place"]++ 1‘["place"]

Best Lower Multi-set Bounds DCCP’Ch_R_S 1

empty

DCCP’RXbuf 1

empty

DCCP’TXbuf 1

empty

Home Properties -----------------------------------------------------------------------Home Markings:

None

Liveness Properties -----------------------------------------------------------------------Dead Markings:

[7,8]

Dead Transitions Instances: None Live Transitions Instances: None

Figure 2.11: An example of state space report.

reachable marking is called the upper multi-set bound [81, 105, 108, 132, 146] of a place p. Analogously, the largest multi-set which is smaller than or equal to the markings of place p in any reachable marking is called the lower multi-set bound [81, 105, 108, 132, 146] of a place p. In Fig. 2.11 every place has an empty lower multi-set bound. Sometimes these boundedness properties are useful for debugging the model and can be used to determine the size of buffer required for storing messages.

26

Dead Markings A Dead Marking is a marking that has no transitions enabled and hence no successor. Thus the system terminates. The state space report (Fig. 2.11) shows that markings number 7 and 8 (M7 , M8 ) are dead markings. Figure 2.12 shows the content of the dead markings. Both markings have no message left in TXbuf and nothing left in the channel place. The difference between both markings is the order of the messages stored in RXbuf because the channel can reorder the messages. In M7 the message “place” overtakes “a”. Dead markings play an important role in the validation of the protocol’s behaviour [14].

7 1:0

8 1:0

7 Reordering’RXbuf 1: 1‘["place","a"] Reordering’Ch_R_S 1: empty Reordering’TXbuf 1: 1‘[] 8 Reordering’RXbuf 1: 1‘["a","place"] Reordering’Ch_R_S 1: empty Reordering’TXbuf 1: 1‘[]

Figure 2.12: Dead markings M7 and M8 . Home Markings A marking that can always be reached from every reachable marking is called a “home marking”. A dead marking is a home marking if there is only one terminal strong connected component in the SCC graph which comprises the dead marking. The state space of the reordering channel CPN model in Fig. 2.1 has no home markings (except when the number of message is one). On the other hand, the state space of the FIFO channel CPN model has a home marking that is also the only dead marking. Dead Transitions Dead Transitions are transitions that are never enabled. Sometimes this can happen because the system in the particular configuration we analyse may not activate certain transitions. However it may be enabled in other configurations. For example, some behaviour may only happen in abnormal conditions. Nevertheless dead transitions are useful for debugging the CPN model. There is no dead transition in our example.

27

Live Transitions A transition is live if and only if for every reachable marking, there exists a marking that is reachable, such that the transition is enabled in that marking. Our examples do not have any live transition.

2.6

Related Analysis Techniques

Despite its merits as discussed in section 2.5, the state space method has some major disadvantages. Limited to Finite state systems Since it attempts to compute all reachable states, the state space method is limited to finite state systems. A finite state space can be obtained from an infinite state space by exploiting symmetries and the notion of data independence [91]. Hence sometimes infinite state systems can be transformed to finite systems and analysed using the state space method. Fixed Values of Parameters Constructing a state space requires the instantiation of values of the parameters of the model. Thus only one out of many possible state spaces is analysed at a time. This can be prohibitively expensive. Examples of parameters used in this thesis are the maximum number of retransmissions of each packet type and the initial sequence number sent. Verification of systems for every possible value of its parameters (regardless of parameter values), called parametric verification [64, 146], are beyond the scope of this thesis. State Explosion Problem The size of the state space depends on the parameter values in the system. When the parameter values increase, the state space size may increase rapidly. With respect to main memory, the number of reachable states becomes too large to be stored. With respect to execution time, the larger the number of stored states, the longer it takes to compare if a successor (new) state has been already generated. This limits the number of configurations of the system we can analyse.

28

To alleviate this problem a number of techniques have been proposed [204]. Some methods construct a condensed state space in which certain system properties are still preserved by exploiting certain properties such as symmetry and equivalence [41, 54, 104, 106, 131]. Partial order techniques [1, 42, 76, 135] exploit interleaving properties such that the effect of executing concurrent events is often independent of their ordering. In this thesis, the main technique adopted to alleviate the state explosion problem is the Sweepline method [155]. In the next two sections we introduce the Sweep-line and the language comparison techniques.

2.6.1

The Sweep-Line Method

The main idea of the sweep-line method [155] is that during state space generation any states that will not be reached again can be deleted from memory. At any stage of conventional state space generation, we can divide the states in memory into two groups. The first group comprises the states stored in memory that have been fully processed, that is, all their successors have been generated. The second group is the set of states stored in memory that have not yet been processed. The problem is how to ensure that the deleted fully processed states will not be reached again. The solution is to identify an indicator called a “progress measure” associated with the marking of the CPN model. Many systems exhibit some kind of progress while it is executing. The most obvious one is “time” (global clock). In general, many variables exhibit progress as the system executes. The most difficult task of the sweep-line method is to identify this progress measure. This requires experienced users with a good understanding of the problem. In a positive way, the user-defined progress measure makes this method so general that it can be applied to a wide range of applications. The basic sweep-line algorithm requires a progress measure that never decrease during the state exploration, a so called monotonic progress measure. This requirement is later relaxed in the generalized sweep-line method [137]. The sweep-line method can prove system properties on-the-fly by testing specified predicates while the states are calculated. However when an erroneous state is discovered, the sequences leading to this error are not stored. Thus useful debugging information is not stored. The solution for this drawback was proposed in [138] by storing a spanning tree of the explored states on external storage (disk). A path finding technique is implemented to seek for each state on the path leading to the error.

29

2.6.2

Language Analysis and Protocol Verification

Apart from using state spaces to prove or verify the properties of a system, state spaces can provide a means to compare models at different levels of abstraction. A state space can be viewed as a finite state machine (FSM) and the binding elements can be viewed as the alphabet accepted by the FSM. Hence, all possible sequences of events are defined by the language of the FSM. Thus the theory of FSMs and their languages [90] can be applied to determine if the language accepted by one FSM or state space is preserved in another. Any non-deterministic FSM with empty () transitions can be reduced to a canonical FSM that is minimal, deterministic and -removed while the original language is still preserved [90]. Two languages represented by the two minimal FSMs (canonical form) can be compared to see if one is a subset of the other. If both are subsets of each other, they are the same and the two systems they represent are language equivalent. Language comparison is used in the area of protocol verification [14] to compare languages derived from two different levels of abstraction of a protocol. The first is a high level of abstraction representing the requirements of its users, known as a service specification [11]. The second is the protocol specification which we wish to prove is a refinement of the service specification. Layered Protocol Architecture This language comparison is well established in a layered protocol architecture [197] where lower layers are encapsulated and can be viewed as a channel. The user at a specific upper layer can observe only the interaction at the interface with the lower layer. These interaction sequences are defined by the service specification. The internal operation of the lower layers is encapsulated and cannot be seen by the upper layer. Despite the fact that messages are passed vertically between layers, the specific layer views the message transferred horizontally or peer-to-peer. Hence the protocol specification defines internal peer-to-peer operation. This layered architecture has been well-known since it was adopted by the International Organization for Standardization (ISO) in the seven-layer Open System Interconnection (OSI) Reference Model [99, 197]. Many other protocol development organizations, such as ITU-T, specify their protocols based on this layered architecture as well. Their specifications include both service and protocol specifications. Unlike ITU-T or ISO, IETF specifications often do not provide the service specification. This thesis does not include a lengthy discussion of this protocol verification method-

30

ology because of two main reasons. 1. The methodology is already well known [14]. It has been applied to verify many industrial protocols [14, 78, 146, 169, 169, 214]. 2. RFC 4340 does not provide service specification. Four user commands; active open; passive open; active close and server active close appear in only the finite state machine diagram. The DCCP interaction with other layers is still an open research question [51, 185]. Thus this thesis does not emphasise the verification of DCCP against its service. Nevertheless we define DCCP’s service according to ISO conventions [100] in [70] and Appendix B to conduct an experiment on checking safety properties on-the-fly with the sweep-line method.

2.7

Concluding Remarks

This chapter informally introduces Coloured Petri Nets (CPNs) which we use for modelling and analysing the DCCP connection management procedures. CPNs provide a high level of user friendliness from their graphical representation with the ability to manipulate a rich set of abstract data types. They are well suited to formally specifying and analysing concurrent and non-deterministic systems such as communication protocols. The CPN models in this thesis were developed using an industrial-strength support tool, Design/CPN. Design/CPN provides a simulator for model debugging and Occurrence Graph tools for state space analysis. This chapter uses reordering, FIFO and a combined FIFO/reordering channel models as introductory examples of CPNs. The combined FIFO/reordering channel model helps us to efficiently update and maintain only one model (instead of two) while the protocol is being developed. We have considered other alternatives to combined FIFO and reordering channels. Another method involves defining new signatures and structures using ML. It will be more efficient but it is hidden and too obscure to understand. Our proposed solution is undertaken at the modelling level and uses simple ML functions. A draw back is that our approach consumes more memory because we store packets twice. Nevertheless according to our experience maintaining one CPN model is much more efficient than maintaining two CPN models. We use the combined model to compute the analysis results in Appendix D of this thesis. We did not use the combined model to compute the results of any papers in Part II for two reasons. Firstly this idea came out too late (around June 2006). Secondly, we attempt to alleviate the state explosion problem by 31

using memory more efficiently. In the next chapter we summarise the definition of DCCP connection management which also provides a brief informal introduction to DCCP.

32

Chapter 3 Definition of DCCP Connection Management This chapter introduces the basic concepts of the Datagram Congestion Control Protocol (DCCP) specified in RFC 4340 [124]. It aims to provide readers with sufficient information to understand the CPN models in the following chapters. This chapter is organized into four sections. Section 3.1 gives an overview of the characteristics of DCCP. Section 3.2 specifies the format of DCCP packets. Section 3.3 defines the state variables used in DCCP’s procedures. Section 3.4 summarizes DCCP’s connection management procedures.

3.1

DCCP Overview

DCCP is a point-to-point transport protocol operating over the Internet between two DCCP entities, the client and server. It provides a bidirectional flow of data for applications that prefer timeliness to reliability. Timeliness does not preclude retransmission as long as packets arrive at the receiver in time. Different DCCP applications may require different levels of reliability using different retransmission schemes. Many of DCCP’s applications are expected to have asymmetric data flow. For example in online games, data sent from the server to the client contains delay-sensitive graphical animation and sound but data sent from the client to the server contains only control commands. Because the commands are only short messages and can be lost, it can easily use UDP with no congestion control. On the other hand, graphic animation and sound require long messages that can quickly consume available bandwidth. Thus it may prefer a TCP-like sawtooth response to slow down the sending rate when congestion occurs. Hence DCCP 33

introduces the concept of a half-connection [124]. Each connection is logically divided into two half-connections. A half-connection comprises data packets sent from one side and its corresponding acknowledgements sent from the other side. Each half-connection can adopt a different congestion control mechanism. DCCP identifies congestion control mechanisms using the term Congestion Control Identification (CCID). It is vital that both sides must know and agree on the same CCID for each half-connection. To achieve this requirement, RFC 4340 specifies a general purpose feature negotiation mechanism for reliably negotiating a set of features including CCID. Some features specify acknowledgement mechanisms that are used to feed back congestion information to the sender. For instance, an acknowledgement scheme called Ack Vector [124] can precisely indicate which packets are lost. The detailed specification of the congestion control algorithm and its related acknowledgement mechanisms are defined in other RFCs (e.g. RFC 4341 [61] and RFC 4342 [62]). While TCP provides a reliable byte stream for application data, DCCP supports unreliable datagrams. This means that data can be lost, corrupted, delayed, duplicated or received out of sequence. Normally unreliable datagrams carry messages using connectionless protocols such as UDP, IP (Internet Protocol) [178] and ICMP (Internet Control Message Protocol) [177]. In contrast DCCP is a connection-oriented protocol for the following reason. DCCP is designed to provide congestion control over streaming media applications [60]. Congestion control algorithms need to know loss information because it is related to the level of congestion in the network. To detect, report and estimate loss information, DCCP uses packet sequence and acknowledgement numbers. To keep track of the sequence and acknowledgement numbers, DCCP needs state variables stored at both sides. State variables of both sides must be synchronised, otherwise DCCP may misinterpret loss information. Thus DCCP needs mechanisms to set up, synchronise and clear the state variables stored at each end. Hence connection establishment, synchronisation and close down procedures are required. In other words, DCCP can be considered as an upgraded version of UDP equipped with connection management, synchronisation procedures, feature negotiation and congestion control mechanisms. However, this thesis is confined to the connection management and synchronisation procedures specified in RFC 4340 and does not address congestion control and feature negotiation. More information about features negotiation and congestion control can be found in [61, 62, 124]. For a detailed discussion of design rationale and a 34

comparison with TCP, readers are referred to [60, 114].

3.2

DCCP Packet Format

A set of messages, called packets, are used to setup and release connections and convey data between a client and a server. RFC 4340 [124] defines a DCCP packet as a sequence of 32 bit words comprising a DCCP Header and Application Data as shown in general in Fig. 3.1. The header comprises a generic header, followed by an acknowledgement number (if any) and then options and features fields. The length of the Option and Application Data fields can vary.

3.2.1

DCCP Header

The DCCP header contains the following fields: Source and Destination Ports: Similar to those fields in TCP and UDP, these two 16-bit fields are used to identify the application process that uses DCCP. The Source Port identifies the application at the initiator, while the Destination Port identifies the same application at the responder. Data Offset: This 8-bit value represents the offset (in 32-bit words) from the beginning 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Source Port

Data Offset Generic Header Res

Packet X Type = 1

Destination Port

CcVal CsCov

Reserved

Checksum

Sequence Number (high bits)

Sequence Number (low bits) DCCP Header Reserved

Acknowledge Number

(high bits) Acknowledge Number (low bits)

Option Type

Length

Feature No.

Values Options and Padding

... Application Data Application Data

... Figure 3.1: DCCP packet format.

35

of the packet header to the beginning of application data, indicating the length of the header field. CCVal: This 4-bit value is used as a counter for congestion control. Its use is defined for the particular congestion control mechanism that is to be used on the connection. For example, in RFC 4342 [62]: CCID3, the sender assigns a 4-bit window counter value to CCVal field on every data packet sent. At the start this field is set to zero and increased by one every quarter of a round-trip time (RTT). The receiver uses the CCVal counters to calculate the receive rate and to determine when feedback packets are sent. The receiver can use the CCVal counter to estimate the RTT if there is no better information available. CsCov: The parts of the packet that are covered by the checksum field can be varied depending on the value of the Checksum Coverage 4-bit field (CsCov). The DCCP header is always covered. When CsCov = 0, the entire packet is protected. When CsCov is 1 to 15 the DCCP header, options and the first (CsCov-1)*4 bytes of the application data are covered. Note that when CsCov =1, the application data is not protected. When corrupted data is detected in the unprotected area by the data link layer, it is encouraged to forward the packet rather than retransmit or drop it. How DCCP interacts with the data link layer is still an open research question. Checksum: Depending on CsCov, the 16-bit checksum covers some part or the whole packet against data corruption. It uses the same checksum algorithm as TCP/IP (section 9.1 of [124]). Type: The 4-bit Packet Type field is used to specify the name of ten packets. Table 3.1 defines the 4-bit value for each packet. Any packets received with the reserved type are ignored (not processed and not acknowledged). During connection establishment, DCCP uses five packet types: DCCP-Request; DCCP-Response; DCCP-Ack; DCCP-DataAck and DCCP-Data. During the data transfer phase DCCP uses the DCCP-Data, DCCPAck and DCCP-DataAck packets. Three packet types: DCCP-CloseReq; DCCP-Close and DCCP-Reset are used for closing the connection. The DCCP-Sync and DCCPSyncAck packets are used to resynchronise the state variables (see section 3.3) of both sides. X (Extended Sequence Numbers): When this bit is set to one, it indicates that the DCCP packet uses 48-bit sequence and acknowledgement numbers. If it is set to zero, it indicates the use of short (24-bit) sequence and acknowledgement numbers. The packet header with short sequence and acknowledgement numbers is shown in Fig. 3.2. Only DCCP-Data, DCCP-Ack and DCCP-DataAck can set X to either zero or one and use 36

Table 3.1: DCCP Packet Types. Four-bit field

Packet type

0000

DCCP-Request

0001

DCCP-Response

0010

DCCP-Data

0011

DCCP-Ack

0100

DCCP-DataAck

0101

DCCP-CloseReq

0110

DCCP-Close

0111

DCCP-Reset

1000

DCCP-Sync

1001

DCCP-SyncAck

1010 - 1111

Reserved

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

Source Port Generic Header

Data Offset

Res

Packet X Type = 0

Reserved

Destination Port

CcVal CsCov

Checksum

Sequence Number

Acknowledge Number

Figure 3.2: DCCP packet header using short sequence and acknowledgement numbers.

either 24 or 48 bit sequence and acknowledgement numbers. All other packet types must set X to one and use only 48-bit sequence and 48-bit acknowledgement numbers. Sequence Number: The congestion control algorithms require loss information. In order to detect loss, DCCP uses sequence numbers. This 48-bit field (or 24-bit) represents the unique identity of packets in sequence. DCCP increases its sequence number by one for every packet sent. The choice of 48-bit sequence and acknowledgement numbers increases protection against blind attacks such as injecting the DCCP-Reset with a random sequence number into the connection. Longer sequence numbers (48-bit) also reduce the problem of old duplicates due to sequence number wrap. Sequence numbers are incremented using

37

modulo 248 arithmetic. Sequence number wrap occurs when the connection lasts so long that the sequence number returns to its initial value and the sequence numbers are reused. An old packet that still remains in the network can be received as a new packet because both use the same sequence number. Acknowledgement Number: Because of sending unreliable datagrams which can be lost, DCCP may never retransmit. Thus it does not use TCP’s cumulative acknowledgement scheme. DCCP’s acknowledgement informs the sender of the sequence number of the latest packet received rather than the next expected sequence number. All DCCP packets except DCCP-Request and DCCP-Data include the acknowledgement field. At the beginning of connection setup, before receiving any packet, the client sends a DCCP-Request. Thus a DCCP-Request will not acknowledge any packets and hence has no acknowledgement number. DCCP-Ack is used purely for acknowledgement while DCCP-DataAck carries application data with a piggybacked acknowledgement. To reduce overhead during data transfer, DCCP-Data without an acknowledgement field is used to convey application data only. Options Field: The options field is a multiple of 32-bit words which may contain more than one option. Because each option consists of a multiple of 8 bits, the field may need to be extended to the word boundary using padding. Options are classified into two groups: single byte and multi-byte. A single byte option has a value from 0 to 31 which represents an option type. Option type is an 8-bit integer which represents the meaning of the option. The format of a multi-byte option is shown in Fig. 3.1. The first byte is the option type. The second byte is the length in bytes of each option including option type, the length and data of the option. Currently RFC 4340 specifies 16 option types. This does not include CCID specific options which are specified in other RFCs. Feature Options: DCCP allows both sides of the connection to change their configurations, called “features”, using the feature negotiation procedures. The negotiation can happen at any time but typically during connection establishment. Each entity can initiate the negotiation for two kinds of features: local features denoted by (L) and indicating the initiator’s features and remote features (R), the other side’s features. Four particular options are dedicated to feature negotiation; Change L, Confirm L, Change R and Confirm R, with option type values 32 to 35 respectively. The format of Confirm or Change Options includes feature numbers and feature values as shown in Fig 3.1. The feature number represents the meaning of the feature. For instance, 1 means CCID and 2 means short sequence number allowed. Other feature numbers are listed in RFC4340 [124]. 38

Feature numbers 128-255 are reserved for CCID specific features.

3.2.2

DCCP-Request, DCCP-Response and DCCP-Reset

The structure of DCCP-Request and DCCP-Response packets are shown in Fig. 3.3. Both may contain application data. They also contain an additional 32-bit field called the Service Code [55]. The service code is used to identify an application-level service to which the client’s application attempts to connect. Instead of binding an application service to a particular port number, the service code allows a larger number of concurrent connections for a particular service. This is useful when a server opens a large number of ports to the same service simultaneously. Figure 3.4 shows the structure of the DCCP-Reset packet. It includes an additional 32-bit field comprising an 8-bit Reset Code with three bytes of data. When the sender resets the connection, it indicates the reason in the Reset Code. The meaning of the Reset Code is summarized in Table 3.2. The three bytes of data allows DCCP to provide more information on the reason for resetting the connection. If this is insufficient, Error text (human-readable) can be attached in the Application Data area. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Source Port

Data Offset Generic Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Source Port

CcVal CsCov

Checksum

X

Res 0 0 0 1 = 1

Destination Port

Destination Port

Reserved


Sequence Number (low bits) Data Offset Generic Header

CcVal CsCov

Checksum

Reserved

X

Res 0 0 0 0 = 1

Reserved

Acknowledge Number

(high bits)


Acknowledge Number (low bits) Sequence Number (low bits)

Service Code

Service Code

Options and Padding

Options and Padding

Application Data

Application Data

(a)

(b)

Figure 3.3: a) DCCP-Request packet structure b) DCCP-Response packet structure

39

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

Source Port

Data Offset Generic Header

Destination Port

CcVal CsCov

Checksum

X

Res 0 1 1 1 = 1

Reserved


Sequence Number (low bits) DCCP Header Reserved

Acknowledge Number


Reset Code

Data 1

Data 2

Data 3

Options and Padding

Application Data Area :Error Text

Figure 3.4: DCCP-Reset packet structure.

Table 3.2: Reset Code from [124]. Number

Meaning

0

Unspecified

1

Closed

2

Aborted

3

No Connection

4

Packet Error

5

Option Error

6

Mandatory Error

7

Connection Refused

8

Bad Service Code

9

Too Busy

10

Bad Init Cookie

11

Aggression Penalty

12-127

Reserved

128-255

CCID-Specific codes

40

3.3

Sequence Number Parameters and Variables

Each DCCP endpoint must maintain the following parameters and variables for each connection.

3.3.1

Parameters

ISS: The initial sequence number sent by each entity. This is the 48-bit sequence number of the first DCCP-Request sent by the client or the first DCCP-Response sent by the server. Initial sequence numbers are chosen to avoid old packets delivery and sequence number attacks by an attacker who can guess the sequence numbers. Discussion of how to choose initial sequence numbers can be found in section 7.2 of RFC 4340 [124]. ISR: The initial sequence number received from the other side. This is the 48-bit sequence number of the first DCCP-Request received by the server or the first DCCPResponse received by the client.

3.3.2

Variables

GSS: The greatest sequence number sent by the entity. The initial value is equal to ISS. GSR: The greatest sequence number received from the other side. The initial value is equal to ISR. GAR: The greatest acknowledgement number received from the other side that is not in a DCCP-Sync packet. The initial GAR value at the client is equal to the acknowledgement number of the first DCCP-Response received. At the server the initial GAR value is equal to ISS.

3.4

DCCP Connection Management Procedures

Figure 3.5 depicts a state diagram which provides an overview of DCCP’s connection management procedures. It is a redrawn version of the state diagram in RFC 4340. Ellipses in Fig. 3.5 represent states while arrows represent state transitions. A DCCP connection proceeds through three stages: connection establishment; data transfer; and connection close down. It comprises nine states: CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, OPEN, CLOSEREQ, CLOSING and TIMEWAIT. The initial and final state is the CLOSED state. The inscription on each arrow describes the input and output (if 41

CLOSED

active open snd Request

passive open

REQUEST

LISTEN

rcv Close snd Reset

rcv Response snd Ack/DataAck

rcv Request snd Response

PARTOPEN

RESPOND

rcv packet

rcv Ack/DataAck

OPEN

CLOSING

rcv Reset

CLOSEREQ active close or rcv CloseReq snd Close

server active close snd CloseReq

rcv Close snd Reset

TIMEWAIT 2 MPL timer exipres

Figure 3.5: DCCP state diagram redrawn from [124].

any) actions. For instance, the inscription on the arc from the LISTEN state to the RESPOND state is “rcv Request snd Response”. This means that when the server receives a DCCP-Request, it returns a DCCP-Response. The server always passes through the LISTEN state after a “passive open” command from the application, whereas the client is identified by an “active open” from its application and passes through the REQUEST state. Applications on both sides can issue an “active close” command but only the server’s application can issue the “server active close” command.

3.4.1

Typical Connection Establishment Procedure

The typical procedure for connection establishment is shown in the time sequence diagram of Fig. 3.6. In Fig. 3.6 the client is on the left side while the server is on the right. Time proceeds down the page. DCCP states are written in capital letters beside the vertical lines. Application commands such as active open and passive open are written inside square brackets. Arrows indicate packets being transferred between the two DCCP entities. Written above the arrow is the DCCP packet including its sequence number and an acknowledgement number (if any). For instance, the DCCP-Response packet contains sequence number ISS s and acknowledgement number ISS c. ISS s is the server’s initial 42

Client CLOSED [active open] REQUEST

Server CLOSED [passive open] LISTEN Request (seq=ISS_c)

Response (seq=ISS_s, ack=ISS_c) RESPOND Ack (seq=ISS_c+1, ack=ISS_s) PARTOPEN Ack (seq=ISS_s+1, ack=ISS_c+1) OPEN OPEN

Figure 3.6: Typical connection establishment. sequence number and ISS c is the client’s initial sequence number. According to the state diagram of Fig. 3.5, both sides originally start in the CLOSED state. We assume that the server enters the LISTEN state after a “passive open” command is issued by the application at the server. In the CLOSED and LISTEN states no connection yet exists. On receiving an “active open” command from its application, the client selects and records the Initial Sequence Number Sent (ISS), enters the REQUEST state and sends a DCCP-Request packet that includes ISS as its sequence number requesting the connection to be established. This packet may include any options and features that require negotiation. When receiving the DCCP-Request packet, the server (in LISTEN) records the Initial Sequence Number Received (ISR) as well as choosing its ISS and enters the RESPOND state. It also replies with a DCCP-Response packet (with its ISS) indicating its willingness to continue establishing the connection. The DCCP-Response may also include any options and features being negotiated. On receiving the DCCP-Response, the client (in REQUEST) records ISR and replies with either a DCCP-Ack or DCCP-DataAck to acknowledge the DCCP-Response packet and enters PARTOPEN. This acknowledgement packet may also contain any options and features being negotiated. After receiving an acknowledgement from the client, the server enters the OPEN state and may start transferring data or send an acknowledgement. After receiving a DCCPData, DCCP-DataAck or DCCP-Ack packet in PARTOPEN, the client enters OPEN indicating that connection establishment is complete. During data transfer, the server and client may exchange DCCP-Data, DCCP-Ack and DCCP-DataAck packets.

43

3.4.2

Typical Close Down Procedures

Before a new connection begins, one side has to wait in the TIMEWAIT state for 2 Maximum packet lifetimes (MPL1 ) in order to ensure that no old packets from the previous connection are delivered in the new connection. To reduce the impact of a state exhaustion attack, which involves attackers trying to use up the server’s memory by requesting an enormous number of connections to be established, the server should not be burdened with this delay and thus not be required to hold the TIMEWAIT state. Typically it is the client that waits before closing is complete. Figure 3.7 shows the typical close down procedure when the application at the server initiates connection release by issuing a “server active close” command. After sending a DCCP-CloseReq packet, the server enters the CLOSEREQ state. On receiving a DCCPCloseReq packet, the client replies with a DCCP-Close packet to which the server responds with a DCCP-Reset packet and enters the CLOSED state. On receiving the DCCP-Reset packet, the client waits in the TIMEWAIT state for 2 MPL before entering the CLOSED state. In the two scenarios shown in Fig. 3.8 and Fig. 3.9, either entity may send a DCCPClose packet to terminate the connection if receiving an “active close” command from the application. The entity that receives DCCP-Close enters the CLOSED state while the entity that receives the DCCP-Reset packet will enter the TIMEWAIT state. Client OPEN

CLOSING

Server OPEN [server active close] CloseReq (seq = m, ack = n) CLOSEREQ Close (seq = n+1, ack = m) Reset (seq = m+1, ack = n+1)

CLOSED

TIMEWAIT (2MPL) . . . CLOSED

Figure 3.7: Typical connection release.

1

Maximum packet lifetime time (MPL) = Maximum Segment Lifetime (MSL) in TCP

44

Client OPEN [active close] CLOSING

Server OPEN Close (seq = m, ack = n) Reset (seq = n+1, ack = m)

CLOSED

TIMEWAIT (2MPL) . . . CLOSED

Figure 3.8: Connection release by client. Client OPEN

Server OPEN Close (seq = m, ack = n)

CLOSED

[active close] CLOSING

Reset (seq = n+1, ack = m) TIMEWAIT (2MPL) . . . CLOSED

Figure 3.9: Connection release by server on active close.

3.4.3

Valid Sequence and Acknowledgement Number Intervals

During the connection, DCCP entities maintain a set of parameters and state variables. In addition to the major state, ISS, ISR, GSS, GSR and GAR, DCCP specifies two parameters: “Sequence Number validity window Width” (W) and “Acknowledgement Number validity window Width” (AW). Sequence (acknowledgement) number validity windows are subsets of the sequence (acknowledgement) number spaces. The endpoint expects to receive the packets that have sequence (acknowledgement) numbers falling inside these windows. DCCP sets up these window widths for the two half connections using feature negotiation procedures. RFC 4340 specifies the default value of window width to be 100 packets, the minimum window width to be 32 packets and the maximum window width to be 246 −1 packets. Based on these parameters and state variables (ISS, ISR, W, AW, GSS, GSR and GAR), valid sequence and acknowledgement number intervals are defined by Sequence Number Window Low and High [SWL,SWH], and Acknowledgement Number Window Low and High [AWL,AWH] as follows [124]: 45

3W ) 4 W SWL = GSR + 1 − f loor( ) 4 SWH = GSR + ceil(

(3.1) (3.2)

AWH = GSS

(3.3)

AWL = GSS + 1 − AW

(3.4)

where ceil(x) is a function that returns the smallest integer greater than or equal to x and floor(x) is a function that returns the largest integer less than or equal to x. In general, received packets having sequence or acknowledgement numbers outside these windows are “sequence-invalid”. Table 3.3 [124] shows the validity condition for each packet type. At the beginning of connection set up, SWL and AWL are equal to the initial sequence number received (ISR) and sent (ISS) respectively. DCCP-CloseReq, DCCP-Close and DCCP-Reset packets are used to close a connection. Thus they must be the latest (new) packet received which means their sequence number is greater than GSR and acknowledgement number is greater than GAR. DCCP-Sync and DCCP-SyncAck are used to bring DCCP state variables back into synchronisation. DCCP-Sync and DCCPSyncAck that are too old are discarded. On the other hand the upper limit of the sequence number interval, SWH, can prevent both packets performing their functions. Thus there is no upper limit for sequence number validity checks of DCCP-Sync and DCCP-SyncAck in Table 3.3.

3.4.4

Synchronisation Procedure

Sections 5.7 and 7.5.4 and the pseudo code in section 8.5 of RFC 4340 [124] define the synchronisation procedures which we summarize as follows. 1. The validity check of sequence and acknowledgement numbers is not conducted when DCCP is in the CLOSED, LISTEN or TIMEWAIT state. 2. The validity check of only the acknowledgement number of DCCP-Response or DCCP-Reset are conducted in the REQUEST state because there is no ISR or GSR in the REQUEST state. 3. On receiving a sequence-invalid packet, the receiver does not update its GSR and GAR. DCCP attempts to re-synchronise the sequence number variables (GSRs and GARs) by sending a DCCP-Sync packet. According to section 7.5.4 of RFC 4340 the acknowledgement number in the DCCP-Sync is set equal to the invalid received sequence number.

46

Table 3.3: Validity condition for sequence and acknowledgement numbers from [124]. Packet

Seq No. Check

Ack No. Check

Request

SWL≤ seqno ≤SWH

N/A

Response

SWL≤ seqno ≤SWH

AWL≤ ackno ≤AWH

Data

SWL≤ seqno ≤SWH

N/A

Ack

SWL≤ seqno ≤SWH

AWL≤ ackno ≤AWH

DataAck

SWL≤ seqno ≤SWH

AWL≤ ackno ≤AWH

CloseReq

GSR< seqno ≤SWH

GAR≤ ackno ≤AWH

Close

GSR< seqno ≤SWH

GAR≤ ackno ≤AWH

Reset

GSR< seqno ≤SWH

GAR≤ ackno ≤AWH

Sync

SWL≤ seqno

AWL≤ ackno ≤AWH

SyncAck

SWL≤ seqno

AWL≤ ackno ≤AWH

Type

However, when receiving an invalid DCCP-Reset, the acknowledgement number in the DCCP-Sync is set equal to GSR. 4. After the other end receives the DCCP-Sync, it updates GSR and replies with a DCCP-SyncAck. The acknowledgement in DCCP-SyncAck must equal the sequence number of the DCCP-Sync packet. DCCP does not update GAR since the acknowledgement number may be sequence-invalid. 5. Upon receiving the DCCP-SyncAck, the DCCP entity updates GSR and GAR. 6. Sequence-invalid DCCP-Sync and DCCP-SyncAck packets are ignored. 7. If the entity receives a DCCP-Sync or DCCP-SyncAck (either sequence-valid or sequence-invalid) in CLOSED, LISTEN, REQUEST and TIMEWAIT, it replies with a DCCP-Reset packet.

3.4.5

Timeout Mechanisms

In addition to the timer (2MPL) in the TIMEWAIT state discussed in section 3.4.2, DCCP defines two other types of timers: retransmission and connection fail. Table 3.4 summarizes the timer values for both retransmission and connection fail timeouts recommended by RFC 4340 [124]. When a sender does not receive an answer for a period specified in the column “Retransmission Timeout” in Table 3.4, it will retransmit the packet that was previously sent, but with its sequence number incremented. The DCCP entity in the 47

Table 3.4: Summary of timer values in the associated states.

State

Retransmission Timeout

Connection Fail Timeout

REQUEST

1 sec to 64 sec

3 minutes

RESPOND

-

4MSL(8minutes)

PATRTOPEN

2RTT (0.2 sec)

4MSL(8minutes)

CLOSEREQ

2RTT to 64 sec

4MSL(8minutes)

CLOSING

2RTT to 64 sec

4MSL(8minutes)

REQUEST state should use the exponential back-off timer but the timer value should not be greater than 64 seconds. The server does not set a timer in RESPOND but replies with a DCCP-Response whenever receiving a sequence-valid DCCP-Request. After holding a state for the period shown in the column “Connection Fail Timeout” of Table 3.4, the end point will send a DCCP-Reset and enter the CLOSED state.

3.4.6

Reset Processing

DCCP describes complex procedures related to the use of the DCCP-Reset packet in sections 6, 7, 8, 10 and 11 of RFC 4340 [124]. We summarize the reset procedures that are related only to connection management specified in sections 7 and 8 as follows. 1. Any DCCP-Reset received in CLOSED, LISTEN, or TIMEWAIT is ignored but any other packets received are responded to with DCCP-Reset. 2. Since no connection exists in CLOSED, LISTEN or TIMEWAIT, there are no state variables (GSS, GSR and GAR) associated with these states. Section 8.3.1 of RFC 4340 specifies how DCCP generates a DCCP-Reset in response to receiving a packet in CLOSED, LISTEN or TIMEWAIT. Firstly, the sequence number of the DCCP-Reset is equal to the received acknowledgement number plus one. Secondly, the acknowledgement number of DCCP-Reset is equal to the sequence number received. Thirdly, if the packet received has no acknowledgement number, the sequence number of DCCP-Reset is set to zero. 3. According to the pseudo code in section 8.5, all packets received in REQUEST other than DCCP-Response and DCCP-Reset will be responded to with a DCCP-Reset. 48

Section 8.1.1 of RFC 4340 specifies how the client in REQUEST sends a DCCP-Reset. Because the client in REQUEST has no ISR and no GSR, the acknowledgement number of DCCP-Reset is set to zero. 4. According to step 6 of the pseudo code and section 7.5.4 of RFC 4340 [124], if the received DCCP-Reset is invalid, DCCP responds with a DCCP-Sync. However the acknowledgement number of DCCP-Sync is equal to GSR instead of the received sequence number as described in section 3.4.4 previously.

3.4.7

Processing Unexpected Packets

According to steps 1 and 6 of the pseudo code of RFC 4340, any packets with an ill-formed header are ignored to prevent attackers attempting to reset the connection. Moreover, in the pseudo code, step 7 defines some scenarios that should never happen. If they occur, DCCP responds by sending a DCCP-Sync. Those scenarios are as follows. 1. The server should not receive DCCP-Response or DCCP-CloseReq packets. 2. The client should not receive a DCCP-Request packet. 3. The server in RESPOND should not receive DCCP-Data packets. 4. After the connection has been established, both sides should not receive DCCPRequest or DCCP-Response packets.

3.5

Concluding Remarks

The structure of RFC 4340 comprises three main procedures: connection management (including synchronisation); feature negotiation and some anticipated acknowledgement mechanisms that are used to report congestion situations in the Internet. This chapter has provided background on DCCP’s procedures with emphasis on the connection management and synchronisation procedures. Having introduced CPNs in Chapter 2 and DCCP in this chapter, now we are in a position to review related work in the context of the formal analysis and verification of DCCP connection management.

49

Chapter 4 Related Work The aim of this thesis is to use formal methods to investigate the correctness of DCCP’s connection management and synchronisation procedures. This chapter reviews previous work related to analysing or verifying the properties of DCCP connection management. As far as we are aware, apart from our work (including [128] which we shall discuss in Chapter 5), there is no other independent published work regarding the analysis and verification of DCCP’s connection management procedures. All work related to DCCP focusses on either its protocol architecture [114, 173, 216] or performance evaluation of DCCP congestion control [23, 39, 150]. Nevertheless while the DCCP specification was being developed, there were two unpublished analyses mentioned in [114]. Section 4.4 discusses this unpublished work, referred to in [49, 114]. Despite the lack of previous work related to the analysis of DCCP connection management by others, there exists a vast number of previous articles on the modelling and analysis of many different protocols. DCCP is a point-to-point transport protocol between two parties: the client and the server. Thus we shall focus on reviewing previous work on protocols that have similar characteristics to DCCP. The closest related protocols to DCCP are the OSI Transport Protocol [92] and TCP [179]. Besides reviewing previous work on the analysis of TCP connection management in section 4.3 and the unpublished analyses of DCCP by IETF in section 4.4, section 4.1 provides a brief review of the work on modelling and analysis of the OSI Transport Protocol using Petri Nets. Research that uses a similar methodology to this thesis is discussed in section 4.2.

50

4.1

Modelling and Analysis of the OSI Transport Protocol using Petri Nets

The use of Petri Nets for modelling protocols was suggested by Merlin [161, 163]. Examples of Petri Net representation of the alternating bit protocol and a routing protocol were developed [162]. Although Petri nets seem to be a natural technique for modelling protocols, they lack elegant data representation. Thus two main kinds of high-level Petri Nets were later proposed: Predicate/Transition Nets [74] and Coloured Petri Nets [105]. Their tokens are complex data values that can be modified upon transition firing. This led to the possibility of modelling and analysing much larger systems. To understand previous work more readily we shall briefly describe the classes of the OSI Transport Protocol [92]. The OSI Transport Protocol is classified into five different classes. The class is selected according to the quality of service the user desires and the quality of service the providers can provide. The five classes are: Class 0 - Simple class This protocol class provides functions for connection establishment and data transfer. It does not provide any quality enhancement. Network service disconnection, failure or reset automatically implies the release of the associated transport connection. Class 1 - Basic error recovery class When the network service signals a disconnection, failure or reset, this protocol class has the ability to restore the network connection to normal without involving the user. A network service disconnection no longer implies a transport disconnection. Class 2 - Multiplexing class This protocol class provides multiplexing of several transport connections but does not provide error detection and error recovery. Even though it provides an explicit connection release procedure, the protocol is terminated when the network service is disconnected or reset.

51

Class 3 - Error Recovery and multiplexing class This protocol class provides the characteristics of class 2 plus the ability to recover from a network disconnect, failure or reset. It also includes an explicit flow control. Class 4 - Error detection and recovery class Class 4 provides the characteristics of class 3, plus the capability to detect and recover from errors that result from a low grade of service available from a network service provider. Time out mechanisms are mainly used to recover from errors. Thus timers and the maximum life time of message in the network are required in this protocol class. Table 4.1 summarizes the previous work on modelling and analysis of the OSI Transport Protocol. Berthelot and Terrat [8] modelled the European Computer Manufacturer Association (ECMA) transport protocol using Petri Nets and Predicate/Transition Nets. The connection and disconnection phases (class 1 and class 2) were modelled using Petri Nets while the data transfer phase (class 3) was modelled using Predicate/Transition Nets. The channels for the data transfer phase were assumed to be FIFO with no duplication. If a message was lost or corrupted, it was replaced with an “error” message. To verify the model they used the reduction and invariant methods for the ordinary Petri Net model and assertion proofs on the Predicate/Transition Net model. They proved that the Petri Net model is safe and live and that the initial state was a home state. The correctness of data transmission was also proved. The protocol has no deadlock and messages are sent without loss, duplication or overtaking. Courtiat et al [44] extended the work of Berthelot and Terrat in two ways. Firstly they modelled the class 2 transport protocol and service using Petri Nets. Secondly they extracted reduced reachability graphs using a projection method and compared the protocol sequences against the service sequences. Their Petri Net models were specified and verified using a computer aid software tool called OGIVE (Outil graphique interactif de v érification) [35]. OGIVE provides facilities for editing Petri Nets interactively; validating the model using place and transition invariant analysis; and extracting reduced reachability graphs from the global Petri Net model. General properties such as boundedness, freedom of deadlock and liveness as well as the verification against the service specification were discussed. They found that the class 2 OSI Transport Protocol does progress according to its service specification. They also suggested that Petri Nets are adequate for protocol specification and validation.

52

Table 4.1: Previous work on modelling and analysis of the OSI Transport Protocol Authors

Protocol

Procedures

Technique

Analysis method

Berthelot

ECMA/OSI

Class 1 and 2

Petri nets

Invariant Analysis

and Terrat

Transport

Class 3

Predicate

Assertion Proof

(1982)

Protocol

Courtiat et al

OSI Transport

(1984)

Protocol

Transition Nets Class 2

Petri nets

Invariant Analysis

(OGIVE)

Reachbility Analysis

and Service

Language Comparison

J¨ urgensen

OSI Transport

Class 4

Petri nets

Invariant Analysis

and Vuong

Protocol

(Time out)

(OGIVE+)

Reachability Analysis

Bearman et al

OSI Transport

Class 0

NPN


(1985)

Protocol

Class2

(PROTEAN)

Billington et al

OSI Transport

Class 0

NPN


(1986)

Protocol

Class2

(PROTEAN)

Language Comparison

(1984)

Despite using the same tool (OGIVE) as [44], J¨ ugensen and Vuong’s work [109] was different. They focussed on analysing a more complex protocol, the class 4 OSI Transport Protocol which included retransmission on time out. They used an extended version of OGIVE, called OGIVE+, to check state ambiguities and reception errors. Even though some state ambiguities and errors were detected, they were considered not harmful. Another investigation of the OSI Transport Protocol was reported from Telecom Australia Research Laboratories (TRL). Bearman et al [4, 5] modelled and analysed the class 0 and class 2 transport protocol. Their work was different from [8, 44, 109] in three ways. Firstly, instead of Petri Nets, they adopted Numerical Petri Nets (NPN) [196] to model larger systems with more compact representation using an automated support tool called PROTEAN (PROTocol Emulation and Analysis) [20]. Secondly, the class 0 and class 2 protocol were studied when each side implemented different options of the specification. Thirdly, they focussed on error handling capability. After [4, 5] identified several ambiguities and faults, they notified the problems to the ISO subcommittee. Billington et al [21] later outlined a methodology for protocol specification and verification. The methodology was illustrated by an example of the class 0 OSI Transport Protocol using PROTEAN. PROTEAN had facilities to generate the service language and the composite language provided by the two protocol entities. However, at that stage PROTEAN still lacked an

53

automatic language comparison.

4.2

Related Work using a Similar Methodology

The protocol engineering methodology adopted in this thesis originated from Telecom Australia Research Laboratories (TRL). In the early 1980s, TRL developed a software tool called PROTocol Emulation and Analysis (PROTEAN) [20] based on Numerical Petri Nets (NPNs) [196]. NPNs are a kind of high-level Petri Net in which tokens can be complex data values and the net is inscribed to express complex enabling and firing rules. Besides facilities for the input and editing of NPNs, PROTEAN provided interactive simulation, reachability analysis and language analysis. It was applied to model and analyse several protocols and signalling systems [20] such as Common Channel Signalling number 7 [110], OSI Transport Protocol [21] and OSI File Transfer, Access and Management (FTAM) protocol [141]. Floreani [58] designed and verified a communications gateway between radio networks and Broadband Integrated Services Digital Networks (B-ISDN) using Coloured Petri Nets and Design/CPN. Despite the modelling and the state space analysis being conducted using Design/CPN, PROTEAN [20] was used for language reduction and ARA (Advanced Reachability Analysis) [205] was used for comparing two reduced state spaces: the specification and refined specification. Using a simple ML program, the PROTEAN input file was extracted from the state space generated by the Occurrence Graph tool of Design/CPN. The graph comparison tool in ARA requires two input files of labelled transition systems (LTS). These LTS files were generated by manipulating the output language files from PROTEAN. Unlike Floreani’s work which involves several file interchanges, Gordon [78] simplified the language comparison process by using Design/CPN and the FSM suite of tools [63]. The service and protocol CPN models and their state spaces were generated using Design/CPN and its Occurrence Graph tool. The FSM input file was extracted from these state spaces using a simple ML program. The two state spaces were considered as FSMs and they are minimized and compared using FSM tools. Based on the protocol engineering methodology in [21] which was further elaborated in [14], various communication protocols have been studied by PhD students in the Computer Systems Engineering Centre (CSEC) under the supervision of Professor Billington. A comparison of their PhD theses is summarized in Table 4.2. The first column of the 54

Table 4.2: Comparison among PhD Thesis by CSEC students. Student

Protocol RM-ODP Trader WTP

Standards Organization ITU-T ISO/IEC WAP-Forum

Tokmakoff 1998 Gordon 2001 Villapol 2003 Ouyang 2004 Han 2004

Type Transaction

RSVP

IETF

Signalling

IOTP

IETF

Transaction

TCP

IETF

Transport

Liu 2006

CES

ITU-T

Signalling

Gallasch 2007 This thesis

Stopand-Wait DCCP

-

Data Link

IETF

Transport

Transaction

Medium 1. Reordering with no loss 1. Reordering with no loss 1. Reordering with no loss 1. FIFO with no loss 1. Reordering With no loss 2. Reordering with loss 1. FIFO with no loss 2. FIFO with loss 1. FIFO with loss 1. FIFO with no loss 2. FIFO with loss 3. Reordering with no loss 4.Reordering with loss

Language Comparison No

Sweep-Line Analysis No

Parametric

Yes

No

Yes

Yes (Basic) No

No

Yes

No

No

Yes

No

Yes

No

Yes (Data Transfer Service only) Yes (Service only)

Yes

No

Yes

Yes (On-the-Fly with Sweepline)

Yes (Generalized with Augmented Model)

No

No

table lists student names and the year in which their thesis was published. The second and third columns are the protocols they investigate and the related standardization bodies. The fourth and fifth columns describe the type of the protocol and the underlying medium over which the protocol operates. The last three column are related to analysis methods the students adopted: Language comparison, Sweep-line Analysis and parametric analysis/verification. Tokmakoff [199] modelled, analysed and prototyped the Open Distributed Processing (ODP) [96] trader using Coloured Petri Nets and Java. Gordon [78, 79] verified the Class 2 Wireless Transaction Protocol (WTP) [215]. Villapol [214] modelled and analysed the Resource Reservation Protocol (RSVP) [30]. Ouyang [169] verified the Internet Open Trading Protocol (IOTP) [31]. Han [81] specified the TCP service and verified the TCP connection management protocol [179]. Liu [146–149] verified the Capability Exchange Signalling Protocol (CES) [102]. She also investigated regularities of the state space structure to derive symbolic representations of state spaces which is an important step towards parametric verification. Gallasch focussed on the parametric verification of the Class of Stop-and-Wait Protocols [13,64–68]. Except for [199], all students place emphasis on protocol verification [14]. Reviews on the protocol verification methodology can be found in [14, 64, 78, 81, 146, 169]. We have already briefly discussed this methodology in

55

section 2.6.2. The protocols defined by IETF in Table 4.2 do not include a service specification. Thus Villapol, Ouyang and Han had to create the service specification themselves in order to formally verify the protocol specification against the service specification [14]. These service specifications were defined based on the early work of Billington [10] on formalising the OSI Transport Service [101]. Gordon’s work [78] provides students with an excellent example of how to use CPNs and state space analysis to verify the general properties of a protocol and how to use language analysis to formally verify the protocol language against the service language. Since then Liu [146], Han [81] and Gallasch [64] have attempted to extend the existing methods of protocol verification. Liu and Billington [149] observed that the CES service state space grew linearly with the channel capacity and derived a recursive formula to represent the family of state spaces. The state space for the channel capacity l can be generated from the state space for capacity l -1. Billington and Han [19] formally specified the TCP data transfer service using a symbolic representation. Both led to further progress toward parametric verification in [146] and [64, 65]. With respect to modelling, although the CPN model in [78] has a hierarchical structure, Gordon did not use page instances in Design/CPN to improve maintainability of the model. While Ouyang [169] reused some CPN pages, Han [81] modelled one TCP entity and instantiated it twice to represent the client and the server. The page instance technique is useful when different entities have common procedures. Gordon [78, 79] also attempted to use the basic sweep-line technique [37] to extend his analysis results. However the basic sweep-line algorithm requires the progress measure to be monotonic. While other students in CSEC have shifted their interest toward parametric verification [13,66–68,81,146], Gallacsh [69–73] has enhanced the sweep-line algorithm and conducted some experiments on sweep-line analysis of IOTP and TCP. His experiments [69,72] provide us with a profound understanding of how to apply the sweep-line technique to the protocol verification problem.

4.3

Verification of TCP Connection Management

While TCP was still evolving, since 1978 many researchers [140, 145, 160, 168, 188, 195] began to scrutinize TCP’s connection management procedures. An excellent literature review in the area of verifying TCP connection management can be found in [81]. Con56

sidering previous work done by others, while some are out-of-date due to the specification being changed, some used a simplified version of TCP and investigated only the connection establishment scenario. For example, Kurose and Yemini [140] considered only the client-server situation while Mehrpour and Karbowiak [160] modelled TCP segments without sequence and acknowledgement numbers. Recent work by Ye and MacGregor [219,220] provides an interesting perspective. They studied Selective Acknowledgement (SACK) TCP which mainly involves performance analysis in the data transfer phase. Even though a couple of simulation tools such as ns-2 and OPNET are widely used, the simulation cannot prove the correctness of the protocol. Ye and MacGregor propose to use Coloured Petri Nets and Design/CPN to model and analyse the resilience aspects of SACK TCP. Besides the correctness of the protocol behaviour, CPN can be used to clearly explain the step-by-step behaviour of SACK TCP in various circumstances such as network congestion and failure. Recent work [16,81,82] on TCP connection management was more complete than others in many respects. Using an event processing approach, the CPN model in [16, 81, 82] well captures TCP’s behaviour specified in RFC 793 [179] and RFC 1122 [29]. TCP segments in the model contain the sequence number, the acknowledgement number and the control bits. The transmission control block (TCB) in the model contains TCP’s major states, a reduced set of state variables and a listen status flag. Even though the CPN model in [16, 81, 82] captures TCP’s behaviour in terms of event processing, there are some drawbacks. 1. The data structures of segments and the TCB represented in the model do not always reflect the TCP specification. For instance, in the CLOSED state there is no connection associated with an entity and thus no state variables exist. However, in [16, 81, 82] these variables do exist in the CLOSED state and are given dummy values. 2. Han [16,81,82] did not model modulo arithmetic operations nor discuss the effect of sequence number wrap in TCP. 3. Han [16, 81, 82] considers only reordering channels and does not consider FIFO channels. Because a reordering channel can mask out errors [14], the incremental analysis of TCP operating over FIFO channels provides us confidence of the correctness of the model as well as the correctness of the protocol.

57

4.4

Validation of DCCP Connection Management by IETF (Unpublished Work)

According to [49, 114] there were two unpublished analyses of DCCP. Firstly, Handley modelled and analysed the DCCP Internet draft version 5 [126] using a tool called the Labelled Transition System Analyser (LTSA) [153, 154]. The LTS model [114] includes major states, timers, packet types, lossy channels and duplicated packets. A deadlock was discovered during connection establishment and then it was removed. However this model did not include sequence and acknowledgement numbers in packets nor the state variables (stored in DCCP entities) that relate to sequence numbers. Thus the model is too abstract and cannot be used to conduct the sequence number validity check and synchronisation procedures. Without sequence numbers, the sequence number wrap behaviour cannot be investigated. Moreover the model is not up-to-date since the DCCP specification had a lot of technical changes after Internet draft version 5. Secondly, since Internet Draft version 6 [115], IETF has included pseudo code, simplified the finite state diagram and deleted the input/output table. This modification is necessary because the protocol is so complex that reasoning from the finite state diagram and stable table (input/output table) is not enough to ensure that DCCP operates correctly. An ad hoc exhaustive state space tool [114] was developed by IETF to verify the specified pseudo code. Verifying the pseudo code by this tool is very beneficial for designing DCCP [114]. It leads to further specification refinement and provides more confidence. However, no details of any of this work has been published.

4.5

Concluding Remarks

Previous work has demonstrated the utility of CPNs for modelling and analysing various classes of protocols including transport layer protocols such as the OSI Transport Protocol and TCP. In particular, the work of Han [16,81] on TCP connection management demonstrates that errors can be found in such mature transport level protocols as TCP [16]. This provides confidence that applying similar tools and methodology to DCCP connection management should be effective. If the modelling and analysis can be progressed in a timely way, it will be possible to improve the protocol before it is released as a standard. This thesis is different from the work in [16, 81] on TCP in many respects: a) DCCP’s connection management procedures differ from TCP’s in many important 58

Table 4.3: Differences between TCP and DCCP.

Differences Handshake Flow control FSM (number of states) Simultaneous open Graceful release Sequence number Acknowledgement number Sequence number of the retransmitted segment/packet Acknowledgement scheme

TCP 3-way yes 11 states yes yes 32-bit 32-bit same as previous sequence number cumulative

Synchronisation

implicit in flow control

DCCP 4-way no 9 states no no 48 or 24-bit 48 or 24-bit always increased by one greatest sequence number received explicit procedure

ways. Their differences are summarized in Table 4.3. b) We modelled and analysed DCCP’s connection management procedures while the DCCP specification was still evolving. From October 2003 to March 2006, IETF released nine versions of DCCP Internet Drafts (version 5-13). Thus we had to continually update and re-analyse our CPN model until DCCP was published as a RFC in March 2006. c) In our CPN model we take into account circular arithmetic modulo 248 and 224 on sequence and acknowledgement numbers. Two basic modulo operations are increment and circular comparison [124] between two sequence numbers. These modulo arithmetic operations are not considered in [16, 81]. d) We analyse scenarios in which the sequence and acknowledgement numbers roll back to zero. e) DCCP-Data, DCCP-Ack and DCCP-DataAck packets may use 24-bit short sequence and acknowledgement numbers. Our model has included the algorithm of extending short to long sequence and acknowledgement numbers. The client and the server can send DCCP-Data, DCCP-Ack and DCCP-DataAck using either long or short sequence numbers. f) We include analysis results when DCCP operates over FIFO channels with/without loss in Appendix D, while Han [16, 81] only considered reordering channels. g) We use the sweep-line technique to compare the DCCP service and protocol languages 59

on-the-fly and give some insight into how to determine sources of progress for our model. The next chapter presents a summary of the papers in Part II.

60

Chapter 5 Summary of DCCP’s Verification The main body of this thesis comprises four international journal papers and three international fully refereed conference papers. These papers can be classified into two groups. The first group records the work done while the development of DCCP specification was in progress, that is before RFC 4340 was published. These papers [206–209, 212] are presented in Chapters 6-10. The second group focusses on attempts to alleviate the state explosion problem by applying the sweep-line technique to obtain more analysis results. These paper [70, 211] are included in Chapter 11 and Appendix A. This chapter also includes some new results which have not been published in the above papers.

5.1 5.1.1

Development of the DCCP specification DCCP version 5: the Initial CPN Model (Chapter 6)

After DCCP Internet Draft version 5 [126] was released on 27 October 2003, we rapidly built and analysed an initial CPN model of DCCP connection management. On 28 November 2003 we were able to submit a paper on the model and its analysis [206] to the Fourth International Network Conference (INC 2004). This paper is presented in Chapter 6 of this thesis. The initial model is highly abstract and based on a lot of assumptions. The channels are assumed to be reordering without loss. Nevertheless, the initial analysis reveals a deadlock in the connection establishment procedure where the client is in the CLOSED state and the server is in OPEN. This deadlock is caused by a delayed Reset packet with sequence number zero. Internet Draft version 6 [115] released on 16 February 2004 had significant changes in the connection establishment procedures. It introduced a four-way handshake with a

61

new major state called PARTOPEN. From the PARTOPEN state the client enters the OPEN state when it receives a DCCP-Data, DCCP-DataAck or DCCP-Ack packet from the server. Also, the use of GAR became mandatory and was required to validate Reset packets. We quickly updated our CPN model but assumed that only Ack packets were necessary for the connection management procedures. Our quick analysis showed that the deadlock shown in [206] was removed in DCCP version 6.

5.1.2

Synchronisation Procedure

Early versions of the synchronisation mechanism in Internet Draft versions 0-4 used the Challenge Option and Identification Option. A new mechanism using a unique packet type, DCCP-Sync, was introduced in DCCP version 5. DCCP version 6 introduced DCCP-SyncAck and revised the synchronisation procedure. Another procedure that works very closely with the synchronisation mechanism is the procedure for the sequence number validity check. Due to the significant changes of both procedures (synchronisation and sequence number validity check) in Internet Draft versions 4, 5 and 6 as well as discussions in DCCP mailing list, we considered that it would be wise to exclude both procedures from the model until they became stable. Thus our early work concentrated on DCCP’s connection establishment and close down procedures to ensure that our CPN model correctly covered every possible action of DCCP in each major state.

5.1.3

DCCP Version 6

Our initial model [206] was upgraded to DCCP Internet Draft version 6 [115] by Kongprakaiwoot [128]. He extended our initial model to include the PARTOPEN state and regrouped transitions into a fourth level of CPN pages. His main contribution is the DCCP state table extracted from the narrative description and pseudo code in Internet Draft version 6 [115]. Then he validated his CPN model against this state table. He also attempted to apply the sweep-line technique to analyse the DCCP connection management model using GSS and GSR as progress measures. Including the non-deterministic use of Data, DataAck and Ack packet and the PARTOPEN state, he found a similar deadlock to the one we discovered in [206]. Kongprakaiwoot [128] focussed on the correctness of every possible action in each state. Thus some details were not included in his CPN model. For example, the sequence number validity check of every DCCP packet type (except DCCP-Reset) was not included.

62

Without the sequence number validity check, synchronisation procedures cannot be modelled. While initialization process of GSR and GAR was not considered, initial values of GSR and GAR were setup by the initial markings. Because DCCP version 6 defined 24-bit sequence (acknowledgement) numbers as mandatory and extended sequence (acknowledgement) numbers (48 bits) as optional, DCCP packets in his model used only the mandatory 24-bit sequence (acknowledgement) numbers. Despite detailed checking of his CPN model, there was still an error in the model [128]. When the DCCP-CloseReq is received in the REQUEST state, according to the pseudo code in [115] the client sends a DCCP-Reset. But the client in the CPN model of [128] sends a DCCP-Close instead. This demonstrates how difficult it is to interpret the DCCP informal specification.

5.1.4

DCCP version 7

DCCP Internet draft version 7 [116] was released on 18 July 2004. It has three significant changes that affect our model. Firstly the 48-bit long sequence numbers are mandatory for all packet types. Short sequence numbers are only allowed to be used in DCCP-Data, DCCP-Ack and DCCP-DataAck packets. Thus we needed to use the colour set infinite integer (instead of integer) to represent 48-bit sequence and acknowledgement numbers in Design/CPN. Secondly, according to the sequence number validity check conditions in version 7, a DCCP-Reset packet with a sequence number of zero is no longer always valid. Thirdly, section 8.3.1 of DCCP version 7 defines a new mechanism to send a DCCP-Reset packet in CLOSED and LISTEN states in which GSR and GAR do not exist. Hence we began to update the CPN model by incorporating the sequence number validity check and synchronisation procedures.

5.1.5

Racing toward RFC

Since Internet Draft version 7 [116], IETF rapidly updated the DCCP specification and released version 8 [117] on 25 October 2004 and version 9 [118] on 14 November 2004. There was no significant change in those versions with respect to the connection management procedures. On 17 December 2004 we learnt from the DCCP mailing list that IETF had already started the process of requesting to publish DCCP as a standard based on Internet Draft version 9. This implied that the DCCP specification including the sequence number validity check and synchronisation procedures were stable. We were interested to

63

include these two procedures in our CPN model and formally verify properties of DCCP connection management. It was crucial that errors were discovered and rectified before DCCP became an Internet standard. Even though we attempted to expedite the modelling and analysis process, it took us about 3 months from 17 December 2004 to refine, validate and analyse the model. DCCP version 10 [119] and 11 [120] were released on 7 March 2005 and 10 March 2005 respectively in response to the comments from Internet Engineering Steering Group (IESG). Fortunately, none of these changes affected our CPN model. Chatter (Chapter 7 and 8) When we analysed the CPN model of Internet Draft version 9 using ISS equal to 2000, we encountered the state explosion problem. Investigating a partial state space, we discovered a long sequence of alternating DCCP-Reset and DCCP-Sync packets. On Professor Billington’s suggestion, we conducted state space analysis experiments using small values of ISS. The results showed that the state space size and the interaction sequences between DCCP-Sync and DCCP-Reset packets were finite and varied linearly with the value of ISS. Because the sequence numbers are 48 bits long, the ISS value is typically large. Thus these peculiar interaction sequences are typically very long but finite. This behaviour is known as “chatter” [212]. It is similar to livelock that was discussed in Chapter 2. Both livelock and chatter are situations in which the system keeps repeating the same actions without progress. While the livelock continues forever, the chatter eventually returns to a safe state within a finite time. However this chatter creates unnecessary traffic, adversely affecting congestion in the Internet as opposed to the intention of DCCP. On 20 April 2005 we submitted our new model and its analysis to the 25th IFIP WG 6.1 International Conference on Formal Techniques for Networked and Distributed Systems (FORTE 2005) [212]. This is the subject of Chapter 7. To emphasise how severe the chatter problem was, we attempted to estimate how many packets were repeated and needlessly exchanged when the problem occurs. In Chapter 8 [208] we showed that if the problem occurred, then the probability of over 2 billion messages being needlessly exchanged was greater than 0.99999. After the paper [212] was accepted, we submitted it to IETF. The principal editor of the DCCP specification, Dr. Kohler, advised us that the chatter problem was more severe than we originally thought, especially when using short sequence numbers or when one side is in CLOSED but the other side is in OPEN, called a “half-open connection” [114]. He 64

also provided a solution and asked us to re-analyse our model to see if the chatter problem was removed. The solution was: when the sequence-invalid DCCP-Reset is received, the acknowledgement number of the sending DCCP-Sync is equal to GSR instead of the received sequence number. After revising the model, our revised analysis results showed that the chatter problem was removed. Short Sequence Numbers Dr. Kohler’s suggestion about the chatter problem when using short sequence numbers motivated us to upgrade the model to include a non-deterministic use of both long and short sequence numbers. When the 24-bit short sequence (acknowledgement) numbers are received, they are extended to 48-bit number based on GSR (GSS). Basically the upper 24-bit of the extended sequence (acknowledgement) number is equal to the upper 24-bit of GSR (GSS). The algorithm for extending the short number (24-bit) to a long number (48-bit) also takes into account when the short sequence number rolls over from 224 − 1 to zero. To be able to verify correctness of this algorithm we needed to analyse scenarios in which the short sequence numbers wrap around 224 − 1. Thus we needed to model circular comparison modulo 224 and addition modulo 224 . Analysing the revised model that included short sequence numbers, we found an error in the algorithm for extending short sequence numbers to long sequence numbers (page 60 of [120]). After we reported the problem to IETF, IETF again revised the algorithm [123]. After including the new algorithm in our model, the analysis results confirmed that the error was removed. An Ambiguity in the TIMEWAIT state According to a strict interpretation of the pseudo code in section 8.5 and the narrative description in sections 7 and 8 of Internet Draft version 11 [120], an end point in TIMEWAIT does not update GSR and GAR, while GSS is always increased by one for every packet sent. During state space analysis, we encountered the state explosion problem. We used the occurrence graph tool to investigate the state space in detail and discover a long exchange of Reset and Sync messages as shown in Fig. 5.1 (a). Because the Reset(seq=0,ack=3) received in the REQUEST state is valid, the client initializes GSR and GAR. In TIMEWAIT the client does not update its GSR so that the acknowledgement number of DCCP-Reset sent is always zero and therefore less than the server’s GAR. Thus the DCCP-Reset packets sent are always invalid. 65

Client Server CLOSED CLOSED [active open] (ISS=2) REQUEST Request (seq = 2) (GSS,GSR,GAR) Request (seq = 3) (3,x,x) Rst (seq = 0, ack = 3) (ISS=2) TIMEWAIT [passive open] (3,0,3) LISTEN Response (seq=2,ack=2) Not update GSR,GAR RESPOND Rst (seq = 4, ack = 0) (2,2,2) (4,0,3) Sync (seq = 3, ack = 4) (3,2,2) Rst (seq = 5, ack = 0) (5,0,3) Sync (seq = 4, ack = 5) (4,2,2) Rst (seq = 6, ack = 0) (6,0,3) . . .

Client Server CLOSED CLOSED [active open] (ISS=2) (ISS=2) REQUEST Request (seq =2) CLOSED (GSS,GSR,GAR) Request (seq =3) (3,x,x) Rst(seq =0,ack =3) TIMEWAIT [passive open] . LISTEN . Response (seq=2,ack=2) . RESPOND . Rst (seq=3,ack=2) (2,2,2) . TIMEWAIT CLOSED . CLOSED

(a)

(b)

Figure 5.1: The chatter behaviour a) when the client in TIMEWAIT unsuccessfully attempts resetting the connection; b) when the client in TIMEWAIT successfully resets the connection. In practice, the message sequence does not last forever because the client holds TIMEWAIT for 2 MPL and the server should return to CLOSED after holding RESPOND for 4MPL. One solution to this problem could be to let the entities in TIMEWAIT update GSR and GAR. We have implemented this solution and tested the model. Updating GSR and GAR in TIMEWAIT does remove the problem. This result made us believe that our first interpretation was incorrect and there was an ambiguous interpretation on how to update GSR and GAR in TIMEWAIT. Thus we thought that the DCCP entity should update GSR and GAR in TIMEWAIT. During rearranging our CPN model according to an event-processing approach we found that a DCCP entity in the CLOSED, LISTEN and TIMEWAIT states behaves in a very similar way. Thus we suggested to IETF that it is not necessary for TIMEWAIT to maintain state variables because the connection is about to close. Fig. 5.1 (b) shows when the client in TIMEWAIT behaves as same as in CLOSED, it successfully resets the connection. This suggestion was also supported by our analysis results which showed a reduction of the state space size (from 42,192 to 26,859 nodes for the case of connection establishment) with no deadlocks nor livelocks. IETF agreed that TIMEWAIT should be classified in the same group as the CLOSED and LISTEN states [125].

66

5.1.6

Sequence number wrap (Chapter 9)

We included modulo 248 arithmetic for incrementing and comparing sequence numbers in our model and analysed the connection establishment procedures, concentrating on the region where sequence numbers wrap back to zero. The results for long sequence numbers in Chapter 9 were published at the 14th IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS2006) [207]. We discovered that the connection establishment procedure can fail, resulting in a half-open connection when the initial sequence number was close to the wrapping boundary. An ambiguity on how to update GSR when receiving DCCP-Sync or DCCPSyncAck According to RFC4340 [124] when a DCCP entity receives DCCP-Sync or DCCP-SyncAck, it shall update GSR in order to re-synchronise the state variables. What is the meaning of update? After examining the specification thoroughly, we believe that the specification can be interpreted in two possible ways. A: GSR is set equal to the received sequence number. B: GSR is set equal to the received sequence number only if the received sequence number is greater than the existing GSR. When the protocol operates over channels without loss and the sequence number does not wrap, the analysis results of both interpretations do not reveal deadlock, livelock or chatter. However, the size of the state spaces are slightly different. The CPN model in Chapter 9 used interpretation A. The additional state space analysis results for interpretation B when sequence number wraps are shown in Appendix E.1 (only long sequence numbers allowed) and Appendix E.2 (short sequence number also allowed). Interpretation B also provides the same time sequence diagrams as discussed in Chapter 9 section 9.5. When we applied the sweep-line method, we selected the interpretation B because GSR is monotonic which is preferable when using it as a progress measure. By generating the graph of Strongly Connected Components from the full state space, we also investigate if there are any livelocks, according to the methodology described in section 2.5.2, in all state spaces generated in Appendix E.1 and Appendix E.2. There are no livelocks in the analysis results.

67

5.1.7

Modelling Methodology (Chapter 10)

Since Internet Draft version 7 was released, our CPN model has been significantly revised. The model was not only refined but also restructured to faithfully reflect the DCCP definition in RFC 4340 to facilitate model validation. We decided that it was useful to publish this modelling experience. The paper [209] in Chapter 10 focusses on how the CPN model has evolved. We discuss the development of the architecture, data structures and specification style of the model. Through this iterative modelling process, we gain insight, better understanding of the system and uncover incompleteness and ambiguities as described in [209, 212]. Page limits prevented the complete CPN model from being included in [209], however, it has been possible to include the complete model in the journal paper [211] discussed below.

5.2 5.2.1

Sweep-line analysis Deriving new progress measures (Chapter 11)

The paper [211] in Chapter 11 extends our analysis results by using the sweep-line method. Unlike [69], [211] is different in three ways. Firstly, we analyse scenarios when sequence numbers wrap. Secondly, we discuss how the sweep-line method’s progress measures using 11 variables are derived. Thirdly, we are able to extend the analysis results using an augmented model in which we introduce 14 additional variables to track progress. This creates further state explosion but when used with the sweep-line method, the peak number of states is reduced by over two orders of magnitude. The reduction in the number of states stored in previous work such as [69, 72, 79] has never been greater than a factor of 10. Our results show that the proposed method can achieve a reduction of a factor of 270. Importantly the larger the state space, the more efficient the sweep-line technique is. We can obtain further results when using the progress measures discussed in [69, 72]. This paper [211] also contains the complete CPN model and its declarations. We believe this model provides a formal and precise representation of DCCP’s connection management and synchronisation procedures, suitable for analysis. It gathers together all the required information in one place, synthesizing the information obtained from different parts of RFC 4340, including the state diagram, narrative descriptions and the pseudo code (sections 7, 8 of [124]). It therefore also provides a major step towards implementation of DCCP’s connection management and synchronisation procedures. 68

5.2.2

Verification against DCCP’s service on-the-fly (Appendix A)

Language comparison [14, 21, 78, 81, 169] requires comparing two FSMs: one representing the protocol language and the other representing the service language. Both FSMs are normally derived from the full state spaces which are generated from the CPN models. While the state space of the service specification is often small, the state space of the protocol specification is often very large because it contains detailed procedures that are not observed by the upper layer. It is often that the full state space of the protocol specification may be too large to be stored in main memory (state explosion). Without the full state space, the standard approach (e.g. see [78]) using FSM tools [63] is not possible. The paper [70] in Appendix A discusses a way to compare languages without storing the full state space of the protocol specification. The idea of language comparison on-the-fly using the sweep-line method was originated by Billington who suggested it as a line of research to Kristensen [70] while he was working for the Computer Systems Engineering Centre. As well as focussing on the theory of using the sweep-line method to check safety properties on-the-fly, which was done by the other three authors, this paper [70] plays a significant role in this thesis because it contains the results of verifying the protocol language against the service language on-the-fly. Because RFC4340 does not include a service specification for DCCP, we defined DCCP’s service based on ISO conventions [100] and the work of Billington and Han [10, 17, 18, 81] and created the CPN model of the DCCP service contained in Appendix B. Discussion of the DCCP service definition is not included in this thesis due to its similarity to the work in [81]. The CPN model and its analysis in Appendix A is different from other papers included in this thesis in two respects. Firstly, the model includes a temporary state, RESPOND tmp, because we need two separate transitions: one for the server receiving the first DCCP-Request packet in LISTEN and the other for the server sending the first DCCP-Response packet. Secondly, the analysis of this paper included the nondeterministic use of both short and long sequence numbers while the other papers use only the long sequence numbers. We wrote ML functions for mapping binding elements to service primitives and conducted the experiments on language comparison on-the-fly using the sweep-line library which was developed by Gallasch. The author of this thesis analysed the data and wrote

69

sections 5.2 to 5.5 of [70] in conjunction with his supervisor. Analysis results show that the protocol language is a subset of the service language which means we did not find any illegal protocol sequences.

70

Part II Papers

71

Declaration for Chapter 6 Declaration by candidate In the case of Chapter 6, “Initial Result of a Formal Analysis of DCCP Connection Management”, the nature and extent of each author’s contributions to the work were the following: Nature of Contribution

Extent of Contribution (%)

The order of authorship

1st

2nd

1. Guarantor of integrity of entire study

40

60

2. Conceived the idea for the study

90

10

3. Developing the CPN model and related ML functions

90

10

4. Analysing and interpreting the experimental results

75

25

5. Manuscript preparation

85

15

6. Critical revision of the manuscript for

5

95

7. Manuscript editing

5

95

8. Final approval of the version of

5

95

0

100

important intellectual content

the manuscript to be published 9. Study supervision


Date

Declaration by co-author The undersigned hereby certify that: (1) the above declaration correctly reflects the nature and extent of the candidate’s contribution to this work, and the nature of the contribution of each of the co-authors. (2) they meet the criteria for authorship in that they have participated in the conception, execution, or interpretation, of at least that part of the publication in their field of expertise; (3) they take public responsibility for their part of the publication, except for the responsible author who accepts overall responsibility for the publication; (4) there are no other authors of the publication according to these criteria; (5) the co-author permits the publication to be included in this thesis.

Signature

Date 72

Chapter 6 Initial Result of a Formal Analysis of DCCP Connection Management Chapter 6 appears as an international conference paper, S. Vanit-Anunchai and J. Billington, “Initial Result of a Formal Analysis of DCCP Connection Management”, In Proceedings of the Fourth International Network Conference (INC 2004), pages 63-70, Plymouth, UK, 6-9 July 2004, University of Plymouth.

This chapter is a postprint of the paper which is subject to University of Plymouth Copyright. It is the same as the paper except for minor typographical changes. The text is re-published in this thesis according to the permission obtained from Professor Steven Furnell, University of Plymouth.

The homepage of the INC 2004 conference is http://www.network-research-group.org/PreviousINCEvents/inc2004/

73

Initial Result of a Formal Analysis of DCCP Connection Management S. Vanit-Anunchai and J. Billington Computer Systems Engineering Centre, University of South Australia Mawson Lakes Campus, SA 5095, Australia email:[email protected], [email protected]

Abstract A new protocol in the TCP/UDP family, the Datagram Congestion Control Protocol (DCCP), is designed to control congestion when considering delay sensitive applications. We believe it is useful to formally verify DCCP’s connection management procedures before they are implemented. We use Coloured Petri Nets (CPNs) to model these procedures. The CPN model is analyzed using reachability analysis which reveals an undesirable terminal state in the connection establishment procedure. Keywords DCCP, Formal Methods, Coloured Petri Nets, Reachability analysis

6.1

Introduction

An IETF working group [126] is currently developing a new transport protocol, the Datagram Congestion Control Protocol (DCCP), for delay sensitive applications such as streaming media, telephony and on-line games. The protocol is needed because the Internet’s current service can not provide satisfactory service quality for these applications. Many media applications attempt to avoid problems by using the User Datagram Protocol (UDP) which does not provide congestion control. The growth of applications not using congestion control is a serious threat to the Internet [113]. While data transfer can tolerate loss, the process of connection setup/tear down and negotiation of options/features is required to be reliable. Although the specification of DCCP is still work in progress, we believe that the DCCP connection management procedures are now essentially stable and require formal verification as soon as possible. In this paper we use Coloured Petri Nets (CPN) [105] to model the finite state machine (FSM) diagram and narrative description of DCCP connection management according to the draft specification [126]. We model DCCP packets using the packet type and include 74

sequence and acknowledgement numbers. The goal is to examine terminal states of DCCP connection management and to investigate if there are any deadlocks or livelocks. As far as we are aware this paper presents the first formal specification and analysis of DCCP connection management. The rest of the paper is organized as follows. Section 6.2 gives an informal description of DCCP connection management while sections 6.3 and 6.4 describe the CPN model and its functional analysis. Section 6.5 concludes this paper.

6.2

DCCP Connection Management

DCCP establishes connections between a client (the initiator) and a server. The connection management procedures of DCCP are defined by the state diagram shown in Fig. 6.1. It comprises eight states: CLOSED, LISTEN, REQUEST, RESPOND, OPEN,

rcv any but Request, Reset, and Ack/ DataAck with valid Init Cookie [send Reset]

rcv any but Reset [send Reset]

CLOSED

rcv Request app denies [send Reset]

app listens

rcv Request app accepts using Init Cookie [send Response with Init Cookie]

rcv Close [send Reset] [cancel timer]

LISTEN rcv Request app accepts [send Response] [set timer] [new socket]

rcv Reset [reset timer]

rcv Reset or app close or backoff fails [send Reset unless Reset received] [reset timer]

rcv Ack or DataAck with valid Init Cookie [new socket] rcv Ack or DataAck [cancel timer]

app close [send CloseReq] [set timer] rcv Close or backoff fails [send Reset] [cancel timer]

timer expires [send Request] [backoff timer]

REQUEST

rcv Close or timer expires [send Reset] [cancel timer]

RESPOND

app opens [send Request] [set timer]

rcv Response [send Ack or DataAck] [cancel timer] rcv Close [send Reset]

rcv Close [send Reset] [cancel timer]

OPEN app close (server only) [send CloseReq] [set timer] rcv Reset [set timer]

CLOSEREQ

timer expires [send CloseReq] [backoff timer]

rcv CloseReq (client only) or app close (either) [send Close] [set timer] timer expires [send Close] [backoff timer]

CLOSING

rcv Reset [reset timer]

rcv Reset or backoff fails [reset timer]

TIME−WAIT

rcv CloseReq [send Close] [restart timer]

rcv any but Reset [send Reset]

timer expires

Figure 6.1: DCCP connection management finite state machine from [126]

75

CLOSEREQ, CLOSING and TIME-WAIT. The LISTEN, RESPOND and CLOSEREQ states are for the server only while the REQUEST state is for the client only. The DCCP packet is a sequence of 32 bit words comprising header and data fields. DCCP header fields provide control information for establishing and closing a connection, congestion control, options/feature negotiation and guarding against misbehaviour or attack. A field in the header, packet type, specifies the type of message: Request, Response, Data, DataAck, Ack, CloseReq, Close, Reset, Move and Sync. Request and Response packets will initialize a 24 bit sequence number which is increased by one (modulo 224 ) with every packet sent including Ack packets. This allows DCCP to control congestion due to acknowledgements while TCP cannot. The acknowledgement number (24 bits) provides the greatest valid sequence number which has been received so far. Unlike cumulative acknowledgement in TCP, DCCP acknowledgements do not attempt to give information on which packets have not arrived, as delay sensitive dataflows, such as voice or video, will not be retransmitted. However DCCP has options regarding acknowledgements. For instance, the “Ack Vector” option can provide loss information on particular packets. These options are not included in our model which concentrates on the core functionality of DCCP initially. The typical connection management scenario is shown in Fig. 6.2. Connection setup starts when the DCCP application at the client issues an “application opens” command and the DCCP application at the server issues an “application listens” command. To establish a connection, DCCP uses a three way handshake similar to TCP. However, unlike TCP, DCCP does not support simultaneous open and its treatment of sequence numbers is different. Connection release starts when the server application issues an “application close” command. DCCP does not implement a graceful close (c.f. TCP), but closes both ends as quickly as possible, discarding any data that arrives in the closing states. The client holds on a reasonable period in the TIME-WAIT state to prevent acceptance of old duplicates that may otherwise cause difficulties for the next connection. There are another two scenarios for tearing down a connection as shown in Fig. 6.3. In the state diagram the “application close” command at the server is ambiguous as it can result in the server either sending a CloseReq or Close packet. In our model, we use “application close request” to inform the server to send a CloseReq packet and “application close” to inform the server to send a Close packet.

76

Client CLOSED [application opens]

Client OPEN

Server CLOSED [application Listens] LISTEN Request (seq=x)

Server OPEN [application close] CloseReq (seq = m, ack = n) CLOSEREQ

REQUEST

Close (seq = n+1, ack = m) CLOSING

Response (seq = y, ack=x) RESPOND

Reset (seq = m+1, ack = n+1) Ack (seq = x+1, ack = y)

CLOSED

OPEN

TIMEWAIT . . CLOSED

OPEN

(a)

(b)

Figure 6.2: Typical message sequence for DCCP connection a) setup b) close down

Client OPEN [application close] CLOSING

Client OPEN

Server OPEN


Close (seq = m, ack = n)

[application close] CLOSING

Reset (seq = n+1, ack = m)

Reset (seq = n+1, ack = m) CLOSED

CLOSED TIMEWAIT . . CLOSED

TIMEWAIT . . CLOSED

(a)

(b)

Figure 6.3: Two alternative message sequences for DCCP connection close down

6.3 6.3.1

CPN Model of DCCP Connection Management Modelling Assumptions and Interpretation of Specifications

In our model we assume the channel can delay and re-order packets but otherwise is lossless, error free and does not duplicate packets. The reason for not starting from a lossy channel is because a lossy channel can mask out inherent deadlocks of the model. The CPN model is based on the following interpretation of DCCP: 1. DCCP packets are modelled using the packet type and sequence and acknowledgement numbers. Other fields are not relevant for analysing the core functionality of DCCP. 2. Sync and Move packets are not included because they are not related to connection establishment. 3. The sequence number window and acknowledgement number window are large enough to contain every packet. Thus all packets in our model have a valid sequence number and a valid acknowledgement number except for Reset packets. 4. The Reset Packet is valid if and only if the sequence number is zero or greater than GSR (Greatest Sequence Number Received). This means only new Reset packets 77

are valid. However, when the entity is in the CLOSED or LISTEN state, no sequence number nor acknowledgement number is allocated for Reset packets. In this case both numbers are set to zero. 5. When the entity is in the CLOSED or LISTEN state and receives a Reset packet, it will ignore the Reset packet. 6. Retransmissions are as specified in the state diagram (Fig. 6.1). 7. As described in the specification (but not in Fig. 6.1), when the server is in the RESPOND state and receives the new valid Request packet, the server will reply with a Response packet. 8. The user issues four commands to the DCCP entity: “application opens”, “application listens”, “application close”, and “application close request”. “application close request” and “application close” are used at the server as indicated above. Moreover our model also includes the commands “application accepts” and “application denies”. 9. We do not use the GAR (Greatest Acknowledgement Number Received) variable which is considered optional in the specification. 10. When the entity receives an improper packet, according to the specification the entity could either answer with a Reset packet or ignore it. In our initial model, we assume the entity ignores improper packets. This assumption will be relaxed in future work.

6.3.2

CPN model

Coloured Petri Nets [105] are a graphical modelling language for design, verification and analysis of distributed, concurrent and complex systems. CPNs include hierarchical constructs that allow modular specifications to be created. Design/CPN [202] is a software tool used to create, maintain, simulate and analyse CPNs. We use Design/CPN to create and analyse our DCCP model using reachability analysis. Our structure for the DCCP CPN model is strongly influenced by [83] who model and analyse TCP connection management. However the procedures and results obtained are quite different. Our CPN model comprises three hierarchical levels, as shown in Fig. 6.4 a). The first level is named DCCP. This level calls a page named DCCP CM (DCCP connection management) at the second level. The third level has eight pages, each of which is named by a DCCP state. Figure 6.4 b) shows the Global Declarations which define the data associated with the CPN. The top level, corresponding to DCCP#1 in the hierarchy page, is the DCCP Overview page as shown in Fig. 6.5. It is a CPN diagram 78

Hierarchy#10010

DCCP#1

Declarations#11

M Prime

DCCP_C DCCP_S

DCCP_CM#2

color INT = int;

Closed

CLOSED#3 LISTEN#4

Listen

REQUEST#5

Request

RESPOND#6

Respond

OPEN#7

Open

CLOSEREQ#8

CloseReq

CLOSING#9

Closing

TimeWai1#10

TimeWait

color PacketType = with Request | Response | Ack | Data | DataAck | CloseReq | Close | Rst | Move | Sync; color SeqAck = record SEQ:INT*ACK:INT; color PACKET = product PacketType*SeqAck; color STATE = with CLOSED | LISTEN | RESPOND | OPEN | CLOSEREQ | TIMEWAIT | REQUEST | CLOSING; color BackOffFlag = with ON | OFF; color GS = record GSS:INT*GSR:INT; color DCCB = product STATE*BackOffFlag*GS; color APP_CMD = with appListens | appOpens |appAccepts | appDenies| appClose | appCloseReq; var p:PacketType; var seq_ack:SeqAck; var s:STATE; var flag:BackOffFlag; var gs:GS; var a:APP_CMD;

(a)

(b)

Figure 6.4: a) Hierarchy page b) Global Declarations 1‘appOpens

1‘appListens

APP_C

APP_S

APP_CMD

APP_CMD CH_c-s

1‘(CLOSED,OFF, {GSS=100,GSR=0}) CState DCCB

1‘(CLOSED,OFF, {GSS=4000,GSR=0})

PACKETS DCCP_C HS

DCCP_CM#2 CH_c-s->CH_A-B CState->State CH_s-c->CH_B-A APP_C->App_A

DCCP_S HS

CH_s-c PACKETS

SState DCCB

DCCP_CM#2 CH_s-c->CH_A-B SState->State APP_S->App_A CH_c-s->CH_B-A

Figure 6.5: The first level page (DCCP page)

comprising places (represented by ellipses), two substitution transitions (represented by rectangles with an HS tag) and arcs which connect places to transitions and vice versa. The client is on the left and the server on the right and they communicate via two channels, shown in the middle of Fig. 6.5. We model a unidirectional and re-ordering channel by places named CH c-s and CH s-c which are typed by PACKET. PACKET is a product set, defined in Fig. 6.4 b). It comprises the PacketType and SeqAck sets (representing sequence and acknowledgement numbers) also defined in Fig. 6.4 b). Through these places, tokens, which are values taken from the type of the place and represent packets, are transferred between DCCP entities. Places, CState and SState, typed by DCCB (see Fig. 6.4 b), model DCCP state information. The colour set DCCB is defined as

79

a product comprising colour sets STATE, BackOffFlag (back-off timer flag), and GS. The colour set GS is defined as a record of GSS (Greatest Sequence Number Sent) and GSR (Greatest Sequence Number Received). Places named APP C and APP S, typed by APP CMD, model DCCP user commands as discussed in section 2. Tokens associated with these places shown on the top of ellipses, for example “1‘appOpens”, are called initial markings. They represent the initial state of the system. The substitution transitions DCCP C and DCCP S in Fig. 6.5 are linked to the second level page named DCCP CM in Fig. 6.6 a). The DCCP CM organizes the DCCP connection management process into a further eight substitution transitions. Each such transition is named by a DCCP state and linked with a page in the third level. These third level pages model client and server behaviour for each state. Space limits prevent us from including each of these pages, but a representative example is given in Fig. 6.6 b). The figure shows the level of detail required to capture the procedures to be followed by the client in the REQUEST state. It comprises all the state transitions of Fig. 6.1, including details from the narrative description of DCCP, and assumes that any other packets received will be discarded.

6.4 6.4.1

Analysis of DCCP Connection Establishment Initial configuration

We analyze the DCCP connection management protocol using Design/CPN4.0.5 [202] on a Pentium-III 1 GHz computer with 512MB RAM. We can analyze various scenarios by changing the initial markings in the DCCP page. Due to space limitations, we only discuss the case of connection establishment when both entities are in the CLOSED state, the user places (APP C, APP S) contain commands “application opens” and “application listens” respectively and the channel places are empty as shown in Fig. 6.5.

6.4.2

Investigation of Terminal States

Table 6.1 summarizes the result of state space analysis using the occurrence graph tool [202]. The occurrence graph (OG) has 1268 nodes and 3032 arcs. There are 45 terminal states which are the leaf nodes of the OG, also known as dead markings. The last column shows the number of terminal states which have the same pair of client/server states but different values for GSS and GSR. In all cases nothing is left in the channels. 80

P

In

App_A HS

APP_CMD

CH_A-B

Closed

P Out

PACKETS

Listen HS

Request HS

Respond HS

Open HS

P I/O

CloseReq

State

HS

DCCB

Closing HS

TimeWait HS

P In

CH_B-A PACKETS

(a) P In

APP_A appClose

APP_CMD P Out (REQUEST,t,gs)

(Rst,{SEQ=#GSS(gs)+1,ACK=#GSR(gs)})

OUTPUT

AppClose (TIMEWAIT,OFF,{GSS=#GSS(gs)+1,GSR=#GSR(gs)})

PACKETS

(REQUEST,t,gs) Rcv_Rst if #SEQ(seq_ack) > #GSR(gs) orelse #SEQ(seq_ack)=0 then 1‘(TIMEWAIT,OFF,{GSS=#GSS(gs),GSR=#SEQ(seq_ack)}) else 1‘(REQUEST,t,gs) P I/O (REQUEST,t,gs) Rcv_Response

STATE DCCB

(Rst,seq_ack) if #SEQ(seq_ack) > #GSR(gs) then 1‘(Ack,{SEQ=#GSS(gs)+1,ACK=#SEQ(seq_ack)}) else 1‘(Ack,{SEQ=#GSS(gs)+1,ACK=#GSR(gs)}) (Response,seq_ack)

if #SEQ(seq_ack) > #GSR(gs) then 1‘(OPEN,OFF,{GSS=#GSS(gs)+1,GSR=#SEQ(seq_ack)}) else 1‘(OPEN,OFF,{GSS=#GSS(gs)+1,GSR=#GSR(gs)}) (REQUEST,t,gs) Rcv_Close

if #SEQ(seq_ack) > #GSR(gs) then 1‘(Rst,{SEQ=#GSS(gs)+1,ACK=#SEQ(seq_ack)}) else 1‘(Rst,{SEQ=#GSS(gs)+1,ACK=#GSR(gs)}) (Close,seq_ack)

if #SEQ(seq_ack) > #GSR(gs) then 1‘(CLOSED,OFF,{GSS=#GSS(gs)+1,GSR=#SEQ(seq_ack)}) else 1‘(CLOSED,OFF,{GSS=#GSS(gs)+1,GSR=#GSR(gs)}) (REQUEST,OFF,gs)

(Request,{SEQ=#GSS(gs)+1,ACK=#GSR(gs)}) TimerExpires

(REQUEST,ON,{GSS=#GSS(gs)+1,GSR=#GSR(gs)})

(REQUEST,ON,gs) (TIMEWAIT,OFF,{GSS=#GSS(gs)+1, GSR=#GSR(gs)})

(REQUEST,t,gs)

(Rst,{SEQ=#GSS(gs)+1,ACK=#GSR(gs)}) BackOffFails

[pRst andalso p Response andalso p Close] Rcv_Other

INPUT (p,seq_ack)

(REQUEST,t,gs)

P In PACKETS

(b)

Figure 6.6: a) The DCCP CM page b) The Request page

81

Table 6.1: Terminal States for DCCP Connection Establishment Class 1 2 3 4

Client’s State OPEN CLOSED CLOSED CLOSED

Server’s State OPEN LISTEN CLOSED OPEN

Number of Dead Markings 4 3 37 1

There are four different classes of terminal states. The first class of four terminal states is the desired dead markings where both client and server are OPEN. The second class of three terminal states is when the client is CLOSED, but the server is in LISTEN. This can occur when the server is down (initially CLOSED) when it receives the request from the client. The server resets the connection (so that the client is CLOSED) and then moves into the LISTEN state, when the server recovers. The third class occurs when the request or response is so delayed that the connection setup fails with both entities in CLOSED. A scenario is shown in Fig. 6.7 a). The fourth class comprises one undesired terminal state, when the server is OPEN but the client is CLOSED, as shown in Fig. 6.7 b). This happens because the server receives the first Request packet while it is CLOSED, and responds with a Reset packet with a sequence number of zero. This Reset packet is delayed so that it comes as the last packet in the connection setup sequence. Having not received the Response packet in time, the client times out and sends a second Request packet. Before the second Request packet arrives, the server receives an “application listens” command and enters the LISTEN state. The connection setup procedure continues until both entities are in the OPEN state. Finally the Reset packet arrives at the client, which enters TIME-WAIT and then returns to CLOSED, leaving the connection unsynchronised. If the client has not sent an application-level request in its Ack packet, then the system is deadlocked, as the server will be waiting for the client’s request. The client will interpret the reset as indicating that the server is currently down and hence will not attempt to reconnect for sometime. Even when it does try again, the server will either ignore the new request or send a reset, as it is in the Open state. This will further frustrate the client. If the client does make an application-level request in its Ack packet, the server will send a packet (such as DataAck) to the client, which being in the CLOSED state, will reply with a Reset packet. This will result in the server returning to CLOSED. The client will then need to re-establish the connection. As indicated in the DCCP specification, the server, when in the LISTEN state, may be so busy that it responds to the Request packet with 82

a)

b)

Figure 6.7: Message sequence a) One scenario of class 3 b) class 4

a Reset packet. This increases the possibility of this unsatisfactory situation occurring. A new version (version 6) of DCCP was released on 16 February 2004, three months after the submission of this paper. It uses GAR to validate the Reset packet. We have revised our CPN model of DCCP to align with version 6. Our analysis reveals that the new version no longer has this problem.

6.5

Conclusion

This paper has presented an abstract, formal specification and initial analysis of version 5 of DCCP connection management using Design/CPN. We discovered an undesirable terminal state which has since been corrected in the latest version of DCCP. Future work will include an analysis of the closing procedures. We are also interested in modelling and analysing the procedure for Options/Features negotiation and misbehaviour attack, and in relaxing some modelling assumptions. In particular, it will be important to analyse the procedures when the channels are lossy.

83

Declaration for Chapter 7 Declaration by candidate In the case of Chapter 7, “Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol”, the nature and extent of each author’s contributions to the work were the following: Nature of Contribution



1st

2nd

3rd


40

60

0


80

20

0


65

15

20


70

25

5


85

10

5


5

95

0


5

95

0


5

95

0

0

100

0




Date

Declaration by co-author The undersigned hereby certify that: (1) the above declaration correctly reflects the nature and extent of the candidate’s contribution to this work, and the nature of the contribution of each of the co-authors. (2) they meet the criteria for authorship in that they have participated in the conception, execution, or interpretation, of at least that part of the publication in their field of expertise; (3) they take public responsibility for their part of the publication, except for the responsible author who accepts overall responsibility for the publication; (4) there are no other authors of the publication according to these criteria; (5) the co-authors permit the publication to be included in this thesis. Signature

Date

Signature

Date 84

Chapter 7 Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol Chapter 7 appears as a published journal paper, S. Vanit-Anunchai, J. Billington and T. Kongprakaiwoot, “Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol”, In F.Wang, editor, Proceedings of the 25th IFIP WG 6.1 International Conference on Formal Techniques for Networked and Distributed Systems (FORTE 2005), volume 3731 of Lecture Notes in Computer Science, pages 143-158, Taipei, Taiwan, 2-5 October 2005, Springer, Heidelberg. The difference between this version and that published in LNCS concerns section 3.5 of the paper. After email discussions with Dr Kohler, one of the editors of DCCP, we agree that we overlooked the reference to initialising GAR to ISS when the variable was first defined in the declarations at the top of section 8.5 (Pseudocode) of DCCP version 11. Hence, DCCP is not incomplete in this way. Thus we have deleted the last paragraph of section 3.5 in this version. We fully agree with Dr Kohler that it would be clearer to insert this initialisation in Step 3 of the pseudocode (LISTEN state) after the “Choose S.ISS” line. Further, we believe that this only needs to apply to the SERVER, as the first value of GAR at the CLIENT will be the ACK number of the received Response packet, which is not necessarily equal to ISS, as the first request could have been lost and another one sent and responded to with a higher sequence number. Hence we believe that the global initialisation of GAR in the declarations can be safely removed, once GAR is initialised in Step 3.

85

The copyright of this text belongs to Springer-Verlag. The text is re-published in this thesis according to the permission stated in http://www.springer.de/comp/lncs/copyright.html The homepage of LNCS series is http://www.springer.de/comp/lncs/index.html

86

Discovering Chatter and Incompleteness in the Datagram Congestion Control Protocol Somsak Vanit-Anunchai1 , Jonathan Billington1 and Tul Kongprakaiwoot2 1 Computer

Systems Engineering Centre, University of South Australia Mawson Lakes Campus, SA 5095, Australia email:[email protected], [email protected] 2 TextMe Co., Ltd., 20 North Sathorn Rd, Bangkok 10500, Thailand email:[email protected]

Abstract A new protocol designed for real-time applications, the Datagram Congestion Control Protocol (DCCP), is specified informally in a final Internet Draft that has been approved as an RFC (Request For Comment). This paper analyses DCCP’s connection management procedures modelled using Coloured Petri Nets (CPNs). The protocol has been modelled at a sufficient level of detail to obtain interesting results including pinpointing areas where the specification is incomplete. Our analysis discovers scenarios where the client and server repeatedly and needlessly exchange packets. This creates a lot of unnecessary traffic, inducing more congestion in the Internet. We suggest a modification to the protocol that we believe solves this problem.

Keywords: DCCP, Internet Protocols, Coloured Petri Nets, State space methods.

7.1

Introduction

Streaming media applications and online games are becoming increasingly popular on the Internet. Because these applications are delay sensitive, they use the User Datagram Protocol (UDP) rather than the Transmission Control Protocol (TCP). The users then implement their own congestion control mechanisms on top of UDP or may not implement any control mechanism at all. The growth of these applications therefore poses a serious threat to the Internet. To tackle this problem, an Internet Engineering Task Force (IETF) working group is developing a new transport protocol, called the Datagram Congestion Control Protocol (DCCP) [113,115,120,126]. The purpose of DCCP is to support various 87

congestion control mechanisms that suit different applications. It therefore could replace TCP/UDP for delay sensitive applications and become the dominant transport protocol in the Internet. Hence we consider that it is important to verify DCCP as soon as possible, to remove errors and ambiguities and ensure its specification is complete before implementation. In this paper, Coloured Petri Nets (CPNs) [105] are used to model and analyse DCCP’s connection management procedures. We chose CPNs because they are used widely to model and analyse concurrent and complex systems [12, 107] transport protocols like TCP [14, 83]. We have previously applied our methodology [14] to earlier versions of DCCP. We demonstrated [206] that a deadlock occurs in DCCP version 5 [126] during DCCP connection setup. Further work [128] upgraded the model to version 6 [115] and also discovered undesired terminal states. These models [128,206] were incomplete, in that they did not include DCCP’s synchronisation procedures, which are used in conjunction with connection management. As far as we are aware, this paper describes the first formal specification of DCCP’s connection establishment, close down and synchronisation procedures for version 11 [120] of the specification. Further, using a set of initial configurations, we incrementally analyse the connection management procedures including the synchronisation mechanism. Although no deadlock or livelock is found, we discover some chatter in the protocol where both ends repeatedly exchange packets, creating a lot of unnecessary traffic. We canvass a possible solution to this problem. A further contribution of this paper is the identification of areas where the specification is incomplete. This paper is organised as follows. To make the paper self-contained, section 7.2 summarises DCCP’s connection management procedures. The CPN model of DCCP is illustrated in section 7.3, which starts with a statement of scope and modelling assumptions, and closes with a discussion of areas of incompleteness in the specification. Section 7.4 presents our analysis results and section 7.5 summarises our work.

7.2

Datagram Congestion Control Protocol

DCCP [120] is a connection oriented protocol designed to overcome the problem of uncontrolled UDP traffic. The connection management procedures have some similarities with TCP, with some states being given the same names. However, DCCP’s procedures are substantially different from those of TCP. For example, connection establishment uses 88

a 4-way handshake (rather than 3), there is no notion of simultaneously opening a connection, connection release is simpler, as it does not aim to guarantee delivery of data in the pipeline, and the use of sequence numbers is quite different. There is also a procedure which allows a server to request that the client closes the connection and waits for 2 Maximum packet lifetimes (MPL) to ensure all old packets are removed, before a new instance of the connection can be established, rather than the server having to wait for this period. Further, DCCP includes procedures for resynchronising sequence numbers. This section summarises the key features of DCCP connection management that we wish to model and analyse.

7.2.1

DCCP Packet Format

Like TCP, DCCP packets comprise a sequence of 32 bit words as shown in Fig. 7.1. The DCCP header contains 16 bit source and destination port numbers, an 8 bit data offset, a 16 bit checksum and sequence and acknowledgement numbers in a very similar way to TCP. However, there are significant differences. DCCP defines 10 packets that are encoded using a 4 bit Packet Type field, rather than the control bits used in TCP (for SYN, FIN, RST, ACK). The packets are: Request, Response, Data, DataAck, Ack, CloseReq, Close, Reset, Sync and SyncAck. Sequence (and acknowledgement) numbers are 48 bits long (instead of 32 bits) and number packets rather than octets. The sequence number of a DCCP-Data, DCCP-Ack or DCCP-DataAck packet may be reduced to 24 bits by setting the X field to 0. CCVal, a 4 bit field, contains a value that is used by the chosen congestion control mechanism [120]. Checksum Coverage (CsCov), also a 4 bit field, specifies how much of the packet is protected by the 16 bit Checksum field. Finally, the Options field can contain information such as Cookies and time stamps but also allows DCCP applications to negotiate various features such as the Congestion Control Identifier (CCID) and the size (width) of the Sequence Number validity window [120].

7.2.2

Connection Management Procedures

The state diagram, shown in Fig. 7.2, illustrates the connection management procedures of DCCP. It comprises nine states rather than TCP’s eleven states. The typical connection establishment and close down procedures are shown in Fig. 7.3. Like TCP, a connection is initiated by a client issuing an “active open” command. We assume that the application at the server has issued a “passive open” command. After receiving the “active open”,

89

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

Source Port

Data Offset

Res

Packet X Type = 1

Destination Port

CcVal CsCov

Reserved

Checksum


Sequence Number (low bits)

Reserved

Acknowledge Number


Options and Padding

Application Data

Figure 7.1: DCCP Packet Format. +---------------------------+ +---------------------------+ | v v | | +----------+ | | +-------------+ CLOSED +------------+ | | | passive +----------+ active | | | | open open | | | | snd Request | | | v v | | +----------+ +----------+ | | | LISTEN | | REQUEST | | | +----+-----+ +----+-----+ | | | rcv Request rcv Response | | | | snd Response snd Ack | | | v v | | +----------+ +----------+ | | | RESPOND | | PARTOPEN | | | +----+-----+ +----+-----+ | | | rcv Ack/DataAck rcv packet | | | | | | | | +----------+ | | | +------------>| OPEN |Ch_A_B App_Client->App_A Client_State->State Ch_S_C->Ch_B_A

Ch_S_C

DCCP_CM#2 Ch_S_C->Ch_A_B App_Server->App_A Server_State->State Ch_C_S->Ch_B_A

PACKETS

Figure 7.6: The DCCP Overview Page.

1 color PacketType1 = with Request | Data; 2 color PacketType2 = with Sync | SyncAck | Response | Ack | DataAck | CloseReq | Close | Rst; 3 var p_type1:PacketType1; 4 var p_type2:PacketType2; 5 color SN = IntInf with ZERO..MaxSeqNo;

var sn:SN;

6 color SN_AN = record SEQ:SN*ACK:SN;

var sn_an:SN_AN;

7 color PacketType1xSN = product PacketType1*SN; 8 color PacketType2xSN_AN = product PacketType2*SN_AN; 9 color PACKETS = union PKT1:PacketType1xSN+PKT2:PacketType2xSN_AN;

Figure 7.7: Definition of DCCP PACKETS.

the right and they communicate via two channels, shown in the middle of Fig. 7.6. We model unidirectional and re-ordering channels from the client to the server and vice versa by places named Ch C S and Ch S C which are typed by PACKETS. Fig. 7.7 declares PACKETS (line 9) as a union of packets with and without acknowledgements. Places, Client State and Server State, typed by CB (Control Block), store DCCP state information. Fig. 7.8 defines CB (line 5) as a product comprising STATE, RCNT (Retransmit Counter), GS (Greatest Sequence Number) and ISN (Initial Sequence Number). Places named App Client and App Server, typed by COMMAND, model DCCP user commands. Fig. 7.8 also defines COMMAND (line 6). Tokens associated with these places shown on the top of ellipses, for example “a Open”, are called initial markings. They represent the initial state of the system.

97

1 color STATE = with CLOSED | LISTEN | REQUEST | RESPOND | PARTOPEN | S_OPEN | C_OPEN | CLOSEREQ | CLOSING | TIMEWAIT; 2 color RCNT = int;

var rcnt:RCNT; (*Retransmit Counter *)

3 color GS = record GSS:SN*GSR:SN*GAR:SN;

var g:GS;

4 color ISN = record ISS:SN*ISR:SN;

var isn:ISN;

5 color CB = product STATE*RCNT*GS*ISN; 6 color COMMAND = with p_Open | a_Open | server_a_Close | a_Close;

Figure 7.8: DCCP’s Control Block and User Commands.

7.3.4

Second, Third and Fourth Level Pages

The substitution transitions DCCP C and DCCP S in Fig. 7.6 are linked to the second level page named DCCP CM (as shown in Fig. 7.5). DCCP CM is organized into a further ten substitution transitions linked to the third level pages, representing the processing required in each DCCP state. We group the transitions that have common functions into the fourth level pages. In particular, we model the behaviour of DCCP in the RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING states when receiving DCCP-Reset and DCCP-Sync packets into pages named Reset Rcv and Sync Rcv pages under the Common Processing page in the third level. The RcvOthPkt page models DCCP’s behaviour in the OPEN, CLOSEREQ and CLOSING states when receiving packets other than DCCPCloseReq, DCCP-Closing, DCCP-Reset, DCCP-Sync and DCCP-SyncAck. Space limits prevent us from including all pages, but a representative example is given in Fig. 7.9. The figure shows the level of detail required to capture the procedures to be followed by both the client and the server when receiving the DCCP-Sync and DCCP SyncAck packets. Fig. 7.10 shows functions incr(), Update() and PktValid() used in the Sync Rcv page.

7.3.5

Incompleteness in the Specification

User commands appear in the state diagram of Fig. 7.2 but the specification [120] does not provide any detail. As stated in version 5 [126], the application may try to close during connection establishment. Thus an “active close” command could occur in the REQUEST, RESPOND, PARTOPEN and OPEN states. Similarly, at the server, a “serve active close” command could also occur in the RESPOND and OPEN states. We assume this to be the case in our model, but do not analyse it in this paper.

98

[state = RESPOND orelse state = S_OPEN orelse state = C_OPEN orelse state = PARTOPEN orelse state = CLOSEREQ orelse state = CLOSING] (state, rcnt, g, isn)

RcvSync

State CB

(PARTOPEN,rcnt,g,isn)

P Out

Output

PKT2(Sync,sn_an)

if PktValid(Sync,sn_an,g,isn) then (state,rcnt,{GSS=incr(#GSS(g)), GSR=#SEQ(sn_an), GAR=#GAR(g)}, isn) else (state,rcnt,g, isn)

P I/O

if PktValid(Sync, sn_an, g, isn) then 1‘PKT2(SyncAck,{SEQ=incr(#GSS(g)), ACK=#SEQ(sn_an)}) else empty

PACKETS

RcvSyncAckIn PARTOPEN

PKT2(SyncAck,sn_an) if PktValid(SyncAck,sn_an,g,isn) then (C_OPEN, 0,{GSS=#GSS(g), GSR=#SEQ(sn_an), GAR=Update(#GAR(g), #ACK(sn_an))}, isn) [state = RESPOND orelse state = C_OPEN else (PARTOPEN,rcnt,g,isn) orelse state = S_OPEN orelse state = CLOSEREQ orelse state = CLOSING] (state,rcnt,g,isn)

P In

RcvSyncAck

Input PKT2(SyncAck,sn_an)

if PktValid(SyncAck,sn_an,g,isn) then (state,rcnt,{GSS=#GSS(g), GSR=#SEQ(sn_an), GAR=Update(#GAR(g), #ACK(sn_an))},isn) else (state,rcnt,g,isn)

PACKETS

Figure 7.9: The Sync Rcv Page.

7.4 7.4.1

Analysis of DCCP CPN Model Initial configuration

Using an incremental approach [14] we analyse different connection management scenarios by choosing a number of different initial markings. This is to gain confidence in the model and to provide insight into DCCP’s behaviour. In this paper we limit the maximum number of retransmissions to one to make the generation of the state space tractable. We analyse the DCCP model using Design/CPN 4.0.5 on a Pentium-IV 2 GHz computer with 1GB RAM. Initial markings of each scenario are shown in Table 7.2. Case I is for connection establishment. The client and server are both CLOSED with ISS set to five. The client issues an “active Open” command while the server issues a “passive Open” command. There are five scenarios of connection termination when both ends are in the OPEN state. Cases II, III and IV model the case when only one end issues a close command. Cases V and VI represent the simultaneous close scenarios when both ends issue close commands at the same time. Each end has the initial values of GSS, GSR and GAR shown in Table 7.2, and the channels are empty.

99

1 fun incr(sn:SN) = if (sn = MaxSeqNo)

then ZERO

else IntInf.+(sn, ONE);

2 fun Update(new:SN,old:SN) = if (IntInf.>(new,old)) then new else old; 3 val W

= IntInf.fromInt(100); val AW = IntInf.fromInt(100);

4 fun SeqValid(p_type2:PacketType2, s2:SN_AN, g:GS, isn:ISN) = 5 let

(* Sequence Number Validity *)

6 val SWL=IntInf.max(IntInf.-(IntInf.+(#GSR(g),ONE), 7

IntInf.div(W,IntInf.fromInt(4))),#ISR(isn));

8 val SWH=IntInf.+(IntInf.+(#GSR(g),ONE), 9

RealToIntInf 0((IntInfToReal 4 W)*3.0/4.0+0.5));

10 in

case p_type2 of Response => IntInf.>=(#SEQ(s2),SWL)

11

andalso IntInf.

IntInf.>=(#SEQ(s2),SWL) andalso IntInf.

IntInf.>=(#SEQ(s2),SWL) andalso IntInf. IntInf.>(#SEQ(s2),#GSR(g)) andalso IntInf.

IntInf.>(#SEQ(s2),#GSR(g)) andalso IntInf.

IntInf.>(#SEQ(s2),#GSR(g)) andalso IntInf.

IntInf.>=(#SEQ(s2),SWL)

18

| SyncAck =>

IntInf.>=(#SEQ(s2),SWL)

19

| _ => false

20

end;

21 fun AckValid(p_type2:PacketType2, s2:SN_AN, g:GS, isn:ISN) = 22

let

(* Acknowledgement Number Validity*)

23

val AWL = IntInf.max(IntInf.-(IntInf.+(#GSS(g),ONE),AW),#ISS(isn));

24

val AWH = #GSS(g);

25 in

case p_type2 of Response =>

26

IntInf.>=(#ACK(s2),AWL) andalso IntInf.


IntInf.>=(#ACK(s2),AWL) andalso IntInf. IntInf.>=(#ACK(s2),#GAR(g)) andalso IntInf.

IntInf.>=(#ACK(s2),#GAR(g)) andalso IntInf.

IntInf.>=(#ACK(s2),#GAR(g)) andalso IntInf.


IntInf.>=(#ACK(s2),AWL) andalso IntInf. false

35 end; 36 fun PktValid(p_type2:PacketType2, s2:SN_AN, g:GS, isn:ISN) = 37

SeqValid(p_type2:PacketType2,s2:SN_AN,g:GS,isn:ISN)

38

andalso AckValid(p_type2:PacketType2,s2:SN_AN, g:GS, isn:ISN);

Figure 7.10: Functions used in the Sync Rcv Page.

7.4.2

State Space Results

Table 7.3 summarizes the state space statistics. The last column shows the number of terminal states which have the same pair of states but different value of GSS, GSR and GAR. In all cases nothing is left in the channels. In case I, connection establishment, there are three different types of terminal states. The first type is desired when both ends are in OPEN. The second type is when both

100

Table 7.2: Initial Configurations. Case

App Client

App Server

I

1‘a Open

1‘p Open

II

1‘a Close

IV

1‘Server a Close

VI

1‘a Close

1‘a Close

Server State

CLOSED

CLOSED

GSS=0,GSR=0,GAR=0

GSS=0,GSR=0,GAR=0

ISS=5,ISR=0

ISS=5,ISR=0

OPEN

OPEN

GSS=200,GSR=200,GAR=200

GSS=200,GSR=200,GAR=200

OPEN

OPEN

GSS=200,GSR=200,GAR=200

GSS=200,GSR=200,GAR=200

OPEN

SOPEN

GSS=200,GSR=200,GAR=200

GSS=200,GSR=200,GAR=200

1‘a Close

III

V

Client State

1‘a Close

OPEN

OPEN

GSS=200,GSR=200,GAR=200

GSS=200,GSR=200,GAR=200

1‘Server

OPEN

OPEN

a Close

GSS=200,GSR=200,GAR=200

GSS=200,GSR=200,GAR=200

Table 7.3: State Space Results. Case

I

Nodes

171,040

Arcs

457,535

Time

Dead Markings

(sec)

Client State

Server State

Number

1,067

OPEN

OPEN

67

CLOSED

CLOSED

1,153

CLOSED

LISTEN

4

II

73

119

0

CLOSED

CLOSED

8

III

73

119

0

CLOSED

CLOSED

8

IV

30,787

76,796

62

CLOSED

CLOSED

645

V

3,281

8,998

3

CLOSED

CLOSED

64

VI

>545,703

>1,475,936

>152,200

CLOSED

CLOSED

>702

VI a)

437

828

0

CLOSED

CLOSED

33

VI b)

3,324

8,381

3

CLOSED

CLOSED

89

VI c)

33,644

85,926

74

CLOSED

CLOSED

642

ends are CLOSED. This can occur when the request or response is sufficiently delayed so that the Back-off timer expires, closing the connection. The third type is when the client is CLOSED, but the server is in the LISTEN state. This situation can happen when the server is initially CLOSED and thus rejects the connection request. After that the server recovers and moves to the LISTEN state. Although we are unable to obtain the full state space for case VI because of state explosion, we can obtain partial state spaces. Case VI a) is when there is no retransmission. Case VI b) is when only one DCCP-Close is 101

retransmitted. Case VI c) is when only one DCCP-CloseReq is retransmitted. Cases II, III, IV, V, VI a), VI b) and VI c) have only one type of terminal state when both ends are in CLOSED. The Strongly Connected Component (SCC) graphs of all cases (except case VI) were generated. The size of each SCC graph is the same as the size of the state space. This indicates that there are no cycles and hence no livelocks in the state spaces.

7.4.3

DCCP Chatter during Connection Establishment.

Further analysis of case I shows that the state space size grows almost linearly with ISS, as illustrated in Table 7.4. We have investigated how ISS affects the state space size and found an interesting result. Fig. 7.11 shows a trace illustrating chatter for the case when ISS=2. The values in brackets, for instance (7,2,3), are (GSS,GSR,GAR). The server, in the CLOSED state, repeatedly sends a sequence-invalid DCCP-Reset packet while the client in PARTOPEN repeatedly responds with DCCP-Sync. The sequence and acknowlTable 7.4: Growth of the State Space as a Function of ISS. ISS

1

2

3

4

5

Nodes

86,058

104,464

124,763

146,955

171,040

Arcs

225,485

275,540

330,900

391,565

457,535

Time

Dead Markings

(sec)

Client State

Server State

Number

325

OPEN

OPEN

67

CLOSED

CLOSED

733

CLOSED

LISTEN

4

OPEN

OPEN

67

CLOSED

CLOSED

823

CLOSED

LISTEN

4

OPEN

OPEN

67

CLOSED

CLOSED

923

CLOSED

LISTEN

4

OPEN

OPEN

67

CLOSED

CLOSED

1,022

CLOSED

LISTEN

4

OPEN

OPEN

67

CLOSED

CLOSED

1,153

CLOSED

LISTEN

4

457

596

785

1,067

102

Client Server CLOSED CLOSED [active open] [passive open] REQUEST Request (seq =2) LISTEN (GSS,GSR,GAR) (GSS,GSR,GAR) Request (seq =3) REQUEST (x,3,x) (3,x,x) Response(seq =2,ack =3) RESPOND PARTOPEN Ack (seq = 4,ack=2) (2,3,x) (4,2,3) Time Out Rst (seq =3, ack =3) CLOSED Rst (seq = 0, ack = 2) Sync (seq = 5,ack=0) (5,2,3) Rst (seq = 1, ack = 5) CLOSED Sync (seq = 6,ack=1) (6,2,3) Rst (seq = 2, ack = 6) CLOSED Sync (seq = 7,ack=2) (7,2,3) Rst (seq = 3, ack = 7) CLOSED TIME-WAIT CLOSED Rst (seq = 3, ack = 4)

Figure 7.11: Repeatedly Exchanged Messages for Case I with ISS=2.

edgement numbers in both packets increase over time until the sequence number of the DCCP-Reset received is greater than the client’s GSR and becomes sequence-valid according to Table 7.1. Fig.7.11 shows the sequence number of the DCCP-Reset generated increases from zero to three while the client’s GSR is equal to two. When receiving the sequence-valid DCCP-Reset (with seq=3), the client enters the TIMEWAIT state and then CLOSED after 2 MPL. A similar situation happens when the server enters the LISTEN state after sending the DCCP-Reset with sequence number zero. This behaviour creates unnecessary traffic, adversely affecting congestion in the Internet. It will be particularly severe if the initial sequence number is even moderately large, which will often be the case. This problem is caused by the invalid DCCP-Reset packet having sequence number zero. Because there are no sequence number variables in the CLOSED or LISTEN state, according to the specification [120] section 8.3.1, the sequence number of the DCCP-Reset packet generated in the CLOSED and LISTEN states is the received acknowledgement number plus one. If there is no received acknowledgement number because the received 103

packet type is DCCP-Request (or DCCP-Data), the sequence number of the DCCP-Reset packet is set to zero and the acknowledgement number is set to the received sequence number. In versions 5 and 6 of the draft specification [115, 126], the DCCP-Reset packet with sequence number zero is specified as a valid packet. However, our previous work [128,206] shows that this valid DCCP-Reset causes deadlocks where the server is in the OPEN state and the client is in CLOSED. Since draft specification version 7, a DCCP-Reset with sequence number zero is no longer considered a valid packet. A solution may be to ignore an incoming packet without an acknowledgement number when received in the CLOSED or LISTEN state. This is because every state (except CLOSED and LISTEN) has a Back-off timer, which will guarantee that the other end will eventually go to the CLOSED state.

7.5

Conclusion

This paper has illustrated a formal specification and has provided an initial but detailed analysis of DCCP’s connection management procedures. Significant effort has been spent on ensuring that the CPN specification accurately captures the pseudo code and narrative description in the final Internet Draft version 11 [120]. This has revealed areas in the specification which we believe to be incomplete as discussed in section 7.3.5. Our analysis has discovered scenarios where the client keeps sending DCCP-Sync packets in response to the server sending sequence-invalid DCCP-Reset packets. This may have an adverse effect on congestion in the Internet, if the initial sequence number chosen is even moderately large. Future work will involve modifying the procedures to eliminate this problem and verifying that the revised model works correctly. We need to analyse our model when an application closes during connection establishment as was discussed in section 7.3.5. We would also like to extend our work to include Option/Feature negotiation.

104

Declaration for Chapter 8 Declaration by candidate In the case of Chapter 8, “Chattering Behaviour in the Datagram Congestion Control Protocol”, the nature and extent of each author’s contributions to the work were the following: Nature of Contribution



1st

2nd


40

60


40

60


90

10


40

60


75

25


5

95


5

95


5

95

0

100




Date


Signature

Date 105

Chapter 8 Chattering Behaviour in the Datagram Congestion Control Protocol Chapter 8 appears as a published journal paper, S. Vanit-Anunchai and J. Billington. “Chattering Behaviour in the Datagram Congestion Control Protocol”, IEE Electronics Letters, 41(21):1198-1199, October 2005.

This chapter is, except for minor typographical changes, the same as the paper. The text is re-published in this thesis according to the permission stated in http://www.ietdl.org/journals/doc/IEEDRL-home/info/journals/el/submissions.jsp

It is a postprint of a paper submitted to and accept for publication in IEE Electronics Letters and is subject to Institution of Engineering and Technology Copyright. The copy of record is available at IET Digital Library.

106

Chattering Behaviour in the Datagram Congestion Control Protocol S. Vanit-Anunchai and J. Billington Computer Systems Engineering Centre, University of South Australia Mawson Lakes Campus, SA 5095, Australia email:[email protected], [email protected]

This paper illustrates the presence of chatter in the connection management procedures of an Internet Draft transport protocol, the Datagram Congestion Control Protocol (DCCP). It identifies circumstances in which the client and server repeatedly and needlessly exchange long sequences of packets.

Introduction: The Internet Engineering Task Force has been making rapid progress over the last 18 months developing a new transport protocol, the Datagram Congestion Control Protocol (DCCP) [115, 116, 120, 126]. The latest draft, version 11 (March 2005), will shortly become an RFC. The purpose of DCCP is to support various congestion control mechanisms that suit delay sensitive applications (such as voice or computer games), in an attempt to limit congestion in the Internet that could arise if this traffic used UDP. It is therefore likely to become an important Internet transport protocol. Hence we consider that it is critical to verify DCCP as soon as possible, to remove errors before it is widely implemented. This letter demonstrates that chatter is possible in the protocol where both ends needlessly exchange long sequences of packets before closing, creating a lot of unnecessary traffic.

DCCP connection management: The connection management procedures of DCCP [120] are defined by pseudo code which includes a finite state machine with nine states: CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, OPEN, CLOSEREQ, CLOSING and TIME-WAIT. A DCCP packet [120] includes port numbers, a checksum, 48 bit sequence (and acknowledgement) numbers and a packet type defining 10 packets: Request, Response, Data, DataAck, Ack, CloseReq, Close, Reset, Sync and SyncAck. The typical connection establishment and close down procedures are shown in Fig. 8.1. For each connection, DCCP entities maintain a set of state variables. The important variables are Greatest Sequence Number Sent (GSS), Greatest Sequence Number Received (GSR), Greatest Acknowledgement Number Received (GAR), Initial Sequence Number Sent and 107

Client CLOSED [active open] REQUEST

Server

Request (seq=x)

Response (seq=y,ack=x)

Client OPEN

CLOSED [passive open] LISTEN

CloseReq (seq=m,ack=n)

CLOSING

RESPOND

Close (seq = n+1, ack = m)

CLOSED

PARTOPEN Ack (seq=x+1,ack=y)

OPEN TIMEWAIT(2 MPL)

OPEN

Server OPEN [server active close] CLOSEREQ

Reset (seq=m+1,ack=n+1)

. .

Ack (seq=y+1,ack=x+1)

CLOSED

(a)

(b)

Figure 8.1: Typical Connection Establishment and Release Scenarios. Received (ISS and ISR), Sequence Number validity window width (W) and Acknowledgement Number validity window width (AW). Valid sequence and acknowledgement number intervals are calculated using these variables. Received packets that do not satisfy these intervals are called “sequence-invalid”.

Resynchronising sequence numbers: Malicious attack or a burst of noise may result in state variables and windows being unsynchronised. The Sync and SyncAck packets are used to resynchronise both ends. When receiving a sequence-invalid packet, an end must reply with a Sync packet but does not update GSR because the sequence number received could be wrong. However the acknowledgement number in the Sync packet is set equal to this invalid received sequence number. After receiving a sequence-valid Sync, an end normally replies with a SyncAck, but when in CLOSED or LISTEN it responds with a Reset, with its sequence number equal to the acknowledgement number in the Sync plus one.

DCCP chatter : We modelled the connection management procedures of version 11 [120] of DCCP with Coloured Petri Nets (CPNs) [105–107], and used reachability analysis to study their behaviour. We found that the size of the state space (of all reachable states) grows almost linearly with ISS and becomes intractable for ISS > 10. Further investigation revealed that there are many chattering scenarios. One possible scenario is shown in Fig. 8.2 for the case when ISS=2 for both ends. The triples, e.g. (7,2,3), represent (GSS,GSR,GAR) and “x” is an undefined value. Importantly, the first Request packet is delayed and arrives when the server is CLOSED. This is possible when the

108

Figure 8.2: Repeatedly Exchanged Messages when ISS=2.

retransmitted request is received and responded to, but the client’s Ack (or Acks if the Ack is retransmitted) to the Response is delayed or lost. The server times out (enters CLOSED) and sends a Reset (with seq=3,ack=3) which is also significantly delayed or lost. After sending a Reset with sequence number zero on receipt of the old request, the server enters the LISTEN state and repeatedly sends a sequence-invalid Reset packet while the client repeatedly responds with Sync. The sequence and acknowledgement numbers in both packets increase over time until the sequence number of the Reset received is greater than the client’s GSR (which is 2, due to the server’s ISS being 2 in the Response packet) and becomes sequence-valid. When receiving the sequence-valid Reset (with seq=3), the client enters the TIMEWAIT state and then CLOSED after 2 Maximum Packet Lifetimes (MPL). This behaviour creates unnecessary traffic that would adversely affect congestion in the Internet. It will be particularly severe if the initial sequence number is even moderately large, which will nearly always be the case, given a random choice of ISS within a 48 bit range. From Fig. 8.2 (and all other scenarios run), we conjecture that the number of exchanged messages is given by 2(ISS+1)+1. Given a random choice of ISS, 109

as mandated by DCCP [120], the probability of ISS being 109 or more is (248 − 109 )/248 which is greater than 0.99999. If a chattering scenario occurs, it is thus exceedingly likely that more than two billion messages will be needlessly exchanged. Although the chance of this particular scenario is low, we have discovered a large number of possible chattering scenarios. For example, the server can remain in CLOSED after the Timeout, for any period before moving to LISTEN, and the same chattering behaviour occurs. Given the enormous number of potential DCCP connections in the Internet, we consider that this problem could be a serious threat leading to unnecessary congestion and performance degradation.

Discussion and Possible solution: This problem is caused by the invalid Reset packet having sequence number zero. Because there is no sequence number variable in the CLOSED or LISTEN state, the sequence number of the Reset packet generated in the CLOSED and LISTEN states is the received acknowledgement number plus one [120]. However, if there is no received acknowledgement number because the received packet type is Request (or Data), the sequence number of the Reset packet is set to zero and the acknowledgement number is set to the received sequence number. In earlier draft specifications (versions 5 and 6) [115, 126], the Reset packet with sequence number zero was specified as a valid packet. However in [128, 206] we showed that this valid Reset caused deadlocks. A solution to the chattering problem could be to ignore an incoming packet that does not include an acknowledgement number when received in the CLOSED or LISTEN state, rather than sending a reset. This is because every state (except CLOSED and LISTEN) has a Back-off timer [120], which will guarantee that the other end will eventually enter the CLOSED state.

110

Declaration for Chapter 9 Declaration by candidate In the case of Chapter 9, “Effect of Sequence Number Wrap on DCCP Connection Establishment”, the nature and extent of each author’s contributions to the work were the following: Nature of Contribution



1st

2nd


40

60


20

80


80

20


80

20


60

40


5

95


5

95


5

95

0

100




Date


Signature

Date 111

Chapter 9 Effect of Sequence Number Wrap on DCCP Connection Establishment Chapter 9 is the submitted version of an international conference paper, S. Vanit-Anunchai and J. Billington, “Effect of Sequence Number Wrap on DCCP Connection Establishment”, In Proceedings of the 14th IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), pages 345354, Monterey, California, USA, 11-13 September 2006, IEEE Computer Society Press.

The paper is subject to Institution of Electrical and Electronic Engineering (IEEE) copyright. The copy of a shorter version is available at IEEE Computer Society Digital Library. The text is re-published in this thesis according to the permission stated in http://www.ieee.org/web/publications/rights/policies.html c 2006 IEEE. Personal use of this material is permitted. However, permission to reprint or re-publish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

112

Effect of Sequence Number Wrap on DCCP Connection Establishment S. Vanit-Anunchai and J. Billington Computer Systems Engineering Centre, University of South Australia Mawson Lakes Campus, SA 5095, Australia email:[email protected], [email protected]

Abstract This paper investigates the connection establishment procedures of the Datagram Congestion Control Protocol (DCCP) when sequence numbers wrap. A formal executable specification of DCCP connection management is obtained using Coloured Petri Nets. The model includes the synchronisation procedure, sequence number wrapping and the algorithm for extending short sequence numbers. We discover that during connection establishment if sequence numbers wrap, it is possible that the attempt to set up the connection fails.

Index Terms - DCCP, Formal Methods, Coloured Petri Nets, State Space Methods.

9.1

Introduction

The Datagram Congestion Control Protocol (DCCP) [60,115,120–122,126] is a new transport protocol developed by the Internet Engineering Task Force (IETF). It has recently been approved by the Internet Engineering Steering Group (IESG) as a new standard, RFC 4340 [124]. DCCP is designed to support various kinds of congestion control mechanisms used by different delay sensitive applications. Currently these applications use either the Transmission Control Protocol (TCP) [179] or the User Datagram Protocol (UDP) [176]. Providing reliable transmission and congestion control, TCP often introduces an uncontrollably large delay (or large deviation of delay) and unsatisfactory performance. The Stream Control Transmission Protocol (SCTP), RFC 2960 [180], can improve performance by reducing overhead between the flows and can defend against the state exhaustion attack1 using a cookie mechanism and the four way handshake during 1

The state exhaustion attack involves the attackers trying to use up the server’s memory by requesting

an enormous number of connections to be established.

113

connection establishment. However, similar to TCP, SCTP provides a reliable flow of data and uses the same rate adaptive algorithm for congestion control making its performance unacceptable for delay sensitive applications. In contrast, UDP provides unreliable transmission in which messages could be corrupted, lost and reordered. If users can tolerate this degradation, UDP is more suitable for delay sensitive applications because of the absence of congestion control. Some applications implement their own congestion control mechanisms on top of UDP, however, most applications do not have any control mechanism at all. This uncontrolled traffic poses a serious threat of congestion collapse on the Internet [60]. DCCP is designed to overcome this problem. Further discussion and detailed design rationale for DCCP can be found in [60]. DCCP comprises four major parts: connection set up and close down procedures; unreliable flow of datagrams; a reliable signaling protocol called “options and features”; and reliable congestion control mechanisms. Currently there are only two congestion control mechanisms in the standard, RFC 4341 [61] and RFC 4342 [62], but more mechanisms tailored for different applications are also being adopted or developed for the standard. We believe that DCCP has high potential to be used widely in the Internet for delay sensitive applications. Hence we consider that it is of vital importance to verify whether DCCP works correctly before it is widely distributed. In this paper, we use Coloured Petri Nets (CPNs) [105] to model DCCP’s connection set up and close down procedures for DCCP RFC 4340 [124]. CPNs are widely used to model and analyse concurrent and complex systems [12,107]including verification of communication protocols such as TCP [14, 82, 83]. In addition to [212], our model includes non-deterministic use of both long and short sequence numbers and allows sequence numbers to wrap. Although in [120–122] the use of short sequence numbers was initially enabled by default, in the final version, RFC 4340 [124], the use of short sequence numbers is initially disabled. This implies that only packets with long sequence numbers will be used during connection establishment. Thus in this paper we disable the use of short sequence numbers during connection establishment. The contribution of this paper is three fold. Firstly, it demonstrates a successful application of formal methods to protocol verification. Our previous work [208, 212] has already helped to improve the DCCP specification [123]. Secondly, this paper attempts to give some insight into why connection establishment requires a four way handshake (instead of three way as in TCP). Thirdly, this paper illustrates the protocol’s behaviour when sequence numbers exceed 248 − 1. It shows that when the sequence number wraps 114

back to zero, the connection set up attempt can fail resulting in a deadlock. This paper is organised as follows. Section 9.2 introduces DCCP, while Section 9.3 summarises our previous work. The description of our CPN model of DCCP connection management is described in section 9.4. The analysis of connection establishment when sequence numbers wrap is discussed in section 9.5. Section 9.6 presents the conclusion and future work. We assume some familiarity with CPNs [105].

9.2 9.2.1

Overview of DCCP Connection Management DCCP packet format

A set of messages, called packets, are used to setup and release the connection and convey data between a client and a server. RFC 4340 [124] defines a DCCP packet as a sequence of 32 bit words comprising a DCCP Header and Application Data as shown in Fig. 9.1. The length of the Option and Application Data fields can vary. A four bit field in the header, Packet Type, specifies the type of message: Request, Response, Data, DataAck, Ack, CloseReq, Close, Reset, Sync and SyncAck. Request and Data packets do not include acknowledgement numbers. The sequence numbers of Data packets and the sequence numbers and acknowledgement numbers of Ack and DataAck packets can be reduced to 24-bit short sequence numbers when setting the Extended Sequence Number field (X) to 0. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Source Port

Data Offset

Destination Port

CcVal CsCov

Checksum

Generic Header Res

Packet X Type = 1

Reserved


Sequence Number (low bits)

Reserved

Acknowledge Number


Options and Padding

Application Data

Figure 9.1: DCCP packet format.

115

The DCCP header also contains 16 bit source and destination port numbers, and a 16 bit checksum. An 8 bit data offset indicates the length (in 32-bit words) from the beginning of the Header to the beginning of the Application data. CCVal, a 4 bit field, is a value used by the congestion control mechanisms [61,62]. Checksum Coverage (CsCov), also a 4 bit field, specifies the part of the packet being protected by the 16 bit Checksum. The Options field contains not only state information such as Cookies and time stamps but also commands for applications to negotiate various features such as the Congestion Control Identifier (CCID) and the width of the Sequence Number validity window [124].

9.2.2

DCCP connection management procedures

DCCP connection management has one connection establishment procedure and five closing procedures. In RFC 4340 it is represented by the state diagram shown in Fig. 9.2 comprising nine states: CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, OPEN, CLOSEREQ, CLOSING and TIMEWAIT. The typical procedure of connection set up and close down is shown in Fig. 9.3. For a detailed description of the procedures see [124,212]. +---------------------------+ +---------------------------+ | v v | | +----------+ | | +-------------+ CLOSED +------------+ | | | passive +----------+ active | | | | open open | | | | snd Request | | | v v | | +----------+ +----------+ | | | LISTEN | | REQUEST | | | +----+-----+ +----+-----+ | | | rcv Request rcv Response | | | | snd Response snd Ack | | | v v | | +----------+ +----------+ | | | RESPOND | | PARTOPEN | | | +----+-----+ +----+-----+ | | | rcv Ack/DataAck rcv packet | | | | | | | | +----------+ | | | +------------>| OPEN |App Server_State->State Ch_C_S->Ch_B_A

DCCP_CM#2 Ch_C_S->Ch_A_B App_Client->App Client_State->State Ch_S_C->Ch_B_A

Figure 9.5: The DCCP overview Page. P

P Out

In

App

Ch_A_B PACKETS

COMMAND

UserCMD HS

Idle_State HS

Request HS P I/O

Respond

State HS CB

PartOpen HS

DataTransfer HS

ClosingDown HS

HS

Common Processing P

In

Ch_B_A PACKETS

Figure 9.6: DCCP CM page.

with an HS tag) represent the client and the server. Both are linked to the second level page named DCCP CM (shown in Fig. 9.6). The client and server communicate via two channel places (represented by ellipses), shown in the middle of Fig. 9.5. The places and transitions are connected by arcs. The places Ch C S and Ch S C each model a unidirectional reordering channel, from the client to the server and the server to the client respectively, and are typed by PACKETS. The descriptions in the two boxes at the bottom of Fig. 9.5 show the assignment of socket 122

places on the top page to port places on the subpage DCCP CM for the two substitution transitions (DCCP C and DCCP S). For instance, places Client State and Server State are linked to place State in Fig. 9.6. Place Ch C S is linked to place Ch A B for the client and place Ch B A for server and vice versa for place Ch S C.

9.4.4

Global declarations

Figure 9.7 declares PACKETS (line 16) as a union of four colour sets: Type1LongPkt, representing

long

sequence

number

packets

without

acknowledgement

numbers;

Type2LongPkt, representing long sequence number packets with long acknowledgement numbers; Type1ShortPkt, representing short sequence number packets without acknowledgement numbers; and Type2ShortPkt, representing short sequence number packets with short acknowledgement numbers. Long sequence numbers (SN48) in line 8 are represented by “infinite integers” in ML ranging from zero to 248 − 1. Short sequence numbers (SN24) in line 10 are represented by integers ranging from zero to 224 − 1. Each packet (line 1215) is defined by a product comprising the Packet Type (line 2-6), X (Extended Sequence Number bit, line 7) and sequence number (or a record of sequence and acknowledgement numbers). Short sequence numbers are allowed only for DCCP-Data, DCCP-Ack and DCCP-DataAck packets. Thus line 5 defines a packet type for DCCP-Data with short sequence numbers, while line 6 defines a different packet type for DCCP-Ack and DCCP-DataAck because they also include acknowledgements. The strong type of packet representation is very useful for developing and debugging the model. Mistakes in the model can be detected immediately by a syntax check rather than at runtime. The places Client State and Server State in Fig. 9.5, typed by CB (Control Block), store DCCP state information for the client and server entities respectively. We classify DCCP states according to their functional behaviour into three groups: idle, request and active states. The differences are mainly related to how an entity responds the DCCPReset and DCCP-Sync packets. When in the CLOSED, LISTEN and TIMEWAIT states, the GSS, GSR, GAR, ISS and ISR state variables do not exist, while the client in the REQUEST state has only instantiated GSS and ISS. Thus we define each group with a different set of state variables. Fig. 9.8 defines CB (line 10) as a union of colour sets: IDLE, REQUEST and ACTIVExRCNTxGSxISN. IDLE (line 3) defines three idle states: CLOSED, LISTEN and TIMEWAIT. The CLOSED state is split into CLOSED I to represent the initial CLOSED state and CLOSED F to represent a terminal CLOSED state. This separation is useful when inves123

1: (* Packet Structure *) 2: color PktType1 = with Request | Data; 3: color PktType2 = with Sync | SyncAck | Response 4:

| Ack | DataAck

| CloseReq | Close | Rst;

5: color DATA=subset PktType1 with [Data]; 6: color ACK_DATAACK=subset PktType2 with [DataAck,Ack]; 7: color X = bool; 8: color SN48 = IntInf with ZERO..MaxSeqNo48; 9: color SN48_AN48 = record SEQ:SN48*ACK:SN48; 10: color SN24 = int with 0..max_seq_no24; 11: color SN24_AN24 = record SEQ:SN24*ACK:SN24; 12: color Type1LongPkt=product PktType1*X*SN48; 13: color Type2LongPkt=product PktType2*X*SN48_AN48; 14: color Type1ShortPkt=product DATA*X*SN24; 15: color Type2ShortPkt=product ACK_DATAACK*X*SN24_AN24; 16: color PACKETS=union PKT1:Type1LongPkt 17:

+PKT2:Type2LongPkt+PKT1s:Type1ShortPkt

18:

+PKT2s:Type2ShortPkt;

Figure 9.7: Definition of DCCP PACKETS. 1: (* DCCP state variables*) 2: color RCNT=int;(*Retransmission Counter*) 3: color IDLE=with CLOSED_I| LISTEN| CLOSED_F| TIMEWAIT; 4: color REQUEST = product RCNT*SN48*SN48; 5: color ACTIVE = with RESPOND| PARTOPEN| S_OPEN| C_OPEN 6:

| CLOSEREQ | C_CLOSING |S_CLOSING;

7: color GS = record GSS:SN48*GSR:SN48*GAR:SN48; 8: color ISN = record ISS:SN48*ISR:SN48; 9: color ACTIVExRCNTxGSxISN=product ACTIVE*RCNT*GS*ISN; 10: color CB = union IdleState:IDLE+ReqState:REQUEST 11:

+ ActiveState:ACTIVExRCNTxGSxISN;

12: color COMMAND = with p_Open | a_Open | a_Close 13:

| server_a_Close;

Figure 9.8: DCCP’s control block and user commands.

124

tigating and analysing state spaces. The colour set REQUEST is a product comprising RCNT (Retransmission Counter, line 2), GSS and ISS. Because there is only one state in this group, the REQUEST state is already distinquished from other states by using the ML constructor ReqState in the union (line 10). The ACTIVExRCNTxGSxISN (line 9) is a product comprising ACTIVE (line 5), RCNT, GS (Greatest Sequence and Acknowledgement Numbers, line 7) and ISN (Initial Sequence Numbers, line 8). ACTIVE (line 5) defines five DCCP states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. Because the client and server respond to the CloseReq packet differently in the OPEN and CLOSING states, we differentiate these states for the client and server: C OPEN and C CLOSING for the client; and S OPEN and S CLOSING for the server. Figure 9.8 also defines a colour set COMMAND on line 12. The places App Client and App Server in Fig 9.5, typed by COMMAND, model DCCP user commands (i.e. commands that can be issued by the applications that use DCCP). For example, the user command 1‘a Open is the initial marking of App Client indicating that the client’s application desires to open a connection.

9.4.5

The second level page

Figure 9.6 shows the DCCP CM page which comprises eight substitution transitions. UserCMD models the actions taken when receiving commands from users. Idle State models the actions in the CLOSED, LISTEN and TIMEWAIT states. Request, Respond and PartOpen model event processing in each of the corresponding states. DataTransfer models the actions taken when receiving the DCCP-Data, DCCP-Ack and DCCP-DataAck packets in the OPEN, CLOSEREQ and CLOSING states. ClosingDown models the actions on receiving a DCCP-Close or DCCP-CloseReq packet in the five active states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. Common Processing comprises the actions common to various states. These actions involve retransmissions, receiving DCCPReset, DCCP-Sync and DCCP-SyncAck packets, receiving unexpected packets and receiving packets with an invalid header.

9.4.6

An example of the third level page

Due to the space limit, we briefly explain only one page of the third level, IdleState. Figure 9.9 specifies the actions of the entity when it is in CLOSED, LISTEN or TIMEWAIT. For example, the second transition named “RcvPktWOAck ” (Receive packet without ac-

125

P I/O

Output

State [p_type2Rst ]

CB

RcvPktWAck

IdleState id_state

PKT2 (Rst, LONG, SeqAck(NoGS, SA48 sn_an))

P Out PACKETS

PKT2 (p_type2, LONG, sn_an)

IdleState id_state

RcvPktWOAck

if( id_state = LISTEN andalso p_type1=Request) then ActiveState (RESPOND,0,{GSS=S_iss, GSR=sn,GAR=S_iss},{ISS=S_iss,ISR=sn}) else IdleState id_state IdleState id_state

if (id_state=LISTEN andalso p_type1=Request) then 1‘PKT2 (Response, LONG, {SEQ=S_iss, ACK=sn}) else 1‘PKT2 (Rst, LONG, SeqAck(NoGS, S48 sn)) PKT1 (p_type1, LONG, sn)

[(p_type2 = Ack orelse p_type2 = DataAck) andalso ShortEnable] PKT2 (Rst, LONG, SeqAck(NoGS,SA24 sn24_an24) ) RcvShortWAckPkt PKT2s (p_type2, SHORT, sn24_an24)

[ShortEnable] IdleState id_state

RcvShortWOAckPkt

PKT2 (Rst, LONG, SeqAck(NoGS, S24 sn24) ) PKT1s (Data, SHORT, sn24)

P In

Input IdleState id_state

PACKETS

RcvReset PKT2 (Rst, LONG, sn_an)

IdleState TIMEWAIT

TimerExpires

IdleState CLOSED_F

Figure 9.9: The IdleState Page.

knowledgement) and its arc inscriptions model the action when the server receives a DCCP-Request or Data packet in an idle state. When the server receives DCCP-Request in the LISTEN state, it initializes all state variables, enters the RESPOND state and replies with a Response packet. The fifth transition, “RcvReset” models that the Reset packet is always discarded. “TimerExpires” abstractly models the maximum packet lifetime timer in the TIMEWAIT state. Other transitions model when any other packets are received, including Sync and SyncAck, where the entities respond with a Reset. “ShortEnable” in a guard’s expression (e.g. see transition “RcvShortWOAck”) disables or enables the use of short sequence numbers. In this paper we disable short sequence numbers by setting “ShortEnable” to false. The ML function SeqAck computes the sequence and acknowledgement numbers of packets. The sequence wrapping operation is called by function SeqAck.

9.5

Analysis

The DCCP Connection Management model was analysed on a Pentium-IV 2.6 GHz computer with 1GB RAM using the occurrence graph tool of Design/CPN 4.0.5 [202]. We have analysed both the connection set up and close down procedures for various configurations. In this paper, we report results concerning the connection establishment procedures when only long sequence numbers are used. We are particularly interested in investigat126

ing connection set-up when sequence numbers wrap. We use DCCP’s default value for validity window widths (W = AW = 100) and the same value of ISS for both client and server. With the initial marking shown in Fig. 9.5 (both ends initially closed, passive open by the server, and active open from the client) and limiting the maximum number of retransmissions to one, we vary ISS and generate the state space. The results are summarized in Table 9.2. The table lists the number of nodes and arcs of the state space (columns 2 and 3) and a classification of terminal markings (i.e. states from which there is no escape known as dead markings in CPNs) (columns 4-7) for values of ISS close to the modulo

Table 9.2: State space size and terminal markings of connection establishment when varying ISS (W=AW=100). ISS

Nodes

Arcs

Terminal Markings A

B

C

D

0

14,167

45,023

65

1

1

0

1

14,782

46,956

65

1

1

0

2

14,782

46,956

65

1

1

0

.

.

.

.

.

.

.

248 − 80

14,782

46,956

65

1

1

0

248 − 79

14,446

45,782

65

1

1

0

248 − 78

13,684

43,156

65

1

1

0

248 − 77

11,894

37,696

65

1

1

0

248 − 76

11,892

37,684

59

1

1

2

248 − 75

11,438

36,144

59

1

1

2

248 − 74

11,438

36,144

59

1

1

2

.

.

.

.

.

.

248 − 9

11,438

36,144

59

1

1

2

248 − 8

11,438

36,144

59

1

1

2

248 − 7

11,437

36,143

59

1

1

2

248 − 6

11,433

36,135

59

1

1

2

248 − 5

11,101

35,091

59

1

1

2

248 − 4

11,261

35,703

59

1

1

2

248 − 3

11,853

37,808

59

1

1

2

248 − 2

13,904

44,061

59

1

1

2

248 − 1

13,776

43,606

59

1

1

0

.

127

248 boundary taking into account the window size.

9.5.1

Terminal marking classification

The terminal markings are classified into 4 types. All terminal markings have no packets left in the channels and hence there are no unspecified receptions. Terminal markings of Type A are desirable and correspond to successful connection establishment (both the client and server are in the OPEN state). Terminal markings of Types B and C correspond to situations where the connection attempt fails because the back-off timer expires due to congestion. Both are acceptable. In Type B terminal markings both sides are CLOSED. For Type C markings, the client is CLOSED, but the server is in the LISTEN state. This can happen when the server is initially CLOSED (down for maintenance or busy) and rejects the connection request. The server then recovers and moves to the LISTEN state (waiting for the next request). These three terminal markings are expected, however, Type D terminal markings are deadlocks where the client is CLOSED but the server stays in OPEN.

9.5.2

Type D terminal markings

The last column of Table 9.2 shows that two deadlocks occur for values of ISS from 248 −76 to 248 − 2. These two deadlocks are very similar. The only difference is that the value of GSR in the server is different by one, due to the retransmission of a DCCP-Ack by the client. The time sequence diagram of Fig. 9.10 shows the cause of the two deadlocks when ISS = 248 − 76. Both the client and server are initially closed (perhaps because the server is currently overloaded). The client requests a connection which is delayed by congestion, and hence retransmits the request with its sequence number incremented (as is the case with DCCP). This request arrives at the server ahead of the original request, but the server is closed and returns a reset with sequence number 0 and ack = 248 − 75 (as mandated by DCCP). This reset is also delayed. The server then recovers and moves to LISTEN, waiting for requests. The original delayed request arrives and is accepted by the server. The server issues a DCCP-Response with sequence number = ISS, acknowledges receipt of the request, moves to the RESPOND state and instantiates ISR (=248 − 76). It also creates its state variables GSS (=ISS), GSR (=ISR) and GAR (initially set to ISR). The client receives the Response, returns the Ack, moves to PARTOPEN and updates its

128

Client CLOSED ISS = 248-76 [active open] REQUEST (GSS,GSR,GAR) (248-75, x, x)

Server CLOSED Request(seq=248-76) Request(seq = 248-75) Reset(seq=0,ack= 248-75) [passive open] LISTEN RESPOND Response (seq=248-76,ack=248-76) ISR = 248-76, ISS = 248-76 (GSS,GSR,GAR) Ack(seq= 248-74,ack=248-76) (248-76, 248-76, 248-76)

PARTOPEN (248-74,248-76, 248-76)

Data (seq=248-75) OPEN (248-75, 248-74, 248-76)

OPEN (248-74,248-75, 248-76) TIMEWAIT . . CLOSED

(a) Client CLOSED ISS = 248-76 [active open] REQUEST (GSS,GSR,GAR) (248-75, x, x)

Server CLOSED Request(seq=248-76) Request(seq = 248-75) Reset(seq=0,ack= 248-75) [passive open] LISTEN RESPOND Response (seq=248-76,ack=248-76) ISR = 248-76, ISS = 248-76 (GSS,GSR,GAR) Ack(seq =248-74,ack=248-76) (248-76, 248-76, 248-76)

PARTOPEN (248-74,248-76, 248-76) Time-out (248-73,248-76, 248-76)

Ack (seq=248-73,ack=248-76) Data (seq =248-75)

OPEN (248-73,248-75, 248-76)

OPEN (248-75, 248-74, 248-76) (248-75, 248-73, 248-76)

TIMEWAIT . . CLOSED

(b)

Figure 9.10: Two Scenarios when ISS = 248 − 76 a) no retransmission in PARTOPEN b) one retransmission in PARTOPEN.

129

state variables. The server receives the Ack, updates GSS, GSR and GAR, and in this scenario, sends a Data packet. This is allowed by DCCP (see page 18 of [124]). The client in Fig. 9.10(b) retransmits DCCP-Ack in PARTOPEN while the client in Fig. 9.10(a) does not. This has the effect of increasing the value of GSR in the server by one with respect to Fig. 9.10(a). When the client receives the Data packet it updates GSR and moves to OPEN. Because Data packets do not include acknowledgements, GAR remains at 248 − 76. It now receives the old Reset and performs the validity check in Table 9.1. From equation (1), SWH is 0, so its sequence number satisfies the sequence number check. Using equation (3) and the current value of GAR at the client, it can be seen that the acknowledgement number is also in the correct range. Thus this reset is valid and the client enters CLOSED leaving the server in OPEN, a deadlock. This is the case in both scenarios in Fig. 9.10. The same behaviour occurs for values of ISS up to 248 −2. When ISS = 248 −1, the reset with sequence number = 0 becomes invalid, because the client’s GSR = 0 when it receives the reset. A Sync, SyncAck handshake follows, with the client and server remaining in OPEN. Thus, so long as the old reset is invalid, no deadlock occurs. The deadlock is caused by a DCCP-Data packet being sent by the server instead of a DCCP-DataAck packet. If a DataAck packet is sent, then GAR is updated (incremented by 2 or more depending on the number of retransmissions) in the client, the old reset will fail the acknowledgement number check, and both ends will remain in OPEN after a Sync handshake. Our current testing of the model has confirmed this to be the case when retransmissions are limited to one.

9.5.3

State Space Size as ISS varies

Although we can not generate the state space for every value of ISS, we conjecture that for ISS = 1 to 248 −80, the state spaces are isomorphic. This is because it is only the values of the sequence number variables that change for particular states, which intuitively should not have any effect on the size of the state space. Surprisingly for ISS = 248 − 79 to 248 (0), this property does not hold. The number of nodes in the state space decreases from 14,782 (ISS = 248 − 79) to 11,101 when ISS = 248 − 5 and then rises rapidly back to 14,782 when ISS wraps around to 0 and then 1.

130

When ISS = 0 and ISS = 1 Figure 9.11 shows a cause of the difference in the size of the state spaces for ISS = 0 and ISS = 1. We find that when ISS = 0, the server is closed by a valid Reset with acknowledgement number = 0. But when ISS = 1, after receiving an invalid Reset with acknowledgement number = 0, the server replies with a DCCP-Sync leading to more packet exchanges and a bigger state space. Client CLOSED ISS = 0 [active open] (GSS,GSR,GAR) REQUEST Time-out (1, x, x) Back-off CLOSED

Server CLOSED

Request(seq=0) Request(seq = 1) Reset (seq=2 ack=0)

Response(seq=0,ack=0)

[passive open] LISTEN RESPOND ISR = 0, ISS=0 (GSS,GSR,GAR) (0, 0, 0) TIMEWAIT

Reset (seq=0,ack=1) CLOSED Reset (seq=1,ack=0)

. . CLOSED

(a) Client CLOSED ISS = 1 [active open] (GSS,GSR,GAR) REQUEST Time-out (2, x, x) Back-off CLOSED

Server CLOSED

Request(seq=1) Request(seq = 2) Reset(seq=3 ack=0)

Response(seq=1,ack=1)

[passive open] LISTEN RESPOND ISR = 1, ISS=1 (GSS,GSR,GAR) (1, 1, 1)

Sync (seq=2,ack=1) CLOSED Reset (seq=2,ack=2) TIMEWAIT . Reset (seq=2, ack=1) . Reset (seq=0, ack=2) CLOSED

CLOSED

(b)

Figure 9.11: Comparing the same scenarios when a) ISS = 0 b) ISS = 1.

131

When ISS = 248 − 79 In the case of ISS = 248 − 79 and W = 100, when an entity receives DCCP-Request or DCCP-Data in an idle state (CLOSED, LISTEN or TIMEWAIT), it will reply with DCCP-Reset with sequence number = 0 (see page 66 of [124]). From equation (1) when GSR = 248 − 79, SWH = 248 − 4. Thus according to Table 9.1, a reset with sequence number = 0 will be invalid. However, as the message exchange progresses, when GSR = 248 − 75, SWH = 0. When SWH = 0, the DCCP-Reset with sequence number = 0 becomes valid (see Table 9.1). But in the case of ISS = 248 − 80 for the same sequence of actions, when GSR is 248 − 76, SWH = 248 − 1. The DCCP-Reset with sequence number = 0 is still invalid which leads to re-synchronisation and a bigger state space. Using the occurrence graph tool we can generate a scenario supporting this argument as shown in Fig. 9.12 (ISS = 248 − 79). In this case upon receiving the valid Reset (seq = 0, ack = 248 − 77) (last message) the server closes. If ISS = 248 − 80, we will have Client CLOSED [active open] ISS = 248-79 REQUEST (GSS,GSR,GAR) (248-78, x, x)

Server CLOSED Request(seq=248-79) Request(seq = 248-78) Response(seq= 248-79,ack=248-79) Ack(seq=248-77, ack=248-79)

PARTOPEN (248-77,248-79, 248-79) Time-out (248-76,248-79, 248-79) (248-75,248-78, 248-78)

Back-off CLOSED

[passive open] LISTEN

Ack(seq= 248-76, ack=248-79) Response(seq= 248- 78, ack=248-78) Ack(seq=248-75, ack =248-78)

RESPOND ISR = 248-79, ISS = 248-79 (GSS,GSR,GAR) (248-79, 248-79, 248-79)

Request valid because seq > ISR (248-78, 248-78, 248-79)

Reset(seq=248- 74, ack =248-78) Data (seq= 248-77) Rst(seq=0, ack=248-77)

OPEN (248-77, 248-77, 248-79)

(248-77, 248-76, 248-79) (248-77, 248-75, 248-78) GSR=248-75 Æ SWH=0 Ack>GAR Æ Rst valid TIMEWAIT . . CLOSED

Figure 9.12: A scenario when ISS = 248 − 79. 132

the same action sequence as depicted in Fig. 9.12 but all state variables will be shifted by -1. All sequence and acknowledgement numbers are also changed according to the state variables. This means the server receives an invalid Reset (seq = 0, ack = 248 − 78) when the server’s GSR = 248 − 76, SWH = 248 − 1. An invalid reset stimulates a Sync handshake, increasing the state space. As ISS increases from 248 − 79, the number of the valid Resets also increases. As ISS increases from 248 − 75, all Reset packets with sequence number = 0 are valid because SWH ≥ 0 (given valid values of acknowledgement numbers). This explains why the size of state space remains the same for all values of ISS up to and including 248 − 8. The difference between the sizes of the state spaces for ISS = 248 − 8 and ISS = 248 − 7 is only one node and one arc. We use the occurrence graph tool to filter and search for that marking. We discover that the marking is marking M in Fig. 9.13. We find that in the case of ISS = 248 − 7, the two markings, M and N when ISS = 248 − 8, are merged. We believe a similar process decreases the state space until ISS = 248 − 5. All Reset packets with sequence number = 0 are still valid up until ISS = 248 −5. When ISS = 248 − 4, the message exchange can progress until GSR ≥ 0. Then Reset packets with sequence number = 0 become invalid, and synchronisation attempts are made again, increasing the size of the state space.

1. ISS = 248-8: The State PARTOPEN (GSS = 248-2, GSR = 248-7) and back-off timer expires generates Reset (seq = 248-1, ack = 248-7). In the state space there are two markings: M: Both client and server in CLOSED, Reset (seq = 248-1, ack = 248-7) in Ch_C_S, Other places are empty. N: Both client and server in CLOSED, Reset (seq = 0, ack = 248-7) in Ch_C_S, Other places are empty. 48 2. ISS = 2 -7: The State PARTOPEN (GSS = 248-1, GSR = 248-6) and back-off timer expires generates Reset (seq = 0, ack = 248-6). In the state space there is one marking: N: Both client and server in CLOSED, Reset (seq = 0, ack = 248-6) in Ch_C_S, Other places are empty. Figure 9.13: The difference between two state spaces when ISS = 248 −8 and ISS = 248 −7.

133

When ISS = 248 − 1 and ISS = 0 We find that when ISS = 248 − 1, the client is closed by a valid Reset with both sequence and acknowledgement numbers = 0. Both entities terminate in CLOSED. But when ISS = 0, the Reset is invalid and the client replies with DCCP-Sync leading to further packet exchanges and a bigger state space. However in this case both the client and server remain OPEN. This gives a reason why there are more Type A terminal markings when ISS = 0 rather than 248 − 1. We conjecture that a similar reason holds for there being 65 Type A terminal markings for ISS up to and including 248 − 77.

9.6

Conclusion and future work

This paper has outlined our approach to developing a CPN model of IETF’s Datagram Congestion Control Protocol as it has evolved over the past two years. It has illustrated the current model which we believe is the first executable formal model of DCCP’s connection management and synchronisation procedures for RFC 4340. Compared with our work in [212], the model presented here includes the latest procedures, is much more compact and allows sequence numbers to wrap. We analysed the connection establishment procedures and found that a deadlock can occur where the server is OPEN but the client is CLOSED, when the value of ISS is between 248 − 76 and 248 − 2. This is due to DCCP allowing the server to send a DCCPData packet while in the RESPOND state in response to the DCCP-Ack from the client. The client’s GAR variable is thus not updated allowing an old reset packet to close the client without the server knowing. This failure can be avoided by not allowing the server to send a Data packet in the RESPOND state. The server must always acknowledge the Ack from the client in the 4 way handshake using a DCCP-Ack or DCCP-DataAck packet. We also investigated the size of the state space as a function of the Initial Sequence Number (ISS) and found that it decreased for ISS between 248 − 79 and 1. This can be explained by resets becoming valid in this range, which are not valid otherwise. The valid resets cause the DCCP entity to close, whereas the invalid resets result in synchronisation attempts which increase the size of the state space and remove the deadlocks. Our results only cover the case when ISS is the same at both ends. Our current experiments reveal that the deadlocks discussed in this paper are due to the server’s ISS being in the range 248 −76 to 248 −2, and are not dependent on the value of the client’s ISS. 134

However, we need to investigate this more thoroughly. We would also like to investigate if we can relax the assumption regarding the number of retransmissions and to quantify the relationship between the window size and range of ISS that is affected.

135

Declaration for Chapter 10 Declaration by candidate In the case of Chapter 10, “Modelling the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures”, the nature and extent of each author’s contributions to the work were the following: Nature of Contribution



1st

2nd


40

60


40

60


80

20


50

50


90

10


5

95


5

95


5

95

0

100




Date


Signature

Date 136

Chapter 10 Modelling the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures Chapter 10 appears as an international conference paper, S. Vanit-Anunchai and J. Billington, “Modelling the Datagram Congestion Control Protocols Connection Management and Synchronisation Procedures”, In J. Kleijn and A. Yakovlev, editors, Proceedings of the 28th International Conference on Application and Theory of Petri Nets and other models of concurrency (ICATPN07), volume 4546 of Lecture Notes in Computer Science, pages 423-444, Siedlce, Poland, 25-29 June 2007, Springer, Heidelberg.

This chapter is, except for minor typographical changes, the same as the paper. The copyright of this text belongs to Springer-Verlag. The text is re-published in this thesis according to the permission stated in http://www.springer.de/comp/lncs/copyright.html

The homepage of LNCS series is http://www.springer.de/comp/lncs/index.html

137

Modelling the Datagram Congestion Control Protocol’s Connection Management and Synchronisation Procedures S. Vanit-Anunchai1 and J. Billington Computer Systems Engineering Centre, University of South Australia Mawson Lakes Campus, SA 5095, Australia email:[email protected], [email protected]

Abstract The Datagram Congestion Control Protocol (DCCP) is a new transport protocol standardised by the Internet Engineering Task Force in March 2006. This paper specifies the connection management and synchronisation procedures of DCCP using Coloured Petri nets (CPNs). After introducing the protocol, we describe how the CPN model has evolved as DCCP was being developed. We focus on our experience of incremental enhancement and iterative modelling in the hope that this will provide guidance to those attempting to build complex protocol models. In particular we discuss how the architecture, data structures and specification style of the model have evolved as DCCP was developed. The impact of this work on the DCCP standard is also briefly discussed.

Keywords: Internet Protocols, DCCP, Coloured Petri Nets, Formal Specification.

10.1

Introduction

Background Recently, the Internet Engineering Task Force (IETF) has published a set of standards for a new transport protocol, the Datagram Congestion Control Protocol (DCCP) [114], comprising four standards called Request For Comments (RFCs): RFC 4336 [60]; RFC 4340 [124]; RFC 4341 [61]; and RFC 4342 [62]. RFC 4336 discusses problems with existing transport protocols and the motivation for designing a new transport protocol. RFC 4340 1

Somsak Vanit-Anunchai was partially supported by an Australian Research Council Discovery Grant

(DP0559927) and Suranaree University of Technology.

138

specifies reliable connection management procedures; synchronisation procedures; and reliable negotiation of various options. RFC 4340 also provides a mechanism for negotiating the congestion control procedure to be used, called “Congestion Control Identification” (CCID). The congestion control mechanisms themselves are specified in other RFCs. Currently there are two published: RFC 4341 (CCID2) “TCP-like congestion control” [61] and RFC 4342 (CCID3) “TCP-Friendly Rate Control” [62] but more mechanisms are being developed for the standard. Motivation RFC 4340 [124] describes its procedures using narrative, state machines and pseudo code. The pseudo code has several drawbacks. Firstly, it does not include timers and user commands. Secondly, because it executes sequentially, unnecessary processes can execute before reaching the process that is needed. This unnecessary execution makes it difficult to read, which may lead to misinterpretation of the procedures. Thus to avoid misinterpretation, the implementor has to strictly follow the pseudo code. Following the sequential pseudo code, we cannot exploit the inherent concurrency in the protocol. Thirdly, there may also be subtle errors in the RFC which may be found using formal methods. This has motivated us to formally specify DCCP’s procedures using Coloured Petri Nets (CPNs) [105]. Previous work We have closely followed the development, design and specification of DCCP Connection Management (DCCP-CM) since Internet Draft version 5 [126]. Our study aims to determine if any errors or deficiencies exist in the protocol procedures. We analysed the connection establishment procedures of version 5 and discovered a deadlock [206]. When version 6 [115] was released, we upgraded our CPN model [128] and found similar deadlocks. Version 11 of the DCCP specification was submitted to IETF for approval as a standard. We updated our model accordingly and included the synchronisation mechanism. We found that the deadlocks were removed but we discovered a serious problem known as chatter 2 [208, 212]. When updating the CPN model to RFC 4340, we investigated the connection establishment procedure when sequence numbers wrap [207]. We found that in this case it is possible that the attempt to set up the connection fails. In [70] 2

The chatter scenario comprised undesired interactions between Reset and Sync packets involving a

long but finite exchange of messages where no progress was made, until finally the system corrected itself.

139

we defined the DCCP service and confirmed that the sequence of user observable events of the protocol conformed to its service. In [210] we proposed an idea to improve the efficiency of the sweep-line method using DCCP as a case study. However, all of these papers place emphasis on the model’s analysis and present very little of the model itself. In contrast, this paper focusses on the modelling process. It discusses design decisions and how the DCCP-CM CPN models were developed rather than the analysis of the protocol procedures. Our final version of the DCCP-CM CPN model is the result of incremental refinement of three earlier versions which were used to obtain the results in [128, 206, 212]. Contribution We use Coloured Petri Nets to model the DCCP connection management and synchronisation procedures of RFC 4340. In contrast to the pseudo code, our proposed CPN specification includes user commands, timer expiry and channels. It is formalised so that ambiguities are removed and the risk of misinterpretation is low. The specification is restructured so that relevant aspects of the procedures are brought together and don’t need to be sought in different parts of the document. It now captures concurrent behaviour which is inherent in the protocol whereas the pseudo code and state machine are sequential. The CPN model can be analysed to determine errors. In particular we illustrate how to use hierarchical CPNs to model DCCP connection management and discuss our experience during the modelling process. The rest of the paper is organised as follows. Section 10.2 provides an overview of DCCP and its connection management procedures. Section 10.3 describes the evolution of our DCCP-CM CPN model as DCCP has been developed by IETF. Finally, conclusions and future work are discussed in Section 10.4.

10.2

Overview of DCCP’s connection management procedures

DCCP is a point-to-point protocol operating over the Internet between two DCCP entities, which we shall call the client and the server. DCCP is connection-oriented to facilitate congestion control. DCCP’s procedures for connection management comprise connection establishment and five closing procedures. RFC 4340 includes the state transition diagram

140

shown in Fig. 10.1(a), which gives the basic procedures for both the server and client entities. The server is identified by always passing through the LISTEN state after a “passive open” command from the application, whereas the client is instantiated by an “active open” and passes through the REQUEST state. Also, only the server can issue the “server active close” command.

10.2.1

DCCP packet format

A set of messages, called packets, is used to setup and release connections, synchronise sequence numbers, and to convey data between a client and a server. RFC 4340 [124] defines a DCCP packet as a sequence of 32 bit words comprising a DCCP Header and Application Data as shown in Fig. 10.1(b). The header comprises a generic header, followed by an acknowledgement number (if any) and then fields for options and features. The DCCP header contains 16 bit source and destination port numbers (for addressing application processes), and a 16 bit checksum to detect transmission errors. Since the Options field can vary in length, an 8 bit data offset indicates the length in 32-bit words from the beginning of the Header to the beginning of the Application data. CCVal, a 4 bit field, is a value used by the congestion control mechanisms [62]. Checksum Coverage (CsCov), also a 4 bit field, specifies the part of the packet being protected by the checksum. A four bit field specifies the type of packet: Request, Response, Data, DataAck, Ack, CloseReq, Close, Reset, Sync and SyncAck. By default, packets include a 48-bit sequence number. Request and Data packets do not include acknowledgement numbers.

CLOSED


passive open

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

Source Port

REQUEST

Destination Port

LISTEN

rcv Close snd Reset


Generic Header


PARTOPEN

Data Offset

CcVal CsCov

Packet X Res Type = 1

Reserved

Checksum


RESPOND Sequence Number (low bits)

rcv packet

rcv Ack/DataAck

DCCP Header Reserved

Acknowledge Number


OPEN

Option Type

CLOSING

rcv Reset

Length

Feature No.

active close or rcv CloseReq snd Close


Values Options and Padding

CLOSEREQ rcv Close snd Reset

... Application Data Application Data

TIMEWAIT

...

2 MPL timer exipres

(a)

(b)

Figure 10.1: (a) DCCP state diagram redrawn from [124] (b) DCCP packet format. 141

The sequence numbers of Data packets and the sequence numbers and acknowledgement numbers of Ack and DataAck packets can be reduced to 24-bit (short) when setting the Extend Sequence Number (X) field to 0. The Option fields contain state information or commands for applications to negotiate various features such as the Congestion Control Identifier (CCID) and the width of the sequence number validity window [124].

10.2.2

DCCP connection management procedures

The typical procedure of connection establishment is shown in the time sequence diagram of Fig. 10.2(a). We assume that the server has entered the LISTEN state after a “passive open” command is issued by the application at the server. On receiving an “active open” command from its application, the client enters the REQUEST state and sends a DCCPRequest packet requesting a connection to be established. This packet may include any options and features that require negotiation. Client CLOSED [active open]

Server CLOSED [passive open] LISTEN

Client OPEN

Request (seq=x) REQUEST Response (seq = y, ack=x) RESPOND

Server OPEN [server active close] CloseReq (seq = m, ack = n) CLOSEREQ Close (seq = n+1, ack = m)

CLOSING

Ack (seq = x+1, ack = y)

Reset (seq = m+1, ack = n+1)

PARTOPEN

CLOSED

Ack (seq = y+1, ack = x+1) OPEN OPEN

TIMEWAIT (2MPL) . CLOSED

(a)

(b)

Figure 10.2: Typical connection establishment and release scenarios. When receiving the DCCP-Request packet, the server (in LISTEN) enters the RESPOND state, and replies with a DCCP-Response packet indicating its willingness to establish the connection. The DCCP-Response will also include any options and features being negotiated. On receiving the DCCP-Response, the client (in REQUEST) replies with either a DCCP-Ack or DCCP-DataAck packet to acknowledge the DCCP-Response and enters PARTOPEN. After receiving an acknowledgement from the client, the server enters the OPEN state and may start transferring data. After receiving a DCCP-Data, DCCP-Ack or DCCP-DataAck packet, the client enters OPEN indicating that the connection has been established. During data transfer, the server and client may exchange DCCP-Data, DCCP-Ack and DCCP-DataAck packets. In order to ensure that no old packets are delivered in the new connection, one side 142

has to wait for 2 Maximum packet lifetimes (MPL3 ) before a connection can be restarted. To improve performance, especially in the face of state exhaustion attacks4 , the server should not be burdened with this delay. Typically it is the client that waits before closing is complete. Fig. 10.2(b) shows the typical close down procedure when the application at the server initiates connection release by issuing a “server active close” command. After sending a DCCP-CloseReq packet, the server enters the CLOSEREQ state. On receiving a DCCP-CloseReq, the client replies with a DCCP-Close to which the server responds with a DCCP-Reset packet and enters the CLOSED state. On receiving the DCCP-Reset, the client waits in the TIMEWAIT state for 2 MPL before entering the CLOSED state. Either entity may send a DCCP-Close packet to terminate the connection on receiving an “active close” command from the application. The entity that receives the DCCPReset packet will enter the TIMEWAIT state. There are another 2 possible scenarios beside these three closing procedures called simultaneous closing. One scenario occurs when applications on both sides issue an “active close”. The other is when the client user issues an “active close” and the server user issues the “server active close” command.

10.2.3

Synchronisation procedure

During the connection, DCCP entities maintain a set of state variables. The important variables are Greatest Sequence Number Sent (GSS), Greatest Sequence Number Received (GSR), Greatest Acknowledgement Number Received (GAR), Initial Sequence Number Sent and Received (ISS and ISR), Valid Sequence Number window width (W) and Acknowledgement Number validity window width (AW). Based on the state variables, the valid sequence and acknowledgement number intervals are defined by Sequence Number Window Low and High [SWL,SWH], and Acknowledgement Number Window Low and High [AWL,AWH] (see [124, 207, 212]). In general, received packets having sequence and acknowledgement numbers outside these windows are sequence-invalid. DCCP performs a sequence validity check when packets arrive but not in the CLOSED, LISTEN, REQUEST and TIMEWAIT states. On receiving a sequence-invalid packet, DCCP re-synchronises the state variables, GSR and GAR, by sending a DCCP-Sync packet. It does not update its GSR and GAR. According to section 7.5.4 of [124] the acknowledgement number in the DCCP-Sync is set 3 4

Maximum packet lifetime time (MPL) = Maximum Segment Lifetime (MSL) in TCP A state exhaustion attack involves attackers trying to use up the server’s memory by requesting an

enormous number of connections to be established.

143

equal to the invalid received sequence number (except when receiving an invalid DCCPReset). After the other end receives the DCCP-Sync, it updates GSR and replies with a DCCP SyncAck. It does not update GAR since the acknowledge number is sequenceinvalid. Upon receiving the DCCP-SyncAck, the DCCP entity updates GSR and GAR. A sequence-invalid DCCP-Sync and DCCP-SyncAck must be ignored. However if the entity receives a DCCP-Sync or DCCP-SyncAck (either valid or invalid) in CLOSED, LISTEN, REQUEST and TIMEWAIT, it replies with a DCCP-Reset packet.

10.3

CPN Model development

This section describes our CPN model and how it has evolved during the period of modelling as DCCP was developed in a series of Internet Drafts. We start with a simple and abstract model with a lot of assumptions. While the DCCP specification was being developed by IETF, our DCCP-CM CPN models have been gradually refined to faithfully reflect the DCCP specification. Our contribution to RFC 4340 is also discussed in this section. Our models were created and maintained using Design/CPN [202], a software package for the creation, editing, simulation and state space analysis of CPNs. Design/CPN supports the hierarchical construction of CPNs [105], using constructs called substitution transitions. These transitions (macro expansions) hide the details of subnets and allow further nesting of substitution transitions. This allows a complex specification to be managed as a series of hierarchically related pages which are visualised in a hierarchy page, automatically generated by Design/CPN.

10.3.1

Refinement of the hierarchical structure of DCCP-CM CPN model

The first step of modelling DCCP connection management (DCCP-CM) is to identify the interaction between DCCP entities and their environment. The top level of our initial CPN model [206] (Internet Draft version 5) shown in Fig. 10.3 comprises six places and two substitution transitions. Substitution transition DCCP C represents the client and DCCP S represents the server. There are two places, App Client and App Server which store application commands (e.g. Active Open), for the client and server, two places, Client State and Server State, that store DCCP entity states, including state variables,

144

1‘appListens

1‘appOpens

APP_Server

APP_Client COMMAND

COMMAND CH_C_S



PACKETS DCCP_C HS

Client_State CB

DCCP_S HS

Server_State CB

CH_S_C PACKETS

Figure 10.3: The top level page from [206]. Hierarchy#10010

DCCP#1 DCCP_C DCCP_S

Declarations#11

M Prime

DCCP_CM#2 Closed Listen

CLOSED#3 P

LISTEN#4

In

App_A HS

COMMAND

CH_A_B

Closed

P Out

PACKETS

Listen HS

Request Respond

REQUEST#5

Request HS

Respond

RESPOND#6

HS

Open

Open

HS

OPEN#7

P I/O

State

CB

CloseReq HS

CloseReq Closing TimeWait

CLOSEREQ#8

Closing HS

TimeWait

CLOSING#9

HS

TimeWai1#10

P In

CH_B_A PACKETS

(a)

(b)

Figure 10.4: (a) The hierarchy page from [206] (b) The second level page from [206]. in a so called Control Block (CB) and two places, CH C S and CH S C, representing channels between the client and server (one for each direction). The layout of the model is suggestive of the conceptual locations of the entities being modelled: the applications in the layer “above” DCCP; the client on the left and server on the right; and the channels between the client and server. This follows the practice adopted in [14] and is very similar to the top level page of our CPN model of TCP [14, 81]. We initially assume the packets in channels can be reordered but not lost. The next step is to model the DCCP entities in the second level CPN page. The substitution transitions DCCP C and DCCP S are linked to the DCCP CM#2 page (see Fig. 10.4 (a)). The DCCP CM#2 is arranged into a further eight5 substitution transitions 5

DCCP Internet Draft version 5 did not include the PARTOPEN state.

145

(Fig. 10.4 (b)) named after DCCP major states. Each substitution transition is linked to a third level CPN page which models DCCP behaviour for each major state. This modelling method follows a “state-based” approach because the model is similar to how DCCP is specified using the state diagram. In a state-based approach, every major state is considered in turn, and in each state, transitions are created for each input, which may be a user command, the arrival of a packet or the expiry of a timer. The state-based approach is very suitable when we are creating and building a new model as it is easy to understand and validate against the state machine and the narrative description. A disadvantage of the state-based approach is that the model may include a lot of redundancy because different states may process the same inputs in the same or similar way. When we upgraded the model [128] to DCCP version 6, one state could have many executable transitions (more than 7-8 transitions). Thus we regrouped transitions that have similar functions into fourth level pages as shown in Fig 10.5. For example, the client’s actions in the REQUEST state are rearranged into three groups: terminating the connection; not-terminating the connection; and retransmission on time-out. Hierarchy#10010 DCCP#1

M

Prime

Declarations#3 Open

DCCP_CM#2 DCCP_C DCCP_S

Open#10

Closed

Rcv_Terminate_Packet

Closed#4

Open_Teardown#30

Listen

CloseReq

Listen#5

Close_Request#8

Request

Request#7


CloseReq_Teardown#31 Rcv_Terminate_Packet TimeOut

Request_Teardown#15

CloseReq_Timeout#32 Rcv_nonTerminate_Packet

Request_Receive_Packet#24

Closing

Closing#11

TimeOut


Request_Timeout#23

Closing_Teardown#33

Respond

Respond#6

TimeOut Rcv_Terminate_Packet

Closing_Timeout#34

Respond_Teardown#25 Rcv_nonTerminate_Packet

Respond_Receive_Packet#26

TimeWait

Timewait#12

PartOpen

PartOpen#9


PartOpen_Teardown#27 Rcv_nonTerminate_Packet

PartOpen_Receiver_Packet#28 TimeOut

PartOpen_Timeout#29

Figure 10.5: The hierarchy page from [128].

146

As we refined the state-based CPN model by including more detail of the Internet Drafts, it became increasingly difficult to maintain the model. We faced this difficulty when developing the CPN model [212] for version 11. To overcome this problem we folded transitions that are common to many states and moved them to a CommonProcessing#7 page as shown in Fig. 10.6. The obvious common actions are how to respond to DCCP-Sync and DCCP-Reset packets. This resulted in an immediate pay off. When we reported the chatter problem [212] in version 11 [120] to IETF, IETF asked us to test their solution [123] in our CPN model. To incorporate the solution we changed only a single variable on an arc in the Reset Rcv page. We could thus analyse the modified model within five minutes to show that chatter had been removed. The important merit of removing redundancy by folding similar transitions is the ability to maintain the model efficiently. The resulting CPN model is a little more difficult to read, but the maintenance pay off is well worth it. When the specification is mature and relatively stable, we recommend removing redundancies by folding similar transitions so that it is easier to maintain. After IETF had revised DCCP and issued version 13 [122], we decided to remove further redundancies by Hierarchy#10 010

DCCP#1

M

DCCP_C

Prime

Declarations#12

DCCP_CM#2

DCCP_S Closed

Listen

Request

Open

Closed#30

Open#36 RcvTerminatePkt36

Listen#31

Open_Teardown#462 CloseReq

Request#32

Close_Request#37

RcvNonTerminated_Pkt32

RcvTerminatePkt37

Request_Receive_Packet#421

CloseReq_Teardown#473

TimeOut32

TimeOut37

Request_Timeout#422 Respond

CloseReq__Timeout#472 Closing

Respond#33

Closing#38 RcvTerminatePkt38

RcvNonTerminate_Pkt33

Closing_Teardown#483

Respond_Receive_Packet#431

TimeOut38

RcvTerminatePkt33

Closing_Timeout#482

Respond_Teardown#432 PartOpen

TimeWait

Timewait#35

PartOpen#34 RcvNonTerminatePkt34

PartOpen_Receiver_Packet#441

Common

CommonProcesses#7 RcvOtherPkt

TimeOut34

PartOpen_Timeout#442

RecOthPkt#497 RcvReset

RcvTerminatePkt34

PartOpen_Teardown#443

Reset_Rcv#498 RcvSync

Sync_Rcv#499

Figure 10.6: The hierarchy page from [212].

147

Hierarchy#10010 M Prime

DCCP#1 DCCP_C

Declarations#16

DCCP_CM#2

DCCP_S UserCMD

UserCommands#3

Idle_State

IdleState#4

Request

Request#5

Respond

PartOpen DataTransfer ClosingDown Common

Respond#6 PartOpen#7 DataTransfer#8 ClosingDown#9 CommonProcessing#10 RcvSync RcvReset TimeOut UnexpectedPkt RcvInvalidHeader

RcvSync#11 RcvReset#12 Retransmission#13 UnExpected#14 RcvInvalid#15

Figure 10.7: The hierarchy page of the final DCCP-CM CPN model.

folding and regrouping all transitions (which we illustrate in section 10.3.3). During the folding process we considered a trade-off between redundancy and readability. The structure of the final CPN model is shown in Fig. 10.7. We merged the CLOSED, LISTEN and TIMEWAIT states and gathered them into the IdleState page. The procedures that are common to states other than the idle states were regrouped into new pages, including the UserCommands and ClosingDown pages, and those grouped together under the CommonProcessing page such as the Retransmission page. This also involved some renaming of pages and resulted in a much simpler architecture as can be seen in Fig. 10.7. The number of pages was reduced from 32 to 15, and the number of transitions from 86 to 52.

10.3.2

Refinement of the data structures of the DCCP-CM CPN model

In the previous subsection we discussed the modelling process and the refinement of the structure of our models. This section discusses the way we refined the data structures over four versions of DCCP-CM CPN model [128, 206, 210, 212]. The DCCP-CM model

148

we initially built and published in [206] is based on DCCP version 5 [126]. The model was simple and abstract and has the following merits: compact, easy to understand, rapidly built and fast to analyse. It took only two weeks for an inexperienced student to create and test the model [206]. A deadlock was quickly discovered using state space analysis. DCCP Internet Draft version 5 Our initial model [206] was based on a number of assumptions: 1) A DCCP packet was modelled by its packet type and sequence and acknowledgement numbers. Other fields in the DCCP header were omitted because they do not affect the operation of the connection management procedure. 2) DCCP version 5 specified 24-bit sequence numbers and provided an option for extended 48-bit sequence numbers. We only modelled 24-bit sequence numbers. 3) Version 5 specified that the Request and Data packets do not have acknowledgement numbers. However for ease and speed of creating the model we allowed these two packet types to have dummy acknowledgement numbers. 4) State variable GAR was omitted because it was optional in DCCP version 5. 5) After version 5 was released, there was a lot discussion in IETF regarding the synchronisation procedure. At that time the synchronisation procedure was not mature. (For example version 5 did not specify the DCCP-SyncAck packet.) Hence synchronisation was not included. 6) Processing of unexpected packets was not taken into account. 7) Wrapping of sequence numbers was not included. 8) Features/options were not included. 9) Malicious attacks were not considered. Assumptions 3 and 4 allowed us to defined the CB (Control Block) in Fig. 10.8 to be a product of STATE, BackOffFlag and a record of GSS and GSR. For example, Fig. 10.3 shows the initial marking 1‘(CLOSED, OFF, {GSS=100, GSR=0}) in the place Client State. Because we used the same data structure for every state, the CPN model was simple and built rapidly. As a result of assumption 7, we did not need to implement modulo arithmetic, however, our results were restricted to when sequence numbers do not wrap. Despite all these assumptions, our analysis of the initial DCCP-CM CPN model revealed that a deadlock occurred during connection setup [206]. The deadlock was due to Reset packets with sequence number zero being valid. Hence the deadlock we found was not due to any of the assumptions made. 149

1: color STATE = with CLOSED | LISTEN | REQUEST | RESPOND | OPEN | CLOSEREQ 2:

| CLOSING | TIMEWAIT;

3: color BackOffFlag = with ON | OFF; 4: color StateVariable = record GSS:INT*GSR:INT; 5: color CB = product STATE*BackOffFlag*StateVariable; 6: color PacketType = with Request | Response | Ack | DataAck | Data | CloseReq 7:

| Close | Rst ;

8: color SeqAck

= record SEQ:INT*ACK:INT;

9: color PACKETS = product PacketType*SeqAck;

Figure 10.8: Definition of DCCP’s Control Block and PACKETS from [206]. 1: color SEQ24

= int with 0..16777215; (* 24-bit sequence number *)

2: color PacketType = with Request | Response | Ack | DataAck | Data | CloseReq 3:

| Close | Rst;

4: color SeqWAck

= record SEQ:SEQ24*ACK:SEQ24;

5: color SeqAck

= union WAck:SeqWAck + SEQ24;

6: color PACKETS = product PacketType*SeqAck;

Figure 10.9: Definition of PACKETS from [128]. DCCP Internet Draft version 6 When we updated the DCCP-CM model to DCCP version 6 [128], we attempted to faithfully define the packet structure. Firstly, we restricted the value of the sequence number to range from zero to 224 − 1 (line 1 of Fig. 10.9). Secondly, the sequence and acknowledgement number record (SeqAck) was redefined as a union of the sets SeqWAck and SEQ24 (line 5 of Fig. 10.9). Thus the Request and Data packets, which do not include an acknowledgement number, can be modelled accurately. The model in [128] also includes the PARTOPEN state but does not include the re-synchronisation process. The analysis of the CPN model of DCCP Internet Draft version 6 showed the deadlock problem was still present. DCCP Internet Draft version 11 Instead of 24-bit sequence numbers, Internet Draft version 7 [116] specified 48-bit long sequence numbers as mandatory for all packet types. Short sequence numbers were only allowed to be used in Data, Ack and DataAck packets. We upgraded the DCCP-CM

150

1: color PacketType1 = with Request | Data; 2: color PacketType2 = with Sync | SyncAck | Response | Ack | DataAck 3:


4: color SN = IntInf with ZERO..MaxSeqNo; 5: color SN_AN = record SEQ:SN*ACK:SN; 6: color PacketType1xSN = product PacketType1*SN; 7: color PacketType2xSN_AN = product PacketType2*SN_AN; 8: color PACKETS = union PKT1:PacketType1xSN+PKT2:PacketType2xSN_AN;

Figure 10.10: Definition of PACKETS from [212]. CPN model [212] according to DCCP version 11 [120]. This model represents long sequence numbers by “infinite integers” in ML, ranging from zero to 248 − 1 (line 4 of Fig. 10.10) but does not include short sequence numbers. We also incorporated an up-todate algorithm for checking sequence number validity and included the synchronisation mechanism. The previous declaration in Fig. 10.9 allows Request and Data packets to have acknowledgement numbers and other packet types to be without acknowledgement numbers. To improve the representation of the packet structure, we defined PacketType1 to be a DCCP packet without an acknowledgement number and PacketType2 to be a DCCP packet with an acknowledgement number as shown in Fig. 10.10 (line 1-2). In DCCP versions 5 and 6 we found deadlocks because a delayed Reset packet with a sequence number of zero is always valid. Since version 7 [116] a Reset packet with a sequence number of zero was no longer always valid. This modification to the specification removed these deadlock problems. Although we did not find any deadlocks or livelocks in DCCP version 11, we discovered chatter [212]. In [208] we showed that if a chattering scenario occurs, it is highly likely (probability > 0.99999) that more than two billion messages will be needlessly exchanged. Although the chance of a particular scenario is low, we discovered a large number of possible chattering scenarios. The Internet Standard RFC4340 After submitting the discovery of chatter to IETF, the principal editor of the specification advised us that the chatter problem was more severe than we originally thought, especially when using short sequence numbers. This motivated us to revise the model to include both long and short sequence numbers. Figure 10.11 shows the definition of PACKETS in the final CPN model. As before, long sequence numbers (SN48) in line 15 of

151

1: (* Packet Structure *) 2: (* Maximum Sequence Number Values *) 3: val MaxSeqNo48=IntInf.-(IntInf.pow(IntInf.fromInt(2),48),IntInf.fromInt(1)); 4: val MaxSeqNo24=IntInf.-(IntInf.pow(IntInf.fromInt(2),24),IntInf.fromInt(1)); 5: val max_seq_no24 = IntInf.toInt(MaxSeqNo24); 6: (* Packet Types

*)

7: color PktType1 = with Request | Data; 8: color PktType2 = with Sync | SyncAck | Response | Ack | DataAck 9:


10: color DATA=subset PktType1 with [Data]; 11: color ACK_DATAACK=subset PktType2 with [DataAck,Ack]; 12: (* Extended Sequence Number Flag *) 13: color X = with LONG | SHORT; 14: (* Sequence Number *) 15: color SN48 = IntInf with ZERO..MaxSeqNo48; 16: color SN48_AN48 = record SEQ:SN48*ACK:SN48; 17: color SN24 = int with 0..max_seq_no24; 18: color SN24_AN24 = record SEQ:SN24*ACK:SN24; 19: (* Four Different Types of Packets *) 20: color Type1LongPkt=product PktType1*X*SN48; 21: color Type2LongPkt=product PktType2*X*SN48_AN48; 22: color Type1ShortPkt=product DATA*X*SN24; 23: color Type2ShortPkt=product ACK_DATAACK*X*SN24_AN24; 24: color PACKETS=union PKT1:Type1LongPkt 25:

+ PKT2:Type2LongPkt

+ PKT1s:Type1ShortPkt + PKT2s:Type2ShortPkt;

26: (* Variables *) 27: var sn:SN48;

var sn_an:SN48_AN48;

28: var sn24:SN24; var sn24_an24:SN24_AN24; 29: var LS:BOOL;

var ack_dataack:ACK_DATAACK;

Figure 10.11: Definition of DCCP PACKETS in the final CPN model.

Fig. 10.11 are represented by infinite integers ranging from zero to 248 − 1. Short sequence numbers (SN24) in line 17 are represented by integers ranging from zero to 224 − 1. The strong typing of packets is very useful for developing and debugging the model, as certain mistakes can be easily detected by a syntax check.

152

While analysing the revised model, we found an error in the algorithm for extending short sequence numbers to long sequence numbers (page 60 of [120]) and submitted the problem to IETF. IETF devised solutions to these problems (chatter and the algorithm for short sequence number extension) [123]. These solutions have been incorporated into RFC 4340 [124]. When revising the CPN model, we attempted to define the control block in Fig. 10.12 so that it truly reflected DCCP’s definition and removed ambiguities. When in CLOSED and LISTEN, the GSS, GSR, GAR, ISS and ISR state variables do not exist, while the client in the REQUEST state has only instantiated GSS and ISS. Thus we classify DCCP states into three groups: idle, request and active states. These three groups also have differences regarding the functional behaviour of how to respond to the DCCP-Reset and DCCP-Sync packets. We suggested to IETF that it is not necessary for TIMEWAIT to maintain state variables because the connection is about to close. It was agreed that 1: (* DCCP state variables*) 2: color RCNT=int;(*Retransmission Counter*) 3: (* FSM State *) 4: color IDLE=with CLOSED_I| LISTEN| CLOSED_F| TIMEWAIT; 5: color REQUEST = product RCNT*SN48*SN48; 6: color ACTIVE = with RESPOND| PARTOPEN| S_OPEN| C_OPEN 7:


8: (* Sequence Number Variables *) 9: color GS = record GSS:SN48*GSR:SN48*GAR:SN48; 10: (* Initial Sequence Number *) 11: color ISN = record ISS:SN48*ISR:SN48; 12: (* Control Block *) 13: color ACTIVExRCNTxGSxISN=product ACTIVE*RCNT*GS*ISN; 14: color CB = union IdleState:IDLE 15:

+ ReqState:REQUEST

16:


17: (* User Commmands *) 18: color COMMAND = with p_Open | a_Open | a_Close | server_a_Close; 19: (* Variables *) 20: var idle_state:IDLE; var active_state:ACTIVE; var g:GS;

Figure 10.12: DCCP’s control block and user commands in the final model.

153

TIMEWAIT should be classified in the group of idle states [125]. This helps to reduce the size of the state space (e.g. from 42,192 to 26,859 nodes for the case of connection establishment). We define each group of states with a different set of state variables. Fig. 10.12 defines CB (line 14) as a union of colour sets: IDLE, REQUEST and ACTIVExRCNTxGSxISN. IDLE (line 4) defines three idle states: CLOSED, LISTEN and TIMEWAIT. The CLOSED state is split into CLOSED I to represent the initial CLOSED state and CLOSED F to represent a terminal CLOSED state. This separation is useful when analysing state spaces [210]. The colour set REQUEST is a product comprising RCNT (Retransmission Counter, line 2), GSS and ISS. Because there is only one state in this group, the REQUEST state is already distinguished from other states by using the ML selector ReqState in the union (line 14). The ACTIVExRCNTxGSxISN (line 13) is a product comprising ACTIVE (line 6), RCNT, GS (Greatest Sequence and Acknowledgement Numbers, line 9) and ISN (Initial Sequence Numbers, line 11). ACTIVE (line 6) defines five DCCP states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. Because the client and server respond to the CloseReq packet differently in the OPEN and CLOSING states, we differentiate these states for the client and server: C OPEN and C CLOSING for the client; and S OPEN and S CLOSING for the server. Figure 10.12 also defines the colour set, COMMAND, on line 18. The places App Client and App Server in Fig. 10.3, typed by COMMAND, model DCCP user commands (i.e. commands that can be issued by the applications that use DCCP). For example, the user command 1‘a Open is the initial marking of App Client indicating that the client’s application desires to open a connection.

10.3.3

Illustration of folding and regrouping of transitions at the executable level

This section discusses some examples of how the DCCP CM CPN model has evolved at the executable level from the purely state-based approach to a mixed state-based and event processing model. We firstly present the second-level page to provide an overview of the revised model.

154

P In

App_A COMMAND UserCMD

HS

Ch_A_B

P Out

PACKETS Idle_State

HS

Request HS

Respond HS

P I/O

State

PartOpen HS

CB DataTransfer HS

ClosingDown HS

HS

Common Processing

Ch_B_A

P In

PACKETS

Figure 10.13: The DCCP CM page.

The second level page Figure 10.13 shows the DCCP CM page which comprises eight substitution transitions. UserCMD models the actions taken when receiving commands from users. Idle State combines similar processing actions required in the CLOSED, LISTEN and TIMEWAIT states. Request, Respond and PartOpen encapsulate the major processing actions in each of the corresponding states. DataTransfer represents actions taken when receiving the DCCP-Data, DCCP-Ack and DCCP-DataAck packets in the OPEN, CLOSEREQ and CLOSING states. ClosingDown defines the procedures undertaken on receiving a DCCPClose or DCCP-CloseReq packet in the five active states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. Finally, Common Processing comprises procedures that are common to various states including packet retransmissions, timer expiry, and the receipt of DCCP-Reset, DCCP-Sync and DCCP-SyncAck packets, unexpected packets and packets with an invalid header. The IdleState page The “state-based” model of Fig. 10.6 was further refined to include the processing of short sequence numbers. The resulting procedures for DCCP in the CLOSED, LISTEN and TIMEWAIT states are shown in Figs 10.14, 10.15 and 10.16. It is apparent that the

155

P In

App_A COMMAND 1‘p_Open PassiveOpen

IdleState CLOSED_I IdleState LISTEN P I/O State

1‘a_Open ActiveOpen

IdleState CLOSED_I

PKT1 (Request, LONG, C_iss)

Output

ReqState (0,C_iss,C_iss) [(p_type2Rst) andalso (cb=IdleState CLOSED_I orelse cb = IdleState CLOSED_F) ] PKT2 (Rst, LONG, {SEQ=incr(#ACK(sn_an)), ACK=#SEQ(sn_an)}) cb RcvPktWAck

CB

P Out PACKETS

PKT2 (p_type2, LONG, sn_an) [cb=IdleState CLOSED_I orelse cb=IdleState CLOSED_F] PKT2 (Rst, LONG, {SEQ=ZERO,ACK=sn}) RcvPktWOAck PKT1 (p_type1, LONG, sn)

cb

RcvShortSeq HS

[cb=IdleState CLOSED_I orelse cb = IdleState CLOSED_F] RcvReset

cb

Input

P In

PKT2 (Rst, LONG, sn_an)

PACKETS

Figure 10.14: The CLOSED page. Output

RcvShortSeq HS

State

P I/O CB

IdleState LISTEN

RcvRequest

PKT2 (Response, LONG, {SEQ=S_iss, ACK=sn}) PKT1 (Request, LONG, sn)

ActiveState (RESPOND, 0, {GSS=S_iss, GSR=sn, GAR=S_iss},{ISS=S_iss,ISR=sn}) [p_type2 Rst ] IdleState LISTEN

P Out PACKETS

RcvPktWAck

PKT2 (Rst, LONG, {SEQ=incr(#ACK(sn_an)), ACK= #SEQ(sn_an)}) PKT2 (p_type2, LONG, sn_an)

[p_type1 Request] IdleState LISTEN

RcvPktWOAck

PKT2 (Rst, LONG, {SEQ=ZERO, ACK = sn}) PKT1 (p_type1, LONG, sn)

IdleState LISTEN

RcvReset

Input PKT2 (Rst, LONG, sn_an)

P In PACKETS

Figure 10.15: The LISTEN page.

procedures for receiving packets in each of these three states are almost identical. The only difference is the receipt of the Request packet in LISTEN. We also observe that the TIMEWAIT state includes state variables such as those required for recording sequence number values (e.g. for GSS, GSR and GAR). However, on close inspection we considered that these variables were not required. We discussed this issue with the main IETF DCCP

156

P Out

ActiveState (TIMEWAIT, rcnt, g, isn)

TimerExpire

Output

IdleState CLOSED_F

PACKETS


RcvPktWOAck

ActiveState (TIMEWAIT, 0, {GSS=incr(#GSS(g)), GSR=Update(sn,#GSR(g)),GAR=#GAR(g)}, isn)

PKT1 (p_type1, LONG, sn) [p_type2 Rst ]

P I/O

State CB

PKT2 (Rst, LONG, {SEQ=incr(#GSS(g)), ACK=Update(sn,#GSR(g))})


RcvPktWAck

ActiveState (TIMEWAIT, 0, {GSS=incr(#GSS(g)), GSR=Update(#SEQ(sn_an), #GSR(g)), GAR=Update(#ACK(sn_an), #GAR(g))}, isn)

PKT2(Rst, LONG, {SEQ=incr(#GSS(g)), ACK=Update(#SEQ(sn_an),#GSR(g))}) PKT2(p_type2, LONG, sn_an)

RcvShortSeq HS

P In

RcvReset ActiveState (TIMEWAIT, rcnt, g, isn)

Input PKT2 (Rst, LONG, sn_an) PACKETS

Figure 10.16: The TIMEWAIT page. ActiveState (RESPOND,0,{GSS=S_iss, GSR=sn,GAR=S_iss},{ISS=S_iss,ISR=sn})

RcvRequest

PKT2 (Response, LONG, {SEQ=S_iss,ACK=sn})

Output P

IdleState LISTEN PKT1 (Request, LONG, sn) [p_type2Rst ] IdleState idle_state

RcvLongWAck

Out

PACKETS

PKT2 (Rst, LONG, SeqAck(NoGS, SA48 sn_an)) PKT2 (p_type2, LONG, sn_an)

IdleState idle_state

[idle_state LISTEN orelse p_type1 Request ] PKT2(Rst, LONG, SeqAck(NoGS, S48 sn)) RcvLongWOAck


[(p_type2 = Ack orelse p_type2 = DataAck) andalso ShortEnable ] PKT2 (Rst, LONG, RcvShortWAck SeqAck(NoGS,SA24 sn24_an24) )

PKT1 (p_type1, LONG, sn)

PKT2s (p_type2, SHORT, sn24_an24) State P I/O CB

[ShortEnable] IdleState idle_state

RcvShortWOAck



RcvReset

IdleState TIMEWAIT

TimerExpires


Input P In

IdleState CLOSED_F

PACKETS

Figure 10.17: The IdleState page.

editor, who agreed to remove ambiguity in the specification to make it clear that these variables are not needed in TIMEWAIT. We therefore deleted these variables. Further we grouped all the user commands together in a new page called UserCommands, thus removing transitions PassiveOpen and ActiveOpen from the CLOSED page. This then allowed the CLOSED, LISTEN and TIMEWAIT pages to be merged into a single page called IdleState shown in Fig. 10.17. The RcvRequest and TimerExpire transitions remain the same, but the other transitions for receipt of packets are folded together, and the

157

substitution transition for the processing of short sequence number packets is expanded, so that all processing at a similar level is included on this page. This reduces the number of (executable) transitions from 17 to 7, and removes 3 substitution transitions. The folded model thus elegantly captures common processing in these states, highlights the differences and reduces maintenance effort, at the cost of introducing a variable that runs over the idle states. The RcvReset page During the development process we gained insight into the protocol’s behaviour. An example of this is that DCCP’s behaviour, when receiving a Reset packet, can be classified into three cases. Firstly, the CLOSED, LISTEN and TIMEWAIT states ignore Reset packets as shown in Fig. 10.17. Secondly the client in the REQUEST state replies with a Reset packet. Because the client in REQUEST has not yet recorded an ISR, the acknowledgement number of the outgoing Reset is equal to zero according to section 8.1.1 of [124]. Thirdly, when the DCCP entity in any other active state receives a valid Reset, it enters TIMEWAIT but on receiving an invalid Reset, it replies with a Sync packet. However the Sync packet has an acknowledgement number equal to GSR rather than the sequence number received (section 7.5.4 of [124]). Instead of including a RcvReset transition in every state page, we group this behaviour into one CPN page as shown in Fig. 10.18. It comprises three transitions: InActiveState, InRequestState and InIdleState. Each one models the action of DCCP when receiving a Reset packet in a state corresponding to its name. Thus we moved transition RcvReset from IdleState to the RcvReset page. This page illustrates the “event processing” style of specification. In this case it provides a more compact and maintainable model compared with the state-based approach, where the number of executable transitions has been reduced from 9 to 3. The Retransmission page During connection set up and close down retransmissions occur when DCCP has not received a response from its peer within a specified period (a timer expires). We group all transitions related to retransmission into a CPN page called the Retransmission page shown in Fig. 10.19. Retransmission in each state is modelled by the transition corresponding to the state’s name: Retrans REQUEST; RetransShort PARTOPEN; RetransLong PARTOPEN; Retrans CLOSEREQ and Retrans CLOSING. In PARTOPEN the client can retransmit either an Ack or a DataAck with short or long sequence numbers. Each 158

ActiveState (active_state,rcnt,g,isn)

InActiveState

P I/O ReqState (rcnt,gss,iss)

InRequestState


P Out

PACKETS

if RstValidinReqState(sn_an,gss,iss) then empty else SndRstInReq(gss) PKT2 (Rst, LONG, sn_an)

if RstValidinReqState(sn_an,gss,iss) then IdleState TIMEWAIT else ReqState (rcnt,IntInf.+(gss,ONE),iss)

CB

Output

PKT2(Rst, LONG, sn_an)

if PktValid(Rst, sn_an, g, isn) then IdleState TIMEWAIT else ActiveState (active_state,rcnt,incrGSS(g),isn) State

if PktValid(Rst,sn_an,g,isn) then empty else 1‘PKT2(Sync, LONG, {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

InIdleState

Input

P In


PACKETS

Figure 10.18: The RcvReset page. [rcnt < MaxRetransRequest ] Retrans_REQUEST

ReqState(rcnt, gss, iss)

PKT1 (Request, LONG, incr(gss))

ReqState (rcnt+1, incr(gss), iss)

BackOff_REQUEST

ReqState (MaxRetransRequest,gss,iss)

SndRstInReq(gss)

IdleState CLOSED_F [ rcnt < MaxRetransAckDataAck andalso ShortEnable] ActiveState (PARTOPEN, rcnt, g, isn) RetransShort_PARTOPEN

PKT2s(ack_dataack,SHORT, {SEQ=mod_sn24(incr(#GSS(g))), ACK=mod_sn24(#GSR(g))})

ActiveState (PARTOPEN,rcnt+1, incrGSS(g),isn) P I/O State CB

ActiveState (PARTOPEN,rcnt,g,isn)

[rcnt < MaxRetransAckDataAck] RetransLong_PARTOPEN

PKT2(ack_dataack, LONG, {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

ActiveState (PARTOPEN,rcnt+1, incrGSS(g),isn)

P Out PACKETS

[rcnt < MaxRetransCloseReq] ActiveState (CLOSEREQ,rcnt,g,isn)

Output

Retrans_CLOSEREQ

PKT2 (CloseReq, LONG, {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

ActiveState(CLOSEREQ, rcnt+1,incrGSS(g),isn) [(active_state = C_CLOSING orelse active_state =S_CLOSING) andalso rcnt < MaxRetransClose ] PKT2 (Close, LONG, ActiveState (active_state,rcnt,g,isn) Retrans_CLOSING {SEQ=incr(#GSS(g)),ACK=#GSR(g)}) ActiveState (active_state, rcnt+1,incrGSS(g),isn)


[BackOff(active_state,rcnt) ] PKT2(Rst, LONG, BackOff_ActiveState {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

IdleState CLOSED_F

Figure 10.19: The Retransmission page. retransmission increases the retransmission counter (rcnt) by one. This approach clearly shows the states in which retransmission is possible. For example, retransmission does not occur in the RESPOND state. When the counter reaches the maximum retransmission value, DCCP resets the connection and enters the CLOSED state. These actions are modelled by the transition BackOff REQUEST for the REQUEST state and BackOff ActiveState for the RESPOND, PARTOPEN, CLOSEREQ and CLOSING states. The guard function, BackOff, checks whether the number of retransmissions has reached the maximum value or not. Although no Response packet is retransmitted in RESPOND, DCCP enters the CLOSED state after holding the RESPOND state for longer than the backoff timer period (4MPL). 159

The common backoff timer procedure for active states is captured in the one transition (BackOff ActiveState), avoiding repetition of this behaviour in each state page.

10.4

Conclusion and future work

This paper has presented our approach to the development of a formal model of the connection management and synchronisation procedures of the Internet’s Datagram Congestion Control Protocol. We discuss how our CPN model was refined using an incremental approach while the specification was being developed by IETF. We started with a small model of an early Internet Draft and illustrated how to use hierarchical CPNs to structure the model. This model used a state-based approach. We then showed how the model’s hierarchical structure and data structures evolved to capture DCCP’s specification faithfully as it was progressively developed by IETF. At various stages of the development we analysed the model and found errors in the specification. Serious errors, such as chatter, were reported to IETF and their solutions verified before DCCP became a standard (RFC 4340). We found that as the state-based CPN model grew, a lot of redundancy crept into the model. This was especially the case when including the synchronisation procedures. The redundancy occurs when the receipt of the same packet in different states requires the same processing. We revised parts of the model using an event processing style so that similar events occurring in various states are regrouped into one transition. The final model is significantly more compact than the previous models. Significant effort was put into validating the model. This can be facilitated by firstly using the state-based approach so that it is easy to check that an action is defined for the receipt of each packet in each state. The state-based approach is easier to read, however, the judicious introduction of the event processing style in significant parts of the model made it easier to maintain, as our interaction with IETF proved. The overall benefits of the approach include: the model is formal and hence removes ambiguity; the model gathers together disparate parts of the RFC that are specified by a combination of narrative, a state machine and pseudo code in different sections; the concurrency inherent in the protocol is retained; and the CPN model can be analysed to obtain results which are fed back into the standardisation process to improve the specification before it becomes a standard. Our incremental approach to the analysis of the model requires consideration of four 160

different channel types: ordered without loss; ordered with loss; reordered without loss; and reordered with loss. To facilitate maintenance of the model, we are currently integrating these different channel types into a single CPN model. We are also interested in modelling and analysing the feature negotiation procedures.

161

Declaration for Chapter 11 Declaration by candidate In the case of Chapter 11, “Analysis of the Datagram Congestion Control Protocol’s Connection Management Procedures using the Sweep-line Method”, the nature and extent of each author’s contributions to the work were the following: Nature of Contribution



1st

2nd

3rd


50

40

10


80

10

10


90

5

5

4. Developing the progress measures

85

5

10


80

10

10


80

10

10


5

80

15


5

75

20


5

90

5

0

80

20




Date

Declaration by co-author The undersigned hereby certify that: (1) the above declaration correctly reflects the nature and extent of the candidate’s contribution to this work, and the nature of the contribution of each of the co-authors. (2) they meet the criteria for authorship in that they have participated in the conception, execution, or interpretation, of at least that part of the publication in their field of expertise; (3) they take public responsibility for their part of the publication, except for the responsible author who accepts overall responsibility for the publication; (4) there are no other authors of the publication according to these criteria; (5) the co-authors permit the publication to be included in this thesis.

Signature

Date

Signature

Date

162

Chapter 11 Analysis of the Datagram Congestion Control Protocol’s Connection Management Procedures using the Sweep-line Method Chapter 11 is a preprint of an accepted journal paper, S. Vanit-Anunchai, J. Billington, and G.E. Gallasch, “Analysis of the Datagram Congestion Control Protocols Connection Management Procedures using the Sweep-line Method”, International Journal on Software Tools for Technology Transfer, special section on material from CPN06.

This chapter is, except for minor typographical changes, the same as the paper. The copyright of this text belongs to Springer-Verlag. The text is re-published in this thesis according to the permission stated in http://www.springer.de/comp/lncs/copyright.html

The homepage of LNCS series is http://www.springer.de/comp/lncs/index.html

163

Analysis of the Datagram Congestion Control Protocol’s Connection Management Procedures using the Sweep-line Method S. Vanit-Anunchai1 , J. Billington and G. E. Gallasch2 Computer Systems Engineering Centre, University of South Australia Mawson Lakes Campus, SA 5095, Australia email:[email protected], Jonathan.Billington,[email protected]

Abstract State space explosion is a key problem in the analysis of finite state systems. The sweep-line method is a state exploration method which uses a notion of progress to allow states to be deleted from memory when they are no longer required. This reduces the peak number of states that need to be stored, while still exploring the full state space. The technique shows promise but has never achieved reductions greater than about a factor of 10 in the number of states stored in memory for industrially relevant examples. This paper discusses sweep-line analysis of the connection management procedures of a new Internet standard, the Datagram Congestion Control Protocol (DCCP). As the intuitive approaches to sweep-line analysis are not effective, we introduce new variables to track progress. This creates further state explosion. However, when used with the sweep-line, the peak number of states is reduced by over two orders of magnitude compared with the original. Importantly, this allows DCCP to be analysed for larger parameter values.

Keywords: State Space Methods, Sweep-line, DCCP, Coloured Petri Nets, State Explosion. 1

Somsak Vanit-Anunchai was partially supported by an Australian Research Council Discovery Grant

(DP0559927) and Suranaree University of Technology. 2 Guy Edward Gallasch was supported by an Australian Research Council Discovery Grant (DP0559927).

164

11.1

Introduction

The state space method is one of the main approaches for formally analysing and verifying the behaviour of concurrent and distributed systems. In essence, this method generates all or part of the reachable states of the system. After the state space is generated, many analysis and verification questions about the system’s behaviour (such as “does the system deadlock or livelock?”), can be answered. Unlike theorem proving, state space analysis tools are easier to use because they involve less complex mathematics that is often hidden by automatic computer tools, and they can provide counter examples for debugging purposes. Despite these advantages, the state space approach suffers from the well known state explosion problem [204]. Even relatively small systems can generate state spaces that cannot be stored in computer memory. Thus many attempts have been made to alleviate this problem. An excellent overview and literature review about the state explosion problem is given in [204]. The attempts to alleviate state explosion fall into three broad classes. The first considers methods that represent the state space in a condensed or compact form, such as symmetry reduction [54, 104]. The second class restricts state space exploration to a subset of the reachable states and includes partial order methods [172, 217] such as stubborn sets [203]. The third class involves deleting or throwing away states or state information on-the-fly during state space exploration. It includes methods such as bit-state hashing [89, 218], state space caching [77, 87], the sweep-line method [37, 137] and the pseudo-root technique [170]. To further reduce the state space, techniques from the different classes have also been combined, e.g. sweep-line and equivalence [15]. The sweep-line method exploits a notion of progress exhibited in the system being analysed. Progress mappings are defined by the user, to map the states of the system into a set of ordered progress values. Based on progress values, this method deletes old states from memory by reasoning that states with a lower progress value will not (or are unlikely to) be reached from states with a higher progress value. During exploration, a number of system properties, such as absence of deadlocks, can be verified on-the-fly. In the area of formal analysis and verification of computer protocols that recover from loss using retransmissions, the maximum number of retransmissions of messages plays an important role in state explosion. When the maximum number of retransmissions increases, the size of the state space tends to increase rapidly [66]. When using a small maximum number of retransmissions, errors tend to reveal themselves quickly, but this

165

does not guarantee that the system is error free for larger values of the maximum number of retransmissions. Thus it is necessary to extend state space analysis to include the highest maximum number of retransmissions possible, up to the limit specified by the protocol’s specification. Previously we have used the sweep-line method to verify termination properties of Coloured Petri Net (CPN) [105, 108, 132] models of various protocols such as the Wireless Transaction Protocol (WTP) [79], the Internet Open Trading Protocol (IOTP) [72], and the Transmission Control Protocol [69]. The Datagram Congestion Control Protocol (DCCP), specified in Request For Comments (RFC) 4340 [124], is a new transport protocol proposed by the Internet Engineering Task Force (IETF). The protocol is designed to support various kinds of congestion control mechanisms used by different delay sensitive applications. We use CPNs to build and analyse a formal executable model of DCCP’s connection management procedures according to RFC 4340 [124]. Our analysis [207] shows that DCCP connection establishment can fail when sequence numbers wrap3 . However, state explosion limits our analysis to a maximum of only one retransmission. We need to extend the analysis to cover two retransmissions and to determine two properties: whether the undesired deadlocks are still present; and whether any new errors have emerged as a result of the additional retransmissions. Instead of applying the more conventional approach of trying to reduce the size of the state space, we induce state space explosion by introducing new state variables into the specification model in order to capture additional information during model execution. By carefully selecting new state variables, the state space of the augmented model has a structure which facilitates far more efficient sweep-line analysis when compared with the state space of the specification model. This paper is a revised version of [210]. It has been expanded to include the full CPN model of DCCP’s connection management procedures. The contribution of this paper is three fold. Firstly, the paper presents the first complete formal specification of the connection management procedures of RFC 4340 at a level of detail sufficient for analysing all the main procedures. Building the CPN model has allowed us to remove ambiguities so that the risk of misinterpretation is very low. The CPN specification has the additional benefit that all relevant aspects of the procedures that are defined in different parts of the RFC have been brought together. Secondly, this paper provides insight into how an 3

Sequence number wrap occurs when the sequence number rolls over the maximum sequence number

to zero.

166

effective progress mapping for the DCCP connection management CPN model is derived. This is important because an effective progress mapping is key to the performance of the sweep-line method. Thirdly, we apply sweep-line analysis to the augmented model and demonstrate that the number of peak states stored, compared with sweep-line analysis of the specification model, can be significantly reduced. This has allowed us to extend the analysis of DCCP connection establishment to scenarios which could not be obtained with conventional analysis. This paper is organised as follows. Section 11.2 briefly describes DCCP’s connection management procedures which are then formalised in Section 11.3. Section 11.4 identifies sources of progress and derives a progress mapping for our augmented model of DCCP’s connection management procedures. The analysis results obtained for scenarios where sequence numbers wrap are discussed in Section 11.5. Finally, Section 11.6 presents our conclusions and future work. We assume some familiarity with CPNs [105, 108, 132].

11.2

Overview of DCCP’s connection management procedure

DCCP connection management has one connection establishment procedure and five closing procedures. These procedures are defined in [124] with the state diagram shown in Fig. 11.1. DCCP uses 8 packet types: Request, Response, Ack, DataAck, Data, CloseReq, Close and Reset to set up, transmit data and close down the connection. Two packet types, Sync and SyncAck, are used for synchronisation procedures. Figure 11.2 shows the typical procedure for connection set up (Fig. 11.2 (a)) and close down (Fig. 11.2 (b)). In brief, a connection is initiated by an application at the client issuing an “active open” command. (We assume that the application at the server has issued a “passive open” command.) After receiving the “active open” the client sends a DCCP-Request packet to the server to initialise sequence numbers, and enters the REQUEST state. The server replies with a DCCP-Response packet, indicating that it is willing to communicate with the client and acknowledging the DCCP-Request. The client sends a DCCP-Ack (or DCCP-DataAck) packet to acknowledge the DCCP-Response packet and enters the PARTOPEN state. The server acknowledges the receipt of the DCCP-Ack, enters the OPEN state and is ready for data transfer. Upon receipt of a DCCP-Ack (or DCCP-

167

CLOSED


passive open

REQUEST

LISTEN

rcv Close snd Reset



PARTOPEN

RESPOND

rcv packet

rcv Ack/DataAck

OPEN

CLOSING

CLOSEREQ active close or rcv CloseReq snd Close

rcv Reset

rcv Close snd Reset


TIMEWAIT 2 MPL timer exipres

Figure 11.1: DCCP state diagram redrawn from [124]. Client CLOSED [active open]

Server CLOSED [passive open] LISTEN Request (seq=x)

REQUEST Response (seq = y, ack=x) RESPOND Ack (seq = x+1, ack = y) PARTOPEN Ack (seq = y+1, ack = x+1) OPEN OPEN

(a) Client OPEN

Server OPEN [server active close] CloseReq (seq = m, ack = n) CLOSEREQ Close (seq = n+1, ack = m)

CLOSING Reset (seq = m+1, ack = n+1) CLOSED TIMEWAIT (2MPL) . CLOSED

(b)

Figure 11.2: Typical connection establishment and release scenarios.

168

Data, DCCP-DataAck or DCCP-SyncAck) packet, the client also enters OPEN and is now also ready for data transfer. For connection close down, the application at the server issues a “server active close” command. The server sends a DCCP-CloseReq and enters the CLOSEREQ state. The client, upon receiving the DCCP-CloseReq, enters CLOSING and generates a DCCPClose packet in response. After the server receives the DCCP-Close packet, it responds with a DCCP-Reset packet and enters the CLOSED state. When the client receives the DCCP-Reset packet, it holds the TIMEWAIT state for 2 maximum packet lifetimes (2MPL) before also entering the CLOSED state. Alternatively, either side may send a DCCP-Close packet to close the connection when receiving an “active close” command from the application. The end that sends the DCCPClose packet will hold the TIMEWAIT state as shown in Fig. 11.3. Beside these three closing procedures, there are another 2 possible scenarios concerned with simultaneous closing. The first procedure is invoked when both users issue an “active close”. The second occurs when the client user issues an “active close” and the application at the server issues the “server active close” command. For a detailed description of the connection set up and close down procedures, see [124]. During the connection, DCCP entities maintain a set of variables. In addition to the state and timers, the important variables are Greatest Sequence Number Sent (GSS), Greatest Sequence Number Received (GSR) and Greatest Acknowledgement Number Received (GAR). The Initial Sequence Numbers Sent and Received (ISS and ISR), the Valid Sequence Number window width (W) and the Acknowledgement Number validity window width (AW) are also important parameters for a connection. Based on these parameters and the state variables, the valid sequence and acknowledgement number intervals are defined by Sequence Number Window Low and High [SWL,SWH], and Acknowledgement Client OPEN [active close] CLOSING

Server OPEN

Client OPEN

Close (seq = m, ack = n)



[active close] CLOSING


CLOSED

CLOSED



(a)

(b)

Figure 11.3: Alternative close down procedures.

169

Number Window Low and High [AWL,AWH] [124].

11.3

CPN model of DCCP connection management

We have followed the development of DCCP Connection Management (DCCP-CM) since the publication of Internet Draft version 5 [126] in 2003. Design/CPN [202] has been used to build and maintain our DCCP connection management CPN models, with the aim of detecting errors or deficiencies in the protocol procedures. We analysed the connection establishment procedures of version 5 and discovered a deadlock [206]. When version 6 [115] was released, we revised our CPN model to reflect the changes and found similar deadlocks [128]. Version 11 of the DCCP specification was submitted to IETF for approval as a standard. We updated our model accordingly and included the synchronisation mechanism. We found that the deadlocks were removed but we discovered a serious problem known as chatter 4 [208, 212]. On updating the CPN model to RFC 4340, we investigated the connection establishment procedure when sequence numbers wrap [207] and, as indicated in the introduction, found that the attempt to set up the connection can fail. In [70, 73] we defined the DCCP service and confirmed that the sequence of user observable events of the protocol conformed to its service. Most recently [209] we have reported our experience with the incremental enhancement and iterative modelling of the connection management procedures as the DCCP specification was developed. However, none of these papers have presented the full CPN model for RFC 4340, with [209] only illustrating how the specification has evolved and [207] just including results. Thus the purpose of this section is to present the full CPN specification of the connection management procedures. We include the structure of the specification in a CPN hierarchy diagram, all of the CPN pages and some of the declarations in the rest of this section. The complete declarations including related ML functions can be found in the Appendix. Insight into the decisions behind the modelling choices can be found in [209] and are thus not included, as the emphasis of this paper is a) to provide a complete formal specification that captures DCCP’s connection management and synchronisation procedures and b) to allow the development of the progress mappings for the sweep-line to be understood. 4

The chatter scenario comprised undesired interactions between Reset and Sync packets that could

involve long but finite exchanges of these packets where no progress was made, until finally the system corrected itself.

170

11.3.1

Modelling assumptions

RFC 4340 specifies a number of protocol mechanisms for DCCP: reliable connection management; synchronisation of sequence numbers; reliable feature negotiation; and acknowledgement/optional mechanisms. The acknowledgement/optional mechanisms are normally used during data transfer together with a procedure for congestion control which is determined using the feature negotiation proocedures. Different congestion control procedures are (or will be) specified in other RFCs (e.g. RFC 4341, RFC 4342). Our CPN model captures all of DCCP’s procedures associated with connection set up, close down and synchronisation as specified in RFC 4340 but does not include the data transfer and feature negotiation procedures. A DCCP packet is modelled by its packet type, and long (or short) sequence and acknowledgement numbers. Other fields in the DCCP header are omitted because they do not affect the operation of the connection management procedure. Malicious attacks are not considered. In this paper we only discuss the case when the communication channels can delay and reorder packets without loss.

11.3.2

Model structure

The DCCP Connection management (DCCP-CM) CPN model comprises four hierarchical levels shown in Fig. 11.4. It has a total of 6 places, 52 executable transitions, 15 substitution transitions and 18 ML functions. The top level page named DCCP#1 is the DCCP overview page shown in Fig. 11.5. Two substitution transitions DCCP C and DCCP S (rectangles with the HS tag) in Fig. 11.5 represent the client and the server. Both are linked to the second level page named DCCP CM. The DCCP CM page comprises eight substitution transitions shown in Fig. 11.6. Each substitution transition is linked to the third level page. UserCommands models the actions taken when receiving commands from users. The IdleState page combines similar processing actions required in the CLOSED, LISTEN and TIMEWAIT states. The Request, Respond and PartOpen pages define the major processing actions in each of the corresponding states. The actions taken when receiving the DCCP-Data, DCCP-Ack and DCCP-DataAck packets in the OPEN, CLOSEREQ and CLOSING states are modelled in the DataTransfer page. The ClosingDown page defines the procedures undertaken on receiving a DCCP-Close in the states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING and when the client receives a DCCP-CloseReq in the PARTOPEN, OPEN and CLOSING states. Finally, CommonProcessing shown in Fig. 11.7 comprises five sub-

171

Hierarchy#10010 M Prime

DCCP#1 DCCP_C DCCP_S

Declarations#16

DCCP_CM#2

UserCMD

UserCommands#3

Idle_State

IdleState#4

Request

Request#5

Respond

PartOpen DataTransfer ClosingDown Common

Respond#6 PartOpen#7 DataTransfer#8 ClosingDown#9 CommonProcessing#10 RcvSync#11

RcvSync

RcvReset#12

RcvReset

Retransmission#13

TimeOut

UnExpected#14

UnexpectedPkt

RcvInvalid#15

RcvInvalidHeader

Figure 11.4: The DCCP hierarchy page.

1‘a_Open

1‘p_Open

App_Client

App_Server Ch_C_S

COMMAND

PACKETS

1‘ IdleState CLOSED_I

Client_State CB

COMMAND 1‘IdleState CLOSED_I

DCCP_C

DCCP_S

HS

HS

Server_State CB

Ch_S_C PACKETS

Figure 11.5: The DCCP overview page.

stitution transitions which are linked to fourth level pages. They model the procedures that are common to various states including: receiving DCCP-Sync and DCCP-SyncAck packets; the receipt of DCCP-Reset packets; retransmissions and timer expiry; and processing unexpected packets and those with an invalid header.

172

App_A

P In

P Out COMMAND

Ch_A_B

PACKETS UserCMD HS Idle_State HS Request HS Respond HS

State

PartOpen

P I/O

HS CB DataTransfer HS ClosingDown HS Common HS Processing Ch_B_A

P In

PACKETS

Figure 11.6: DCCP CM page.

P Out

RcvSync

Output

HS PACKETS

RcvReset HS

P I/O

TimeOut

State HS CB

UnexpectedPkt HS

P In

RcvInvalidHeader

Input

HS

PACKETS

Figure 11.7: CommonProcessing page.

173

11.3.3

The DCCP Overview page

The top level page (DCCP#1) shown in Fig. 11.5 comprises two substitution transitions (for the client and server as mentioned above) and six places. There are two places that allow communication with the applications that use DCCP, one for the client, App Client, and the other for the server, App Server. The states of the client and server protocol entities are stored in the places Client State and Server State. The client and server communicate via two channel places, Ch C S and Ch S C, shown in the middle of Fig. 11.5. Each models a unidirectional reordering channel, from the client to the server and the server to the client respectively. Each place has a type (or colour set) which is defined in a set of declarations. The declarations define the data structures and any associated variables and functions used in the model. The declarations are written in CPN ML [46], a variant of Standard ML [166]. In Fig. 11.5, the channel places, Ch C S and Ch S C, are typed by PACKETS. Figure 11.8 defines PACKETS (lines 27-30) as the union of four colour sets: Type1LongPkt, Type2LongPkt, Type1ShortPkt, and Type2ShortPkt. Long sequence numbers (SN48) in line 15 are represented using the ML infinite integer type and range from zero to 248 − 1. Short sequence numbers (SN24) in line 17 are represented by integers ranging from zero to 224 −1. Each packet (lines 21-26) is defined by a product comprising the Packet Type (lines 3-9), X (Extended Sequence Number bit, called ‘X’ in [124], line 12) and the sequence number (or a record of sequence and acknowledgement numbers). Short sequence numbers are allowed only for DCCP-Data, DCCP-Ack and DCCP-DataAck packets. Thus line 7 defines a packet type for DCCP-Data with short sequence numbers, while lines 8-9 define a different packet type for DCCP-Ack and DCCP-DataAck because they also include acknowledgements. Strong typing of packets is very useful for developing and debugging the model. DCCP states and state variables are stored in a structure called the Control Block. The places Client State and Server State in Fig. 11.5, are thus typed by CB, for Control Block. We classify DCCP states into three groups according to their functional behaviour: idle, request and active states. The differences are mainly related to how an entity responds to DCCP-Reset and DCCP-Sync packets. When in the CLOSED, LISTEN and TIMEWAIT states, the GSS, GSR, GAR, ISS and ISR state variables do not exist, while the client in the REQUEST state has only GSS and ISS instantiated. Thus we define each group with a different set of state variables.

174

1: (* Define the Packet Structure *) 2: (* Packet Types *) 3: color PktType1 = with Request | Data; 4: color PktType2 = with Sync | SyncAck | Response 5:

| Ack | DataAck | CloseReq

6:

| Close | Rst;

7: color DATA = subset PktType1 with [Data]; 8: color ACK_DATAACK = subset PktType2 9:

with [Ack, DataAck];

10: 11: (* Extended Sequence Number Bit*) 12: color X = with LONG | SHORT; 13: 14: (* Sequence and Acknowledgement Number (Long/Short) *) 15: color SN48 = IntInf with ZERO..MaxSeqNo48; 16: color SN48_AN48 = record SEQ:SN48*ACK:SN48; 17: color SN24 = int with 0..max_seq_no24; 18: color SN24_AN24 = record SEQ:SN24*ACK:SN24; 19: 20: (* Four Kinds of Packet *) 21: color Type1LongPkt = product PktType1*X*SN48; 22: color Type2LongPkt = product PktType2*X 23:

*SN48_AN48;

24: color Type1ShortPkt= product DATA*X*SN24; 25: color Type2ShortPkt= product ACK_DATAACK*X 26:

*SN24_AN24;

27: color PACKETS = union PKT1:Type1LongPkt 28:

+ PKT2:Type2LongPkt

29:

+ PKT1s:Type1ShortPkt

30:

+ PKT2s:Type2ShortPkt;

Figure 11.8: Definition of DCCP PACKETS.

175

Figure 11.9 defines CB (lines 18-19) as a union of three colour sets: IDLE, REQUEST and ACTIVExRCNTxGSxISN. IDLE (lines 8-9 of Fig 11.9) defines three idle states: CLOSED, LISTEN and TIMEWAIT. The CLOSED state is split into CLOSED I to represent the initial CLOSED state and CLOSED F to represent the final CLOSED state. Differentiating the initial CLOSED state from the final CLOSED state helps increase the effectiveness of the sweep-line method when using the client and server states as a measure of progress. Because we consider only one connection instance, splitting the CLOSED state into CLOSED I and CLOSED F does not affect the protocol’s behaviour. The colour set REQUEST (line 10) is a product comprising RCNT (Retransmission Counter, line 3), GSS and ISS. Because there is only one state in this group, the REQUEST state is already distinguished from other states by using the ML selector, ReqState, in the union defined in lines 18-19. ACTIVE (lines 11-13) defines five DCCP states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. Because the client and server respond to the CloseReq packet differently in the OPEN and CLOSING states, we differentiate these states for the client and server by prefixing them by “C” for the client; and “S” for the server. This allows us to use DCCP CM as a page instance for the client and server, greatly reducing redundancy in the model. This was of great benefit when upgrading the model as DCCP was developed. ACTIVExRCNTxGSxISN (line 14) is a product comprising ACTIVE (lines 11-13), RCNT, GS (Greatest Sequence Numbers and Greatest Acknowledgement Numbers, line 4) and ISN (Initial Sequence Numbers, line 5). The places App Client and App Server at the top of Fig 11.5, typed by COMMAND, model DCCP user commands (i.e. commands that can be issued by the applications that use DCCP). Figure 11.9 defines a colour set COMMAND on lines 21-22. COMMAND comprises user commands for opening and closing connections. The distribution of tokens in the places of a CPN is called a marking and represents a state of the system. The initial marking represents the initial state. In Fig. 11.5, the initial markings are written above each place. Client State and Server State have an initial marking of one CLOSED I idle state token. The user command 1‘a Open is the initial marking of App Client indicating that the client’s application desires to open a connection. Similarly, the initial marking of App Server is 1‘p Open requesting the server to enter the LISTEN state so that it is ready to receive requests from clients. The initial markings of Ch C S and Ch S C are empty, representing that no packets are currently in either channel.

176

1: (* DCCP variables: Counter; Greatest Sequence Numbers; 2:

Initial Sequence Numbers *)

3: color RCNT = int; (* Retransmission Counter *) 4: color GS = record GSS:SN48*GSR:SN48*GAR:SN48; 5: color ISN = record ISS:SN48*ISR:SN48; 6: 7: (* Major States *) 8: color IDLE = with CLOSED_I | LISTEN 9:

| CLOSED_F | TIMEWAIT;

10: color REQUEST = product RCNT*SN48*SN48; 11: color ACTIVE = with RESPOND_tmp | RESPOND 12:

| PARTOPEN | S_OPEN | C_OPEN

13:


14: color ACTIVExRCNTxGSxISN = product ACTIVE*RCNT 15:

*GS*ISN;

16: 17: (* DCCP’s Control Block

*)

18: color CB = union IdleState:IDLE+ReqState:REQUEST 19:


20: (* Application Commands *) 21: color COMMAND = with p_Open | a_Open 22:

| server_a_Close | a_Close;

Figure 11.9: DCCP’s control block and user commands.

11.3.4

The third and fourth level pages

The UserCommands page in Fig. 11.10 specifies the actions when the entity receives commands from its application. Transition a Open models sending a Request when the client receives an active open command in CLOSED. Transition p Open models the server entering the LISTEN state on receiving a passive open command in CLOSED. When the server receives a server active close command in the RESPOND or OPEN state, it sends a CloseReq packet and enters CLOSEREQ. This is modelled by transition s a Close. Transitions a CloseInREQUEST and a Close model the actions taken when the entity receives an active close command in the REQUEST, PARTOPEN, RESPOND and OPEN states. The IdleState page in Fig. 11.11 specifies the actions of the entity when it is in 177

App_A P In COMMAND 1‘a_Open

ReqState(0,C_iss,C_iss)

a_Open

PKT1 (Request, LONG, C_iss)

IdleState CLOSED_I

1‘p_Open State

P I/O

p_Open

IdleState CLOSED_I IdleState LISTEN

CB

ActiveState(active_state, rcnt, g, isn)

1‘server_a_Close

[active_state = RESPOND orelse active_state = S_OPEN ] PKT2(CloseReq,LONG,{SEQ=incr(#GSS(g)), s_a_Close ACK=#GSR(g)}) Output

ActiveState(CLOSEREQ,0, incrGSS(g),isn)

P Out PACKETS

1‘a_Close

ReqState (rcnt,gss,iss)

a_CloseInREQUEST

PKT2 (Rst, LONG, {SEQ=incr(gss), ACK=ZERO})

IdleState CLOSED_F

ActiveState(active_state,rcnt,g,isn)

[active_state=PARTOPEN orelse active_state = RESPOND orelse active_state = C_OPEN orelse active_state =S_OPEN ] PKT2(Close,LONG, 1‘a_Close {SEQ=incr(#GSS(g)),ACK=#GSR(g)}) a_Close

if (active_state =RESPOND orelse active_state = S_OPEN) then ActiveState(S_CLOSING, 0, incrGSS(g),isn) else ActiveState(C_CLOSING, 0, incrGSS(g), isn)

Figure 11.10: The UserCommands page.

ActiveState (RESPOND,0,{GSS=S_iss, GSR=sn,GAR=S_iss},{ISS=S_iss,ISR=sn})

RcvRequest

IdleState LISTEN

Output P Out

PKT1 (Request, LONG, sn) [p_type2Rst ]


PKT2 (Response, LONG, {SEQ=S_iss,ACK=sn})

RcvLongWAck

PACKETS

PKT2 (Rst, LONG, SeqAck(NoGS, SA48 sn_an)) PKT2 (p_type2, LONG, sn_an)


[idle_state LISTEN orelse p_type1 Request ] PKT2(Rst, LONG, SeqAck(NoGS, S48 sn)) RcvLongWOAck


[(p_type2 = Ack orelse p_type2 = DataAck) andalso ShortEnable ] PKT2 (Rst, LONG, RcvShortWAck SeqAck(NoGS,SA24 sn24_an24) )

PKT1 (p_type1, LONG, sn)

PKT2s (p_type2, SHORT, sn24_an24)

State P I/O [ShortEnable] CB


RcvShortWOAck


IdleState TIMEWAIT

TimerExpires

IdleState CLOSED_F

Input P In PACKETS

Figure 11.11: The IdleState page.

178

CLOSED, LISTEN or TIMEWAIT. The transition named RcvRequest models the server receiving a Request in the LISTEN state. It initializes all state variables, enters the RESPOND state and replies with a Response packet. TimerExpires abstractly models the maximum packet lifetime timer expiring in the TIMEWAIT state. The remaining 4 transitions model that when any other packets, including Sync and SyncAck, are received (in any idle state), the entity responds with a Reset. Because no sequence number variables (GSS, GSR and GAR) exist in an idle state, according to section 8.3.1 of [124], the acknowledgement number of the Reset being sent is equal to the sequence number of the received packet. The sequence number of the Reset is equal to the acknowledgement number of the received packet plus one. If the received packet has no acknowledgement number, the sequence number of the Reset is equal to zero. These requirements are captured by the function SeqAck which is used to calculate the sequence and acknowledgement numbers of the Reset packet. ShortEnable in a guard’s expression (e.g. see transition RcvShortWOAck) disables or enables the use of short sequence numbers. If short sequence numbers are not allowed, a packet received with a short sequence number is discarded. This behaviour is captured in the RcvInvalid page shown in Fig. 11.12. The Request page In the REQUEST state only Response and Reset packets are expected. Upon receiving a valid Response packet, the client replies with either an Ack or a DataAck packet, initializes ISR, GSR and GAR and enters the PARTOPEN state. These actions are represented by the transition RcvResponseSndAck in Fig. 11.13. Because there is no record of ISR and GSR in REQUEST, only the acknowledgment number in the Response can be validated according to step 4 of the pseudo code in section 8.5 of [124]. This action is modelled by function AckValid. If short sequence numbers are allowed, the outgoing packet could include either a long or a short sequence number. Two variables, ack dataack and LS, are used to select an Ack or DataAck packet with long or short [ not ShortEnable ] cb

State

RcvType2ShortPkt

PKT2s (p_type2s,SHORT,sn24_an24)

Input

P I/O [ not ShortEnable ]

CB cb

RcvType1ShortPkt

PKT1s (Data, SHORT, sn24)

Figure 11.12: The RcvInvalid page.

179

P In PACKETS

ReqState (rcnt, gss, iss)

RcvResponseSndAck

if AckValid(Response,sn_an,gss,iss,iss) then ActiveState (PARTOPEN, 0,{GSS=incr(gss), GSR=#SEQ(sn_an), GAR=#ACK(sn_an)}, {ISS=iss,ISR=#SEQ(sn_an)}) else IdleState CLOSED_F ReqState (rcnt, gss, iss)

if AckValid(Response,sn_an, gss,iss, iss) then (if LS then 1‘PKT2 (ack_dataack, LONG, SeqAck(gssGS gss,SA48 sn_an)) else 1‘PKT2s (ack_dataack, SHORT, ShortSeqAck(gssGS gss,SA48 sn_an))) else SndRstInReq(gss)

State


[p_type2 Rst andalso p_type2 Response] RcvLongWAckSndRst

SndRstInReq(gss) PKT2 (p_type2, LONG, sn_an)

[(p_type2s = Ack orelse p_type2s = DataAck) andalso ShortEnable ] RcvShortWAckSndRst

IdleState CLOSED_F

SndRstInReq(gss) PKT2s (p_type2s, SHORT, sn24_an24)

CB


P Out PACKETS

PKT2 (Response, LONG, sn_an)

IdleState CLOSED_F

P I/O

Output

RcvLongWOAckSndRst

IdleState CLOSED_F

SndRstInReq(gss) PKT1 (p_type1, LONG, sn)

[ShortEnable] ReqState (rcnt, gss, iss)

RcvShortWOAckSndRst

IdleState CLOSED_F

SndRstInReq(gss) PKT1s (Data, SHORT, sn24)

Input

P In PACKETS

Figure 11.13: The Request page.

sequence number. If the Response is invalid, the entity resets the connection. The reset sent is built by the function SndRstInReq. Because the client has not yet recorded ISR, the acknowledgement number of the outgoing Reset is equal to zero according to section 8.1.1 of [124]. The other transitions model that if the client receives any packets other than Response or Reset, it resets the connection. The Respond page This page (Fig. 11.14) models how the server responds when it receives Request, Ack or DataAck packets. When receiving a Request retransmitted from the client, the server replies with a Response by the transition RcvRequest. The transitions RcvLongSndAckDataAck and RcvLongSndData model the server replying with either an Ack or DataAck or Data packet and entering the OPEN state when it receives an Ack or DataAck having a long sequence number. The transitions RcvShortSndAckDataAck and RcvShortSndData model similar actions when an Ack or DataAck with a short sequence number is received. All outgoing Ack, DataAck and Data packets can have either long or short sequence numbers depending on the variable LS. If LS is true, function SeqAck computes the long sequence and acknowledgement numbers of the outgoing packet. Similar to SeqAck, function ShortSeqAck generates short sequence and acknowledgement numbers of the outgoing packet, when LS is false. In active states, the sequence (and acknowledgement) numbers validity check is done by the functions ReqDataValid and PktValid. ReqDataValid is used to check the sequence number of type1 packets (Request or Data). PktValid is used to check both sequence and acknowledgement numbers of type2 packets (see Fig. 11.8). If the packet is sequence-invalid, DCCP sends a Sync packet defined by 180

ActiveState (RESPOND,rcnt,g, isn)

if ReqDataValid(Request, sn, g, isn) then 1‘PKT2 (Response, LONG, SeqAck(gGS g,S48 sn)) else SyncSnd(g,S48 sn)

RcvRequest

[p_type2=Ack orelse p_type2=DataAck ] RcvLongSndAckDataAck

if PktValid(p_type2, sn_an, g, isn) then ActiveState (S_OPEN, 0,UpdateGS(g,SA48 sn_an), isn) else ActiveState (RESPOND, rcnt,incrGSS(g), isn)

P I/O CB

ActiveState (RESPOND,rcnt,g,isn)

RcvLongSndData

if PktValid(p_type2, sn_an,g, isn) then ActiveState (S_OPEN, 0, UpdateGS(g,SA48 sn_an), isn) else ActiveState (RESPOND,rcnt,incrGSS(g),isn)


if PktValid(p_type2, sn_an, g, isn) then (if LS then 1‘PKT2 (ack_dataack, LONG,SeqAck (gGS g,SA48 sn_an)) else 1‘PKT2s (ack_dataack, SHORT, ShortSeqAck(gGS g,SA48 sn_an))) else SyncSnd(g,SA48 sn_an)

if PktValid(p_type2, sn_an, g, isn) then (if LS then 1‘PKT1 (Data, LONG, incr(#GSS(g))) else 1‘PKT1s (Data, SHORT, mod_sn24( incr(#GSS(g))))) else SyncSnd(g,SA48 sn_an) PKT2 (p_type2, LONG, sn_an)

[(p_type2s = Ack orelse p_type2s = DataAck) andalso ShortEnable ] RcvShortSndAckDataAck

if PktValid(p_type2s, extendSA(g,sn24_an24),g,isn) then ActiveState (S_OPEN, 0,UpdateGS(g,SA24 sn24_an24),isn) else ActiveState (RESPOND, rcnt,incrGSS(g),isn)

if PktValid(p_type2s, extendSA(g,sn24_an24), g, isn) then (if LS then 1‘PKT2 (ack_dataack, LONG, SeqAck(gGS g, SA24 sn24_an24)) else 1‘PKT2s (ack_dataack, SHORT, ShortSeqAck(gGS g,SA24 sn24_an24))) else SyncSnd(g, SA24 sn24_an24) PKT2s (p_type2s, SHORT, sn24_an24)

[(p_type2s=Ack orelse p_type2s=DataAck) andalso ShortEnable] RcvShortSndData

ActiveState (RESPOND,rcnt,g,isn)

PACKETS

PKT2 (p_type2, LONG, sn_an)

[p_type2 = Ack orelse p_type2 = DataAck ] State

Output

PKT1 (Request, LONG, sn)

if ReqDataValid(Request,sn,g, isn) then ActiveState (RESPOND,rcnt,UpdateGS(g,S48 sn), isn) else ActiveState (RESPOND, rcnt,incrGSS(g),isn)


P Out

if PktValid(p_type2s, extendSA(g,sn24_an24),g, isn) then ActiveState (S_OPEN, 0,UpdateGS(g,SA24 sn24_an24), isn) else ActiveState (RESPOND,rcnt,incrGSS(g),isn)

if PktValid(p_type2s, extendSA(g,sn24_an24), g, isn) then (if LS then 1‘PKT1 (Data, LONG, incr(#GSS(g)) ) else 1‘PKT1s (Data, SHORT,mod_sn24(incr(#GSS(g))))) else SyncSnd(g, SA24 sn24_an24) PKT2s (p_type2s, SHORT, sn24_an24)

Input

P In

PACKETS

Figure 11.14: The Respond page. 1: (*** Sending a Sync packet in an ACTIVE state ***) 2: fun SyncSnd(g:GS,SA48 sn_an) = 1‘PKT2 (Sync,LONG,{SEQ=incr(#GSS(g)),ACK= #SEQ(sn_an)}) 3: | SyncSnd(g:GS,S48 sn) = 1‘PKT2 (Sync,LONG,{SEQ=incr(#GSS(g)),ACK=sn}) 4: | SyncSnd(g:GS,SA24 sn24_an24) 5: = 1‘PKT2(Sync,LONG,{SEQ=incr(#GSS(g)),ACK=extend_seq(#GSR(g),#SEQ(sn24_an24))}) 6: | SyncSnd(g:GS,S24 sn24) = 1‘PKT2(Sync,LONG,{SEQ=incr(#GSS(g)),ACK=extend_seq(#GSR(g),sn24)});

Figure 11.15: Function SyncSnd sending a Sync packet.

the function SyncSnd in Fig. 11.15. The PartOpen page The PartOpen page (Fig. 11.16) is very similar to the Respond page. It models how the client responds when it receives Response, Ack, DataAck or Data packets. When receiving a Response retransmitted from the server, the client replies with an Ack or DataAck (transition RcvResponse). The transitions RcvDataShort and RcvDataLong model that when the client receives a Data packet with either a short or long sequence number, it enters the OPEN state. The transitions RcvAckDataAckLong and RcvAckDataAckShort model similar actions when an Ack or DataAck with a long or short sequence number is received. If the received packet is sequence-invalid, DCCP sends a Sync packet instead, similar to the Respond page. (Since we do not model DCCP’s data transfer phase, when the client enters the OPEN state, it does not reply.) The DataTransfer page (Fig. 11.17) model DCCP’s behaviour when receiving a Data, Ack or DataAck packet in a state after the connection is established (i.e. in OPEN, CLOSING and CLOSEREQ). It comprises four transitions: RcvDataShort, RcvDataLong, RcvAckDataAckShort and RcvAckDataAckLong. If the packet received is invalid, these transitions reply with a Sync packet. When receiving the valid packet, they don’t reply 181


RcvResponse

[ShortEnable] RcvDataShort



RcvDataLong

[p_type2=Ack orelse p_type2=DataAck] RcvAckDataAckLong

ActiveState (PARTOPEN,rcnt,g, isn) if PktValid(p_type2,sn_an,g, isn) then ActiveState (C_OPEN, 0,{GSS=#GSS(g), GSR=Update(#SEQ(sn_an),#GSR(g)), GAR=Update(#ACK(sn_an),#GAR(g))}, isn) else ActiveState (PARTOPEN,rcnt,incrGSS(g), isn) ActiveState (PARTOPEN,rcnt,g, isn)

if ReqDataValid(Data,extend_seq(#GSR(g), sn24), g, isn) then empty else SyncSnd(g,S24 sn24)

if ReqDataValid(Data,sn,g, isn) then empty else SyncSnd(g,S48 sn) PKT1 (Data, LONG, sn)

if ReqDataValid(Data,sn,g, isn) then ActiveState (C_OPEN, 0,{GSS=#GSS(g), GSR = Update(sn, #GSR(g)),GAR = #GAR(g) }, isn) else ActiveState (PARTOPEN,rcnt,incrGSS(g), isn)

CB

P Out

PACKETS

PKT1s (Data, SHORT, sn24)

if ReqDataValid(Data,extend_seq(#GSR(g),sn24),g, isn) then ActiveState (C_OPEN, 0,{GSS=#GSS(g), GSR = Update(extend_seq(#GSR(g),sn24), #GSR(g)), GAR = #GAR(g) }, isn) else ActiveState (PARTOPEN,rcnt,incrGSS(g), isn) State

Output


if PktValid(Response,sn_an,g,isn) then ActiveState (PARTOPEN,rcnt,UpdateGS(g,SA48 sn_an), isn) else ActiveState (PARTOPEN,rcnt, incrGSS(g), isn)

P I/O

if PktValid(Response,sn_an,g,isn) then ( if LS then 1‘PKT2 (ack_dataack, LONG, SeqAck(gGS g,SA48 sn_an) ) else 1‘PKT2s (ack_dataack,SHORT, ShortSeqAck(gGS g,SA48 sn_an) ) ) else SyncSnd(g,SA48 sn_an)

if PktValid(p_type2, sn_an, g, isn) then empty else SyncSnd(g,SA48 sn_an) PKT2 (p_type2, LONG, sn_an)

[(p_type2s = Ack orelse p_type2s = DataAck) andalso ShortEnable ] RcvAckDataAckShort

if PktValid(p_type2s, extendSA(g,sn24_an24),g, isn) then ActiveState (C_OPEN, 0,{GSS= #GSS(g), GSR=Update(extend_seq(#GSR(g), #SEQ(sn24_an24)), #GSR(g)), GAR=Update(extend_seq(#GSS(g), #ACK(sn24_an24)), #GAR(g))}, isn) else ActiveState (PARTOPEN,rcnt,incrGSS(g), isn)

if PktValid(p_type2s, extendSA(g,sn24_an24),g, isn) then empty else SyncSnd(g,SA24 sn24_an24)

Input

PKT2s (p_type2s, SHORT, sn24_an24)

P In PACKETS

Figure 11.16: The PartOpen page. [(active_state=S_OPEN orelse active_state = C_OPEN orelse active_state=CLOSEREQ orelse Output active_state=C_CLOSING orelse P Out active_state=S_CLOSING) andalso PACKETS ShortEnable] if ReqDataValid(Data,extend_seq(#GSR(g), sn24),g,isn) RcvDataShort

ActiveState (active_state, rcnt,g, isn) if (ReqDataValid(Data,extend_seq(#GSR(g),sn24),g,isn) ) then ActiveState (active_state, rcnt, {GSS=#GSS(g), GSR=Update(extend_seq(#GSR(g),sn24),#GSR(g)), GAR=#GAR(g)},isn) else ActiveState (active_state,rcnt,incrGSS(g), isn)

PKT1s (Data , SHORT, sn24) [active_state=S_OPEN orelse active_state = C_OPEN orelse active_state=CLOSEREQ orelse active_state=C_CLOSING orelse active_state =S_CLOSING ] if ReqDataValid(Data, sn,g,isn) then empty else SyncSnd(g,S48 sn) RcvDataLong

ActiveState (active_state,rcnt,g, isn) if (ReqDataValid(Data,sn,g,isn) ) then ActiveState (active_state, rcnt,{GSS=#GSS(g), GSR=Update(sn,#GSR(g)),GAR=#GAR(g)},isn) else ActiveState (active_state,rcnt,incrGSS(g),isn)

P I/O

then empty else SyncSnd(g,S24 sn24)

PKT1 (Data , LONG, sn)

[(active_state=S_OPEN orelse active_state = C_OPEN orelse active_state= CLOSEREQ orelse active_state=C_CLOSING orelse active_state = S_CLOSING) andalso ShortEnable ] if PktValid(p_type2s, extendSA(g,sn24_an24),g,isn)

State CB ActiveState(active_state,rcnt,g,isn)

RcvAckDataAckShort

if PktValid(p_type2s, extendSA(g,sn24_an24) ,g,isn) then ActiveState(active_state,rcnt,{GSS=#GSS(g), GSR=Update(extend_seq(#GSR(g),#SEQ(sn24_an24)),#GSR(g)), GAR=Update(extend_seq(#GSS(g),#ACK(sn24_an24)),#GAR(g))}, isn) else ActiveState(active_state,rcnt,incrGSS(g), isn)


then empty else SyncSnd(g,SA24 sn24_an24) PKT2s(p_type2s, SHORT, sn24_an24)

[(p_type2=Ack orelse p_type2 = DataAck) andalso (active_state = S_OPEN orelse active_state = C_OPEN orelse active_state = CLOSEREQ orelse active_state = C_CLOSING orelse active_state= S_CLOSING)] if PktValid(p_type2,sn_an,g,isn) then empty RcvAckDataAckLong else SyncSnd(g,SA48 sn_an)

if PktValid(p_type2,sn_an,g,isn) then ActiveState(active_state,rcnt,{GSS=#GSS(g), GSR=Update(#SEQ(sn_an),#GSR(g)), GAR=Update(#ACK(sn_an),#GAR(g))},isn) else ActiveState(active_state,rcnt,incrGSS(g),isn)

P In Input

PKT2(p_type2, LONG, sn_an) PACKETS

Figure 11.17: The DataTransfer page.

but update the state variables accordingly. The ClosingDown page (Fig. 11.18) defines DCCP’s behaviour when receiving a CloseReq or Close packet in an active state. The transition RcvCloseReqClient models that when the client receives a valid CloseReq, it enters the CLOSING state and replies

182

ActiveState (active_state, rcnt, g, isn)

State P I/O CB

[active_state = PARTOPEN orelse active_state = C_OPEN orelse active_state = C_CLOSING ] RcvCloseReqClient

if PktValid(CloseReq,sn_an,g,isn) then ActiveState (C_CLOSING, (if active_state = C_CLOSING then rcnt else 0), UpdateGS(g, SA48 sn_an),isn) else ActiveState (active_state, rcnt,incrGSS(g),isn) ActiveState (active_state,rcnt,g, isn)

if PktValid(CloseReq,sn_an,g,isn) then 1‘PKT2(Close, LONG,SeqAck(gGS g,SA48 sn_an)) else SyncSnd(g,SA48 sn_an)

Output

PKT2 (CloseReq, LONG, sn_an)

P Out PACKETS

Input

P In

PACKETS PKT2(Close, LONG, sn_an)

RcvClose

if PktValid(Close,sn_an,g,isn) then 1‘PKT2(Rst, LONG, SeqAck (gGS g, SA48 sn_an)) else SyncSnd(g,SA48 sn_an)

if PktValid(Close,sn_an,g,isn) then IdleState CLOSED_F else ActiveState (active_state,rcnt,incrGSS(g), isn)

Figure 11.18: The ClosingDown page.

ActiveState (active_state, rcnt, g, isn)

RcvSync

PKT2 (Sync, LONG, sn_an)

if PktValid(Sync,sn_an,g,isn) then ActiveState (active_state,rcnt,{GSS=incr(#GSS(g)), GSR=Update(#SEQ(sn_an), #GSR(g)), GAR=#GAR(g)}, isn) else ActiveState (active_state,rcnt,g, isn)

P I/O

State

CB


if PktValid(Sync, sn_an, g, isn) then 1‘PKT2(SyncAck, LONG, {SEQ=incr(#GSS(g)), ACK=#SEQ(sn_an)}) else empty Output

[active_state = PARTOPEN orelse active_state =RESPOND] RcvSyncAckBeforeOpen PKT2 (SyncAck, LONG, sn_an)

if PktValid(SyncAck,sn_an,g,isn) then ActiveState (go_open(active_state), 0,{GSS=#GSS(g), GSR=Update(#SEQ(sn_an), #GSR(g)), [active_state = C_OPEN GAR=Update(#ACK(sn_an),#GAR(g))}, isn) orelse active_state = S_OPEN else ActiveState (active_state,rcnt,g,isn) orelse active_state = CLOSEREQ orelse active_state = C_CLOSING orelse active_state = S_CLOSING] ActiveState (active_state,rcnt,g,isn)

P Out PACKETS

Input

P In PACKETS

RcvSyncAckAfterOpen PKT2(SyncAck, LONG, sn_an)

if PktValid(SyncAck,sn_an,g,isn) then ActiveState (active_state,rcnt,{GSS=#GSS(g), GSR=Update(#SEQ(sn_an), #GSR(g)), GAR=Update(#ACK(sn_an),#GAR(g) )},isn) else ActiveState (active_state,rcnt,g,isn)

Figure 11.19: The RcvSync page.

with a Close packet. The transition RcvClose models the client or server receiving a Close packet. If the Close is valid, DCCP resets the connection, otherwise it sends a Sync packet. The RcvSync page The RcvSync page (Fig. 11.19) models DCCP receiving a Sync or SyncAck packet in an active state. If the received Sync or SyncAck packet is invalid, the packet is ignored. On receiving a valid Sync packet (see transition RcvSync), GSR is updated but GAR is not because the acknowledgement number in the Sync packet could be sequence-invalid. When a valid SyncAck is received, both GSR and GAR are updated. Transition RcvSyncAckBeforeOpen models that when a valid SyncAck is received in PARTOPEN or RESPOND, the endpoint enters C OPEN or S OPEN respectively using function go open (defined at the end of Appendix). Transition RcvSyncAckAfterOpen models DCCP receiving a SyncAck after it enters OPEN (including the CLOSEREQ and CLOSING states). The RcvReset page (Fig. 11.20) models the receipt of a Reset packet. Transition 183


InActiveState

P I/O

CB

ReqState (rcnt,gss,iss)

InRequestState

P Out

PACKETS

if RstValidinReqState(sn_an,gss,iss) then empty else SndRstInReq(gss) PKT2 (Rst, LONG, sn_an)

if RstValidinReqState(sn_an,gss,iss) then IdleState TIMEWAIT else ReqState (rcnt,IntInf.+(gss,ONE),iss) IdleState idle_state

Output

PKT2(Rst, LONG, sn_an)

if PktValid(Rst, sn_an, g, isn) then IdleState TIMEWAIT else ActiveState (active_state,rcnt,incrGSS(g),isn) State

if PktValid(Rst,sn_an,g,isn) then empty else 1‘PKT2(Sync, LONG, {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

InIdleState

Input PKT2 (Rst, LONG, sn_an)

P In PACKETS

Figure 11.20: The RcvReset page.

InIdleState models that the Reset packet is always discarded in an idle state. In an active state or the REQUEST state if the Reset is valid, DCCP enters TIMEWAIT. If the client receives an invalid Reset while in REQUEST, it resets the connection using function SndRstInReq. Because the client has not yet recorded ISR, the acknowledgement number of the outgoing Reset is equal to zero according to section 8.1.1 of [124]. Receiving an invalid Reset in an active state results in DCCP replying with a Sync packet (see the transition InActiveState). However the Sync packet has an acknowledgement number equal to GSR rather than the sequence number received (section 7.5.4 of [124]). The Retransmission page During connection set up and close down retransmissions occur when DCCP holds a state for too long. DCCP retransmissions are modelled in Fig. 11.21. Retransmission in each state is modelled by the transition corresponding to the state’s name: Retrans REQUEST; RetransShort PARTOPEN; RetransLong PARTOPEN; Retrans CLOSEREQ and Retrans CLOSING. In PARTOPEN the client can retransmit either an Ack or a DataAck. Each retransmission increases the retransmission counter (rcnt) by one. When the counter reaches the maximum retransmission value (lines 1-4 of Fig. 11.22), DCCP resets the connection and enters the CLOSED state. These actions are modelled by the transitions BackOff REQUEST and BackOff ActiveState. The guard function BackOff (lines 5-12 of Fig. 11.22) checks whether the number of retransmissions has reached the maximum value or not. The server in RESPOND returns a Response packet on receiving a valid Request packet. It does not retransmit Response packets but backs off to CLOSED after holding the RESPOND state for 4 MPL. The Unexpected page in Fig. 11.23 models the receipt of unexpected events as defined in the pseudo code of step 7 of section 8.5 of [124]. Firstly, DCCP does not expect to receive a Request or Response after the connection is established. Secondly, the client 184

[rcnt < MaxRetransRequest ] Retrans_REQUEST

ReqState(rcnt, gss, iss)

PKT1 (Request, LONG, incr(gss))

ReqState (rcnt+1, incr(gss), iss)

SndRstInReq(gss)

BackOff_REQUEST

ReqState (MaxRetransRequest,gss,iss) IdleState CLOSED_F

PKT2s(ack_dataack,SHORT, {SEQ=mod_sn24(incr(#GSS(g))), ACK=mod_sn24(#GSR(g))})

[ rcnt < MaxRetransAckDataAck andalso ShortEnable] ActiveState (PARTOPEN, rcnt, g, isn) RetransShort_PARTOPEN ActiveState (PARTOPEN,rcnt+1, incrGSS(g),isn) P I/O State


[rcnt < MaxRetransAckDataAck] RetransLong_PARTOPEN

PKT2(ack_dataack, LONG, {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

ActiveState (PARTOPEN,rcnt+1, incrGSS(g),isn)

CB

P Out PACKETS

[rcnt < MaxRetransCloseReq] ActiveState (CLOSEREQ,rcnt,g,isn)

Output

Retrans_CLOSEREQ

PKT2 (CloseReq, LONG, {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

ActiveState(CLOSEREQ, rcnt+1,incrGSS(g),isn) [(active_state = C_CLOSING orelse active_state =S_CLOSING) andalso rcnt < MaxRetransClose ] PKT2 (Close, LONG, ActiveState (active_state,rcnt,g,isn) Retrans_CLOSING {SEQ=incr(#GSS(g)),ACK=#GSR(g)}) ActiveState (active_state, rcnt+1,incrGSS(g),isn)


[BackOff(active_state,rcnt) ] PKT2(Rst, LONG, BackOff_ActiveState {SEQ=incr(#GSS(g)),ACK=#GSR(g)})

IdleState CLOSED_F

Figure 11.21: The Retransmission page. 1:

val MaxRetransRequest

= 1;

2:

val MaxRetransAckDataAck

= 1;

3:

val MaxRetransCloseReq

= 1;

4:

val MaxRetransClose

= 1;

5:

fun BackOff(state,rcnt):bool = case state of

6:

RESPOND

7:

=>

true

8:

| PARTOPEN

=> (rcnt=MaxRetransAckDataAck)

9:

| C_CLOSING

=> (rcnt=MaxRetransClosing)

10:

| CLOSEREQ

=> (rcnt=MaxRetransCloseReq)

11:

| S_CLOSING

=> (rcnt=MaxRetransClosing)

12:

|_

=> false; Figure 11.22: Declaration for the Retransmission page.

does not expect to receive a Request and the server never expects a Response packet. Thirdly, the server in RESPOND does not expect to receive a Data packet. Fourthly the server never expects to receive a CloseReq. If an unexpected packet is received, the entity replies with a Sync packet. Transitions RcvRequest and RcvResponse model DCCP

185

Output

P Out PACKETS


[active_state RESPOND] RcvRequest

SyncSnd(g, S48 sn)

if ReqDataValid(Request,sn,g,isn) then ActiveState(active_state,rcnt,UpdateGS(g, S48 sn), isn) else ActiveState(active_state,rcnt,incrGSS(g),isn)


PKT1(Request, LONG, sn)

[active_state PARTOPEN] RcvResponse

if PktValid(Response,sn_an,g,isn) then ActiveState (active_state, rcnt, UpdateGS(g, SA48 sn_an),isn) else ActiveState (active_state,rcnt,incrGSS(g), isn)

SyncSnd(g,SA48 sn_an)


P I/O State

ActiveState (RESPOND,rcnt,g,isn) if ReqDataValid(Data,extend_seq(#GSR(g),sn24),g,isn) then ActiveState(RESPOND,rcnt,UpdateGS(g,S24 sn24),isn) else ActiveState (RESPOND,rcnt,incrGSS(g),isn)

CB

ActiveState (RESPOND, rcnt, g, isn) if ReqDataValid(Data,sn,g,isn) then ActiveState(RESPOND,rcnt,UpdateGS(g,S48 sn),isn) else ActiveState (RESPOND,rcnt,incrGSS(g),isn)

RcvDataShort_in RESPOND

RcvDataLong_in RESPOND

SyncSnd(g, S24 sn24) PKT1s (Data, SHORT, sn24)

SyncSnd(g,S48 sn) PKT1 (Data, LONG, sn)

[active_state = RESPOND orelse active_state = S_OPEN orelse active_state = S_CLOSING orelse active_state = CLOSEREQ] ActiveState (active_state, rcnt, g, isn) SyncSnd(g, SA48 sn_an) ServerRcvCloseReq if PktValid(CloseReq, sn_an, g, isn) then PKT2 (CloseReq, LONG, sn_an) ActiveState(active_state, rcnt, UpdateGS(g, SA48 sn_an), isn) else ActiveState(active_state, rcnt, incrGSS(g), isn)

Input

P In PACKETS

Figure 11.23: The Unexpected page. receiving the unexpected Request and Response packets respectively. The transitions RcvDataShort inRESPOND and RcvDataLong inRESPOND model the actions taken by the server on receipt of a short or long Data packet in the RESPOND state. The last transition ServerRcvCloseReq models that when the server receives a CloseReq, it replies with a Sync packet.

11.4

Sweep-line analysis

The success of applying sweep-line relies on the notion of a progress measure which is defined [37] as a tuple P = (O, , ϕ), where O is a set of progress values, ⊆ O × O is a partial order on the progress values, and ϕ : M → O is a progress mapping function from markings of the CPN model, M, to progress values. Gordon et al. [79] point out that protocols can exhibit more than one source of progress and suggest the use of a vector of progress values that we shall call a progress vector. In [69] the progress vector is used in conjunction with lexicographical ordering. We use this approach to analyze the DCCP-CM CPN model. In this paper is a total order rather than partial order. The sweep-line algorithm generates the successors of all unexplored states with the lowest progress value first. Once all states with this lowest progress value have been explored, they will be deleted from memory and the conceptual “sweep-line” will move on to states with the new lowest 186

progress value. A progress mapping is said to be monotonic if, for every reachable state, it has a progress value equal to or less than all of its successors. When this is not the case, i.e. at least one successor of one state has a progress value that is less than its predecessor (representing regress rather than progress), the sweep-line must conduct additional sweeps of (part of) the state space, using the destinations of these so-called regress edges as roots of a new sweep. Thus, some parts in the state space may be explored more than once. However, the sweep-line still guarantees full exploration of a state space and is guaranteed to terminate. Detailed explanations of the sweep-line method can be found in [37, 137].

11.4.1

Notation

We define some notation used for identifying sources of progress in a CPN model. Let M ∈ M be a marking of the CPN model. M(p) is the marking of place p (the multiset of tokens on place p) and |M(p)| is the number of tokens on place p. Measures of progress, such as the greatest sequence number sent, are often included as a component in a product token residing on a state place, e.g. Client State. To extract information from a product token we shall use projection functions. Our progress mappings operate on markings, which are multisets of tokens rather than tokens themselves. However, when p is a state place, it only contains one token (∀M ∈ [M0 , |M(p)| = 1, where [M0 is the set of reachable markings), and hence M(p) is a singleton multiset. If the colour set of place p, is Type(p) then for |M(p)| = 1, we can represent M(p) as 1‘a where a ∈ T ype(p). We can then convert a singleton multiset, into its basis element (i.e. the token), with a function elem, so that when |M(p)| = 1, M(p) = 1‘a and elem(M(p)) = a.

11.4.2

Usual sources of progress

The following describes three usual sources of progress. Sequence Number Variables Firstly, consider GSS. Every time the client or server sends a packet, the state variable GSS (the Greatest Sequence number Sent) increases by one. GSS is stored within a single product token in the places Client State and Server State. However when an entity is in an idle state (CLOSED, LISTEN and TIMEWAIT), there is no GSS. To capture the progress of GSS from the marking of the place Client State we define a progress mapping

187

for the client ϕcgss : M → N, where the superscript “c” refers to the Client entity and ϕcgss (M) = P rojgss (elem(M(Client State)))

(11.1)

and P rojgss takes a state variable of type CB and returns GSS for active states and ISS otherwise. During connection establishment and close down, the number of transmitted packets is small. We consider that the sequence number may wrap only once. If the GSS value is less than ISS, it means that the GSS value has wrapped. In this situation, P rojgss returns GSS plus 248 in order to maintain increasing progress values. If there is no GSS value in the state variable, P rojgss returns ISS because it is the starting value of GSS for each connection. The progress mapping, ϕsgss , ϕcgsr , ϕsgsr , ϕcgar and ϕsgar for other client and server sequence number variables can also be defined in a similar way. Major States Both entities progress through the states defined by colour sets IDLE, REQUEST and ACTIVE. To capture this progress from the token in the place Client State, we define a progress mapping ϕcstate : M → N where ϕcstate (M) = State2Num(P rojstate (elem(M(Client State))))

(11.2)

The projection function, P rojstate , takes a state variable of type CB and returns the DCCP state. Function State2Num maps this state to an integer according to the ordering of DCCP states shown in Column 1 of Table 11.1. The server’s progress mapping, ϕsstate , is defined analogously, using the ordering of DCCP states shown in Column 3 of Table 11.1. Because of lost and delayed packets, an entity may retransmit. The progress exhibited by the retransmission counters (RCNTs) has already been covered by GSS because GSS is increased for every packet sent, including retransmissions. Thus the progress captured by Table 11.1: An ordering and corresponding mapping for DCCP state. Client

State2N um

Server

State2N um

state

(state)

state

(state)

CLOSED I

1

CLOSED I

1

REQUEST

2

LISTEN

2

PARTOPEN

3

RESPOND

3

C OPEN

4

S OPEN

4

C CLOSING

6

C CLOSEREQ

5

TIMEWAIT

7

S CLOSING

6

CLOSED F

8

TIMEWAIT

7

CLOSED F

8

188

RCNTs is not needed. However when retransmission occurs, the state is not changed, and hence, intuitively, it is useful to include both major state and GSS in progress mappings. Application Commands During connection set up and close down, the applications at the client and server will issue commands. The progress of issuing commands can be captured by the decrease in the total number of command tokens in both the App Client and App Server places. This can help to differentiate between the CLOSED F state caused by timer expiry in the TIMEWAIT state and the CLOSED F state resulting from an application close command. Thus we define ϕcmd : M → N where ϕcmd (M) = −|M(App Client)| − |M(App Server)|

(11.3)

Every application command issued corresponds to a change of state. However other DCCP state changes also occur due to internal behaviour. Hence we consider a state change due to an application command to be a more significant event. Thus we give ϕcmd greater weighting than ϕcstate and ϕsstate .

11.4.3

More subtle measures of progress

From our experience with DCCP, more than 90% of the state space has at least one entity in CLOSED, which has no sequence number variables. ϕcstate and ϕcgss provide no differentiation when the client is CLOSED, and similarly for the server. Thus some measure of progress is needed for when an entity is in the CLOSED state. When an entity is in an idle state (CLOSED,LISTEN and TIMEWAIT), there are two ways in which progress is exhibited: a) Receiving DCCP-Reset Packets When either end receives a DCCP-Reset Packet, the total number of packets in both channel places will decrease by one. This is simply because in CLOSED, LISTEN and TIMEWAIT, the entity discards the DCCP-Reset and does not send a packet in response. To capture this measure of progress we define ϕch num : M → N where ϕch num (M) = −|M(Ch C S)| − |M(Ch S C)|

(11.4)

Note that this progress mapping initially decreases as the first packets are sent into the channel. However, when component progress measures are combined using lexicographical ordering (as will be done shortly) this regress is more than offset by progress captured 189

in other ‘more significant’ component progress measures when the number of messages in the channel are increasing. b) Receiving non-DCCP-Reset Packets When any packet but DCCP-Reset is received from one channel by an entity in an idle state, it will send a DCCP-Reset packet into the other channel in response, so that the total number of packets over both channels remains the same. Owing to no GSS, GSR or GAR in these states, the DCCP-Reset packet sent will have a sequence number set to the acknowledgement number of the received packet plus one, and an acknowledgement number set to the sequence number of the received packet. Thus the summation of all sequence numbers and acknowledgement numbers in all packets over both channel places will be increased by one. Thus we define a progress mapping ϕch sum : M → N to capture the progress when an entity in an idle state replies with a Reset packet, where ϕch sum (M) = Sum Seq Ack(M(Ch C S))

(11.5)

+Sum Seq Ack(M(Ch S C)) where the function Sum Seq Ack takes the multiset of packets in a channel and returns the summation of sequence and acknowledgement numbers of every packet. However, there are still two problems. The first is that when an entity in an idle state receives a packet with no acknowledgement number, the sequence number of the Reset packet (sent in reply) is set to zero and its acknowledgement number to the sequence number of the packet received. Thus the markings before and after this action have the same progress value. To overcome this problem, when computing Sum Seq Ack, we consider that the packets with no acknowledgement number have an acknowledgement number = -1. The second problem is that when sequence numbers wrap ϕch sum (M) will decrease and degrade the performance of the sweep-line. Thus we add 248 to a sequence or acknowledgement number if it is less than ISS, as was the case with P rojgss . ϕch num has higher significance than ϕch sum because the effect of ϕch sum is only important when ϕch num is constant. Both ϕch num and ϕch sum have lower significance than other progress mappings because they are only effective when an entity is in an idle state. In conclusion, we have identified several sources of progress of the specification model. The progress vector ϕs when considering only GSS has 7 dimensions, where ϕs (M) = (ϕcmd (M), ϕcstate (M), ϕsstate (M), ϕcgss (M), ϕsgss (M), ϕch num (M), ϕch sum (M)) and the subscript “s” refers to the specification model. 190

(11.6)

Our experiments show that this progress vector is monotonic for all scenarios analysed in this paper, and swapping the order of the client and server progress mappings has no effect on the performance of the sweep-line. Moreover the performance is improved slightly by including progress mappings for the GSR and GAR variables in the vector. Thus the full progress vector ϕs is given by ϕs (M) = (ϕcmd (M), ϕcstate (M), ϕsstate (M), ϕcgss (M), ϕsgss (M), ϕcgsr (M), ϕsgsr (M), ϕcgar (M),

(11.7)

ϕsgar (M), ϕch num (M), ϕch sum (M))

11.4.4

Searching for a better progress measure

Although the sweep-line method helps us to analyze protocols for scenarios that could not be reached before, most results of protocol verification (see for example [69, 72, 79, 138]) show that the peak states stored are around 20-30% of the full state space. The best reduction is shown in [69] where the number of peak states is around 10% (i.e. a reduction in states stored of a factor of 10). The sweep-line method was also applied to compare the service language with the protocol language (language inclusion) of DCCP connection management in [70,73]. It used the same progress measures as described in Section 11.4.2 and 11.4.3. However the reduction in peak states stored [70,73] is about a factor of 3 to 4. Because the state space grows very rapidly with respect to the number of retransmissions, the progress measures used in [70,73] allowed only a few additional scenarios to be analysed (that could not be analysed by conventional state space analysis). Further reduction is thus required to verify DCCP’s connection management behaviour. We learnt from [69, 70, 73] that although the state variables (states and sequence number sent) in the entities seem to be intuitively good progress measures, there are three fundamental problems. Firstly, more than 90% of the state space has either the server or the client in an idle state. Secondly, in these idle states there are no sequence number state variables. Thirdly, sequence numbers can wrap, leading to regress rather than progress. In other words, the efficiency of the sweep-line largely depends on the progress we can capture from the channel places. Channel places are not a good source of progress, partly because of the overtaking property of the channels. This explains why we only get a factor of 3 to 4 reduction in peak states stored. From experiments we have noticed that the initial sequence number received (ISR) plays a crucial role in progress. S ISR is the first sequence number the server receives (in a Request packet). The client’s ISR (C ISR) is in the first Response packet the client 191

receives before moving to PARTOPEN. If the model is modified to store the values of ISR in the places Server State and Client State throughout the connection, including when the entity is in TIMEWAIT and CLOSED F, we find something interesting. For example, when the initial sequence numbers sent (ISS) by both the client and the server are equal to five and one retransmission is allowed for the Request packet, the state space (total 19,602 nodes) is roughly divided into two large groups: group A, 11,930 nodes with S ISR = 5 and group B, 7,612 nodes with S ISR = 6; and one small group of 60 nodes without S ISR. The size of group A is 60.86% of the total state space and the size of the group B is 38.83% of the total state space. Using only S ISR as the progress measure, the sweep-line will finish working on group A before it starts working on group B. In this case the peak states stored can be reduced to 60.91% (11,939 nodes), where some states from group B are generated (but not explored) while exploring the states of group A. Using [S ISR, C ISR] as the progress measure, group A is divided again into another two large groups (6,686 nodes with C ISR = 5 and 4,684 nodes with C ISR = 6) and one small group (560 nodes) with no C ISR. However because there is no loss and the server cannot retransmit the Respond packet, group B is divided into one large group with C ISR = 5 (7,158 nodes) and a small group (454 nodes) with no C ISR. The peak states stored is further reduced to 36.52% (7,158 nodes). The clue is that every new progress measure added reduces the number of states that have the same progress vector. We can continue to successively divide each group again by recording the sequence numbers of the Ack packets (S IACK, C IACK) that cause the server and the client to enter OPEN. Unfortunately, while S ISR and C ISR are the parameters of the specification model, S IACK and C IACK are not. By adding these two parameters, the specification model is modified to produce a different model, raising two issues. Firstly, does the new model (denoted the augmented model) have the same behaviour as the original specification model? Because the added parameters are solely used to measure progress and are not used in any protocol operations, both models exhibit the same behaviour. Secondly, the added parameters increase (explode) not only the total number of states but also the amount of memory used by each node in the state space. This is very harmful for state space analysis. Although the total number of states increases, the number of states in each subset of the partition decreases. During a sweep through one subset, the progress measure described in Sections 11.4.2 and 11.4.3 can be used to further subdivide it. Thus not only is there a reduction in the peak number of states stored but also the potential for a reduction in execution time due to less time being spent comparing newly generated 192

states with the states currently in memory (due to a reduced number of stored states).

11.4.5

Progress mappings for the augmented model

Further to the observation discussed in the previous section, we experiment by adding the new variables one by one. We notice when recording the latest sequence number of the packets sent for each packet type (rather than received ), the sweep-line algorithm gives better reduction in peak memory. Nevertheless ISRs are still used in the progress vector because they are already in the original model. We also exploit the progress from sequence numbers sent of Sync and Reset packets and further divide the state space to an even finer grain. Figure 11.24 shows the modification to the declarations of the state variables. A new colour set called SNV (Sequence Number Vector) is defined in place of ISN. This records the additional progress variables: the latest sequence number of the packet sent for each packet type, and ISR. The colour set SNV is attached to every state, including idle states and REQUEST. Using progress functions similar to those defined in Section 11.4.2, we can extract an additional 14 dimension progress vector (Equation 11.8) to measure progress in the augmented model. The ordering of progress values is arranged according to the point when each variable first appears in the typical scenario shown in Fig. 11.2 (connection setup followed by closing).

ϕa (M) = (ϕcSN Req Resp (M), ϕsISR (M), ϕsSN Req Resp (M), ϕcISR (M), ϕcSN Ack L (M), ϕsSN Ack L (M), ϕsSN Data L (M), ϕsSN CloseReq (M), ϕcSN Close (M), ϕsSN Close (M), ϕsSN Sync (M), ϕcSN Sync (M), ϕsSN Reset (M), ϕcSN Reset (M))

(11.8)

Thus the overall progress vector for the augmented model is: ϕDCCP (M) = (ϕa (M) , ϕs (M))

(11.9)

Although the analysis result using the proposed progress measures are very promising, there is still one drawback. The number of terminal markings increases rapidly with respect to the number of new variables added. To avoid this drawback we introduce four 193

1: (* Modified DCCP state variables *) 2: color SN = IntInf; 3: color RCNT = int;(*Retransmission Counter*) 4: color GS = record GSS:SN48 5:

* GSR:SN48

6:

* GAR:SN48;

7: color SNV = record ISS:SN48 * SNReq_Resp:SN 8:

* ISR:SN48 * SNData_L:SN

9:

* SNAck_L:SN * SNCloseReq:SN

10:

* SNClose:SN * SNSync:SN

11:

* SNReset:SN;

12: color IDLE = with CLOSED_I | LISTEN 13:

| TIMEWAIT | CLOSED_F;

14: color IDLE_STATE = product IDLE*SNV; 15:

(* counter,gss,SNV *)

16: color RCNTxGSSxSNV = product RCNT*SN48*SNV; 17: color ACTIVE = with RESPOND | PARTOPEN | S_OPEN 18:

| C_OPEN | CLOSEREQ | C_CLOSING |S_CLOSING;

19: color ACTIVExRCNTxGSxSNV = product ACTIVE * RCNT 20:

* GS * SNV;

21: color CB = union IdleState:IDLE_STATE 22:

+ ReqState:RCNTxGSSxSNV

23:

+ ActiveState:ACTIVExRCNTxGSxSNV;

24:

Figure 11.24: Modified DCCP’s control block. transitions and two places as shown in Fig. 11.25, to merge redundant terminal markings into the terminal markings that exist in the original state space. The places Cnt C S and Cnt S C are used to count the number of packets in channels. The clean up operation takes place when there is nothing left in both channels.

194

S_cmd

C_cmd

App_Server

App_Client

COMMAND

Ch_C_S

COMMAND

PACKETS

init_S

init_C HS

Client_State

HS

DCCP_C

DCCP_S

Server_State CB

CB

Ch_S_C 1‘0

PACKETS

Cnt_C_S INT

1‘0 Cnt_S_C INT

1‘0 [IntInf. (rcnt=MaxRetransAckDataAck)

| C_CLOSING => (rcnt=MaxRetransClose) | CLOSEREQ

=> (rcnt=MaxRetransCloseReq)

| S_CLOSING => (rcnt=MaxRetransClose) |_

=> false;

(***************************************************************************) (* Function : SeqValid

*)

(* Purpose

: Check if the received pkt has a valid sequence number

*)

(* Input

: Received pkt type, received {seq,ack}, {GSS,GSR,GAR},

*)

(*

{ISS, ISR}

(* Output

*)

: true/false

*)

fun SeqValid(p_type2:PktType2, s2:SN48_AN48, g:GS, isn:ISN) = let val bias

= IntInf.-(#GSR(g),center);

val seq_b

= Wrap(IntInf.-(#SEQ(s2),bias),MaxSeqNo48plus1);

val isr_b

= Wrap(IntInf.-(#ISR(isn),bias),MaxSeqNo48plus1);

val SWL

= IntInf.max(swl,isr_b);

val SWH

= swh;

in case p_type2 of Response

=> IntInf.>=(seq_b,SWL) andalso IntInf. IntInf.>=(seq_b,SWL) andalso IntInf. IntInf.>=(seq_b,SWL) andalso IntInf. IntInf.>(seq_b,center) andalso IntInf. IntInf.>(seq_b,center) andalso IntInf. IntInf.>(seq_b,center) andalso IntInf. IntInf.>=(seq_b,SWL)

| SyncAck

=>

IntInf.>=(seq_b,SWL)

end;

(***************************************************************************) (* Function : AckValid

*)

(* Purpose

: Check if the received pkt has a valid acknowledgement number *)

(* Input

: Received pkt type, received {seq,ack}, GSS, GAR, ISS

*)

(* Output

: true/false

*)

(*

*)

fun AckValid(p_type2:PktType2, s2:SN48_AN48, gss:SN48,gar:SN48, iss:SN48) = let val bias

= IntInf.-(gss,center);

val gar_b

= Wrap(IntInf.-(gar,bias),MaxSeqNo48plus1);

val ack_b

= Wrap(IntInf.-(#ACK(s2),bias),MaxSeqNo48plus1);

val iss_b

= Wrap(IntInf.-(iss,bias),MaxSeqNo48plus1);

val AWL

= IntInf.max(awl,iss_b);

val AWH

= center;

in case p_type2 of Response

=>

IntInf.>=(ack_b,AWL) andalso IntInf.



IntInf.>=(ack_b,gar_b) andalso IntInf.




IntInf.>=(ack_b,AWL) andalso IntInf. IntInf.>=(seq_b, SWL) andalso IntInf. IntInf.>=(seq_b ,SWL)

andalso IntInf.=(ack_b, AWL) andalso IntInf.Ch_A_B Ch_S_C->Ch_B_A Client_State->State App_Client->App_A

PACKETS

DCCP_CM#4 Ch_S_C->Ch_A_B Ch_C_S->Ch_B_A Server_State->State App_Server->App_A

Figure A.10: The DCCP Overview Page.

P

P Out

In

App

Ch_A_B PACKETS

COMMAND

UserCMD HS

Idle_State HS

Request HS P I/O

Respond

State HS CB

PartOpen HS

DataTransfer HS

ClosingDown HS

HS

Common Processing P

In

Ch_B_A PACKETS

Figure A.11: DCCP CM page. Type2LongPkt, representing long sequence number packets with long acknowledgement numbers; Type1ShortPkt, representing short sequence number packets without acknowledgement numbers; and Type2ShortPkt, representing short sequence number packets with short acknowledgement numbers. Long sequence numbers are represented as integers ranging from zero to 248 − 1. Short sequence numbers are represented as integers ranging from zero to 224 − 1. Long sequence numbers require the use of infinite integers (IntInf)

273

1: (* Define the Packet Structure *) 2: color PktType1 = with Request | Data; 3: color PktType2 = with Sync | SyncAck | Response 4:

| Ack | DataAck | CloseReq

5:

| Close | Rst;

6: color DATA = subset PktType1 with [Data]; 7: color ACK_DATAACK = subset PktType2 8:

with [DataAck,Ack];

9: color X = bool; 10: color SN48 = IntInf with ZERO..MaxSeqNo48; 11: color SN48_AN48 = record SEQ:SN48*ACK:SN48; 12: color SN24 = int with 0..max_seq_no24; 13: color SN24_AN24 = record SEQ:SN24*ACK:SN24; 14: color Type1LongPkt = product PktType1*X*SN48; 15: color Type2LongPkt = product PktType2*X 16:

*SN48_AN48;

17: color Type1ShortPkt= product DATA*X*SN24; 18: color Type2ShortPkt= product ACK_DATAACK*X 19:

*SN24_AN24;

20: color PACKETS = union PKT1:Type1LongPkt 21:

+ PKT2:Type2LongPkt

22:

+ PKT1s:Type1ShortPkt

23:

+ PKT2s:Type2ShortPkt;

Figure A.12: Definition of DCCP PACKETS. in Design/CPN as normal integers are restricted to a 31 bit representation. The places Client State and Server State in Fig. A.10, typed by CB (Control Block), store DCCP state information for the client and server entities. When in the CLOSED, LISTEN and TIMEWAIT states, the client and server entities do not have the GSS, GSR, GAR, ISS or ISR state variables, while the client in the REQUEST state has only GSS and ISS. We thus faithfully classify the DCCP states into three groups: idle, request and active states, each with a different set of state variables. Figure A.13 defines CB (line 13) as a union of colour sets: IDLE, REQUEST and ACTIVExRCNTxGSxISN. The colour set IDLE (line 3) defines three idle states: CLOSED, LISTEN and TIMEWAIT. State CLOSED has been split into CLOSED I to represent the initial CLOSED

274

1: (* DCCP state variables *) 2: color RCNT = int; (* Retransmission Counter *) 3: color IDLE = with CLOSED_I | LISTEN 4:

| CLOSED_F | TIMEWAIT;

5: color REQUEST = product RCNT*SN48*SN48; 6: color ACTIVE = with RESPOND_tmp | RESPOND 7:

| PARTOPEN | S_OPEN | C_OPEN

8:


9: color GS = record GSS:SN48*GSR:SN48*GAR:SN48; 10: color ISN = record ISS:SN48*ISR:SN48; 11: color ACTIVExRCNTxGSxISN = product ACTIVE*RCNT 12:

*GS*ISN;

13: color CB = union IdleState:IDLE+ReqState:REQUEST 14:


15: color COMMAND = with p_Open | a_Open 16:

| server_a_Close | a_Close;

Figure A.13: DCCP’s control block and user commands. state and CLOSED F to represent a dead CLOSED state (i.e. a CLOSED state after some protocol activity). Differentiating between the initial CLOSED state and the final CLOSED state allows us to use states in both the client and the server as progress measures. Otherwise the state of greatest progress (CLOSED F) would have the same progress value as the state of least progress (CLOSED I). The colour set REQUEST (line 5) is a product comprising RCNT (Retransmit Counter), GSS and ISS. This colour set implicitly represents the REQUEST state only and hence does not need to explicitly define the states associated with it. The colour set ACTIVExRCNTxGSxISN (line 11) is a product comprising ACTIVE (active state), RCNT, GS (Greatest Sequence Numbers) and ISN (Initial Sequence Numbers). The colour set ACTIVE (line 6) defines the five DCCP states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. An intermediate state, RESPOND tmp, is introduced to aid analysis and is described later. Because the client and server in the OPEN and CLOSING states both respond to the CloseReq packet differently, we differentiate these states for the client and server: C OPEN and C CLOSING are the corresponding states for the client; S OPEN and S CLOSING are the corresponding states for the server.

275

Figure A.13 also defines a colour set COMMAND on line 15. The places App Client and App Server in Fig. A.10, typed by COMMAND, model DCCP user commands. These places represent the commands issued by the client and server users to the client and server entities, respectively, thus abstractly representing the users of the protocol. These users will usually be software. For example, 1‘a Open is the initial marking of App Client, indicating that the client user has issued an active open command. Figure A.11 shows the DCCP CM page comprising four port places and eight substitution transitions. UserCMD models the actions when receiving commands from users. IdleState models the actions in the CLOSED, LISTEN and TIMEWAIT states. Request, Respond and PartOpen model the event processing in each of the corresponding states. DataTransfer models the actions when receiving the Data, Ack and DataAck packets in the OPEN, CLOSEREQ and CLOSING states. ClosingDown models the actions when receiving the Close or CloseReq packet in any of the five active states: RESPOND, PARTOPEN, OPEN, CLOSEREQ and CLOSING. Common Processing represents the actions common to various states. These actions involve retransmissions, receiving Reset, Sync and SyncAck packets, receiving unexpected packets and receiving packets with an invalid header. Because of space limitations, we can only briefly describe one page at the executable level. We will describe the third level page named Request, shown in Fig. A.14. The Request page models the client’s behaviour in the REQUEST state. The only valid packets that can be received by the client in this state are the Response and Reset packets. As mentioned above, the action of receiving a Reset packet is modelled as a common action, and can be seen in Fig. A.9 as the fourth level page named RcvReset. The RcvResponseTxAck transition in Fig. A.14 models the action when the client receives the Response packet. Because this is the first packet received by the client, only the acknowledgement number is checked for validity. If the received Response packet is invalid, the client enters the CLOSED F state and replies with a Reset packet. If the received Response packet is valid, the client replies nondeterministically with either an Ack or a DataAck packet (with either long or short sequence numbers) and enters the PARTOPEN state. The client’s reply is chosen nondeterministically using the LS and ack dataack variables, which can be seen in the inscription on the output arc from transition RcvResponseTxAck to place Output. Both are bound nondeterministically when the RcvResponseTxAck transition occurs: LS to true (long sequence numbers) or false (short sequence numbers), and ack dataack to ‘Ack’ (sending an Ack packet) or ‘DataAck’ (sending a DataAck packet). When the 276

P Out

Output PACKETS

if AckValid(Response,sn_an, gss,iss, iss) then (if LS then 1‘PKT2 (ack_dataack, LONG, SeqAck(gssGS gss,SA48 sn_an)) else 1‘PKT2s (ack_dataack, SHORT, ShortSeqAck(gssGS gss,SA48 sn_an))) else SndRstInReq(gss)

ReqState (rcnt, gss, iss) P I/O

RcvResponseTxAck

State

CB

if AckValid(Response,sn_an,gss,iss,iss) then ActiveState (PARTOPEN, 0,{GSS=incr(gss), GSR=#SEQ(sn_an), GAR=#ACK(sn_an)}, {ISS=iss,ISR=#SEQ(sn_an)}) else IdleState CLOSED_F ReqState (rcnt, gss, iss)


[p_type2 Rst andalso p_type2 Response]

SndRstInReq(gss)

RcvPktWAckSndRst PKT2 (p_type2, LONG, sn_an)

IdleState CLOSED_F


[(p_type2 Rst andalso p_type2 Response) andalso ShortEnable] SndRstInReq(gss) RcvShortPktWAck

IdleState CLOSED_F

PKT2s (p_type2, SHORT, sn24_an24)

ReqState (rcnt, gss, iss) RcvPktWOAckSndRst IdleState CLOSED_F


SndRstInReq(gss) PKT1 (p_type1, LONG, sn)

[ShortEnable]

SndRstInReq(gss)

RcvShortPktWOAck PKT1s (Data, SHORT, sn24)

IdleState CLOSED_F

P In

Input PACKETS

Figure A.14: The Request page.

client receives a packet of any type other than Reset or Response, it replies with Reset and enters the CLOSED F state. This is modelled by the other four transitions on the Request page in Fig. A.14.

A.5.4

DCCP Service Model and Language

DCCP [124] does not define the service of DCCP to its users. Hence our first task was to create a service definition [100, 101]. We did this, as done in [10], from our knowledge of the protocol, and by following the Open Systems Interconnection Connection-Oriented Transport Service Definition [101]. Firstly we defined the service primitives. Those shown in Table A.1 are only for connection management. We then developed a CPN model of the service specification and generated its RG which can be viewed as a finite state automaton. This automaton was input to FSM tools [63] for FSA minimisation. The minimised FSA for DCCP connection management is shown in Fig. A.15 and represents the service language. The upper case abbreviations refer to interactions with the client and lower case abbreviations refer to interactions with the server. In order to explain and justify the introduction of the intermediate state RESPOND tmp, consider the Connect.indication and Connect.response primitives. The Connect.indication primitive (cind) corresponds to the server receiving the first Request packet in LISTEN. 277

Table A.1: DCCP Service Primitives. Primitive

Abbreviation

DCCP-Connect.request

CREQ

DCCP-Connect.indication

cind

DCCP-Connect.response

cres

DCCP-Connect.confirm

CCNF

DCCP-User abort.request

AREQ, areq

DCCP-User abort.indication

AIND, aind

DCCP-Provider abort.indication

PIND, pind

cind PIND

pind

8

areq cres pind

4

PIND AREQ

PIND

14

CCNF

9

pind

AREQ

pind

CCNF 0

CREQ

1

cind

2

cres

areq

10 PIND PIND

PIND

13

AREQ

pind

5 AREQ pind

areq

AREQ

11

areq

aind areq AREQ

cres 7

areq

15

AIND PIND

CCNF

AREQ

PIND 12

3

AREQ AIND

cind

aind 6

areq pind

Figure A.15: DCCP’s Connection Management Service Language. The Connect.response primitive (cres) corresponds to the server sending the first Response packet. Rather than modelling these two events as an atomic action (i.e. by a single transition) they are modelled by two separate transitions, hence necessitating the introduction of an intermediate state. One transition models the server receiving the first Request packet in the LISTEN state, whereupon the server enters the RESPOND tmp state. The other models the transmission of the first Response packet from the RE278

SPOND tmp state, whereupon the server enters the RESPOND state. This allows us to define a mapping from binding elements to service primitives as in Definition A.5 which would not be possible if the two actions were modelled atomically.

A.5.5

Experimental Results

To apply sweep-line analysis to DCCP a suitable progress mapping was developed. This involved identifying sources of progress from our knowledge of the behaviour of DCCP and the DCCP-CPN model. Sources of progress were derived from the state variables of each DCCP entity, including GSS and GAR, and from the states of the entities themselves, by defining an ordering on the set of DCCP entity states. This was formalised into a progress mapping by defining projection and mapping functions to extract the relevant information from the token on each of the Client State and Server State places. A measure of progress can also be derived from the number of packets in the channels, and the sequence numbers of the packets in the channels, again by defining the appropriate projection and mapping functions. Further details of the progress mapping, identification of the sources of progress, and formal definitions of the specific projection and mapping functions used, is beyond the scope of this paper. We investigated 5 configurations as shown in Table A.2. In all configurations the initial markings of the channel places, Ch C S and Ch S C, are empty and the initial state of each side is CLOSED. Table A.2 shows the user commands (where ‘++’ represents multiset addition) on the client and server side for scenarios where the connection can be closed by either entity during establishment. All experiments were conducted on a Pentium-IV 2.6 GHz PC with 1 GByte RAM. Table A.3 shows the results obtained by conventional state space generation of the DCCP Connection Management CPN model using the state space tool of Design/CPN.

Table A.2: Configurations of the DCCP Connection Management CPN model. Initial Markings Configuration

App Client

App Server

A

1‘a Open

1‘p Open++1‘a Close

B

1‘a Open++1‘a Close

1‘p Open

C

1‘a Open

1‘p Open++1‘server a Close

D


1‘p Open++1‘a Close

E


1‘p Open++1‘server a Close

279

Table A.3: Conventional RG Generation Results.

Conventional RG

Config.

number of nodes

time

dead markings

A-(0,0,x,0)

647

00:00:00

3

A-(0,0,x,1)

2,055

00:00:02

3

A-(0,1,x,0)

3,509

00:00:03

3

A-(0,1,x,1)

15,078

00:00:26

3

A-(1,0,x,0)

41,380

00:02:27

3

A-(1,0,x,1)

326,429

06:22:59

3

A-(1,1,x,0)

466,780

19:48:21

3

B-(0,0,x,0)

385

00:00:00

4

B-(0,0,x,1)

941

00:00:01

4

B-(0,1,x,0)

1,815

00:00:01

4

B-(0,1,x,1)

5,956

00:00:08

4

B-(1,0,x,0)

30,821

00:01:20

4

B-(1,1,x,0)

269,462

03:47:28

4

C-(0,0,0,0)

928

00:00:01

3

C-(0,0,0,1)

1,752

00:00:01

3

C-(0,0,1,0)

12,963

00:00:20

3

C-(0,0,1,1)

185,930

01:35:41

3

C-(0,1,0,0)

6,391

00:00:07

3

C-(0,1,0,1)

16,141

00:00:30

3

C-(0,1,1,0)

138,047

00:20:18

3

C-(1,0,0,0)

76,165

00:07:22

3

D-(0,0,x,0)

2,335

00:00:02

6

D-(0,0,x,1)

23,205

00:00:50

6

D-(0,1,x,0)

17,011

00:00:31

6

D-(0,1,x,1)

248,411

03:32:28

6

E-(0,0,0,0)

4,155

00:00:04

6

E-(0,0,0,1)

22,123

00:00:48

6

E-(0,0,1,0)

181,035

00:54:35

6

280

The 4-tuple in the first column represents the values of the maximum number of retransmissions allowed for the Request, DataAck, CloseReq and Close packets respectively. Retransmissions of the CloseReq packet do not occur in Configurations A, B and D, indicated by an ‘x’ in the table. The number of nodes, time taken for RG generation, and the number of dead markings are shown in columns 2, 3 and 4. The configurations shown in Table A.3 are those for which the state space tool of Design/CPN terminated. RG generation did not complete for any other configurations due to state explosion (Design/CPN crashed after filling all available memory). Following the methodology in [14], checking the parallel composition of each reachability graph with the complement of the service shown in Fig. A.15 was done using fsm difference from the FSM tools [63]. Table A.4 shows the results obtained using conventional on-the-fly language inclusion checking and sweep-line language inclusion checking. Conventional on-the-fly language inclusion checking was simulated by providing the sweep-line algorithm with a trivial progress mapping that maps every state to the same progress value, thus preventing deletion of states. This reduces the sweep-line method to conventional state space generation. For conventional on-the-fly language inclusion checking, the number of nodes, the total time taken and the number of dead markings of the parallel composition are shown. For sweep-line language inclusion checking, we record the total number of nodes, peak node storage, total time and the number of dead markings of the parallel composition. The dead markings in columns 4 and 8 of Table A.4 correspond to pairs (vP , vS ) ∈ VP × VS in which vP corresponds to a dead marking of the DCCP Connection Management CPN. The number of unique dead markings of the DCCP CPN, when abstracting from the service complement state, is shown in brackets. This is consistent with the dead marking results obtained when using conventional RG generation as shown in Table A.3. Interestingly, the additional overhead of calculating non-trivial progress values is greater than the time saved through reduced peak state storage, until the total number of states becomes relatively large, i.e. for configurations A-(1,0,x,0), A-(1,1,x,0), B-(1,1,x,0) and C-(1,0,0,0). Language inclusion was found to hold for all configurations analysed by each of the three methods. Moreover, Table A.4 shows that on-the-fly language inclusion checking, both conventional and sweep-line, was able to analyse more configurations than when using the state space tool of Design/CPN. The difference in the conventional state space generation and conventional on-the-fly language inclusion checking can be explained by the fact that the latter does not store the arcs of the RG, and uses a different hashing function for 281

Table A.4: Conventional and Sweep-line results for On-The-Fly Language Inclusion Checking.

Config.

Conventional

Sweep-line

(F SAP || DF SAS )

(F SAP DF SAS )

nodes

dead

total

peak

time

markings

nodes

nodes

dead

%

%

time

markings

space

time

A-(0,0,x,0)

729

00:00:00.42

6 (3)

729

241

00:00:00.47

6 (3)

33.60

111.90

A-(0,0,x,1)

2,409

00:00:01.63

6 (3)

2,409

855

00:00:01.94

6 (3)

35.49

119.02

A-(0,1,x,0)

4,123

00:00:02.96

6 (3)

4,123

1,355

00:00:03.29

6 (3)

32.86

111.15

A-(0,1,x,1)

18,104

00:00:17.64

6 (3)

18,104

6,927

00:00:20.26

6 (3)

38.26

114.85

A-(1,0,x,0)

46,525

00:01:11.09

7 (3)

46,525

16,874

00:01:09.80

7 (3)

36.27

98.19

A-(1,0,x,1)

370,721

00:38:00.22

7 (3)

370,721

132,809

00:40:10.60

7 (3)

35.82

105.72

A-(1,1,x,0)

537,867

01:30:57.82

7 (3)

537,867

182,082

01:20:56.05

7 (3)

33.85

88.97

B-(0,0,x,0)

416

00:00:00.22

6 (4)

416

105

00:00:00.26

6 (4)

25.24

118.18

B-(0,0,x,1)

1,044

00:00:00.63

6 (4)

1,044

349

00:00:00.69

6 (4)

33.43

109.52

B-(0,1,x,0)

1,982

00:00:01.26

6 (4)

1,982

582

00:00:01.45

6 (4)

29.36

115.08

B-(0,1,x,1)

6,474

00:00:04.81

6 (4)

6,474

2,260

00:00:05.73

6 (4)

34.91

119.13

B-(1,0,x,0)

32,456

00:00:36.52

7 (4)

32,456

9,781

00:00:38.93

7 (4)

30.14

106.60

B-(1,1,x,0)

283,516

00:25:52.66

7 (4)

283,516

95,813

00:23:42.80

7 (4)

33.79

91.64

C-(0,0,0,0)

1,019

00:00:00.57

6 (3)

1,019

362

00:00:00.69

6 (3)

35.53

121.05

C-(0,0,0,1)

1,891

00:00:01.17

6 (3)

1,891

660

00:00:01.39

6 (3)

34.90

118.80

C-(0,0,1,0)

13,584

00:00:11.05

6 (3)

13,584

5,424

00:00:12.84

6 (3)

39.93

116.20

C-(0,0,1,1)

194,890

00:09:45.23

6 (3)

194,890

74,475

00:11:29.92

6 (3)

38,21

117.89

C-(0,1,0,0)

7,318

00:00:05.24

6 (3)

7,318

2,607

00:00:06.62

6 (3)

35.62

126.34

C-(0,1,0,1)

18,106

00:00:16.48

6 (3)

18,106

6,427

00:00:20.14

6 (3)

35.50

122.21

C-(0,1,1,0)

151,025

00:06:35.80

6 (3)

151,025

57,453

00:07:24.30

6 (3)

38.04

112.25

C-(1,0,0,0)

85,979

00:03:11.63

7 (3)

C-(1,1,0,0)

-

–:–:–.–

-

85,979

32,304

00:02:58.13

7 (3)

37.57

92.96

1,129,858

401,846

06:19:20.67

7 (3)

-

-

D-(0,0,x,0)

2,443

00:00:01.57

10 (6)

2,443

561

00:00:01.69

10 (6)

22.96

107.64

D-(0,0,x,1)

23,657

00:00:23.40

10 (6)

23,657

7,591

00:00:27.00

10 (6)

32.09

115.38

D-(0,1,x,0)

17,758

00:00:17.00

10 (6)

17,758

4,834

00:00:18.44

10 (6)

27.22

108.47

D-(0,1,x,1)

251,921

00:20:35.69

10 (6)

251,921

84,559

00:21:38.42

10 (6)

33.57

105.08

E-(0,0,0,0)

4,272

00:00:02.88

10 (6)

4,272

1,184

00:00:03.20

10 (6)

27.72

111.11

E-(0,0,0,1)

22,360

00:00:22.57

10 (6)

22,360

7,446

00:00:24.45

10 (6)

33.30

108.33

E-(0,0,1,0)

181,952

00:08:19.43

10 (6)

181,952

65,070

00:08:49.28

10 (6)

35.76

105.98

state storage. It is thus not reasonable to make a direct comparison between the two methods from a technical point of view. Pragmatically, however, the conventional onthe-fly method is generally much faster, particularly for large RGs such as configuration A-(1,1,x,0) which took 1 hour 31 minutes to complete, compared with Design/CPN’s result of over 19 hours. The number of nodes explored by the conventional on-the-fly method is slightly more than the number explored by the state space tool of Design/CPN. This is because the on-the-fly method is exploring the parallel composition of F SAP and

282

DF SAS , rather than just the RG corresponding to F SAP . Evidently, at least one state in F SAP corresponds to more than one state in DF SAS , through different sequences of events leading to the same state in F SAP . Sweep-line on-the-fly language inclusion checking also completed in one case when the conventional on-the-fly language inclusion checking did not. Table A.4 shows it is possible to verify the language inclusion property and obtain the dead markings simultaneously.

A.6

Conclusions and Future Work

Verification of large distributed systems is a difficult task due to their inherent complexity. Safety properties are an important class of properties to verify. In general, safety properties are those which specify a finite set of allowable behaviours of a given system. If all behaviours of the system fall within the allowed set, the safety property is said to hold. Model checking of action-based safety properties (i.e. safety properties specified over a finite set of actions of the system) can be realised by creating formal models (e.g. CPNs) of the system and a safety property of interest, generating their reachability graphs using Design/CPN (or similar), and interpreting them as finite state automata. Automata reduction tools such as FSM [63] can be used to obtain a deterministic (and minimum) FSA that embodies the safety property, and a FSA that embodies the behaviour of the system. FSM can then be used to compare the languages of the two FSAs to determine whether the safety property holds. This approach is similar to the CPN-based protocol verification methodology found in [14]. This is normally possible for moderately complex systems, e.g. protocols with small values of parameters such as retransmission counters. However, for practical protocols such as those used in the Internet, which may have many parameters, it has proven impossible to analyse them using conventional full state spaces with Design/CPN for even moderately large parameter values. For example, it has been impossible to analyse the Transmission Control Protocol’s connection management procedures when values of the maximum number of retransmissions of each retransmission counter is only one [81]. This has stimulated us to consider using the sweep-line method. However, neither Design/CPN nor CPN Tools [47] has the functionality to allow model checking of safety properties, let alone on-the-fly model checking of safety properties using the sweep-line. This paper builds on the first attempt in [73] to provide a language comparison facility for Design/CPN, and presents this language comparison facility in the context of model 283

checking of safety properties in general, not just the language inclusion property. Because we can use FSM for language comparison (and hence checking of safety properties) using conventional reachability analysis, we concentrated on checking safety properties using the sweep-line. As in [73], all the necessary theory for developing an algorithm for onthe-fly model checking of safety properties was synthesised. This entailed using the result that the parallel composition of the system (interpreted as a FSA) with the complement of a deterministic FSA of the safety property yields an FSA with an empty language if the safety property holds. To make this theory accessible we took a tutorial approach and illustrated it with a simple protocol example. We then applied this theory in the context of the sweep-line method and proved that it holds. We showed that conformance to safety properties can be determined by sweeping the parallel composition, rather than just sweeping the state space, and outputting any violation on-the-fly. Using this theory we have developed a prototype implementation for on-the-fly model checking of safety properties with the sweep-line method, and used it to verify the language inclusion property for the connection management procedures of a new Internet protocol called the Datagram Congestion Control Protocol. The DCCP model used is revised and updated with respect to that presented in [73] to incorporate more DCCP features and match the current DCCP specification [124]. We have shown that the protocol does conform to its service and have checked this using FSM, thus validating the prototype. We have also extended this result for DCCP for parameter values that could not be handled using the conventional methodology. Future work may involve combining this algorithm with path-finding [138] in order to record the sequences that violate the safety property. We would then explore using these sequences to generate error traces in the system model RG for debugging purposes. For example, the inverse projection of L(F SASysErr || DF SASa) from Section A.3.3 onto the arc labels of the RG from which F SASysErr was derived allows error traces in the original RG, and thus in the system, to be obtained. These error traces represent the behaviour of the system that violates the safety property. We would also like to extend this method to on-the-fly language equivalence checking. Concerning the verification of DCCP, we wish to continue to improve the effectiveness of the progress mapping used with the DCCP CPN model, to give a greater reduction in the peak number of states and thus allow sweep-line analysis of more configurations of the protocol. One drawback of the current implementation of the sweep-line method is the inability to 284

detect livelocks. This feature would be a useful addition to the capabilities of the sweepline method. Implementing this feature provides another avenue for future research. A second drawback is that users need to define and supply their own progress mapping. Steps have been taken toward automatic generation of a progress mapping for low-level Petri nets [186] and compositional systems [136]. We have not incorporated such techniques into our work as we have used CPNs, however it remains a topic of future research to integrate such techniques into our framework.

Acknowledgements The authors would like to acknowledge their colleagues Dr. Thomas Mailund and Dr. Jörn Freiheit for preliminary discussions of the ideas behind this paper and for comments made on early drafts. We are also grateful to the anonymous reviewers of [73] and of this paper for their constructive comments.

285

Appendix B DCCP-CM Service CPN Model This appendix contains the CPN model for DCCP’s Connection Management Service. Similar to [10, 78, 81], we define the local sequences of service primitives observed at each Service Access Point (SAP) following the OSI Transport Service Definition [101]. Seven service primitives are defined in Table A.1 and are associated with the transitions of the model. The sequences of these primitives at the two service access points are defined by the CPN model, which is structured into 3 pages: ConnectionOpen, ConnectionClose and ProviderAbort. Sequencing of service primitives at each SAP (SAP c or SAP s) is controlled by five states: Idle (IDLE); Outgoing Connection Pending (OCP); Incoming Connection Pending (ICP); Data Transfer Ready (DTR) and Closed (CLOSED). A sequence of service primitives begins in IDLE. OCP indicates that the client SAP has submitted a connection request. ICP indicates that the server SAP receives a connection indication. DTR indicates that connection is established. A sequence of service primitives ends in CLOSED.

B.1

Hierarchy Page Hierarchy#10010

DCCP_CM_Service #1

Declarations#12

M

Prime

Connection_Open

ConnectOpen#2 Connection_Close

UserAbort#3 Provider_Abort

ProviderAbort#4

Figure B.1: Hierarchy page.

286

B.2

The Top Level Page Connection_Open HS

1‘IDLE

1‘IDLE

SAPs

Connection_Close

SAPc

HS

STATE

STATE Provider_Abort HS

Figure B.2: The top level page: DCCP CM Service.

B.3

Global Declarations

1:

color STATE = with IDLE | OCP | ICP | DTR | CLOSED;

2:

var s:STATE;

3:

color Message = with Connect | Abort;

4:

color Meslist = list Message;

5:

var q:Meslist; Figure B.3: Declaration of DCCP service CPN model.

B.4

The Connection Open Page IDLE OCP

1‘[] Ch_C_S

q^^[Connect]

CREQ

DCCP-Connection.request

q

Connect::q q

Meslist FG

cind

IDLE ICP

DCCP-Connection.indication

CHANNEL-C-S

P I/O P

I/O

SAP_S

SAP_C

STATE STATE

OCP

1‘[]

Connect::q

DTR

q DCCP-Connection.confirm

q^^[Connect]

Ch_S_C

CCNF

Meslist FG

cres

DTR

q DCCP-Connection.response

CHANNEL-S-C

Figure B.4: The Connection Open page.

287

ICP

B.5

The Provider Abort Page [sIDLE andalso s CLOSED] CLOSED

PIND1

FG

pind

CLOSED s

s

Meslist

DCCP-Provider_abort.indication

P

[sIDLE andalso s CLOSED]

CHANNEL-C-S

Ch_C_S

[Connect]


I/O

P

SAP_c

SAP_s STATE

STATE

[sIDLE andalso s CLOSED] PIND2

s CLOSED


Figure B.5: The Provider Abort page.

B.6

The User Abort Page NULL

[Connect]^^[Abort] [sIDLE andalso sCLOSED] s

FG CHANNEL-C-S

Ch_C_S

q

AREQ

q^^[Abort]

CLOSED

Meslist

DCCP-User_abort.request

[q[] andalso hd(rev(q))=Abort andalso sIDLE andalso sCLOSED] aind s

q DCCP-User_abort.indication

CLOSED

P

P I/O

SAP_c

SAP_s

STATE

STATE

[q[] andalso hd(rev(q))=Abort andalso s IDLE andalso sCLOSED] s

AIND

FG

q

[sIDLE andalso s CLOSED]

CHANNEL-S-C

Ch_S_C

areq

q

s CLOSED

CLOSED

DCCP-User_abort.indication

q^^[Abort]

Meslist

DCCP-User_abort.request

Figure B.6: The User Abort page.

288

I/O

I/O

Appendix C CPN State Space to FSA C.1

DCCP-CM Service CPN state space to FSA

Listing C.1: ML Code for mapping binding elements in the OG of DCCP-CM service model into numbers representing DCCP service primitives used in [70]. 1 2

(∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗) ( ∗ Mapping f u n c t i o n fr o m OG t o FSA ∗ )

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

f u n be2int ( Bind . ConnectOpen ’ CREQ (1 , _ )) = "1" | be2int ( Bind . ConnectOpen ’ cind (1 , _ )) = "2" | be2int ( Bind . ConnectOpen ’ cres (1 , _ )) = "3" | be2int ( Bind . ConnectOpen ’ CCNF (1 , _ )) = "4" | be2int ( Bind . UserAbort ’ NULL (1 , _ )) = "0" | be2int ( Bind . UserAbort ’ AREQ (1 , _ )) = "5" | be2int ( Bind . UserAbort ’ aind (1 , _ )) = "6" | be2int ( Bind . UserAbort ’ areq (1 , _ ))= "7" | be2int ( Bind . UserAbort ’ AIND (1 , _ )) = "8" | be2int ( Bind . P r o v i d e r Abort ’ PIND1 (1 , _ )) = "9" | be2int ( Bind . P r o v i d e r Abort ’ PIND2 (1 , _ )) = "9" | be2int ( Bind . P r o v i d e r Abort ’ pind (1 , _ ) )= "10" | be2int ( _ ) = " ERROR "; (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

C.2

DCCP-CM CPN state space to FSA

Listing C.2: ML Code for mapping binding elements in the OG of DCCP-CM CPN model into numbers representing DCCP service primitives used in [70] 1 2

(∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗) ( ∗ Mapping f u n c t i o n fr o m OG t o FSA ∗ )

3 4 5 6 7

f u n be2int ( Bind . UserCommand ’ a_Open (1 , _ )) | be2int ( Bind . UserCommand ’ p_Open (2 , _ )) | be2int ( Bind . UserCommand ’ s _ a _ C l o s e (2 , { state = RESPOND , rcnt =_ , g =_ , isn = _ }))

289

= 1 = 0

( ∗CREQ∗ )

= 7

(∗ areq ∗)

8 9 10 11 12 13 14 15 16 17 18 19

| be2int ( Bind . UserCommand ’ s _ a _ C l o s e (2 , { state = S_OPEN , rcnt =_ , g =_ , isn = _ })) = 7 (∗ areq ∗) | be2int ( Bind . UserCommand ’ a _ C l o s e I n R E Q U E S T (1 , _ )) = 5 ( ∗AREQ∗ ) | be2int ( Bind . UserCommand ’ a _ C l o s e (1 , { state = PARTOPEN , rcnt =_ , g =_ , isn = _ })) = 5 ( ∗AREQ∗ ) | be2int ( Bind . UserCommand ’ a _ C l o s e (1 , { state = C_OPEN , rcnt =_ , g =_ , isn = _ })) = 5 ( ∗AREQ∗ ) | be2int ( Bind . UserCommand ’ a _ C l o s e (2 , { state = RESPOND , rcnt =_ , g =_ , isn = _ })) = 7 (∗ areq ∗) | be2int ( Bind . UserCommand ’ a _ C l o s e (2 , { state = S_OPEN , rcnt =_ , g =_ , isn = _ })) = 7 (∗ areq ∗) (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

20 21 22 23 24 25 26 27 28 29 30 31

| be2int ( Bind . IdleState ’ R c v R e q u e s t (2 , _ )) = 2 (∗ cind ∗) | be2int ( Bind . Request ’ R c v R e s p o n s e S n d A c k (1 ,{ LS =_ , rcnt =_ , gss = gss1 , iss = iss1 , sn_an = s1 })) = ( i f A c k V a l i d( Response , s1 , gss1 , iss1 , iss1 ) t h en 0 e l s e 9) ( ∗ PIND ∗ ) | be2int ( Bind . Request ’ R c v L o n g W A c k S n d R s t (1 ,{ p _ t y p e 2= p2 , rcnt =_ , gss =_ , iss =_ , sn_an = _ })) = ( i f ( p2 < > Rst a n d a l s o p2 < > R e s p o n s e) t h en 9 e l s e 0) ( ∗ PIND ∗ ) | be2int ( Bind . Request ’ R c v S h o r t W A c k S n d R s t (1 , _ )) = 9 ( ∗ PIND ∗ ) | be2int ( Bind . Request ’ R c v L o n g W O A c k S n d R s t (1 , _ )) = 9 ( ∗ PIND ∗ ) | be2int ( Bind . Request ’ R c v S h o r t W O A c k (1 , _ )) = 9 ( ∗ PIND ∗ ) (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

| be2int ( Bind . Respond ’ S n d 1 s t R e s p o n s e (2 ,{ rcnt =_ , g =_ , isn = _ })) = 3 (∗ c r e s ∗) | be2int ( Bind . PartOpen ’ R c v D a t a S h o r t (1 ,{ rcnt =_ , g = g1 , isn = isn1 , sn24 = s1 })) = ( i f R e q D a t a V a l i d ( Data , e x t e n d _ s e q (# GSR ( g1 ) , s1 ) , g1 , isn1 ) t h en 4 e l s e 0) ( ∗CCNF∗ ) | be2int ( Bind . PartOpen ’ R c v D a t a L o n g (1 ,{ rcnt =_ , g = g1 , isn = isn1 , sn = s1 })) = ( i f R e q D a t a V a l i d ( Data , s1 , g1 , isn1 ) t h en 4 e l s e 0) ( ∗CCNF∗ ) | be2int ( Bind . PartOpen ’ R c v A c k D a t a A c k S h o r t (1 , { p _ t y p e 2= p2 , rcnt =_ , g = g1 , isn = isn1 , s n 2 4 _ a n 2 4= s1 }))= ( i f P k t V a l i d( p2 , e x t e n d S A( g1 , s1 ) , g1 , isn1 ) a n d a l s o ( p2 = Ack o r e l s e p2 = D a t a A c k) t h en 4 e l s e 0) ( ∗CCNF∗ ) | be2int ( Bind . PartOpen ’ R c v A c k D a t a A c k L o n g (1 , { p _ t y p e 2= p2 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d( p2 , s1 , g1 , isn1 ) a n d a l s o ( p2 = Ack o r e l s e p2 = D a t a A c k) t h en 4 e l s e 0) ( ∗CCNF∗ ) (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

51 52 53 54 55 56 57 58 59 60 61 62 63 64

| be2int ( Bind . ClosingDown ’ R c v C l o s e R e q C l i e n t (1 , { state = state1 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d( CloseReq , s1 , g1 , isn1 ) a n d a l s o ( state1 = P A R T O P E N o r e l s e state1 = C_OPEN ) t h en 8 e l s e 0) ( ∗ AIND ∗ ) | be2int ( Bind . ClosingDown ’ R c v C l o s e (1 , { state = state1 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d ( Close , s1 , g1 , isn1 ) a n d a l s o ( state1 = P A R T O P E N o r e l s e state1 = C_OPEN ) t h en 8 e l s e 0) ( ∗ AIND ∗ ) | be2int ( Bind . ClosingDown ’ R c v C l o s e (2 , { state = state2 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d ( Close , s1 , g1 , isn1 ) a n d a l s o ( state2 = R E S P O N D o r e l s e state2 = S_OPEN ) t h en 6 e l s e 0) ( ∗ a i n d ∗ ) (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

290

65 66 67 68 69 70 71 72 73 74 75 76 77 78

| be2int ( Bind . RcvSync ’ R c v S y n c A c k B e f o r e O p e n (1 ,{ state = state1 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d( SyncAck , s1 , g1 , isn1 ) a n d a l s o state1 = P A R T O P E N t h en 4 e l s e 0) ( ∗CCNF∗ ) | be2int ( Bind . R e t r a n s m issio n ’ B a c k O f f _ R E Q U E S T (1 , { gss =_ , iss = _ })) = 9 ( ∗ PIND ∗ ) | be2int ( Bind . R e t r a n s m issio n ’ B a c k O f f _ A c t i v e S t a t e (2 ,{ state = RESPOND , rcnt = rcnt1 , g =_ , isn = _ })) = ( i f B a c k O f f( RESPOND , rcnt1 ) t h en 10 e l s e 0) ( ∗ p i n d ∗ ) | be2int ( Bind . R e t r a n s m issio n ’ B a c k O f f _ A c t i v e S t a t e (1 ,{ state = PARTOPEN , rcnt = rcnt1 , g =_ , isn = _ })) = ( i f B a c k O f f( PARTOPEN , rcnt1 ) t h en 9 e l s e 0) ( ∗ PIND ∗ ) (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

| be2int ( Bind . RcvReset ’ I n A c t i v e S t a t e (1 ,{ state = state1 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d ( Rst , s1 , g1 , isn1 ) a n d a l s o state1 = P A R T O P E N t h en 9 e l s e 0 ) ( ∗ PIND ∗ ) | be2int ( Bind . RcvReset ’ I n A c t i v e S t a t e (1 ,{ state = state1 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d ( Rst , s1 , g1 , isn1 ) a n d a l s o state1 = C_OPEN t h en 9 e l s e 0 ) ( ∗ PIND ∗ ) | be2int ( Bind . RcvReset ’ I n A c t i v e S t a t e (2 ,{ state = state2 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d ( Rst , s1 , g1 , isn1 ) a n d a l s o state2 = R E S P O N D t h en 10 e l s e 0) ( ∗ p i n d ∗ ) | be2int ( Bind . RcvReset ’ I n A c t i v e S t a t e (2 ,{ state = state2 , rcnt =_ , g = g1 , isn = isn1 , sn_an = s1 })) = ( i f P k t V a l i d ( Rst , s1 , g1 , isn1 ) a n d a l s o state2 = S_OPEN t h en 10 e l s e 0) ( ∗ p i n d ∗ ) | be2int ( Bind . RcvReset ’ I n R e q u e s t S t a t e (1 , { rcnt =_ , gss = g1 , iss = iss1 , sn_an = s1 } )) = ( i f R s t V a l i d i n R e q S t a t e ( s1 , g1 , iss1 ) t h en 9 e l s e 0) ( ∗ PIND ∗ ) | be2int ( _ ) = 0; (∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗)

291

Appendix D Analysis Results This appendix contains the results sweep-line analysis of the DCCP connection management procedures when the protocol operates over four different kinds of channels: FIFO without loss; FIFO with loss; reordering without loss; and reordering with loss. All results are obtained using the sweep-line analysis and the progress measures as discussed in Chapter 11 sections 11.4.2 and 11.4.3. We investigated 6 configurations (A-F) as shown in Table D.1, which have different (combination of) user commands on the client and server sides. These experiments use long sequence numbers only and do not include DCCPDataAck. In all configurations the initial markings of the channel places, Ch C S and Ch S C, are empty and the initial state of each side is CLOSED and ISS values on both sides are set to 5. Case A is the connection establishment scenario. Cases B-F define scenarios in which the connection can be closed by either entity during establishment. All experiments were conducted on a Pentium-IV 2.6 GHz PC with 1 GByte RAM. The analysis results when DCCP operates over four different channels are illustrated in six tables below. 1. Table D.2 and Table D.3 summarize the sweep-line analysis results when DCCP operates over FIFO channels with no loss. 2. Table D.4 and Table D.5 summarize the sweep-line analysis results when DCCP operates over FIFO channels with loss. 3. Table D.6 summarize the sweep-line analysis results when DCCP operates over reordering channels with no loss. 4. Table D.7 summarize the sweep-line analysis results when DCCP operates over reordering channels with loss. The first column in these Tables defines the configurations being analysed, where the 4-tuple is the maximum number of retransmissions allowed for Request, Ack, CloseReq 292

Table D.1: Initial configurations. Initial Markings Case

App Client

App Server

A

1‘active open

1‘passive open

B

1‘active open

1‘passive open ++ 1‘active close

C

1‘active open

1‘passive open ++ 1‘server active close

D

1‘active open

1‘passive open

++ 1‘active close E

F

1‘active open

1‘passive open

++ 1‘active close

++ 1‘active close

1‘active open

1‘passive open

++ 1‘active close

++ 1‘server active close

and Close packet types respectively. An “x” means the retransmission of those packet types never happens in that configuration. Columns 2 and 3 show the number of nodes and arcs of the state space. Column 4 shows the number of peak nodes stored in main memory. Column 5 shows the exploration time of the sweep-line function. The terminal markings are classified into 5 types (I, II, III, IV and V). All terminal markings have no packets left in the channels. Terminal markings of Type I are desirable and correspond to successful connection establishment where both the client and server are in the OPEN state. In Type II terminal markings both sides are CLOSED. For Type III markings, the client is CLOSED, but the server is in the LISTEN state. This can happen when the server is initially CLOSED (down for maintenance or busy) and rejects the connection request. The server then recovers and moves to the LISTEN state (waiting for the next request). These three types of terminal markings (I, II and III) are expected. However, Type IV terminal markings are deadlocks where the client is CLOSED but the server stays in OPEN. Type V terminal markings are also deadlocks where the client stays in OPEN but the server is CLOSED. Columns 11 and 12 contain the upper integer bounds of places Ch C S and Ch S C respectively. The last column shows the ratio (in percent) of the number of peak states stored in main memory to the total number of states in the state space.

293

D.1

FIFO Channels without Loss

Table D.2: Sweep-line analysis results of DCCP connection management: FIFO channels with no loss (part 1). Sweep-line Config.

Terminal Markings

Ch. Bounds

total

total

peak

nodes

arcs

nodes

time

I

II

III

IV

A-(0,0,x,x)

76

125

19

00:00:00

2

1

1

A-(0,1,x,x)

106

179

28

00:00:00

4

1

A-(1,0,x,x)

290

532

74

00:00:00

4

1

A-(1,1,x,x)

458

860

111

00:00:01

8

1

1

0

0

4

4

24.24

A-(0,2,x,x)

150

262

41

00:00:00

6

1

1

0

0

4

4

27.33

A-(1,2,x,x)

724

1,400

186

00:00:01

12

1

1

0

0

5

5

25.69

A-(2,0,x,x)

827

1,610

215

00:00:01

6

1

1

0

0

4

5

26.00

A-(2,1,x,x)

1,402

2,777

364

00:00:01

12

1

1

0

0

5

5

25.96

A-(2,2,x,x)

2,410

4,889

652

00:00:02

18

1

1

0

0

6

6

27.05

A-(0,3,x,x)

210

379

57

00:00:00

8

1

1

0

0

5

5

27.14

A-(1,3,x,x)

1,120

2,224

301

00:00:01

16

1

1

0

0

6

6

26.88

A-(2,3,x,x)

4,041

8,381

1,132

00:00:04

24

1

1

0

0

7

7

28.01

A-(3,0,x,x)

1,949

3,943

512

00:00:02

8

1

1

0

0

5

6

26.27

A-(3,1,x,x)

3,508

7,167

940

00:00:03

16

1

1

0

0

6

6

26.80

A-(3,2,x,x)

6,496

13,528

1,799

00:00:06

24

1

1

0

0

7

7

27.69

A-(3,3,x,x)

4,041

8,381

1,132

00:00:04

24

1

1

0

0

8

8

28.01

B-(0,0,x,0)

220

405

49

00:00:00

0

2

1

0

0

3

4

22.27

B-(0,0,x,1)

391

760

101

00:00:00

0

2

1

0

0

4

5

25.83

B-(0,1,x,0)

401

770

83

00:00:00

0

2

1

0

0

4

4

20.70

B-(0,1,x,1)

809

1,625

198

00:00:01

0

2

1

0

0

5

5

24.47

B-(1,0,x,0)

1,080

2,128

229

00:00:01

0

2

1

0

0

4

5

21.20

B-(1,0,x,1)

2,324

4,748

596

00:00:02

0

2

1

0

0

5

6

25.65

B-(1,1,x,0)

2,035

4,141

408

00:00:02

0

2

1

0

0

5

5

20.05

B-(1,1,x,1)

4,528

9,493

1,052

00:00:04

0

2

1

0

0

6

6

23.23

C-(0,0,0,0)

260

480

61

00:00:00

0

2

1

0

0

3

4

23.46

C-(0,0,0,1)

315

594

79

00:00:00

0

2

1

0

0

4

4

25.08

C-(0,0,1,0)

556

1,082

143

00:00:00

0

2

1

0

0

4

5

25.72

C-(0,0,1,1)

828

1,671

219

00:00:01

0

2

1

0

0

5

5

26.45

C-(0,1,0,0)

504

980

117

00:00:00

0

2

1

0

0

4

4

23.21

C-(0,1,0,1)

647

1,291

162

00:00:01

0

2

1

0

0

5

5

25.04

C-(0,1,1,0)

1,249

2,538

306

00:00:01

0

2

1

0

0

5

5

24.50

C-(0,1,1,1)

1,989

4,199

495

00:00:01

0

2

1

0

0

6

6

24.89

C-(1,0,0,0)

1,270

2,516

290

00:00:01

0

2

1

0

0

4

5

22.83

C-(1,0,0,1)

1,586

3,194

389

00:00:01

0

2

1

0

0

5

5

24.53

C-(1,0,1,0)

3,110

6,389

796

00:00:03

0

2

1

0

0

5

6

25.59

C-(1,0,1,1)

4,672

9,862

1,208

00:00:04

0

2

1

0

0

6

6

25.86

C-(1,1,0,0)

2,566

5,282

574

00:00:02

0

2

1

0

0

5

5

22.37

C-(1,1,0,1)

3,350

7,043

806

00:00:03

0

2

1

0

0

6

6

24.06

294

Ch

Ch

%

V

CS

SC

space

0

0

2

3

25.00

1

0

0

3

3

26.42

1

0

0

3

4

25.52

Table D.3: Sweep-line analysis results of DCCP connection management: FIFO channels with no loss (part 2). Sweep-line Config.

Terminal Markings

Ch. Bounds

total

total

peak

Ch

Ch

%

nodes

arcs

nodes

time

I

II

III

IV

V

CS

SC

space

C-(1,1,1,0)

6,707

14,241

1,590

00:00:06

0

2

1

0

0

6

6

23.71

C-(1,1,1,1)

10,802

23,661

2,599

00:00:11

0

2

C-(2,2,0,0)

16,862

36,678

3,494

00:00:16

0

2

1

0

0

7

7

24.06

1

0

0

7

7

20.72

D-(0,0,x,0)

168

293

32

00:00:00

0

D-(0,0,x,1)

239

436

44

00:00:00

0

2

2

0

0

3

3

19.05

2

2

0

0

4

4

18.41

D-(0,1,x,0)

278

507

51

00:00:02

D-(0,1,x,1)

429

816

88

00:00:03

0

2

2

0

0

4

4

18.35

0

2

2

0

0

5

5

20.51

D-(1,0,x,0)

743

1,402

121

00:00:06

0

2

2

0

0

5

5

16.29

D-(1,0,x,1)

1,152

2,251

D-(1,1,x,0)

1,367

2,673

225

00:00:01

0

2

2

0

0

5

5

19.53

255

00:00:01

0

2

2

0

0

5

5

18.65

D-(1,1,x,1)

2,266

4,570

480

00:00:14

0

2

2

0

0

6

6

21.18

E-(0,0,x,0)

537

1,038

77

00:00:00

0

4

2

0

0

4

4

14.34

E-(0,0,x,1)

1,384

2,809

197

00:00:01

0

4

2

0

0

6

6

14.23

E-(0,1,x,0)

1,198

2,451

163

00:00:01

0

4

2

0

0

5

5

13.61

E-(0,1,x,1)

3,727

7,927

563

00:00:18

0

4

2

0

0

7

7

15.11

E-(1,0,x,0)

2,891

5,841

374

00:00:02

0

4

2

0

0

5

5

12.94

E-(1,0,x,1)

8,939

18,679

1,363

00:00:08

0

4

2

0

0

7

7

15.25

E-(1,1,x,0)

6,489

13,732

899

00:00:06

0

4

2

0

0

6

6

13.85

E-(1,1,x,1)

22,765

49,530

3,556

00:00:22

0

4

2

0

0

8

8

15.62

F-(0,0,0,0)

653

1,264

89

00:00:01

0

4

2

0

0

4

4

13.63

F-(0,0,0,1)

1,168

2,369

200

00:00:01

0

4

2

0

0

5

5

17.12

F-(0,0,1,0)

1,378

2,752

195

00:00:01

0

4

2

0

0

5

5

14.15

F-(0,0,1,1)

2,852

5,952

491

00:00:02

0

4

2

0

0

6

6

17.22

F-(0,1,0,0)

1,511

3,100

226

00:00:01

0

4

2

0

0

5

5

14.96

F-(0,1,0,1)

2,921

6,243

508

00:00:03

0

4

2

0

0

6

6

17.39

F-(0,1,1,0)

3,556

7,442

519

00:00:03

0

4

2

0

0

6

6

14.60

F-(0,1,1,1)

7,852

17,090

1,302

00:00:07

0

4

2

0

0

7

7

16.58

F-(1,0,0,0)

3,457

7,031

493

00:00:03

0

4

2

0

0

5

5

14.26

F-(1,0,0,1)

6,436

13,600

1,104

00:00:06

0

4

2

0

0

6

6

17.15

F-(1,0,1,0)

8,162

16,984

1,207

00:00:07

0

4

2

0

0

6

6

14.79

F-(1,0,1,1)

16,974

36,647

2,898

00:00:16

0

4

2

0

0

7

7

17.07

F-(1,1,0,0)

8,079

17,210

1,219

00:00:07

0

4

2

0

0

6

6

15.09

F-(1,1,0,1)

16,185

35,642

2,809

00:00:15

0

4

2

0

0

7

7

17.36

F-(1,1,1,0)

20,026

43,321

2,989

00:00:19

0

4

2

0

0

7

7

14.93

F-(1,1,1,1)

45,196

100,998

7,520

00:00:47

0

4

2

0

0

8

8

16.64

295

D.2

FIFO Channels with Loss

Table D.4: Sweep-line analysis results of DCCP connection management: FIFO channels with loss (part 1). Sweep-line Config.

Terminal Markings

Ch. Bounds

total

total

peak

Ch

Ch

%

nodes

arcs

nodes

time

I

II

III

IV

V

CS

SC

space

A-(0,0,x,x)

109

279

36

00:00:00

2

1

1

2

0

2

3

33.03

A-(0,1,x,x)

190

500

57

00:00:00

7

1

1

4

0

3

3

30.00

A-(1,0,x,x)

715

2,076

218

00:00:01

15

1

1

12

0

3

4

30.49

A-(1,1,x,x)

1,583

4,753

501

00:00:01

49

1

1

20

0

4

4

31.65

A-(0,2,x,x)

342

950

114

00:00:00

16

1

1

6

0

4

4

33.33

A-(1,2,x,x)

3,568

11,407

1,251

00:00:03

107

1

1

28

0

5

5

35.06

A-(2,0,x,x)

3,421

10,692

988

00:00:03

71

1

1

40

0

4

5

28.88

A-(2,1,x,x)

8,665

28,161

2,693

00:00:09

211

1

1

60

0

5

5

31.08

A-(2,2,x,x)

21,746

74,848

7,291

00:00:25

435

1

1

80

0

6

6

33.53

A-(0,3,x,x)

616

1,815

218

00:00:01

30

1

1

8

0

5

5

35.39

A-(1,3,x,x)

8,109

27,658

2,997

00:00:09

194

1

1

36

0

6

6

36.96

A-(2,3,x,x)

54,012

196,032

18,688

00:01:12

758

1

1

100

0

7

7

34.60

A-(3,0,x,x)

13,632

44,896

3,806

00:00:14

255

1

1

100

0

5

6

27.92

A-(3,1,x,x)

38,254

131,377

11,356

00:00:46

694

1

1

140

0

6

6

29.69

A-(3,2,x,x)

104,221

376,592

32,967

00:02:28

1,357

1

1

180

0

7

7

31.63

A-(3,3,x,x)

277,433

1,046,548

89,913

00:08:21

2,279

1

1

220

0

8

8

32.41

B-(0,0,x,0)

402

1,238

121

00:00:00

0

2

1

0

2

3

4

30.10

B-(0,0,x,1)

921

3,077

307

00:00:01

0

2

1

0

2

4

5

33.33

B-(0,1,x,0)

941

3,026

267

00:00:01

0

2

1

0

7

4

4

28.37

B-(0,1,x,1)

2,439

8,407

770

00:00:02

0

2

1

0

7

5

5

31.57

B-(1,0,x,0)

3,298

11,120

960

00:00:03

0

2

1

0

14

4

5

29.11

B-(1,0,x,1)

8,933

31,979

2,867

00:00:10

0

2

1

0

14

5

6

32.09

B-(1,1,x,0)

8,380

29,094

2,169

00:00:09

0

2

1

0

35

5

5

25.88

B-(1,1,x,1)

22,473

81,939

6,310

00:00:26

0

2

1

0

35

6

6

28.08

C-(0,0,0,0)

490

1,511

156

00:00:00

0

2

1

0

2

3

4

31.84

C-(0,0,0,1)

674

2,140

222

00:00:01

0

2

1

0

2

4

4

32.94

C-(0,0,1,0)

1,498

5,012

512

00:00:01

0

2

1

0

2

4

5

34.18

C-(0,0,1,1)

3,135

10,922

1,070

00:00:03

0

2

1

0

2

5

5

34.13

C-(0,1,0,0)

1,273

4,113

397

00:00:01

0

2

1

0

7

4

4

31.19

C-(0,1,0,1)

2,000

6,714

660

00:00:02

0

2

1

0

7

5

5

33.00

C-(0,1,1,0)

4,388

15,232

1,432

00:00:04

0

2

1

0

7

5

5

32.63

C-(0,1,1,1)

9,937

35,974

3,223

00:00:11

0

2

1

0

7

6

6

32.43

C-(1,0,0,0)

4,104

13,825

1,218

00:00:04

0

2

1

0

14

4

5

29.68

C-(1,0,0,1)

6,329

21,918

1,930

00:00:06

0

2

1

0

14

5

5

30.49

C-(1,0,1,0)

13,756

49,215

4,295

00:00:15

0

2

1

0

14

5

6

31.22

C-(1,0,1,1)

29,073

107,300

8,621

00:00:33

0

2

1

0

14

6

6

29.65

C-(1,1,0,0)

11,039

38,499

2,980

00:00:11

0

2

1

0

35

5

5

27.00

296

Table D.5: Sweep-line analysis results of DCCP connection management: FIFO channels with loss (part 2). Sweep-line Config.

Terminal Markings

Ch. Bounds

total

total

peak

Ch

Ch

%

nodes

arcs

nodes

time

I

II

III

IV

V

CS

SC

space

C-(1,1,0,1)

18,337

66,074

5,221

00:00:20

0

2

1

0

35

6

6

28.47

C-(1,1,1,0)

37,549

137,816

10,645

00:00:44

0

2

1

0

35

6

6

28.35

C-(1,1,1,1)

84,663

321,021

23,392

00:01:50

0

2

1

0

35

7

7

27.63

C-(2,2,0,0)

172,479

649,366

39,437

00:04:00

0

2

1

0

172

7

7

22.86

D-(0,0,x,0)

267

749

60

00:00:00

0

2

2

4

0

3

3

22.47

D-(0,0,x,1)

458

1,379

111

00:00:00

0

2

2

4

0

4

4

24.24

D-(0,1,x,0)

557

1,649

128

00:00:01

0

2

2

8

0

4

4

22.98

D-(0,1,x,1)

1,065

3,364

280

00:00:01

0

2

2

8

0

5

5

26.29

D-(1,0,x,1)

4,873

16,234

1,311

00:00:05

0

2

2

28

0

5

5

26.90

D-(1,1,x,0)

5,592

18,439

1,410

00:00:05

0

2

2

44

0

5

5

25.21

D-(1,1,x,1)

12,877

44,801

3,646

00:00:14

0

2

2

46

0

6

6

28.31

E-(0,0,x,0)

1,136

3,765

213

00:00:01

0

4

2

0

0

4

4

18.75

E-(0,0,x,1)

4,709

17,066

1,050

00:00:05

0

4

2

0

0

6

6

22.30

E-(0,1,x,0)

3,207

11,283

639

00:00:03

0

4

2

0

0

5

5

19.93

E-(0,1,x,1)

15,690

59,001

3,453

00:00:18

0

4

2

0

0

7

7

22.01

E-(1,0,x,0)

10,991

39,132

2,197

00:00:11

0

4

2

0

0

5

5

19.99

E-(1,0,x,1)

58,589

220,996

13,666

00:01:11

0

4

2

0

0

7

7

23.33

E-(1,1,x,0)

31,522

117,320

6,207

00:01:35

0

4

2

0

0

6

6

19.69

E-(1,1,x,1)

177,477

688,533

39,368

00:04:14

0

4

2

0

0

8

8

22.18

F-(0,0,0,0)

1,485

4,913

322

00:00:01

0

4

2

0

0

4

4

21.68

F-(0,0,0,1)

3,702

12,938

956

00:00:04

0

4

2

0

0

5

5

25.82

F-(0,0,1,0)

4,677

16,359

1,082

00:00:04

0

4

2

0

0

5

5

23.13

F-(0,0,1,1)

14,508

53,083

3,781

00:00:15

0

4

2

0

0

6

6

26.06

F-(0,1,0,0)

4,434

15,515

999

00:00:04

0

4

2

0

0

5

5

22.53

F-(0,1,0,1)

12,135

44,414

3,060

00:00:13

0

4

2

0

0

6

6

25.22

F-(0,1,1,0)

14,936

54,301

3,411

00:00:16

0

4

2

0

0

6

6

22.84

F-(0,1,1,1)

48,373

182,681

11,809

00:00:59

0

4

2

0

0

7

7

24.41

F-(1,0,0,0)

14,097

50,073

2,963

00:00:14

0

4

2

0

0

5

5

21.02

F-(1,0,0,1)

39,080

144,327

8,891

00:00:45

0

4

2

0

0

6

6

22.75

F-(1,0,1,0)

46,894

173,075

10,257

00:00:53

0

4

2

0

0

6

6

21.87

F-(1,0,1,1)

149,270

569,022

34,222

00:03:21

0

4

2

0

0

7

7

22.93

F-(1,1,0,0)

41,281

152,988

8,446

00:00:47

0

4

2

0

0

6

6

20.46

F-(1,1,0,1)

119,637

457,276

25,919

00:02:38

0

4

2

0

0

7

7

21.66

F-(1,1,1,0)

137,196

521,348

28,604

00:02:59

0

4

2

0

0

7

7

20.85

F-(1,1,1,1)

452,545

1,766,260

97,667

00:12:34

0

4

2

0

0

8

8

21.58

297

D.3

Reordering Channels without Loss

Table D.6: Sweep-line analysis results of DCCP connection management: reordering channels with no loss. Sweep-line Config.

A-(0,0,x,x)

Terminal Markings

Ch. Bounds

total

total

peak

Ch

Ch

%

nodes

arcs

nodes

time

I

II

III

IV

V

CS

SC

space

108

210

35

00:00:00

2

1

1

0

0

2

3

32.41

A-(0,1,x,x)

249

565

86

00:00:00

5

1

1

0

0

3

3

34.54

A-(1,0,x,x)

2,974

8,160

1,098

00:00:03

15

1

1

0

0

3

4

36.92

A-(1,1,x,x)

14,756

47,141

5,286

00:00:17

39

1

1

0

0

4

4

35.82

A-(0,2,x,x)

738

2,088

273

00:00:01

9

1

1

0

0

4

4

36.99

A-(1,2,x,x)

73,915

282,231

28,371

00:02:03

71

1

1

0

0

5

5

38.38

A-(2,1,x,x)

1,046,050

4,313,180

372,466

02:59:12

211

1

0

0

0

5

5

35.61

A-(1,3,x,x)

347,660

1,557,096

141,043

00:18:03

111

1

1

0

0

6

6

40.57

B-(0,0,x,0)

553

1,451

187

00:00:00

0

2

1

0

0

3

4

33.82

B-(0,0,x,1)

1,804

6,015

655

00:00:02

0

2

1

0

0

4

5

36.31

B-(0,1,x,0)

2,305

7,164

787

00:00:02

0

2

1

0

0

4

4

34.14

B-(0,1,x,1)

10,789

40,839

4,235

00:00:12

0

2

1

0

0

5

5

39.25

B-(1,0,x,0)

33,567

120,526

12,551

00:00:40

0

2

1

0

0

4

5

37.39

B-(1,0,x,1)

264,796

1,134,719

98,722

00:09:52

0

2

1

0

0

5

6

37.28

C-(0,0,0,0)

779

2,088

287

00:00:01

0

2

1

0

0

3

4

36.84

C-(0,0,0,1)

1,459

4,506

521

00:00:01

0

2

1

0

0

4

4

35.71

C-(0,0,1,0)

10,519

36,288

4,303

00:00:11

0

2

1

0

0

4

5

40.91

C-(0,0,1,1)

144,554

603,642

56,733

00:04:02

0

2

1

0

0

5

5

39.25

C-(0,1,0,0)

4,248

13,879

1,531

00:00:04

0

2

1

0

0

4

4

36.04

C-(0,1,0,1)

11,050

42,833

4,101

00:00:12

0

2

1

0

0

5

5

37.11

C-(0,1,1,0)

94,683

389,490

37,567

00:01:20

0

2

1

0

0

5

5

39.68

C-(0,1,1,1)

1,423,629

6,971,856

581,184

04:14:28

0

2

1

0

0

6

6

40.82

C-(1,0,0,0)

59,845

217,858

23,300

00:01:22

0

2

1

0

0

4

5

38.93

C-(1,0,0,1)

377,190

1,600,982

136,599

00:15:20

0

2

1

0

0

5

5

36.21

C-(1,0,1,0)

1,875,066

8,363,643

726,606

08:43:48

0

2

1

0

0

5

6

38.75

C-(1,1,0,0)

584,354

2,492,321

212,473

00:39:02

0

2

1

0

0

5

5

36.36

D-(0,0,x,0)

313

693

75

00:00:00

0

2

2

0

0

3

3

23.96

D-(0,0,x,1)

747

2,070

239

00:00:01

0

2

2

0

0

4

4

31.99

D-(0,1,x,0)

1,098

3,024

318

00:00:01

0

2

2

0

0

4

4

28.96

D-(0,1,x,1)

3,688

12,646

1,242

00:00:04

0

2

2

0

0

5

5

33.68

D-(1,0,x,0)

23,212

74,628

7,061

00:00:25

0

2

2

0

0

4

4

30.42

D-(1,0,x,1)

311,733

1,254,736

111,223

00:13:10

0

2

2

0

0

5

5

35.68

D-(1,1,x,0)

154,320

591,716

53,934

00:04:37

0

2

2

0

0

5

5

34.95

E-(0,0,x,0)

1,949

5,708

481

00:00:02

0

4

2

0

0

4

4

24.68

E-(0,0,x,1)

19,789

82,344

6,418

00:00:24

0

4

2

0

0

6

6

32.43

E-(0,1,x,0)

11,506

40,975

3,403

00:00:12

0

4

2

0

0

5

5

29.58

E-(1,0,x,0)

459,195

1,911,473

150,257

00:19:58

0

4

2

0

0

5

5

38.22

E-(0,1,x,1)

183,904

885,854

64,671

00:07:24

0

4

2

0

0

7

7

35.17

F-(0,0,0,0)

3,420

10,640

963

00:00:03

0

4

2

0

0

4

4

28.16

F-(0,0,0,1)

18,251

71,961

6,308

00:00:20

0

4

2

0

0

5

5

34.56

F-(0,0,1,0)

141,420

584,226

51,648

00:03:40

0

4

2

0

0

5

5

36.52

F-(0,1,0,0)

25,310

96,646

8,164

00:00:29

0

4

2

0

0

5

5

32.26

298

D.4

Reordering Channels with Loss

Table D.7: Sweep-line analysis results of DCCP connection management: reordering channels with loss. Sweep-line Config.

Terminal Markings

Ch. Bounds

total

total

peak

Ch

Ch

%

nodes

arcs

nodes

time

I

II

III

IV

V

CS

SC

space

A-(0,0,x,x)

139

426

48

00:00:00

2

1

1

2

0

2

3

34.53

A-(0,1,x,x)

353

1,295

106

00:00:00

7

1

1

5

0

3

3

30.03

A-(1,0,x,x)

4,645

20,781

1,379

00:00:05

54

1

1

35

4

3

4

29.69

A-(1,1,x,x)

24,589

130,743

5,901

00:00:33

167

1

1

75

14

4

4

24.00

A-(0,2,x,x)

1,089

5,175

319

00:00:01

16

1

1

9

0

4

4

29.29

A-(1,2,x,x)

119,939

783,215

30,686

00:04:03

342

1

1

122

30

5

5

25.58

A-(2,1,x,x)

1,897,707

13,349,811

398,627

00:06:17

1,917

1

1

416

132

5

5

21.01

A-(1,3,x,x)

538,882

4,230,442

154,548

00:36:37

592

1

1

178

52

6

6

28.68

B-(0,0,x,0)

710

3,187

263

00:00:01

0

2

1

0

2

3

4

37.04

B-(0,0,x,1)

2,374

13,938

989

00:00:03

0

2

1

0

2

4

5

41.66

B-(0,1,x,0)

3,041

16,558

1,096

00:00:03

0

2

1

0

8

4

4

36.04

B-(0,1,x,1)

14,178

96,781

5,674

00:00:21

0

2

1

0

8

5

5

40.02

B-(1,0,x,0)

48,393

302,801

16,305

00:01:19

0

2

1

0

74

4

5

33.69

B-(1,0,x,1)

397,424

3,019,499

132,298

00:20:19

0

2

1

0

157

5

6

33.29

C-(0,0,0,0)

1,006

4,651

381

00:00:01

0

2

1

0

2

3

4

37.87

C-(0,0,0,1)

1,885

10,274

743

00:00:02

0

2

1

0

2

4

4

39.42

C-(0,0,1,0)

13,681

85,031

5,643

00:00:18

0

2

1

0

2

4

5

41.25

C-(0,0,1,1)

187,000

1,439,974

78,683

00:07:15

0

2

1

0

2

5

5

42.08

C-(0,1,0,0)

5,539

32,079

2,083

00:00:06

0

2

1

0

8

4

4

37.61

C-(0,1,0,1)

14,362

100,781

5,579

00:00:20

0

2

1

0

8

5

5

38.85

C-(0,1,1,0)

121,257

917,698

50,287

00:03:52

0

2

1

0

8

5

5

41.47

C-(0,1,1,1)

1,824,297

16,691,571

739,174

07:40:51

0

2

1

0

8

6

6

40.52

C-(1,0,0,0)

87,376

554,793

28,607

00:02:31

0

2

1

0

74

4

5

32.74

C-(1,0,0,1)

563,216

4,263,536

184,902

00:30:29

0

2

1

0

74

5

5

32.83

C-(1,1,0,0)

826,184

6,312,976

284,814

01:26:26

0

2

1

0

174

5

5

34.47

D-(0,0,x,0)

411

1,505

108

00:00:00

0

2

2

4

0

3

3

26.28

D-(0,0,x,1)

1,007

4,789

337

00:00:01

0

2

2

4

0

4

4

33.47

D-(0,1,x,0)

1,536

7,166

435

00:00:02

0

2

2

10

0

4

4

28.32

D-(0,1,x,1)

5,131

30,590

1,687

00:00:06

0

2

2

10

0

5

5

32.88

D-(1,0,x,0)

37,763

203,937

8,796

00:00:51

0

2

2

125

0

4

4

23.29

D-(1,0,x,1)

530,451

3,695,649

127,386

00:28:06

0

2

2

252

0

5

5

24.01

D-(1,1,x,0)

237,189

1,575,301

62,066

00:08:56

0

2

2

228

0

5

5

26.17

E-(0,0,x,0)

2,518

13,119

690

00:00:03

0

4

2

0

0

4

4

27.40

E-(0,0,x,1)

24,991

192,769

92,207

00:00:40

0

4

2

0

0

6

6

36.84

E-(0,1,x,0)

14,952

96,716

4,378

00:00:20

0

4

2

0

0

5

5

29.28

E-(0,1,x,1)

227,252

2,062,138

86,863

00:12:33

0

4

2

0

0

7

7

38.22

E-(1,0,x,0)

676,497

5,028,011

199,394

00:38:54

0

4

2

0

0

7

7

38.22

F-(0,0,0,0)

4,392

24,470

1,342

00:00:05

0

4

2

0

0

4

4

30.56

F-(0,0,0,1)

23,504

169,878

8,837

00:00:33

0

4

2

0

0

5

5

37.60

F-(0,0,1,0)

181,890

1,389,600

72,364

00:06:20

0

4

2

0

0

5

5

39.78

F-(0,1,0,0)

32,727

228,123

10,744

00:00:48

0

4

2

0

0

5

5

32.83

299

Appendix E Additional Results relating to Chapter 9 E.1

Additional Results when Only Long Sequence Numbers are Allowed

This appendix contains the revised analysis results as discussed in section 5.1.6. Table E.1: Revised Results of Table 9.2 Terminal ISS

Nodes

Arcs

Terminal

Markings

ISS

A

B

C

D

0

14,141

45,208

39

1

1

0

.

1

14,756

47,141

39

1

1

0

2

14,756

47,141

39

1

1

.

.

.

.

.

248 − 80

14,756

47,141

39

248 − 79

14,369

45,773

248 − 78

13,653

248 − 77

Nodes

Arcs

Markings A

B

C

D

.

.

.

.

.

.

248 − 9

11,442

36,349

38

1

1

2

0

248 − 8

11,442

36,349

38

1

1

2

.

.

248 − 7

11,441

36,348

38

1

1

2

1

1

0

248 − 6

11,437

36,340

38

1

1

2

39

1

1

0

248 − 5

11,077

35,202

38

1

1

2

43,313

39

1

1

0

248 − 4

11,269

35,930

38

1

1

2

11,885

37,905

39

1

1

0

248 − 3

11,870

38,061

38

1

1

2

248 − 76

11,883

37,893

39

1

1

2

248 − 2

13,896

44,256

38

1

1

2

248 − 75

11,442

36,349

38

1

1

2

248 − 1

13,768

43,801

38

1

1

0

248 − 74

11,442

36,349

38

1

1

2

300

E.2

Additional Results when Short Sequence Numbers are Allowed

This appendix contains analysis results under the same operating conditions as Appendix E.1 but in addition, short sequence numbers are also allowed. Table E.2: Analysis results when using both short and long sequence numbers (part 1). ISS

Nodes

Arcs

Terminal Markings A

B

C

D

0

26,244

89,575

39

1

1

0

1

26,859

91,508

39

1

1

0

2

26,859

91,508

39

1

1

0

.

.

.

.

.

.

.

224 − 6

26,859

91,508

39

1

1

0

224 − 5

27,307

93,174

39

1

1

0

224 − 4

30,779

105,745

39

1

1

0

224 − 3

37,904

131,729

39

1

1

0

224 − 2

56,071

199,919

39

1

1

0

224 − 1

56,897

202,660

39

1

1

0

.

.

.

.

.

.

225 − 6

56,897

202,660

39

1

1

0

225 − 5

56,305

200,690

39

1

1

0

225 − 4

56,099

200,028

39

1

1

0

225 − 3

55,926

199,478

39

1

1

0

225 − 2

56,884

202,629

39

1

1

0

225 − 1

56,897

202,660

39

1

1

0

.

301

Table E.3: Analysis results when using both short and long sequence numbers (part 2). ISS

.

Nodes

Arcs

Terminal Markings A

B

C

D

.

.

.

.

.

.

247 − 6

56,897

202,660

39

1

1

0

247 − 5

56,305

200,690

39

1

1

0

247 − 4

56,099

200,028

39

1

1

0

247 − 3

55,926

199,478

39

1

1

0

247 − 2

56,884

202,629

39

1

1

0

247 − 1

56,897

202,660

39

1

1

0

.

.

.

.

.

.

248 − 77

56,897

202,660

39

1

1

0

248 − 76

56,903

202,664

39

1

1

2

248 − 75

55,069

195,127

38

1

1

2

.

.

.

.

.

.

248 − 11

55,069

195,127

38

1

1

2

248 − 10

55,068

195,126

38

1

1

2

248 − 9

55,064

195,118

38

1

1

2

248 − 8

55,054

195,098

38

1

1

2

248 − 7

55,025

195,017

38

1

1

2

248 − 6

55,021

195,005

38

1

1

2

248 − 5

53,836

191,079

38

1

1

2

248 − 4

53,266

189,199

38

1

1

2

248 − 3

51,863

184,739

38

1

1

2

248 − 2

38,678

134,704

38

1

1

2

248 − 1

25,175

85,306

38

1

1

0

.

.

302

An Investigation of the Datagram Congestion Control ... - CiteSeerX

An Investigation of the Datagram Congestion Control ... - CiteSeerX

Suggest Documents

An Investigation of the Datagram Congestion Control ... - CiteSeerX

Analysis of Datagram Congestion Control Protocol ...

DCCP (Datagram Congestion Control Protocol) - Keith Briggs

Datagram Congestion Control Protocol (DCCP) - Eddie Kohler

Comparing Stream Control and Datagram Congestion Control with ...

Performance Analysis of Datagram Congestion Control Protocol (DCCP)

Performance Analysis of Datagram Congestion Control Protocol (DCCP)

Congestion Control - CiteSeerX

An investigation into the reasons for the rejection of congestion ...

Congestion Control

Congestion Control

Adaptive Congestion Protocol: A New Congestion Control ... - CiteSeerX

application of adaptive control to atm abr congestion control - CiteSeerX

a model for congestion control of transmission control ... - CiteSeerX

An Improved TCP Congestion Control Algorithm and

Congestion Control in Differentiated Services Networks ... - CiteSeerX

Congestion Control for Distributed Hash Tables - CiteSeerX

Constrained TCP-Friendly Congestion Control for ... - CiteSeerX

Congestion Control in Differentiated Services Networks ... - CiteSeerX

Adaptive-Compression Based Congestion Control ... - CiteSeerX

Fuzzy logic based Congestion control - CiteSeerX

EXPLICIT RATE CONGESTION CONTROL FOR DATA ... - CiteSeerX

Studying Congestion Control with Explicit Router ... - CiteSeerX

TCP Westwood: Congestion Window Control Using ... - CiteSeerX