Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!sdcsvax!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  X.25 problems
Message-ID: <8710141659.aa23865@Huey.UDEL.EDU>
Date: Wed, 14-Oct-87 16:59:35 EDT
Article-I.D.: Huey.8710141659.aa23865
Posted: Wed Oct 14 16:59:35 1987
Date-Received: Sat, 17-Oct-87 05:32:37 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26

Lars,

Non-core gateway daemons, the only ones likely to use ACC interfaces, do
NOT ping gateways other than the three corespeakers and then only with
EGP, which has intrinsic provisions to limit the polling frequency.
The only other polling-type protocol likely to appear over ARPANET paths
is the Network Time Protocol (NTP) spoken by a few gateways, but not
PSC to my knowledge. Therefore, I must conclude that whatever the cause
of vast numbers of ARPANET host pairs with one end at PSC it is due to
normal traffic spasms. Note that the so-called extra-hop problem due
to incomplete knowledge at the corespeakers can create a non-reciprocal
situation where two circuits, not one, are required between certain
host pairs.

What I am not hearing in your explanation on how the ACC interface handles
VC allocation is what happens when all VCs are fully allocated. I have
heard from PSC staff that the driver complains in messages to the operator
when an attempt is made to open another VC past the 64-circuit max. I
would assume the polite driver would keep an activity with entries for
each active VC and clear the oldest/least-used to make room for the next
one. I would assume this would also happen if an incoming call request
appeared from the network and all VCs were committed. Further, I would
assume both the PSN and ACC would do this kind of thing, no matter what the
timeouts chosen.

Dave