GBELING@A.ISI.EDU.UUCP (04/01/87)
hello collegues, we are running here a connection to the arpanet using the PTT's datex-p (i.e. x.25) as a transatlantic transport medium. To do so we have connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams into x.25-packets. Up to some time ago this worked fairly well and reliable and fast (up to 2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway in boston. Since heavy congestion occurs in the arpa/milnet we have a special poroblem: If for some reason the x.25 virtual connection is idle for 2 minutes the van-gateway closes the connection and cannot reopen it: we have to do this because we have to pay the x.25 charges. In the case that we are reading data from the other side and have acked all segments properly the connection is broken and our TCP has to wait until the user timeout cancels the (tcp) connection on our side - what the far-end tcp does we do not know. This happens sometimes when the far tcp does not do retransmissions or so slowly that in the intermediate time x.25 cuts us off. Ip is developed for the case that the underlying connection is a permannt available one i.e. no open or close needed ! If we look to the protocol suite properly there is no way to signal the broken x.25 connection to the user of telnet so that he can react. therefore we think of to reopen the x.25 VC automatically when the other side closes it. this has the disadvantage that we reopen it also when the tcp-connection has finished because x.25 does not know something about tcp-connections. The peculiar problem is that we have to pay for each OPEN of a VC (and afterwards for the time it is open: 5pfg for each open, 15pfg per minute). The problem will become even more complicated when several tcp-connections are multiplexed onto one x.25-virtual circuit or there are several x.25 VCs open at the same time. How did others solve the problem to reopen broken x.25VCs when a tcp-connection to close the connection? thanks gerd beling
Mills@UDEL.EDU.UUCP (04/04/87)
Gerd, I assume the X.25 connection is broken somewhere in the public-net path, perhaps in either of the national X.25 nets or in the X.75 gateway(s). To break that after two minutes of inactivity sounds broken in the extremus, especially if the restoration costs real Geld. On the other hand, your opens are cheap, about equivalent to twenty seconds of connect time, so maybe things aren't that bad, at least if the reset/open can be made transparent to your TCP/TELNET connection. Come to think of it, if the MILNET/ARPANET congestions is as fierce as you report, it might be cheaper to encapsulate IP datagrams as fast-select packets, rather than go through the complete virtual-circuit clankery. This might be a fun puddle to go wading in. Lemme see, at twenty (roundtrip!) packets per Mark, you would break even at about seven minutes. Maybe not too bad under current conditions... While it is in principle possible to do all kinds of things which might convey the connection-closed state at the VAN gateway to the end systems, I suggest this would not be very useful if only to stimulate a re-open. If it really does come down to keeping the connection open, the VAN driver could be modified to send ICMP echoes to its peer just often enough to reset the VAN timers. Be advised you did not hear me say this, for I am not present and will instantly disavow any attribution of such nonsense to mine lips. Now, I hope that will keep the truthspeakers from my throat. Yes, and stop the ICMP echoes after a period when no other traffic is present. [Gaggg] Dave