Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!CCQ.BBN.COM!pogran
From: pogran@CCQ.BBN.COM (Ken Pogran)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  X.25 problems
Message-ID: <8710161321.AA11112@ucbvax.Berkeley.EDU>
Date: Fri, 16-Oct-87 08:36:45 EDT
Article-I.D.: ucbvax.8710161321.AA11112
Posted: Fri Oct 16 08:36:45 1987
Date-Received: Sat, 17-Oct-87 20:38:00 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35

Dave,

In your message Wednesday to Lars Poulsen of ACC you said,

    "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 imeouts chosen."

The PSN developers tell me that the PSN CAN'T initiate a clear of
an active (and non-idle) VC just to make room for the next VC as
that is a violation of the X.25 spec.  The DTE can, of course,
initiate a clear of VCs for any reason.

One thing we CAN do in the PSN is limit, from its side, the
number of active VCs with a host.  For example, if the PSN is
configured to not allow more than N VCs with a host because we
know that's a limitation in the host, the PSN would decline an
incoming call request for a host if it would be the N+1st active
VC with that host.  This might be desirable if the host's
receiving an incoming call request from the PSN that put it over
its limit would cause its software to hang or otherwise behave
badly instead of cleanly rejecting the incoming call.  Don't know
if this pertains to any behavior we're currently seeing in the
net, though.

Ken

P.S.  The developers also tell me that having an idle timer
"stretches" the spec.  I am NOT going to split hairs and get into
semantic discussions over when a VC is "active" and when it is
"idle!"