From JTW at AI.AI.MIT.EDU Sun Nov 29 09:10:04 1987 From: JTW at AI.AI.MIT.EDU (John Wroclawski) Date: Nov 29 87 03:10:04 EST Subject: More TCP stuff Message-ID: <292213.871129.JTW@AI.AI.MIT.EDU> I added a bunch of stuff to TCP to "optimize" (guess) the best packet size based on the path to the foreign entity, and to send and understand TCP max seg size options. In the past, it has just used the minimum possible value everywhere to be safe. This has the effect of roughly doubling the potential throughput to MIT and arpanet hosts. On the other hand, this is all kinda heuristic, and one could imagine some problems... If you could talk to AI well last week and you can't now, please send a note before assuming you are being screwed by the arpanet. From JTW at AI.AI.MIT.EDU Fri Nov 27 06:08:15 1987 From: JTW at AI.AI.MIT.EDU (John Wroclawski) Date: Nov 27 87 00:08:15 EST Subject: No subject Message-ID: <291890.871127.JTW@AI.AI.MIT.EDU> ITS 1606 (NITS on AI at the moment) has a new IMP driver. Hopefully this will fix up the bad IMPOS crashes and improve the lost TCP buffer problem some. (And it's faster, too!) Please collect crashdumps of anything that looks like an IP/IMP screwup and send a note to bug-its... Oh yeah, the NET command in LOCK actually does something useful now, you might try it first if you think the arpanet is unhappy. From SRA at XX.LCS.MIT.EDU Sun Nov 15 22:50:00 1987 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Nov 15 1987 16:50 EST Subject: [malis: new Arpanet end to end protocol ] Message-ID: Follow up.... Date: Nov 10 87 09:49:17 -0500 From: Andy Malis To: Charles Hedrick cc: tcp-ip at SRI-NIC.ARPA, malis at CC5.BBN.COM Re: new Arpanet end to end protocol 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 at 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 From ALAN at AI.AI.MIT.EDU Mon Nov 9 19:37:05 1987 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Mon, 9 Nov 87 13:37:05 EST Subject: MC:CRASH;PI FAULT In-Reply-To: Msg of Mon 9 Nov 87 12:36:25 EST from Michael A. Patton Message-ID: <282278.871109.ALAN@AI.AI.MIT.EDU> Date: Mon, 9 Nov 87 12:36:25 EST From: Michael A. Patton I just reloaded MC. It had gotten a "PAGE FAULT WITH PI IN PROGRESS". Dump is in MC:CRASH;PI FAULT. Seems to have restarted all right. This one is a good joke that has happened once before. The fault was taken by the TCP checksumming code. Presumably what happens is that when a packet arrives with a large enough bogus length, the checksumming code applies the checksumming algorithm to a huge block of memory that starts with the packet and extends up to some nonexistent page. From MAP at AI.AI.MIT.EDU Mon Nov 9 18:36:25 1987 From: MAP at AI.AI.MIT.EDU (Michael A. Patton) Date: Mon, 9 Nov 87 12:36:25 EST Subject: No subject Message-ID: <282226.871109.MAP0@AI.AI.MIT.EDU> I just reloaded MC. It had gotten a "PAGE FAULT WITH PI IN PROGRESS". Dump is in MC:CRASH;PI FAULT. Seems to have restarted all right. From KLH at SRI-NIC.ARPA Fri Nov 6 22:54:46 1987 From: KLH at SRI-NIC.ARPA (Ken Harrenstien) Date: Nov 6 87 13:54:46 PST Subject: [hedrick@aramis.rutgers.edu (Charles Hedrick): new Arpanet end to end protocol] Message-ID: <12348532467.31.KLH@SRI-NIC.ARPA> If this message is true, ITS systems will have problems, since the IMP code counts RFNMs. I guess new code would need to be added which (depending on a runtime flag setting) handles the new scheme. But someone needs to find out exactly what the new scheme is first... --------------- Received: from aramis.rutgers.edu by SRI-NIC.ARPA with TCP; Fri 6 Nov 87 12:06:51-PST Received: by athos.rutgers.edu (5.54/1.14) id AA24392; Fri, 6 Nov 87 02:20:54 EST Date: Nov 6 87 02:20:54 EST From: hedrick at aramis.rutgers.edu (Charles Hedrick) Message-Id: <8711060720.AA24392 at athos.rutgers.edu> To: tcp-ip at sri-nic.arpa Subject: new Arpanet end to end protocol 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. ------- From ALAN at AI.AI.MIT.EDU Mon Nov 2 21:48:24 1987 From: ALAN at AI.AI.MIT.EDU (Alan Bawden) Date: Mon, 2 Nov 87 15:48:24 EST Subject: DIR device In-Reply-To: Msg of Sat 31 Oct 87 16:42:38 EST from Patrick G. Sobalvarro Message-ID: <278714.871102.ALAN@AI.AI.MIT.EDU> Date: Sat, 31 Oct 87 16:42:38 EST From: Patrick G. Sobalvarro ^R dir:pgs; name2 @ doesn't get me a listing of the files on my directory whose second name is @. This used to work, and NAME1 still does work. That's cause DIR:PGS;SECOND @ is how you get a listing of the files on your directory whose second name is @. DIR:PGS;FIRST FOO is how you get a listing of the files on your directory whose first name is FOO. DIR:PGS;NAME1 and DIR:PGS;NAME2 give directory listings -sorted- (not -filtered-) by first or second filename. (For example DIR:PGS;NAME1 DOWN generates a listing of your directory backwards.)