Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!aurora!labrea!jade!ucbvax!CC5.BBN.COM!malis
From: malis@CC5.BBN.COM (Andy Malis)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: new Arpanet end to end protocol
Message-ID: <8711161048.AA14354@ucbvax.Berkeley.EDU>
Date: Mon, 16-Nov-87 05:49:20 EST
Article-I.D.: ucbvax.8711161048.AA14354
Posted: Mon Nov 16 05:49:20 1987
Date-Received: Tue, 17-Nov-87 06:30:11 EST
References: <8711060720.AA24392@athos.rutgers.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 61

Charles,

Your message is quite wrong (I know - I designed the new
End-to-End).  I would be interested in knowing (in private) who
your "reliable source" is, so that such rumors can be source
quenched.  After the recent messages on the tcp-ip list, I'm sure
we all realize how important source quenching is.

The truth of the matter is:

PSN 7.0 has two different End-to-End protocols (old EE and new
EE).  Either one or the other runs at any particular time, and
the two cannot interoperate.  The ARPANET is currently using PSN
7.0 with the old EE.  It is the new EE that will be tested on
Nov. 7, 14-15, and 18.

The old EE protocol explicitly returned, across the PSN subnet, a
separate RFNM packet for each message delivered to a destination
host.  This RFNM packet was then converted, in the source PSN,
into the 1822 RFNM for that message and delivered to the source
host.  This had the result that, depending on traffic mixes,
roughly about 45% to 50% of the packets going through the subnet
were RFNMs.  Since the PSN does so much per-packet processing,
even for these RFNMs, the network was passing much less host
traffic than otherwise might be possible.

We fixed this in the new EE by making it an explicitly windowed
protocol IN THE SUBNET.  The destination PSNs have the ability to
aggregate ACKs (the new EE internal equivalent to RFNMs) and send
multiple ACKs for the same connection in windowed ACK (by using
an INTERNAL message sequence number).  In addition, these ACKs
can now be piggybacked on data traffic, and many ACKs for
different EE connections can be shipped together in the same
subnet packet to a source PSN.

The important thing to note is that when the destination PSN
receives an ACK for a connection, it generates, and sends to the
source host, a separate 1822 RFNM for EACH and EVERY message
submitted by the host and being acknowledged by the ACK.  There
are no host-visible sequence numbers; the 1822 protocol stays the
same as before.

What may have confused you is the fact that we at BBN are,
concurrent with the PSN 7.0 testing, trying to track down which
ARPANET hosts might be affected by a known BSD 4.2 network
software problem that may cause RFNMs to be lost in the host
itself (I believe it is related to the size of the message
received PREVIOUS to the RFNM).  This bug has been fixed in BSD
4.3, and I have been told that Lars Poulsen of ACC
(lars@acc.arpa) has a patch for BSD 4.2-derived host software.

By the way, we have measured in our internal BBNNET (which has
been running PSN 7.0 with the new EE only for over five months
now) that only about 14% of the packets through the network only
contain ACKs - the rest of the ACKs are being piggybacked on the
data traffic.  We are very pleased with this result.  Also, most
of our BBNNET hosts (around 125 C/70s, VAXEN, TOPS-20s, TACs, and
others) use 1822, and they have had no problems with the new EE.

Regards,
Andy