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

Summary Designing a new protocol has never been an easy task. Despite four decades of accu-mulated experience with protocol design, without formal methods it is difficult to designand specify a new protocol without any errors. Using a formal technique called ColouredPetri Nets (CPNs), this thesis investigates the connection management procedures of anew 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 ver-sion 5. A Coloured Petri Net software package called Design/CPN has been used toconstruct, maintain and analyse a CPN model of DCCP’s connection management proce-dures. We iteratively refine the CPN model to incorporate DCCP’s detailed proceduresincluding synchronisation. The research presented in this thesis has been published in 7peer reviewed articles in international journals and conferences. These articles form thebasis of the thesis.The development of the models and their analysis has revealed several subtle prob-lems. Our early analysis results indicate that when DCCP version 5 or 6 operates overa reordering channel without loss, DCCP’s connection establishment procedures can failresulting in deadlocks where the client is CLOSED but the server is OPEN. AlthoughIETF succeeded in removing these deadlocks by modifying the procedures, the changesintroduced a serious problem called “chatter”. Chatter comprises undesired (and possiblyvery long) exchanges of messages where no progress is made until finally the system cor-rects itself. Chatter creates unnecessary traffic which adversely affects congestion in theInternet, precisely the opposite intention of DCCP. In this case we show that if the prob-lem occurred, then the probability of over 2 billion messages being needlessly exchangedwas greater than .99999. This problem was reported to IETF in September 2005 andwas corrected and re-analysed within 24 hours. A number of other problems were alsoreported to IETF in time for them to be rectified and the solutions incorporated beforethe final Internet Standard, RFC 4340, was published in March 2006. In April 2006 ourfurther 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 indeadlock where the client is CLOSED but the server is OPEN. These deadlocks can beremoved if the application on the server issues a close command.xviii