Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucbcad!pasteur!ucbvax!SRI-NIC.ARPA!NIC
From: NIC@SRI-NIC.ARPA (DDN Reference)
Newsgroups: comp.protocols.tcp-ip
Subject: ARPANET UPGRADE
Message-ID: <12367622776.28.NIC@SRI-NIC.ARPA>
Date: 18 Jan 88 17:40:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 93


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.
-------