Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!MATHOM.CISCO.COM!SATZ
From: SATZ@MATHOM.CISCO.COM (Greg Satz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: An ARPANET update
Message-ID: <12359574041.18.SATZ@MATHOM.CISCO.COM>
Date: 19 Dec 87 00:47:57 GMT
References: <pogran@ccq.bbn.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 51


    From: Ken Pogran <pogran@ccq.bbn.com>
    Subject: An ARPANET update
    
        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 Protocol, 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.

The X.25 specification ommits any explanation on when to send RR
acknowledgements. For a low bandwidth link, it is seems reasonable to
wait until the window is (almost) full before sending an RR. It is also
reasonable to want to send an RR (if you don't have an outgoing data
packet ready) after every received data packet when the acknowledgements
must traverse the network instead of having local significance.

Our implementation has a parameter that lets you send an acknowledgment
when N input data packets have been seen. An RR acknowledgement is sent
if there aren't any outgoing data packets. The drawback is that RRs will
be sent more often then necessary. Adding a timer is a very good idea.

After rereading the "Procedures for flow control" I came across the
section of "Delivery confirmation". I don't know if it is worth it, but
maybe the D-bit could be used?
-------