hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) (11/06/87)
I have just heard from a reliable source a fairly interesting fact about the new end to end protocol implemented in PSN 7.0. (Note that my terminology is probably slightly off in this message. I don't know anything about the imp to host protocol, so I am almost certainly introducing some distortion in passing on this information.) Apparently one of the efficiency improvements in the new end to end protocol is that the IMP's will no longer attempt to return a RFNM for each packet. You will be expected to look at the ID number included in the RFNM's. Any outstanding RFNM's with ID numbers lower than the current one are also to be considered as acknowledged. Many implementations apparently simply count RFNM's. They assume that one acknowledgement is received per packet. This will no longer be true with the new end to end protocol, and so these implementations will break. I have some reason to think that most existing implementations fall into this category. Tests of the new end to end protocol are scheduled for Nov 7, 14-15, and 18. Implementors should be alert to misbehaviors during these test periods.
malis@CC5.BBN.COM (Andy Malis) (11/16/87)
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