Visualizing the Internet protocol TCP

Transcription

1 Visualizing the Internet protocol TCP Freek Stulp Rineke Verbrugge Instituto de Sistemas e Robótica Artificial Intelligence Instituto Superior Técnico University of Groningen Home-page: Abstract Protocols are designed to ensure correct transmission of data when communicating over error-prone media. Understanding exactly how a protocol functions over time can be greatly enhanced if the protocol is visualized. This article discusses the Transmission Control Protocol used in the Internet, and presents an application that visualizes it. Future work aims at extending the application to show several protocols under varying conditions, creating a useful educational tool. 1 Introduction Protocols play an essential part in almost every form of communication. Whether it is a phone-call to a friend, or downloading a document from the Internet, protocols are involved. In general, their main purpose is to ensure that the message comes across correctly, even if it is made over faulty connections. One of the most important protocols for communication over the Internet is the Transmission Control Protocol (TCP). In a previous article we derived two knowledgebased algorithms modeling the essential body of the TCP, and concentrated on the epistemic analysis of these algorithms [4]. This article on the other hand will focus on the application developed to visualize the TCP. The rest of the paper is structured in the following way. Section 2 gives a short introduction to protocol verification. In section 3 the Transmission Control Protocol is presented. Its history and implementation are discussed, as well as the knowledgebased algorithms used to model it. Section 4 presents the Java Applet used to visualize the TCP. In section 5 we present the forthcoming application that is currently being developed. The article concludes with section 6. 2 Protocol Verification In their classical paper [2], Halpern and Zuck showed that epistemic logic provides a transparent way to specify and verify a number of protocols (like the alternatingbit protocol) that have been introduced for error-free transmission of sequences of Av. Rovisco Pais 1, Lisboa, Portugal. freeks@ai.rug.nl Grote Kruisstraat 2/1, 9712 TS Groningen, The Netherlands. rineke@ai.rug.nl 1

2 messages over a distributed network. In particular, they introduced two knowledgebased protocols, A and B, that could solve the following problem. Let two processors be given, called the sender S and the receiver R. The sender has an input tape with an infinite sequence X of data elements. S reads these elements and tries to send them to R, which writes the elements on an output tape. The protocols are required to guarantee that (a) at any moment the sequence of data elements received by R is a prefix of X (safety) and (b) if the communication medium satisfies certain so-called fairness conditions, every data element of X will eventually be written by R (liveness). Fairness here means that infinitely many message instantiations from S to R and from R to S are delivered, guaranteeing that every message arrives eventually. In perfect networks in which no errors occur this is trivial, but in real distributed systems errors occur during transmission. Data might simply disappear (a deletion error) or appear out of nowhere (an insertion error), the information content of the data might be corrupted (a mutation error), or it might not arrive in the order in which it was sent (a reordering error). Halpern and Zuck solved the sequence transmission problem for communication media where any two kinds of the first three above-mentioned errors occur. In order to do this, they used for each combination of two errors a special encoding of messages ensuring unique decodability and error detection. Thus, the knowledge-based protocols A and B were implemented in different ways to solve the sequence transmission problem in different kinds of communication media [2]. With the advent of very large networks, such as the Internet, new protocols were developed and implemented. Apart from ensuring the correct transmission of data, they also adapt to the varying circumstances that occur in real-world networking, such as varying bandwidth, varying transmission speed and partial failures of the network. One of these protocols was the Transmission Control Protocol (TCP), which will be discussed in the next section. 3 Transmission Control Protocol This section briefly discusses the Transmission Control Protocol and its abstraction to a knowledge-based protocol. It is a summary of concepts discussed in more detail in [4]. In 1969, the Advanced Research Projects Agency Network (ARPANET) was developed by the U.S. Defense Department. Several protocols were developed for data transmission across this network, of which the TCP was to be used if reliability requirements were high. The Internet as we now know it evolved from the ARPANET. Many things changed, but the TCP has always remained, as any network will need some sort of mechanism to ensure correct transmission. See [3] for an extensive history. The high-level specification of TCP is very similar to protocol B, but has many extra features that address real-world networking issues. One of these is the specification of a Retransmission Time-Out. If the sender has to wait for a package from the receiver (or vice versa) for a long time, it can be assumed that a deletion error occurred, and the package is resent. In protocol B, it is not specified what a long time is, but in TCP this is the Retransmission Time-Out (RTO). Once this expires, a package is resent. An appropriate RTO depends on the overall network properties, as well as varying network conditions over time. See [1] for a good description of how the RTO is determined. Another feature is sliding windows. Instead of dealing with one package at a time (as protocol A and B do), TCP can send a whole window of packages at one time. The receiver only needs to acknowledge the last consecutive received package in the window 2

