Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  X.25 problems
Message-ID: <8710162330.aa10892@Huey.UDEL.EDU>
Date: Fri, 16-Oct-87 23:30:51 EDT
Article-I.D.: Huey.8710162330.aa10892
Posted: Fri Oct 16 23:30:51 1987
Date-Received: Sun, 18-Oct-87 09:30:41 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 15

Ken,

I'm not particulary persuaded by the "non-spec" argument. Let them eat
resets. Holding a VC in reserve may be a useful workaround, but it
does not get at the heart of the problem. Granted, if the VC pool
were exhausted in the PSN, there is not much you can do; however,
if the pool were exhausted in the host, a incoming-call packet
could still be passed to the firmware, which could then close a
VC on its own. The same trick could work in the PSN, which would
close the VC with a dirty-smelly reset.

Aitcha glad we have X.25 to bash? We could always gang up on the TCP
reliable-close issue...

Dave