[14] S. L. Murphy, \Service Specication and Protocol Construction for a Layered Architecture,"

Transcription

1 [14] S. L. Murphy, \Service Specication and Protocol Construction for a Layered Architecture," Ph.D. dissertation, Department of Computer Science, University of Maryland, May Also Computer Science Dept., University of Maryland, Tech. Rep. CS-TR-2583 (or UMIACS-TR-91-3), January [15] A. A. Schoone, \Verication of Connection-Management Protocols," in the 2nd Workshop on Distributed Algorithms, LNCS No. 312, pp. 167{186, September [16] A. U. Shankar, \Modular Design Principals for Protocols with an Application to the Transport Layer," Proceedings of the IEEE, Vol. 79, No. 12, December [17] A. U. Shankar and D. Lee, \Modulo-N Incarnation Numbers for Cache-based Transport Protocols," Computer Science Dept., University of Maryland, Tech. Rep. CS-TR-3046 (or UMIACS-TR-93-24), March [18] J. F. Sgaard-Andersen, N. A. Lynch and B. W. Lampson, \Correctness of Communication Protocols, a Case Study," Tech. Rep. MIT/LCS/TR-589, Laboratory for Computer Science, MIT, November [19] C. A. Sunshine and Y. K. Dalal, \Connection Management in Transport Protocols," Computer Networks, Vol. 2, pp. 454{473, [20] A. Tanenbaum, Computer Networks, 2nd edition, Prentice Hall, [21] R. S. Tomlinson, \Selecting Sequence Numbers," Proc. ACM SIGCOMM/SIGOPS Interprocess Communications Workshop, pp. 11{23, 1975; in ACM Operating Systems Review, Vol. 9, No. 3, [22] Transmission Control Protocol, DARPA Network Working Group Report RFC-793, University of Southern California, September [23] R. W. Watson, \Timer-based mechanisms in reliable transport protocol connection management," Computer Networks, Vol. 5, pp. 47{56, [24] R. W. Watson, \The Delta-t Transport Protocol: Features and Experience," Proc. IEEE Conf. on Local Computer Networks, pp. 399{407,

2 References [1] H. Attiya, S. Dolev and J. L. Welch, \Memory Requirements for Connection Management," to appear in Information and Computation. Also: Technical Report LPCR #9316, Laboratory for Parallel Computing Research, Department of Computer Science, The Technion, Haifa, June [2] D. Belsnes, \Single-Message Communication," IEEE Transactions on Communication, Vol. T-COM-24, No. 2, pp. 190{194, February [3] E. W. Biersack and D. Feldmeier, \A Timer-Based Connection Management Protocol with Synchronized Clocks and its Verication," to appear in Computer Networks and ISDN systems. [4] D. Comer, Internetworking with TCP/IP, Volume I: Principles, Protocols and Architecture, Prentice-Hall, Englewood Clis, NJ, [5] J. G. Fletcher and R. W. Watson, \Mechanisms for a Reliable Timer-Based Protocol," Computer Networks, Vol. 2, pp. 271{290, [6] R. Gawlick, R. Segala, J. Sgaard-Andersen and N. Lynch, \Liveness in Timed and Untimed Systems," Tech. Rep. MIT/LCS/TR-587, MIT, Laboratory for Computer Science, December [7] J. Kleinberg, H. Attiya and N. Lynch, \Trade-Os Between Message Delivery and Quiesce Times in Connection Management Protocols," 3rd Israel Symposium on Theory of Computing and Systems, January 1995, pp. 258{267. [8] J. F. Kurose and Y. Yemini, \The Specication and Verication of a Connection Establishment Protocol using Temporal Logic," in Protocol Specication, Testing and Verication II (C. A. Sunshine, Ed), North-Holland, New-York, [9] G. LeLann and H. LeGo, \Verication and Evaluation of Communication Protocols," Computer Networks, Vol. 2, pp. 50{69, [10] S. S. Lam and A. U. Shankar, \Protocol Verication via Projections," IEEE Trans. on Software Engineering, Vol. 10, No. 4, pp. 325{342, July [11] B. Liskov, L. Shrira and J. Wroclawski, \Ecient At-Most-Once Messages Based on Synchronized Clocks," ACM Trans. on Computers, Vol. 9, No. 2, pp. 125{142. [12] N. Lynch and M. Tuttle, \An Introduction to Input/Output Automata," CWI Quarterly, Vol. 2, No. 3, pp. 219{246, September [13] S. L. Murphy and A. U. Shankar, \Connection Management for the Transport Layer: Service Specication and Protocol Verication," IEEE Trans. on Communications, Vol. 39, No. 12, pp. 1762{1775, December

3 closed states will appear several times. Hence, packets incur a very long delay in the execution constructed in the proof. Therefore, the execution we construct is virtually impossible in practice. Murphy and Shankar specify the intended service of TCP, and present a protocol which provides this service [13]. The protocol assumes that the nodes have unbounded memory; when an MPL bound exists, the nodes can employ bounded incarnation numbers. However, in the Internet, a packet's lifetime can exceed the MPL bound (with a very low probability). Thus, the correctness proof of a protocol which assumes the existence of a strict MPL bound is not applicable (in the mathematical sense) for TCP. Our work continues previous work and studies an additional aspect of transport layer protocols, Other aspects remain to be studied, for example, buering and ow control. In addition, symmetric connection initialization, in which the host at R can also initiate a connection, can be specied and investigated; this will require new protocols, but the impossibility results presented in this paper are applicable for this case as well. 34

4 Proof: Consider the schedule constructed in the proof of Theorem In this schedule, we \collected" an ICP sequence and caused R to accept it after the connection with S had disconnected. These packets can be accumulated in the network since they do not expire after R disconnects. In wide-area networks, MPL is quite large. Protocols which require the nodes to wait for MPL time between consecutive incarnations, are not ecient. Waiting can be eliminated in two methods. One way is by using a three-way handshake oblivious protocol, and the other way is by using a two-way handshake protocol in which information is kept between incarnations for at least MPL time. Shankar and Lee ([17]) present protocols which combine both methods. The nodes retain connection-specic information in a cache for MPL time. If the entry for the requesting client is found in the cache, then the connection is established using two-way handshake; otherwise, a three-way handshake is used. In both methods, bounded sequence numbers can be used, but timers should be employed to assure that old duplicates are not received as valid (e.g., a duplicate packet with the same sequence number as another packet in transit p, can be received before p, causing old data to be delivered to the host). 7 Discussion The precise level of handshake required for establishing a connection correctly was identied, under dierent assumptions on the nodes and the network. Our main results are: 1. If the nodes have bounded memory, no incarnation management protocol exists. 2. If the nodes have unbounded memory and the server retains information between incarnations, then a two-way handshake protocol exists. 3. If the nodes have unbounded memory, a three-way handshake oblivious protocol exists, whereas a two-way handshake oblivious protocol does not exist. 4. If a bound on maximum packet lifetime, MPL, exists and is known to the nodes, then a two-way handshake oblivious protocol exists. 5. If MPL exists, then in executions of two-way handshake oblivious protocols, at least MPL time must elapse between two consecutive incarnations. We have shown that there is no connection management protocol with bounded memory. However, in practice, nodes must have a bounded memory. Supercially, this implies that any practical protocol, e.g., the TCP connection management protocol, is incorrect. Indeed, to the best of our knowledge, there is no rigorous correctness proof for TCP. However, the proof of the impossibility result employs an execution which is highly improbable in practice. When a very large sequence number space is used, a long period of time can elapse until a pair of 33

5 For the induction step, assume that the claim holds for incarnation i. By the code, each time R receives a dis S packet, R empties its buer and sends a single disack packet as a response. When S receives the rst disack packet in an incarnation, it empties its buer and then waits for MPL time before outputting dis S. Obviously, no packets that S sends are in transit afterwards, since the maximum lifetime of a packet is MPL. Therefore, when Req-Con S of incarnation i + 1 occurs, only disack packets from previous incarnations can be in transit. By using Lemma 6.1, the proofs of Lemma 5.2, Lemma 5.5, Lemma 5.3, and Lemma 5.9 become trivial. The proofs of the other lemmas do not change. By Lemma 5.9, R enters an established state when Con R occurs, which implies that the protocol is two-way handshake. By Lemma 5.1, Lemma 5.6, Lemma 5.7, and Lemma 5.8, the protocol satises IM1, IM2, IM4, and IM5, respectively. Therefore, we have: Theorem 6.2 There is a two-way handshake oblivious bounded memory connection management protocol for non-fifo unreliable networks with a known bound on maximum packet lifetime. We now analyze the time it takes to disconnect in this protocol. Let d be the maximum delay time of a packet in a given timed execution. The disconnection procedure starts when S sends R the rst dis S packet in an incarnation. S and R disconnect when they output Dis S and Dis R, respectively. If there are no Lose events, then S disconnects after at most 2d+MPL time: 2d time for the exchange of dis S and disack packets, and MPL additional time for waiting; R disconnects after at most d + MPL time: d time until it receives the dis S packet, and MPL additional time for waiting. 6.3 Waiting in Oblivious Protocols In the two-way handshake oblivious protocol presented in Section 6.2, S and R are required to wait MPL time before outputting Dis S and Dis R, for incarnations to be set up properly. The proof of Theorem 5.11 can be used to show that in two-way handshake oblivious protocols, at least MPL time must pass between the sending of ICP sequences in two consecutive incarnations, for incarnations to be set up properly. If less than MPL time passes between the sending of consecutive ICP sequences, R can be \confused" into accepting an ICP sequence from the previous incarnation, and like in the case when the MPL bound does not exist in the network, R delivers a wrong message to its host. Theorem 6.3 Let P be a two-way handshake oblivious protocol. Let Req-Con S in incarnation i of a given execution of P, i 1, occur at time t. Let Req-Con R in incarnation i + 1 occur at time t 0. Then t 0? t >MPL. 32

6 Program for S Initialization: reset-var S rst-disack := true Req-Con S : request-con S Recv S (seq,oseq,synack): if syn in buer then connect S (seq) Recv S (seq,oseq,dis R ): if rst-disack then send-packet S (seq,dis S ) Req-Dis S : request-dis S Recv S (seq,oseq,disack): if (oseq > ISN S ) and rst-disack then rst-disack := false buer := empty Timer-Set S (MPL) Step: step S if timeout then reset-var S rst-disack := true Dis S Program for R Initialization: reset-var R buer := empty rst-syn := true Recv R (seq,oseq,syn): if rst-syn then request-con R (seq) rst-dis := true rst-syn := false Con R : send-packet R (null,synack) state R := established Req-Dis R : send-packet R (null,dis R ) state R := closing Recv R (seq,oseq,dis S ): if rst-dis then buer := empty Timer-Set R (MPL) rst-dis := false send-packet R (seq.num,seq,disack) Step: step R if timeout then reset-var R rst-syn := true Dis R Figure 10: Two-way handshake oblivious protocol for networks with time constraints 31

7 where the times are nondecreasing and unbounded. A timed sequence, as above, is a timed execution fragment provided that the following hold: 1. S 0 ; e 1 ; S 1 ; : : :; e j ; S j ; : : : is an execution fragment. (See Section 2.1.) 2. Let packet p be sent to node i at the jth timed event. If there exists k > j such that the kth timed event is the matching delivery (Recv i (p); t k ), then t k? t j MPL. The delay of p is t k? t j, and it required to be less than MPL. 3. Let the timed event (e j ; t j ) be Timer-Set X (t), and the timed event (e k ; t k ) be be the rst Timer-Exp X after (e j ; t j ). If there are no Timer-Set X events between (e k ; t k ) and (e j ; t j ), then t k? t j t. Note that Timer-Set X events before (e j ; t j ) have no eect on the system. 6.2 A Protocol for Networks with Known MPL The following protocol is similar to the two-way handshake protocol presented in Section 5.1. The main dierence is that S and R wait MPL time when they are ready to disconnect an existing incarnation. This ensures that packets from this incarnation \age" and will not be received in later incarnations (except for disack packets which may be received in the next incarnation). If, at a later time, R receives a syn packet, it knows for sure that this packet is current and is not from previous incarnations. Therefore, R and S need not retain the value of their counters across incarnations. Specically, when R receives a dis S packet for the rst time, it sends a disack acknowledgment and initiates a timer for MPL time. When the timer expires, R is sure that no old syn packet from previous incarnations is in transit, and can safely disconnect. When S receives the disack packet for the current dis S packet, it initiates a timer for MPL time, during which it discards all arriving packets, and only afterwards S disconnects. The waiting assures that all dis S packets arrive before S disconnects. Since disack packets from the previous incarnation may still arrive in the current incarnation, S validates the oseq sequence number of a disack packet before acknowledging it (i.e., oseq ISN S ). Since S and R do not retain information about the connection between incarnations, the generic protocol can be modied to remove seq S and seq R. The protocol appears in Figure 10, and it employs the procedures presented in Figure 6. The correctness proof of the protocol is a simpler version of the proof of the two-way handshake protocol in Section 5.1. Lemma 6.1 When Req-Con S occurs, the only packets in transit are disack packets. Proof: We prove the lemma by induction on the number of incarnations. For the base case, consider the occurance of Req-Con S in the rst incarnation. Since no packets are in transit initially, the claim holds trivially. 30

8 The proofs of the other lemmas do not change. The proof of Lemma 5.7 uses Lemma 5.13, instead of Lemma 5.3. By Lemma 5.1, Lemma 5.6, Lemma 5.7, and Lemma 5.8, the protocol satises IM1, IM2, IM4, and IM5, respectively. Hence: Theorem 5.16 There is a three-way handshake unbounded memory connection management protocol for non-fifo unreliable networks. 6 Networks with Time Constraints Theorem 3.2 implies that a connection management protocol exists in non-fifo unreliable networks only if the receiver and sender have unbounded memory. Moreover, by Theorem 5.10, the protocol is two-way handshake only if the receiver retains some information about the connection between incarnations. These results crucially depend on the assumption that packets can remain in transit indenitely. We now show that if a bound on packet lifetime in the system (maximum packet lifetime or MPL, for short) is known, then a two-way handshake oblivious bounded memory protocol exists. Remark. When an MPL bound exists but is not known, then Theorem 3.2 and Theorem 5.11 are valid. In these proofs, we obtain a nite schedule in which R outputs Deliver R (m), for a specic m, one more time than it is transmitted, thus violating IM3. Consider a network in which the MPL is larger than the maximum delay of any packet in this schedule. Since the schedule is nite, such a bound exists. Thus, the proposed schedule exists even in a network with an MPL, since the MPL is larger than the time of delivery of all the packets. Therefore, there is not bounded memory incarnation management protocol and no two-way handshake oblivious protocol, when the MPL bound is not known. 6.1 Augmenting the Model We rst augment the model of Section 2 to include time. An occurance time is associated with each event, a bound on delivery time is introduced, and timers are dened. We assume each node's state includes a special Boolean variable timeout, and add the following two actions to the nodes (X is either R or S): output Timer-Set X (t), sets a timer for t time units, and input Timer-Exp X, the timer expires by setting timeout to true. A timed event is a pair (e; t) such that e is an event and t, the \time", is a nonnegative real number. A timed sequence is an innite sequence of alternating states and timed events S 0 ; (e 1 ; t 1 ); S 1 ; : : :; (e j ; t j ); S j ; : : : ; 29

9 are zeroed before S and R disconnect. procedures presented in Figure 6. The code appears in Figure 9, and it employs the The correctness proof of the protocol follows the same lines as the proof of the two-way handshake protocol of Section 5.1. Lemma 5.12 Let p be an ack packet. Assume S sends p in an incarnation, and Recv R (p) occurs. The p is valid if and only if oseq ISN R 6= 0. Proof: Suppose Recv R (p) occurs and oseq ISN R 6= 0. R selects its ISN when Con R or Req-Dis R occur, and therefore p was sent in the current incarnation. A retransmission from previous incarnations has an oseq value less than R's selected ISN. In a similar way, we can prove the following lemma, which replaces Lemma 5.3: Lemma 5.13 Let p be a dis S packet. Assume S sends p in an incarnation, and Recv R (p) occurs. Then p is valid if and only if oseq ISN R 6= 0. We now prove that the variable state R is updated correctly, and that the protocol is threeway handshake. The next lemma follows immediately from Lemma Lemma 5.14 Let p be an ack packet. Assume S sends p in an incarnation, and Recv R (p) occurs. Then p is valid if and only if oseq ISN R and state R = opening. The next lemma replaces Lemma 5.9. Lemma 5.15 If state R = established, then R is in an established state. Proof: Consider a schedule of an incarnation, and assume it is ping-pong. Let P 1 ; P 2 ; P 3 be a prex of the sequence of packets sent in the schedule, divided into subsequences such that S sends the packets in P 1 and P 3, and R sends the packets in P 2. Note that P 1 includes the syn packet, P 2 includes the synack packet, and P 3 includes the ack packet. We have to show that for each message m such that Transmit S (m) occurs before S sends the ack packet, Deliver R (m) can be appended after R receives the ack packet (subject to the constraint that no Req-Dis event occurs). R's variable, seq R, holds the largest sequence number it receives from S in an incarnation. When R sends the synack packet it selects a new ISN. By Lemma 5.14, if Recv R (ack) occurs, state R = opening and oseq ISN R, then the ack packet is valid. If R receives a valid ack packet for the rst time, then Con R occurred, and R can deliver any messages it received. That is, messages for which the Transmit S event occurred before S sent the syn or ack packets. Therefore, when R receives the ack packet, R enters an established state. The variable state R is assigned the value established after R receives a valid ack packet for the rst time, which implies the lemma. 28

10 Initialization: reset-var S Req-Con S : request-con S Program for S Recv S (seq,oseq,synack): if ISN S 6= 0 then if (state S = opening) and (oseq = ISN S ) then connect S (seq) send-packet S (seq,ack) else if seq > seq S 6= 0 then send-packet S (seq,dis S ) seq S := seq else send-packet S (seq,rst) Recv S (seq,oseq,dis R ): if ISN S = 0 then send-packet S (seq,rst) else if ((state S = opening) and (oseq ISN S )) or (seq > seq S 6= 0) then send-packet S (seq,dis S ) seq S := seq Req-Dis S : request-dis S Recv S (seq,oseq,disack): if seq > seq S 6= 0 then reset-var S Dis S Step: step S Initialization: reset-var R buer := empty Program for R Recv R (seq,oseq,syn): if seq > seq R then if seq R = 0 then request-con R (seq) else reset-var R Dis R request-con R (seq) Con R : send-packet R (null,synack) ISN R := seq.num Recv R (seq,oseq,ack): if (state S = opening) and (oseq = ISN R ) then state R := established seq R := seq Req-Dis R : send-packet R (null,dis R ) state R := closing if ISN R = 0 then ISN R := seq.num Recv R (seq,oseq,dis S ): if seq > seq R then send-packet R (seq,disack) if oseq ISN R 6= 0 then reset-var R Dis R Recv R (seq,oseq,rst): if seq > seq R then reset-var R Dis R Step: step R Figure 9: Three-way handshake oblivious 27 unbounded memory protocol

11 lished state after S Recv R (p 1 ),: : :,Recv R (p k ) 2. Therefore, Deliver R (m) can be appended to S Recv R (p 1 ),: : :,Recv R (p k ) 2. Finally, consider the schedule S 1 Recv R (p 1 ),: : :,Recv R (p k ) 2. Since R's state after S 1 is the same as after S, it follows that Deliver R (m) can be appended to S 1 Recv R (p 1 ),: : :,Recv R (p k ) 2. However, this Deliver R (m) has no matching Transmit S (m), which is a violation of IM3, the message grouping condition. 5.3 A Three-way Handshake Oblivious Protocol We now present a three-way handshake oblivious protocol for establishing a connection. A three-way handshake overcomes R's lack of knowledge about previous incarnations with S as follows: when R receives an ICP sequence in a closed state with sequence number x, it sends a request for conrmation of x to S with its own sequence number y; if a valid conrmation of x (which carries y) is received from S, R can safely enter an established state and deliver messages to its host. The protocol is oblivious since it only relies on the fact that the values of the counters (maintained by the nodes) increase with time. It does not depend on the counters growing in some continuous manner, or any other assumption on the value of the counter. Therefore, S and R need not retain connection-specic information between incarnations. Recall from the introduction to this section, that in the case in which R has several connections with other nodes, R employs the same counter for all connections. Therefore, it is important that the protocol does not rely on the initial value of the counter, which is inuenced by all the connections of R. Note that the nodes do not return to a known initial state after disconnecting, since in this case there is no connection management protocol [1]. In detail, the protocol works as follows. When R receives a syn packet, if it is in a closed state then it outputs Req-Con R. If R is in an opening or established state then it disconnects the current connection and outputs Req-Con R if the syn packet is the most recent packet to be sent to R. R remains in an opening state, since the connection could have been requested by a retransmission of a syn from a previous incarnation. If S is in a closed state then an incoming synack packet means that R is connected due to a retransmission of a syn and therefore it sends a rst packet to cause R to disconnect. If S is in a closed state when receiving a dis R packet, then S sends a rst packet to cause R to disconnect from a false connection. Since S and R do not retain information about the connection between incarnations, seq S and seq R 26

12 S S: Req-Con S S: Req-Con S p 1 pk p 1 pk R: R: Req-Con R Con R Req-Con R Con R (a) (b) Figure 8: The schedules used in the proof of Theorem 5.11 are sent (see Figure 8(a)). Let S be with all events at R removed; in particular, if Recv R (p i ) occurs in, it does not occur in S. That is, we delay the all Recv events until after S sends the packet p k. Since is ping-pong, S does not receive any packet from R until after it sends the packet p k (see Figure 8(b)), and therefore, S is a schedule, Clearly S Lose(p 1 ),: : :,Lose(p k ) is a schedule. By IM6, there exists an extension 1 of S Lose(p 1 ),: : :,Lose(p k ) with no Transmit S (m) events, in which Deliver R (m) occurs. Note that the packets p 1 ; : : :; p k are not delivered in 1. Since the network is non-fifo and the sender and receiver are in the same states after S as they are after S Lose(p 1 ),: : :,Lose(p k ), it follows that S 1 is also a schedule. Furthermore, the packets p 1 ; : : :; p k are in transit after S 1. By IM5, there exists an extension of S 1 with no Lose events whose restriction to host actions is Req-Dis S Dis X Dis Y (where X and Y are either S or R but not equal). Furthermore, we can assume that ends with suciently many Send events to empty the outgoing packet queues. The packets p 1 ; : : :; p k are still in transit after S 1. We now show the existence of a reference schedule in which R is in state q R at the beginning of the rst incarnation in an execution, and the rst packets it receives are p 1 ; : : :; p k. Since p 1 ; : : :; p k are initial control packets and do not belong to previous incarnations, R outputs Req-Con R and delivers m upon receiving them. We then use the reference execution and 1 to construct an execution which violates IM3. Let q R be R's (closed) state after S 1. Since the protocol is oblivious, q R 2 Q init. This implies the existence of a nite schedule without host events, such that R is in state q R after. Obviously, S Recv R (p 1 ),: : :,Recv R (p k ) is a schedule. Since there are no packets in transit initially, p 1 ; : : :; p k are the rst packets which R receives, and Con R is an input, there exists an extension 2 of S Recv R (p 1 ),: : :,Recv R (p k ) whose restriction to R's events is Req-Con R Con R. Since the protocol is two-way handshake, R is in an estab- 25

13 ICP sequence (which contains a message m) which was sent in a previous incarnation. Since R is in a closed state when it receives the sequence, and the protocol is only two-way handshake, R enters an established state and delivers m when it receives the ICP sequence. Since m was transmitted in a previous incarnation, this yields a contradiction which proves the theorem. To present the details of the proof, we need to formally dene protocols which do not maintain connection-specic information between incarnations, but do not necessarily return to a xed state when in a closed state. Let Q init be the set of R's states that appear in all executions which do not contain host actions. Let Q dis be the set of states which R enters after outputting Dis R, in all possible executions of the protocol. A protocol is oblivious if Q dis Q init. Intuitively, this means when R disconnects, it enters a state which is reachable without ever having a connection with S. That is, R does not \remember" any connection-specic information when it disconnects. For example, if R maintains a local counter which is incremented by some local action, then any value of the counter should be attainable without any connection with S. This describes the situation in which R has connections with several hosts, and it derives sequence numbers for packets used in all connections from the same counter. Since the counter can be incremented by actions related to other connections and without any host actions with respect to S, we can consider the counter-incrementing actions as internal (with respect to the connection with S). Theorem 5.11 There is no two-way handshake oblivious connection management protocol for non-duplicating networks. Proof: To prove the theorem, we \steal" an ICP sequence from a reference schedule, which \contains" a message m transmitted by S. The ICP sequence is delivered to R after both nodes disconnect. Since the protocol is oblivious, R initiates its connection establishment procedure (i.e., outputs Req-Con R ). Since the protocol is two-way handshake, R delivers the message m to its host when Con R occurs, thus violating the message grouping condition. The details follow. Assume, in contradiction, that a two-way handshake oblivious protocol for connection management exists. Consider a ping-pong schedule 0 with no Lose events whose restriction to host actions is Req-Con S Transmit S (m) Req-Con R Con R Deliver R (m) Con S, for some message m. Such a schedule exists since Req-Con S is an input and can happen any time; Transmit S (m) is an input; IM5 implies that Req-Con R occurs; Con R is an input; IM6 implies that Deliver R (m) occurs; IM5 implies that Con S occurs. Assume S sends the ICP sequence p 1 ; : : :; p k from the beginning of 0 (after Req-Con S Transmit S (m) occur). Let be the prex of 0 that ends just after the packets in p 1 ; : : :; p k 24

14 We have shown that if the last incarnation does not include a Con S event, then it is complete. If a Con S event exists, and there are no Req-Dis events, then it is open, and if Req-Dis events exist, it is complete. Thus, the last incarnation of a fair schedule is either open or complete. In order to show that the protocol is two-way handshake, we show that the state variables of S and R are updated correctly. The only interesting case in verifying that state S and state R correctly partition S's and R's states according to the denitions, is when state R holds the value established. Lemma 5.9 If state R = established, then R is in an established state. Proof: Consider a schedule of an incarnation. Partition the initial sequence of packets which are sent and received in an incarnation into subsequences P 1 and P 2, such that S sends the packets in P 1 and R sends the packets in P 2. Note that P 1 includes the syn packet sent by S, and P 2 includes the synack packet sent by R. We have to show that for each message m, if Transmit S (m) occurs before S sends the syn packet, then Deliver R (m) can be appended after R receives the syn packet (subject to the constraint that no Req-Dis events occur). By Lemma 5.3, if R receives a syn packet with a sequence number greater than seq R, then the syn packet is valid. Once R receives a valid syn packet, it outputs Req-Con R, and when Con R occurs, R can deliver any messages it received, e.g., appended to the syn packet; that is, messages for which the Transmit S occurred before S sent the syn packet are delivered after R receives the syn packet. Therefore, when Con R occurs, R enters an established state. The variable state R is assigned the value established only after Con R occurs, which implies the lemma. These lemmas imply: Theorem 5.10 There exists a two-way handshake unbounded memory connection management protocol for non-fifo unreliable networks. 5.2 Inexistence of Two-Way Handshake Oblivious Protocols We have shown that a two-way handshake connection management protocol exists if R retains connection-specic information between incarnations. (The protocol does not require S to retain any information.) We now prove that a two-way handshake connection management protocol does not exist if R does not retain any information about a specic connection between incarnations; that is, if R deletes any connection records when it disconnects. We show that without connection records in a closed state, R cannot distinguish between new copies and old retransmissions of ICP sequences. In the proof, we \confuse" R, by causing it to receive an 23

15 Lemma 5.2 and Lemma 5.5 imply: Lemma 5.6 The protocol satises the real-time correspondence condition (IM2). Lemma 5.7 The protocol satises the no unwarranted disconnects condition (IM4). Proof: Assume that Dis R occurs. We show that if Req-Dis S does not occur in an incarnation, then Req-Dis R occurs in the corresponding R-section. Consider an S-section and its corresponding R-section. By Lemma 5.3, R outputs Dis R as a result of a valid dis S packet sent in the corresponding S-section. By the code and Lemma 5.4, S sends the dis S packet only if Req-Dis S occurs or if it receives a valid dis R packet from R in the corresponding R-section. R sends the dis R packet only when Req-Dis R occurs, thus, if Req-Dis S does not occur then Req-Dis R occurs. Dene a mapping from Dis events to corresponding Req-Dis events as follows: if Req- Dis S occurs in an incarnation, we map Dis S and Dis R of the corresponding R-section to it; otherwise, we map them to the Req-Dis R event in the corresponding R-section. The mapping is well-dened and one-to-one, since a Dis S occurs only once in an incarnation, and Dis R occurs only once in an R-section. Lemma 5.8 In any fair schedule consisting of a nite number of incarnations, the last incarnation is either complete or open (IM5). Proof: Consider the last incarnation in a fair schedule with a nite number of incarnations. We show that it is either open or complete. By Lemma 5.7, a Dis S or Dis R event is output only as a result of a Req-Dis S event or a Req-Dis R event in the corresponding R-section. Therefore, the inexistence of Req-Dis events implies that there are no Dis events. Thus, if there are no Req-Dis events, then the last incarnation is open. Suppose a Req-Dis R event occurs. Then R sends a dis R packet to S. By the code and Lemma 5.4, when S receives a valid dis R packet or if Req-Dis S occurs, it sends a dis S packet to R. By the code and Lemma 5.3, R disconnects and sends a disack packet when it receives a valid dis S packet, and S disconnects when it receives a valid disack packet. Therefore, if a Req-Dis event occurs, S and R eventually disconnect. We now show that if the last incarnation of a fair schedule contains no Con S event, then it is complete. Consider the case in which there is no Con S event in the last incarnation. Then by the code, either a Req-Dis S event occurs, or S does not receive a valid synack packet. In the second case, since a Con R event does not occur, by HA2, a Req-Dis R event occurs and S it receives a dis R packet. In both cases, S repeatedly sends a dis S packet to R. Therefore, if Con S does not occur, then a Req-Dis event occurs, and as shown above, the incarnation is complete. 22

16 Lemma 5.2 causec is one-to-one. The next lemmas show that S and R only acknowledge valid packets. Recall that a packet received by node X in an incarnation is valid, if node Y sent it in the corresponding Y-section. (X and Y are both either S or R but not equal.) Lemma 5.3 Assume S sends a packet p with sequence number seq in an incarnation and Recv R (p) occurs. Then p is valid if and only if seq > seq R. Proof: When R receives the rst syn packet (which is also the rst packet it receives in the incarnation), it updates seq R. Since seq > seq R, it follow that p was sent after the rst syn packet. Therefore p was sent in the corresponding S-section, and is valid. The \only if" direction of the lemma is proved similarly. The corresponding lemma for S is slightly more complicated. Lemma 5.4 Assume S receives a packet p, with a sequence number seq and a remote node sequence number oseq, in an incarnation. Then p is valid if and only if oseq ISN S or seq > seq S 6= 0. Proof: Let Recv S (p) occur in incarnation i, where p is a synack packet. Suppose oseq ISN S when Recv S (p) occurs. Since the sequence number of the syn packet which S sends in incarnation i is ISN S, p is sent by R after R receives a syn packet sent in the current incarnation. Therefore, p is sent after R outputs Req-Con R in the corresponding R-section. Thus, according to the denition, p is valid. The \if" part of the lemma is proved similarly. Consider now dis R and disack packets. Immediately after Req-Con S occurs in incarnation i, state S is assigned the value opening and seq S holds the value 0. By the code, at that point S only acknowledges a packet if state S = opening and the packet's oseq number is greater or equal to ISN S. By the same arguments as above, S only acknowledges valid dis R packets. Suppose p 0 is the rst valid packet to be acknowledged by S in incarnation i. Then when S receives p 0, it updates seq S to hold the sequence number of p 0. Suppose that seq > seq S 6= 0 when Recv R (p) occurs, where p is a dis R or disack packet. This implies that p was sent by R after p 0, and is therefore valid. The \if" part of the lemma is proved similarly. Lemma 5.5 Consider a sequence of host events in an incarnation. If we restrict to Req-Con and Con actions, then the sequence up to Con S is Req-Con S Req-Con R Con R Con S, where Req-Con R and Con R occur in the corresponding R-section. Proof: By the denition of a corresponding R-section, if Req-Con R occurs in the corresponding R-section, then it follows Req-Con S. Suppose Con S occurs in an incarnation. By Lemma 5.4, S receives a valid synack and by the code, Con R occurs in the corresponding R-section. Therefore, Con R in the corresponding R-section precedes Con S. Thus, the protocol satises the real-time overlap condition. 21

17 Initialization: reset-var S Req-Con S : request-con S Program for S Recv S (seq,oseq,synack): if (state S = opening) and (oseq = ISN S ) then connect S (seq) Recv S (seq,oseq,dis R ): if ((state S = opening) and (oseq ISN S )) or (seq > seq S 6= 0) then send-packet S (seq,dis S ) seq S := seq Req-Dis S : request-dis S Recv S (seq,oseq,disack): if seq > seq S 6= 0 then reset-var S Dis S Initialization: reset-var R buer := empty Program for R Recv R (seq,oseq,syn): if seq > seq R then request-con R (seq) Con R : send-packet R (null,synack) state R := established Req-Dis R : send-packet R (null,dis R ) state R := closing Recv R (seq,oseq,dis S ): if seq > seq R then send-packet R (seq,disack) reset-var R seq R := seq Dis R Step: step R Step: step S Figure 7: Two-way handshake unbounded memory protocol 20

18 is not connection-specic, since the same counter is used for all connections. A host may have connections with many other hosts over a long period of time, and it can become prohibiting to keep connection records indenitely on each potential or past connection. Therefore, erasing connection records between incarnations implies a signicant saving in space. 5.1 A Two-Way Handshake Protocol We rst present a simple two-way handshake connection management protocol, which assumes that the nodes have unbounded memory and the receiver preserves connection records between incarnations. In the protocol, R retains at all times the largest sequence number it received from S. Each node, S and R, holds an unbounded counter from which increasing sequence numbers are derived. Thus, the nodes can lter out retransmission and duplication of packets, by simply comparing a received sequence number with the largest one known to them. Therefore, an initial control packet (syn) sent in a previous incarnation can be rejected by R. R can enter an established state immediately after it receives a valid syn packet, and therefore our protocol is two-way. The protocol appears in Figure 7, and it employs the procedures presented in Figure 6. In more detail, R remembers the largest sequence number it received from S in seq R. When Req-Con S occurs, S sends R a syn packet. R validates the syn packet by comparing the sequence number of the syn packet with seq R, output Req-Con R, and enter an established state when Con R occurs. S can validate R's response to its syn packet, by comparing the number oseq, which R appends to its synack packet with ISN S. When S receives the synack packet, it can output Con S and enter an established state. Therefore, this is a two-way handshake protocol. The value of S's variable, ISN S, is determined once in each incarnation, when Req- Con S occurs. Since ISN S is assigned the sequence number of the syn packet, and since sequence numbers never decrease, the value of ISN S in an incarnation is greater than its value in previous incarnations. In order to formally prove the correctness of the protocol, we have to show that it satises IM1, IM2, IM4, and IM5. It is easy to verify that S and R preserve the following restriction of the host events, by examining their state transitions: (and similarly for R), which implies: Req-Con S [Con S ] [Req-Dis S ] Dis S Lemma 5.1 The protocol preserves the well-formedness of the host interface (IM1). We dene a mapping from S-sections to R-sections. Let causec(s-sec) be R-sec, if R-sec is the R-section which immediately follows the rst Recv R (syn), such that syn was sent in S-sec. Clearly: 19

19 In addition, the incarnation-independent data transfer protocol should satisfy the following assumptions: 1. It has at-most-once semantics. 2. It operates on a non-fifo unreliable network. 3. it is specied so that each event has preconditions and an action; if the preconditions are satised, then then action is enabled. Let established X be the set of established states of node X. The values of ISN X and ISN Y are appended to each packet sent, and the following changes are made in the transition function of node X: For each event e that is not a Recv X event, add state X 2 established X to the preconditions. A Recv X (p) event e becomes a Recv X (p; isn 1 ; isn 2 ) event e 0, with action(e 0 ) being: if state X 2 established X and isn 1 = ISN Y, and isn 2 =ISN X, then action(e). An incarnation-specic data transfer protocol and a connection management protocol, which satisfy the conditions stated above, can be composed to obtain an incarnation management protocol. A proof that the composed protocol is correct appears in [14, Thm. 5] and [16, Thm. 5]. 5 Nodes with Unbounded Memory In this section, we consider the case of nodes with unbounded memory. We show that if R retains information about the connection between incarnations, then a two-way handshake protocol exists. We show that if no information about the connection is kept by R across incarnations, but R does not return to a known initial state, then a two-way handshake protocol does not exist, whereas a three-way handshake protocol exists. These results assume that the network is non-fifo and unreliable. If the nodes do not retain information between incarnations and return to a xed state after disconnecting, then an incarnation management protocol exists if and only if the network is either FIFO or reliable [1]. The dierence between maintaining connection-specic information and retaining some information between incarnations is best illustrated by counter-based protocols. In these protocols, a node employs an unbounded counter, whose value does not decrease, to derive unique sequence numbers. The counter is part of the node's state and does not return to zero when the node disconnects. However, the node erases connection-specic information, e.g., the largest sequence number it received from the other node, when the connection is closed. The counter 18

20 Procedures for S reset-var S : buer := empty seq S := 0 ISN S := 0 state S := closed send-packet S (seq,type): get(seq.num) if seq 6= null then buer := (seq.num,seq,type) else buer := (seq.num,seq S,type) request-con S : state S := opening send-packet S (null,syn) ISN S := seq.num connect S (seq): remove syn from buer if dis S not in buer then Con S state S := established seq S := seq reset-var R : seq R := 0 ISN R := 0 state R := closed Procedures for R send-packet R (seq,type): get(seq.num) if seq 6= null then buer := add (seq.num,seq,type) else buer := (seq.num,seq R,type) request-con R (seq): state R := opening Req-Con R seq R := seq request-dis S : state S := closing get(seq.num) if syn in buer then add (seq.num,seq S,dis S ) to buer else buer := (seq.num,seq S,dis S ) step S : if buer not empty then Send S (rst packet in buer) step R : if buer not empty then Send R (rst packet in buer) Figure 6: Common procedures used in all protocols 17

21 We have the following procedures for S and R: reset-variables: employed at the initialization of the protocol and each time the nodes disconnect an incarnation. request-con: employed during connection establishment; the nodes enter an opening state, S selects a new ISN and sends a syn packet whereas R outputs Req-Con R. connect S : employed by S when a connection is established; S enters an established state. send-packet: a new sequence number is assigned to the packet, and it is placed in the outgoing messages buer. step: send the rst packet in the buer to the remote node. request-dis S : employed during the disconnection procedure; S enters a closing state and sends a dis S packet. Figure 6 includes the code of the procedures, using the following conventions. Each section of code is preceded by the name of the input action that invokes it (initialization is presented the same way for uniformity). For simplicity, each output action is indicated as occurring immediately in response to the appropriate input. Strictly speaking, in order to conform to the I/O automaton model, it would be agged as enabled and would occur later assuming nothing occurs to disable it (e.g., if Req-Dis R occurs, then no pending Deliver R (m) should occur if well-formedness is to be maintained). Incorporating a Data Transfer Protocol: An incarnation-independent data transfer protocol assumes that the connection between two hosts is correctly initialized, and that the hosts are in an established state [16]. Several such protocols exist, e.g., alternating bit, slidingwindow, go-back-n (cf. [20]). In an incarnation-specic data transfer protocol the packets are parameterized with the incarnation identiers (e.g., ISN), i.e., the packets carry an identication of the incarnation they were sent in. We now show how to transform a given incarnationindependent data transfer protocol into an incarnation-specic data transfer protocol, so that it can be incorporated into a connection management protocol, to obtain an incarnation management protocol. This approach is based on [16], but we discuss its details since our specication of incarnation management is somewhat dierent from [16]. A connection management protocol should satisfy the following assumptions in order to allow a data transfer protocol to be composed: 1. When a Req-Con X event occurs, node X selects an initial sequence number, ISN X, which identies the incarnation. 2. Suppose node X receives a packet p in an established state; if p contains two incarnation identiers, isn X and isn Y, such that isn X =ISN X, then isn Y is the connection identier of the remote node Y in the corresponding Y -section. 16

22 S: Req-Con S Con S... Dis S syn synack diss disack R: Req-Con R Con R... Dis R Figure 5: A simple incarnation Req-Con R. Note that the denition does not indicate how to validate a packet; this depends on the specic assumptions made on the nodes and the network. A node X receives a packet p for the rst time in an incarnation in the rst occurrence of Recv X (p) in the incarnation (X is either S or R). In our protocols, packets are acknowledged when they are received for the rst time, and retransmissions are discarded. In our protocols, an incarnation proceeds as follows (see Figure 5). When Req-Con S occurs, S repeatedly sends a syn packet until receiving an acknowledgment. S records its initial sequence number in a local ISN S variable. When R receives a valid syn packet for the rst time, it outputs Req-Con R ; when Con R occurs, R repeatedly sends a synack packet. When S receives a valid synack for the rst time, it outputs Con S. S and R only release incarnations if explicitly requested to do so by either host. When Req-Dis R occurs, R sets its buer to the packet dis R. When S receives a valid dis R packet or a Req-Dis S event occurs, it sets its buer to the packet dis S. When R receives a valid dis S packet for the rst time, it outputs Dis R and sends a disack packet. When S receives a valid disack packet for the rst time, it outputs Dis S. S and R maintain the following variables. Both nodes has a counter from which sequence numbers for packets are derived. The function get(seq.num) increments the counter and assigns its new value to the variable seq.num. Each node uses a buer to hold packets to be retransmitted periodically (syn, synack, ack, dis S, dis R, disack, rst). At S, seq S holds the largest sequence number received from R; similarly, seq R holds at R the largest sequence number received from S. Dierent protocols maintain these variables somewhat dierently; the specic details are described at the relevant places. Packets have three header elds: 1. seq { the sequence number of the packet. 2. oseq { the largest sequence number sent by the other node. 3. type { the packet type: syn, synack, ack, dis S, dis R, disack, and rst. 15

23 For the base case, let 0 be the execution consisting of an initial conguration, and let T 0 = be the set of the packets in transit. For the ith iteration (i > 0), suppose i ends with S and R in states q 0 S and qr, 0 respectively, and the packets in T i are in transit in the last conguration of i. If S(q 0 S ; q0 ) R 6 T i (there are still packets in S(q 0 S ; q0 R ) that are not in transit), then let p be some packet from S(q 0 S ; q0 R) n T i, and denote T i+1 = T i [ fpg. By Lemma 3.1, there exists an execution fragment p such that packets in T i+1 are in transit at the end of i p. Denote i+1 = i p. Note that S and R are in closed states after i+1, and if Transmit S (m) occurs, then a matching Deliver R (m) occurs. We claim that eventually S(q 0 S ; q0 R) T l, for some l. Assume otherwise, and consider the execution which is the limit of f i g 1 i=0. Since the size of the memory of S and R is bounded, there exists a pair of closed states which appears innitely many times in the execution. Thus, there exists l 1, such that at the end of l, S is in state q 00 S and R is in state qr, 00 and S(q 00 S ; q00) R T l. If S(q 0 S ; q0 R) T l (all the packets in S(q 0 S ; q0 R) are in transit), then let S(q 0 S ; q0 R) = fp 1 ; : : :; p k g. Since the network is non-fifo, and there is no bound on message delivery time, the result of applying Recv R (p 1 ),: : :,Recv R (p k ) to l, is an execution, and it has an extension in which only R takes steps that ends with Deliver R (m). This last Deliver R (m) has no matching Transmit S (m), which is a violation of IM3, the message grouping condition. 4 A Generic Connection Management Protocol In addition to impossibility results, we present several connection management protocols in the rest of the paper, all based on the same generic protocol. In this section, we present the generic protocol and also discuss how to combine a data-transfer protocol with a connection management protocol to obtain an incarnation management protocol. We start with a few denitions. Partition the sequence of packets sent in an incarnation into sub-sequences P 1 ; P 2 : : :, such that the packets in P i are sent by S if i is odd and by R if i is even. We call the packets in P 1 the initial control packets (ICP). Intuitively, the initial control packets the rst packets that S sends in its handshake protocol after Req-Con S occurs. A packet received by node X is valid if it is sent by Y in the corresponding Y-section (X and Y are both S or R but not the same). If p is an initial control packet, then it is also valid if it is received after the Dis R event of the preceding R-section. Informally, we would like an initial control packet to be considered valid, even though it is received before R outputs 14