IP over x.25

1 Apr 1987 10:15-EST

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

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:46 GMT