An ARPANET update

Ken Pogran (
Tue, 15 Dec 87 19:01:04 EST

    host initiates the VC. It can arise when a host with a
   connection-less (i.e., 1822) interface initiates
    communication with a host with a connection-oriented (i.e.,
    X.25) interface and "the network" has to initiate the

    We believe that what's happening here is that the receiving
    host's X.25 isn't sending an RR to the PSN for the first data
    packet it receives when the PSN opens the VC. Under the New
    End-to-End Protocol, when going from an 1822-connected host
    to an X.25-connected host, the PSNs wait to see an RR for the
    first packet before subsequent packets are sent from the
    source PSN to the destination PSN (and a RFNM is returned to
    the originating 1822-connected host). Under the Old
    End-to-End Protcol, subsequent packets were sent as soon as
    the receiving host accepted the VC (up to the limit of the
    window); this could result in a RFNM being sent to the
    originating host before the destination host actually
    acknowledged the packet via an RR! (The different behavior
    of the New End-to-End was intended as a fix for what was a
    bug, or perhaps a "cheat", in the old design with respect to
    the meaning of a RFNM.)

    In the case of a symmetric traffic flow, an RR is typically
    piggybacked on a data packet. But, as was mentioned above,
    traffic flows involving Mailbridges frequently aren't
    symmetric. Typically, X.25 implementations send an RR after
    some brief timeout if there's no user packet going out over
    the VC on which to piggyback the RR. But if there is neither
    traffic nor a timeout, and no RR is sent, the flow will cease
    as described above.

    We're going to change the PSNs to behave as they did under
    the Old End-to-End in this regard, at least temporarily.
    This will give us time to work with implementors to resolve
    this issue.

2. The "pinging yourself" problem. We've found a timing bug in
    the PSN that is sometimes triggered when a host "pings"
    itself. Other situations can trigger it, but the timing of
    the sequence of events that occurs when some hosts ping
    themselves seems to be the most conducive to triggering the
    bug. The result is that the PSN doesn't acknowledge delivery
    of one or more messages to the host in question. We've found a
    race condition in the PSN code. A fix for this bug will be
    installed in the ARPANET within the next day or so.

3. The "multiple of 128 bytes" problem. Several people have
    reported a problem with packets apparently being dropped by
    the network when they are a multiple of 128 bytes (perhaps
    +/- a few?) in length. We are actively investigating this
    problem. Anyone with data or insight with regard to this is
    encouraged to contact Andy Malis ( or

4. The gateway at Yale has mostly been off the net since the
    cutover to the New End-to-End Protocol. They are the only
    gateway connected to the ARPANET via an HDH interface running
    at 9.6 kb/s, and are the only ones experiencing this
    particular problem. We believe there is a PSN bug that we
    haven't been able to find yet; so far, we have been unable to
    duplicate this problem in our lab. In the meantime, we have
    developed a work-around that will enable Yale to be up on the
    ARPANET while we work to find and fix the bug. We apologize
    for the inconvenience, and thank the folks at Yale for their
    patience and understanding.

Finally, implementors have asked if they can be included on the
"ARPAUPGRADE" mailing list. We use this list as a "hot line" for
getting information from the community to us and to DCA, and for
internal discussion about the problems. The idea of having an
implementor's mailing list is a good one, however, and we will
shortly set up a new list for those who are actively helping us
track down these various problems.

Please keep those cards and letters coming!

 Ken Pogran

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