NSFNET woe: causes and consequences

02-Oct-87 01:05:04-UT

might have led to the earlier problems over the weekend. The reason some
ateways could work psc-gw anyway was that they had captured the virtual
circuits due to significant traffic loads and frequent connection attempts. My
tests were from lightly loaded host ports which couldn't break into the mayhem
which must be going on in the psc-gw 5250 board.

I have looked at the 5250 driver code, which is pretty simplistic on how it
manages the virtual-circuit inventory. It appears now of the highest priority
that a more mature approach be implemented in the driver, so that
virtual-circuit resources can be reclaimed on the basis of use, age, etc. In
principle, this is not very hard, but would have to be done quickly.
Meanwhile, I suspect a lot of X.25 client gateways (not just NSFNET) are or
soon will be very sick indeed. Note that reclamation requires that open
circuits to one destination may have to be closed abruptly, which can result
in loss of data, then reopened to another destination. Under thrashing
conditions where the load is spread over lots of other gateways and virtual
circuits are flapping like crazy, the cherished ARPANET reputation for
reliable transport may be considerably tarnished.

Those of us who have pondered the wisdom of underlaying X.25 virtual circuits
beneath a connectionless service have repeatedly said that this kind of
problem was certain to occur sooner or later. There are now about 200 gateways
and 300 networks out there. As the ARPANET evolves toward a gateway-gateway
(many-to-many) service, rather than a host-gateway (few-to-many) service, the
problem can only get much worse. I personally believe the ARPANET architects
and engineers, as well as the host and gateway vendors, must quickly come to
solid grips on this issue. Our most precious resource may not be packet
buffers, but connection blocks.


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