3 to inform the sender that it has received all the packages in the window thus far. This reduces the number of acknowledgements, and thus the load on the network. TCP is a communication protocol, not a piece of software. Thus, the protocol specifies the format of the data and acknowledgements that computers exchange as well as the way computers initiate and complete a TCP stream transfer. On the other hand, TCP does not dictate the details of the interface between an application program and TCP itself [1]. This gives a programmer flexibility when implementing TCP for a particular computer s operating system. At the same time, the high-level specification of TCP makes it amenable for an analysis using epistemic logic. Still, to give a true knowledge-based interpretation of the TCP we will first have to convert the technical Internet language to more knowledge-based terms. In [4] the language we use is explained. A justification of certain simplifications is also given. More importantly, the knowledge-based algorithms are presented. They are not repeated explicitly in the current article, as they can be seen in the screen-shot of the application in figure 1, as well as in the Manual section of the accompanying home-page. The derived algorithms were analyzed using modal logic. It was proven that the sender and the receiver using TCP can acquire depth n knowledge about the values of the messages for any n. On the negative side, it was proven that TCP could never ensure common knowledge between the sender and the receiver, by giving specific bounds on the depth of knowledge at each moment of data transmission. Also, the simplification of TCP to a knowledge-based algorithm enables lucid visualization, and the emphasis of this article lies on this aspect. 4 Visualization Proving properties of a protocol using epistemic logic is one thing, but an intuitive understanding of the protocol is another, certainly for those not too familiar with protocols or epistemic logic. The latter is more easily acquired with a visualization, so the knowledge-based algorithms have been implemented and incorporated in an interface, written in Java. This language is highly portable, and can be executed using only an Internet browser. The Applet can be seen on the home-page referred to on the title page. This web-site features the Applet, which can be reached through the Applet option in the menu. There is also a small manual, in which the interface is explained, and in which the algorithms of the protocol are discussed in more detail. Reading this section will be greatly enhanced if the Applet is at hand, especially if only a gray-scale version of the article is available. The interface is shown in figure 1, and consists of four main components. The topmost part represents the network. On the left is the sender, on the right the receiver. Sender and Receiver can send each other packages, consisting of a number (representing the position on the tape from which that package was read) and a letter (representing the data at that position on the tape). Receiver only needs to send acknowledgements, represented Between them is the network. Each package sent travels one of three connections. The middle connection is the standard route; packages travel it with normal speed. The upper one is much slower than the standard connection. This causes reordering problems. The lower connection is broken, so packages get lost as well (dramatically visualized with an explosion!). This causes deletion errors. Mutation and insertion errors have not been modeled in this application. Each time a package is sent by 3

4 Figure 1: The TCP visualization Applet Sender or Receiver, it is transported across the network in a certain time. At the intersection the network decides through which connection the package will travel the network. The probability with which each connection is chosen is specified separately for Sender and Receiver, modeling different network conditions. The user can not yet set these values. Once a package has crossed the network, it is taken off the network, and passed to the sender or the receiver. The center part contains the algorithms for the sender and the receiver. The rule that is currently active is highlighted red, the others are black. The execution of the algorithms is done in steps. At each step, the next rule in the algorithm fires, and the packages are transported some distance across the network. A send command by either of the protocols leads to the introduction of a new package on the network. The center panel also shows the tapes from which data is read by the sender, and data is written by the receiver. The protocols have an explicit read(x,i) and write(x,i) function that enable this. For the receiver, unknown slots on the tape are gray, known slots are white and specify the information contained at that slot. For the sender, slots in the window are white or yellow, those outside are all gray. For both, the variable i, representing the index of the package currently being processed, is indicated beneath the tape by a red index. The three buttons at the bottom allow the user to run the protocol. The stepbutton makes one single step in the protocol, as discussed above. The start-button runs the protocols continuously simply by appending steps. The pause-button pauses the transmission. Resetting the application can easily be done by pressing the refreshbutton of the browser. Summarizing: the application visualizes how Sender and Receiver constantly send each other new data and acknowledgements, how sender reads from the tape and sends 4

