NIC@SRI-NIC.ARPA (DDN Reference) (01/07/88)
It has been determined that some ARPANET host sites have had difficulty cutting over to the new End-to-End protocols (PSN 7.0). For this reason, a cut back to the old End-to-End protocols is being considered for Sunday, 16 January. Site representatives who feel this will cause disruption of network services, user software changes, or need more time to prepare for the cutover, are asked to contact Annette Bauman, ABauman@DDN1.ARPA, (703) 285-5445/(AV) 356-5445 or Bobby Powell, SCCMGR@DDN1.ARPA, (703) 285-5228/(AV) 356-5228. If no response is received by 14 January, we will proceed as planned. -------
NIC@SRI-NIC.ARPA (DDN Reference) (01/19/88)
The PSN 7.0 New End-to-End Deployment to the ARPANET
is now complete. The ARPANET is permanently running the
New End-to-End protocol, with no cutback to the Old End-to-End
anticipated, except if emergency conditions should arise. A
message from Ken Pogran describing the recent corrective actions is
"attached".
Minor problems are still being cleaned up, but none, we believe,
which seriously impact any users. Should problems arise or
persist, however, please continue to send messages to
ARPAUPGRADE@BBN.COM, call the BBN Hotline at (800) 492-4992 or DCA
at (703) 285-5445/5228.
We thank everybody for their past and continued cooperation
in this endeavor.
Ken Turkewitz (BBNCC), Russ Mundy (DCA), Annette Bauman (DCA)
------------------message from Ken Pogran---------------
Here's the latest on the trials and tribulations of the ARPANET
Beta Test of PSN 7 and the New End-to-End Protocol:
In a message entitled "Santa's PSN 7 status" that I sent on
23 December, I announced that BBN had found the solution to the
"stuck VC" problem afflicting Sun hosts connected to the ARPANET
with X.25, and that we had also determined that the "128 byte"
problem was a host problem. Well, Santa turned out to be a
Grinch, because we were dead wrong on both counts.
However, both problems have now (cross your fingers!) been fixed,
along with a few others. The problems (and their resolutions)
are as follows.
1. "Stuck VCs." See my previous messages for a detailed
description of the problem. In essence, asymmetric traffic
flows originating from an 1822-connected host and destined to
an X.25-connected host could result in a "deadly embrace",
with the destination host and the PSN each waiting for the
other to do something. Although this case sounds obscure, it
in fact corresponds to traffic flows from the MILNET (and
perhaps some other networks) across 1822-connected gateways
to the ARPANET and then to X.25-connected hosts -- a common
situation. This problem specifically afflicted Sun hosts,
due to implementation choices Sun made in their X.25 code.
After much discussion, our designers were convinced
that Suns's implementation choices were in fact reasonable (our
apologies to Bill Melohn at Sun for our being hard over in
the other direction at first) and that the PSN's behavior
needed to change to more closely resemble that under the Old
End-to-End protocol (which obviously did not result in a
deadly embrace).
Accomplishing the desired change in behavior in the PSN
turned out to be a lot more complex than we thought; we went
through several iterations of "fixes" each of which we
thought would do it but each of which turned out to be
incomplete in handling some obscure case or other and was
therefore incorrect. (The 1822-X.25 interoperability module
in the PSN is, in effect, a level 3 protocol converter
tightly integrated into the End-to-End Protocol machinery,
and it has all the complexity that protocol converters
typically have. The ultimate "fix" involves a design change
rather than a simple coding fix; the design issues are
probably worth an RFC at some point.) Last weekend we bit the
bullet and designed and coded a much more complex change,
which was tested at selected nodes early this week, with
complete success. The "stuck VC" dragon has, we believe,
finally been slain. Our apologies to everyone on the ARPANET
with an X.25-connected Sun who's been waiting for a fix to
this problem, and our thanks to Bill Melohn of Sun and Bob
Enger of Contel for their patience, which we sorely tried.
2. The "128 byte" problem. X.25 packets of length 128 or
multiples thereof appeared to be "lost" under certain
circumstances. The circumstances under which such packets
were "lost" were, again, communication FROM an 1822-connected
host TO an X.25-connected host. Upon looking at the line
between a PSN and a Sun host with a datascope, we saw "pings"
of such packets going into the Sun, with no response from the
Sun, and concluded it was a Sun problem. Sun looked more
closely than we and noticed that the packet the PSN sent had
the "M" bit set, indicating this was one packet of a
multi-packet sequence, but the PSN never sent another packet.
This was, in fact, another PSN 1822-X.25 interoperability bug
which has now been found and fixed.
3. The HDH problem affecting Yale and Rice. There were several
bugs in the PSN 7 HDH interface code that kept Yale and Rice
off the air a good bit of the time since PSN 7 was deployed.
These bugs, too, have now been found and fixed.
-------jtn@potomac.ads.com (John T. Nelson) (01/21/88)
> The PSN 7.0 New End-to-End Deployment to the ARPANET > is now complete. The ARPANET is permanently running the > New End-to-End protocol, with no cutback to the Old End-to-End > anticipated, except if emergency conditions should arise. A > message from Ken Pogran describing the recent corrective actions is > "attached". > > Minor problems are still being cleaned up, but none, we believe, > which seriously impact any users. > > Ken Turkewitz (BBNCC), Russ Mundy (DCA), Annette Bauman (DCA) Our site is seriously impacted. Our machine (potomac.ads.com) is unable to talk to the ARPAnet (except sun.com which is an X.25 site like us, running the DDN software provided by Sun. I take it from the above message that BBN no longer feels the problem is with the 7.0 PSN software but rather with the sites. -- John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611 "Hi... My name is Hobbes. I'm the product of a malicious 5-year old's twisted and destructive imagination. Would YOU like to be my friend?"
pogran@CCQ.BBN.COM (Ken Pogran) (01/21/88)
John, On the contrary! We have you listed as a host afflicted by the "Stuck VC" problem, for which a fix was deployed to the "affected nodes" (it hasn't been distributed net-wide yet). If you're still not "on the air", then something's gone wrong that we will investigate. It's also not the case that BBN believes that the remaining problems are all site/host problems. We're working on several problems that aren't "show-stoppers", for which we and/or the sites have developed work-arounds -- the ECU problem mentioned by Charles Hedrick at Rutgers, for example. These are problems that had been put on the back burner while we worked to resolve the show-stoppers described in our previous messages. Ken Pogran
pogran@CCQ.BBN.COM (Ken Pogran) (01/22/88)
John, With regard to the problem you reported, being unable to communicate with 1822-connected ARPANET hosts (including gateways): It turns out that the PSN's "community-of-interest" word for your host was set incorrectly, which had exactly the effect you reported: the PSN allowed you to communicate with other X.25-connected hosts, but prohibited you from communicating with 1822-connected hosts. Our troubleshooter reports that we've corrected the problem, and that one of your folks has confirmed that you can now communicate normally with 1822-connected hosts. The "community-of-interest" word is a per-host configuration item in the PSN; unfortunately we can't tell how it came to be set wrong. Most likely it occurred in the (all-too-manual) process of setting up the PSN 7 configuration items based on the existing PSN 6 configuration. Our apologies. Ken Pogran