----MESSAGE-BEGIN---- <1983030106510000> Received: from USC-ISIB by SRI-NIC at 1-Mar-83 1457-PST Date: 1 Mar 1983 1451-PST Subject: Re: Talking to TOPS-20 From: Craig Milo Rogers To: don.provan@CMU-CS-A, KLH@SRI-NIC cc: lloyd@EDN-UNIX, dedwards@USC-ISI, tcp-ip@SRI-NIC In-Reply-To: <28Feb83 122308 DP0N@CMU-CS-A> From RFC 793, Transmission Control Protocol, September 1981, p 43: Note that acknowlegements should not be delayed or unnecessary retransmissions will result. One strategy would be to send an acknowlegement when a small segment arrives (with out updating the window information), and then to send another acknowlegment with new window information when the window is larger. Also, on p. 42: Thw window sent in each segment indicates tha range of sequence numbers the sender of the window (the data receiver) is currently prepared to accept. The implication is that, if your window opens, then you should send a new segment to reflect that fact. Page 43 also mentions that you may wish to defer small updates to the window, and send a larger update a little later. The zero-window probe is designed only to recover from the case that a zero-window update is lost or damaged. There is a more complete discussion of window algorithms in RFC 813, Window and Acknowlegment Strategy in TCP, July 1982. Retransmitting a probe every second for every TAC connection could lead to, shall we say, degraded ARPANET performance. Of course, if every TAC connection were doing that much printing, than perhaps performance would already have degraded. Craig Milo Rogers ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983030115310000> Received: from CMU-CS-A by SRI-NIC at 1-Mar-83 2119-PST Date: 1 March 1983 2031-EST (Tuesday) From: don To: Craig Milo Rogers Subject: Re: Talking to TOPS-20 CC: KLH at SRI-NIC, lloyd at EDN-UNIX, dedwards at USC-ISI, tcp-ip at SRI-NIC Sender: don.provan at CMU-CS-A Reply-To: don.provan at CMU-CS-A In-Reply-To: Craig Milo Rogers's message of 1 Mar 83 17:51-EST Message-Id: <01Mar83 203153 DP0N@CMU-CS-A> you don't have to convince ME that sending a window update on a zero window is a good idea. all you have to convince me of is that i can claim an implementation is not legal if it doesn't send such an update. quotes of possible strategies and tenuous implications do not convince me. is the offical view that such an update must be sent? if so, why was i not getting a window update from a TAC? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983030610220000> Received: from USC-ISIF by SRI-NIC at 6-Mar-83 1826-PST Date: 6 Mar 1983 1822-PST From: POSTEL at USC-ISIF Subject: Zero Windows - Probes & Updates To: tcp-ip at NIC There has been some discussion of the window flow control in TCP and the proper actions to take when the window becomes zero and moves away from zero. When the data sender is faced with a zero window it must probe the receiver periodically at a low rate (e.g., once every two minutes) to see if the window has opened (become positive). When the data receiver that has advertized a zero window makes the window positive it must provide that information to the data sender in an segment transmitted to the other TCP. If no other data is ready to be sent an ACK+Window "update" segment must be sent. Since such a segment does not carry data it's reliable recption cannot be ensured by the TCP mechanisms. However, it is expected that update segment will be the normal way of promptly resuming the data flow when the window opens. The low frequency probes of the window by the data sender are the backup mechanism. There has been some mention of using a much lower rate probe (e.g., once per second). This is counter productive. The probe should be at a low rate, no more frequent than once per 30 seconds, probably best at once per two minutes. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031107570000> Received: from SRI-TSC by SRI-NIC at 11-Mar-83 1644-PST Date: 11 Mar 1983 at 1557-PST To: unix-wizards at SRI-CSL, tcp-ip at NIC Reply-To: dan at SRI-TSC Subject: Looking for a VDH interface for UNIX From: dan at SRI-TSC Is anybody out there running TCP/IP on UNIX, through a VDH interface? I would appreicate hearing about it for any version of UNIX TCP/IP. Thanks! -Dan Chernikoff (dan@sri-tsc) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031410210000> Received: from RAND-UNIX by SRI-NIC at 14-Mar-83 1829-PST Date: Monday, 14 Mar 1983 18:21-PST To: local-nets at MIT-MC, tcp-ip at SRI-NIC Cc: mike at rand-unix Subject: XNS and Network Research Corporation From: mike at rand-unix We are considering using NRC (Network Research) to build a local network for us as they are the only company we can find that supports both RT11 and UNIX. They use XNS which is Xerox's new network protocol. They claim that XNS is fast becoming "the" network protocol for commercial users, far outstripping IP/TCP. They also claimed hhat the Berkeley implementation of IP/TCP doesnt work. This is the second time I have heard this latter claim, the first time from 3COM. So the questions are: a. Is XNS becoming the commercial standard? b. Does the Berkeley 4.?+1 implementation of IPTCP work? c. Has anyone had any experience with NRC? Thanks very much, Michael Wahrman ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031500220000> Received: from USC-ISIF by SRI-NIC at 15-Mar-83 0825-PST Date: 15 Mar 1983 0822-PST From: POSTEL at USC-ISIF Subject: Re: XNS and Network Research Corporation To: mike at RAND-UNIX, local-nets at MIT-MC, tcp-ip at SRI-NIC cc: POSTEL at USC-ISIF In response to the message sent Monday, 14 Mar 1983 18:21-PST from mike@rand-unix Mike: There are a lot of sites running Berkeley Unix with IP/TCP. It is not always clear which sites are using the Berkeley verision of the IP/TCP program or the BBN version of the IP/TCP program. In any case the situation is far different than portrayed by some salesman with his own self interest in mind. I am sure that people who have invested the time and effort in implementing Xerox NS protocols would love it if they did become widely used, but liking something and having it be true are two very different things. I never heard of "Network Research (NRC)". Who are the principals of the company? You can be sure that the ARPA and the DOD are using IP/TCP in the Internet. It seems foolish to me to waste your time on implementing two sets of functionally equivalent protocols for the same machines. If you think that the machines in the local net won't need to talk to machines in the Internet so they don't need compatible protocols - i think you are being very short sighted. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031501330000> Received: from USC-ISID by SRI-NIC at 15-Mar-83 0933-PST Date: 15 Mar 1983 0933-PST From: MILLS at USC-ISID Subject: Re: XNS and Network Research Corporation To: mike at RAND-UNIX, local-nets at MIT-MC, tcp-ip at SRI-NIC cc: MILLS at USC-ISID In response to the message sent Monday, 14 Mar 1983 18:21-PST from mike@rand-unix Mike, Chris Kent would argue that 4.? does in fact work and so would I. Fuzzballs emulate RT-11, support IP/TCP, TELNET, FTP and SMTP and cause a lot of mischief, so I argue they work. 3-COM's implementation as-is does not work. Toggle John Nagle at Ford Aerospace (jbnand he will tell you about Ford's mods to 3-COM that do work. And so it goes. Regards, Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031506160000> Received: from MIT-XX by SRI-NIC at 15-Mar-83 0819-PST Date: 15 Mar 1983 1116-EST From: Chris Ryland Subject: Re: XNS and Network Research Corporation To: mike@RAND-UNIX, local-nets@MIT-MC, tcp-ip@SRI-NIC In-Reply-To: Your message of 14-Mar-83 2131-EST Mike: Yes, it does appear that XNS is gaining the momentum needed to become a true standard (vs. a paper standard). I say this because there are a lot of companies offering or about to offer XNS-based networks (Network Research, ACC, 3Com, Bridge, are a few). "Berkeley IP/TCP doesn't work" is the usual mindless slander. 4.2 IP/TCP works well, though earlier DEBUGGING (i.e., pre-release) versions have had problems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031602570000> Received: from RAND-UNIX by SRI-NIC at 16-Mar-83 1101-PST Date: Wednesday, 16 Mar 1983 10:57-PST To: local-nets at MIT-MC, tcp-ip at SRI-NIC Cc: guyton at rand-unix Subject: XNS and NRC From: guyton at rand-unix The recent msg from Mike Wahrman has led several people to believe that Rand is considering not using TCP/IP. This is not the case. Rand is currently running TCP/IP and will continue to do so as long as we are on the Arpanet Internet. We are looking forward to a local ethernet running TCP/IP in the very near future. Mike is a consultant to Rand, and his query was in regard to a seperate network being set up by his other employer. -- Jim Guyton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983031604135500> Received: from PURDUE by SRI-NIC at 16-Mar-83 0758-PST Date: 16 Mar 1983 09:13:55-EST From: Christopher A Kent Reply-to: cak@purdue To: local-nets@MC, mike@rand-unix, tcp-ip@NIC Subject: Re: XNS and Network Research Corporation Mike, Berkeley's TCP works just fine. It's even been ported to split I/D 11s; I believe that all the 11s on the Arpanet running V7 UNIX are using that TCP. It's true that the pre-releases had many problems, but I think most of those have been resolved, at least within Berkeley (they may not have made it to the outside world). Earlier versions also had functionality that was a superset of the TCP standard (Out-Of-Band data signalling, for example) but I believe that all those features will be removed before final release. XNS may well become a standard for Ethernet based networks; what happens when you want to talk to someone else? Cheers, chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983032007130300> Received: from 30001212401 by SRI-NIC at 20-Mar-83 1142-PST Date: 20 Mar 83 12:13:03 EST (Sun) From: Mike Muuss (TCP-IP Digest) To: tcp-ip@Sri-Nic.ARPA, Large-List-Peple Subject: NIC list -vs- digest Now that the NIC list is also being transmitted to the TCP-IP@BRL list, I have an interesting policy question. Should I assume that people who send messages to the NIC list know that they are going to come out later in the Digest and publish them, so that everybody on the Digest can see and participate in this new "insiders" forum, or, should I individually enquire of every author if I can publish their letter (administrative nightmare), or what? I certainly have no intention of publishing some of the short, misunderstanding-based messages and replies that go to the NIC list, but there is a great deal of information exchanged which might be of value to others. The same goes for the TENEX and TOPS-20 lists at the NIC, which also now feed the digest. For the time being, I will just hld messages from the NIC lists, until some kind of consensus forms. Thanks, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983032007520000> Mail-From: SMTP created at 20-Mar-83 12:40:54 Received: FROM [192.5.21.1] BY USC-ISIF.ARPA WITH TCP ; 20 Mar 83 12:41:05 PST Sender: Mike Muuss From: TCP-IP@Brl.ARPA To: TCP-IP@Brl.ARPA Date: 20 Mar 1983 Subject: TCP-IP Digest, Vol 2 #2 Received: From Brl-Bmd.ARPA via smtptcp; 20 Mar 83 12:52 EST TCP/IP Digest Sunday, 20 March 1983 Volume 2 : Issue 2 Today's Topics: Administrivia: Class "C" Transmission Host Administrivia: NIC list -vs- the Digest Security on TCP/IP? RFC 848 ("Little TCP Services") Misleading Looking for VDH driver for TCP/IP on UNIX ---------------------------------------------------------------------- TCP/IP Digest --- The InterNet Digest LIMITED DISTRIBUTION For Research Use Only --- Not for Public Distribution ---------------------------------------------------------------------- Date: 20 Mar 83 12:28:32 EST (Sun) From: Mike Muuss (TCP-IP Digest) Subject: Administrivia This digest is intentionally a short one. This will be the first digest transmitted from a machine on a class "C" network, connected by gateway to the InterNet. As many hosts may not have up to date routing tables, (or even host tables!), this will be an interesting test to see how far along we really are. Transmission is from host BRL-BMD, 192.5.21.1, via the BRL-GATEWAY connecting 10.3.0.29 and 192.5.21.* Mail which lingers in the queue for more than a few days I will note, and manually forward through host BRL (10.0.0.29), so that everybody should get a copy. The famous maxim applies: "If you don't see this message, please let me know"! Cheers, -Mike ------------------------------ Date: 20 Mar 83 12:13:03 EST (Sun) From: Mike Muuss (TCP-IP Digest) Subject: NIC list -vs- digest Now that the NIC list is also being transmitted to the TCP-IP@BRL list, I have an interesting policy question. Should I assume that people who send messages to the NIC list know that they are going to come out later in the Digest and publish them, so that everybody on the Digest can see and participate in this new "insiders" forum, or, should I individually enquire of every author if I can publish their letter (administrative nightmare), or what? For the time being, I will just hold messages from the NIC lists, until some kind of consensus forms. Thanks, -Mike ------------------------------ Date: 13 Feb 83 22:38:35 EST (Sun) From: smb%mhb5b@brl-bmd Full-Name: Steven M. Bellovin Subject: Security on TCP/IP Mike: has any work been done on security protocols for TCP/IP? That is, we're working on the first link of a Murray Hill Ethernet, which will ultimately connect lots of machines up here. Some of them are mutually suspicious (we have sensitive data on our machines, for example), and I'd like ways to authenticate requests. Given that DOD is sponsoring TCP/IP, I assume that *something* has been done, but I haven't seen any papers, and I'd rather not re-invent the wheel. --Steve ------------------------------ Date: 17 March 1983 21:25 est From: Barry Margolin@Mit-Multics.ARPA Subject: RFC 848 misleading To: TCP-IP@Brl.ARPA RFC 848, entitled "Who Provides the 'Little' TCP Services?", is a little misleading. There are a number of hosts listed as providing almost all the services tested. It seems that the lists were generated by attempting to connect to the hosts, and noting whether the connection was opened. The software that is running in many of these hosts, which all seem to be PDP-11's running RT-11, generally seems to open connections on any port. If it doesn't actually implement the service, it then sends the ASCII string "HOSTNAME Unknown service port NN", where HOSTNAME is replaced by its hostname (with the appropriate domain name) and NN is the port. There are some exceptions to this, in which cases they return the string "HOSTNAME Not yet Postel, not yet"! Barry Margolin Margolin@MIT-Multics.ARPA ------------------------------ Date: 11 Mar 1983 at 1557-PST Subject: Looking for a VDH interface for UNIX From: dan at SRI-TSC Is anybody out there running TCP/IP on UNIX, through a VDH interface? I would appreicate hearing about it for any version of UNIX TCP/IP. Thanks! -Dan Chernikoff (dan@sri-tsc) ------------------------------ END OF TCP-IP DIGEST ******************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983032109142700> Received: from BBNT by SRI-NIC at 21-Mar-83 1128-PST Date: 21 Mar 1983 14:14:27 EST (Monday) From: Rob Gurwitz Subject: Re: XNS and Network Research Corporation In-Reply-to: Your message of Monday, 14 Mar 1983 18:21-PST To: mike at rand-unix Cc: local-nets at MIT-MC, tcp-ip at SRI-NIC a. XNS is "a" commerical standard, but not "the" commercial standard. Doubtless other manufacturers and hangers on would try to sell their protocols as "the" standard. b. Both the BBN (4.1) TCP/IP and the Berkeley (4.1x, 4.2, 4.3) version which decended from it appear to work (otherwise youwouldn't get this message). The BBN code is currently in use on over 90 machines at at least 40 sites. The Berkeley code exists so far in test versions only, but operates at some number of sites and has been ported to the PDP-11 by SRI. c. No. Its interesting that both NRC and 3COM make such statements, viewing TCP/IP and the VAX versions of implementations as "competitors". Caveat emptor. Rob Gurwitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983033008090000> Received: from RADC-MULTICS by SRI-NIC at 30-Mar-83 1018-PST Date: 30 March 1983 13:09 est From: Ata.SysMaint at RADC-MULTICS Subject: Simultaneous opens To: Postel at USC-ISIF cc: tcp-ip at SRI-NIC, Ata.SysMaint at RADC-MULTICS, JSLove at MIT-MULTICS Jon, It is my understanding that the TCP spec supports the idea of 2 TCPs simultaneously opening a connection. However, unless both sides open the connection at exacltly the same time, it will fail. Following the spec, if a segment arrives to a port which does not exist, a RESET is sent back. A RESET, still following the spec, will close the connection and abort the attempted open. Since the chances of 2 TCPs ever being exact in their timing of opening the connections is slim, then the notion or concept of a simultanous open as per spec is really meaningless. However, if a TCP bends the rules a little and retransmits the SYN on a RESET until the timeout period expires, then the chances for a connection to succeed are greatly enhanced. I therefore, request that a change be made to the spec to accomodate this situation, since there are applications (NSW for example) which will make use of the simultanous open feature of TCP, and which will fail if the TCPs follow the spec the way it is now written. John Ata ----MESSAGE-END----