5 its data package by package, window by window, how receiver receives data and writes it to the tape, acknowledging packages meanwhile, and, probably most interesting, how deletion and reordering errors occur, and are dealt with by the protocols. 5 Ongoing and Future Work Although the application was very useful in accompanying the article discussing the epistemic analysis, its educational value is limited. This is mainly because the TCP is a fairly complex protocol, and understanding it requires prior knowledge about protocol verification, or at least modal logic. Even for the epistemic connoisseurs, learning both the interface and TCP at the same time might prove difficult. Nevertheless, it was ideal as an accompaniment of the previous article, as it explained TCP in great detail. An obvious improvement would be if the application had the capability of visualizing several protocols, ranging from relatively simple protocols such as Protocol B to the sophisticated TCP. Our current work is aiming at exactly this. In figure 2 the interface for the new application is shown. Although we think this interface is pretty definitive, the application is not yet operational. The Protocol shown in the screen-shot is Protocol B, but we will add other protocols such as Protocol A, the Alternating Bit Protocol, TCP, UDP (User Datagram Protocol, another Internet protocol), and perhaps more. Figure 2: Visualizing protocols under varying conditions The basic layout and functionality of the program is the same as the application discussed in section 4 (the buttons and tapes have moved), but there are two added features. The first is simply a list of all the facts stored in the knowledge-base. As the application is not fully implemented yet they are empty, but when operational 5

6 the knowledge-base could show facts as K r K s (1, 5), K s (0, 5), or anything else the protocol stores. The second feature makes it especially useful as an educational tool. On the top left, below the protocol selector (currently Protocol B is selected), there is a panel in which the transmission errors can be controlled. Occurrence of specific types of errors (deletion, reordering and mutation) can be enabled or not. If enabled, the user can specify which percentage of packages should be corrupted by this type of error. In the screen-shot, 10% of packages will travel the lower connection and be deleted, whereas 20% will take the slow connection, leading to reordering errors. There are no mutation errors, as the check-box is disabled. This feature allows the user to see how the different errors influence the transmission of data from Sender to Receiver. For students, answering questions as Can Protocol B guarantee safety with a connection in which deletion and mutation errors occur?, or Can TCP cope with mutation errors? might be made a lot easier (and hopefully more fun!) with the application. It gives no proof, but could certainly be used to point the user in the right direction. That this is no overstatement is exemplified by the earlier TCP visualization Applet, which inspired most of the proofs discussed in [4]. 6 Conclusion This article has discussed protocols and their verification. Verification of protocols can be difficult, and proofs of several pages are no exception. Sometimes a more intuitive idea of how a protocol really works over time is desired, especially if one is a newcomer to the field. We feel that visualization is an essential element in forming this intuition. A previous article emphasized the epistemic analysis of the Internet protocol TCP [4], whereas this article has focused on the visualization application that accompanied it. The application shows TCP in action, showing precisely how the protocol functions over time and interacts with the environment. This article was also used to present a similar, forthcoming application which is much more general, visualizing several protocols, and allows the user to control the occurrence of transmission errors. We hope that its educational value will inspire teachers to use it in courses on protocol verification, or modal logic in general. References [1] D.E. Comer, Internetworking with TCP/IP, Volume I: Principles, Protocols and Architecture, Upper Saddle River, Prentice Hall, [2] J.Y. Halpern and L.D. Zuck, A little knowledge goes a long way: simple knowledgebased derivations and correctness proofs for a family of protocols. Journal of the ACM 39, nr. 3 (1992), pp Earlier version appeared in: Proceedings of the Sixth ACM Symposium on Principles of Distributed Computing, 1987, pp [3] M. Miller, Troubleshooting TCP/IP: Analyzing the Protocols of the Internet, San Mateo (CA), Prentice-Hall, [4] F. Stulp and R. Verbrugge, A knowledge-based algorithm or the Internet protocol TCP, Proc. 4rd Conf. on Logic and the Foundations of Game and Descision Theory (LOFT 4), Torino, Italy, June Also to be published in the Bulletin of Economic Research. 6