Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!Sun.COM!melohn
From: melohn@Sun.COM (Bill Melohn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Santa's PSN 7 status
Message-ID: <8801050611.AA06380@sluggo.sun.com>
Date: 5 Jan 88 06:11:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 28

After catching up on my mail over the holidays, it appeared as though
everyone now believes the problems related to "stuck VCs" have been
fixed. However, when I drop my host Sun.COM back to the non-patched
version of our kernel (the one that doesn't attempt to kludge around
the BBN bug by always sending an RR with each packet) I still notice
"stuck VCs", easily reproduceable on one-way VCs between us and
machines on IMPs 11 and 68. Either the latest version of Andy's patch
has not been fully deployed, or it too does NOT fix the problem.

On the 128 byte packet problem; we are in the process of getting
packet traces from the ARPAnet to see exactly what the packet traffic
looks like when we appear to lose the 128 byte packets. I should point
out that this too only appears to happen between us and 1822 hosts
running the new end to end; I suspect that we will find another PSN
7.0 bug at the root cause of this problem. More as soon as I have
the traces.

We are in the process of testing a new version of our software to
handle multiple incoming VCs from the same IP host. Because multiple
VCs are used for X.25 loopback by the PSN under the new end to end, we
feel we have little choice but to support them. I do feel that
requiring this support without any warning that such support would be
required by the new end to end was a mistake, one that our mutual
customers may have to live with until we can test and manufacture
a new software release. It also conceptually wastes VCs, which are
limited resources in many X.25 implementations, because it encourages
in many more cases two or more one-way VCs between host pairs where
a single VC would have existed under the old end to end.