Network Working Group                    Bernard P. CosellRequest For Comments # 386               David C. WaldenNIC # 11358                              Bolt Beranek and Newman Inc.Categories:                              August 16, 1972Updates:Obsoletes:                        LETTER TO TIP USERS -- 2     This is the second letter to TIP users.  The first was RFC #365.There will be more letters to TIP users as they seem to us to be agood way to keep you informed about what's going on.  We suggest youkeep these letters with your TIP User's Guide (TUG) as we will use theletters to provide documentation of TIP system changes which are madebefore we can get TUG revisions printed and distributed. (It is almostinevitable that the TUG revisions follow actual system changes.Further- more, these letters will allow us more discussion of newcommands than in TUG.)     Some of the changes we will be making to the TIP have beensuggested by TIP users. We won't bother with acknowledg- ments.     The @PROTOCOL TO LOGIN and @PROTOCOL TO CLOSE BOTH commands willbe removed very soon. We presume no one uses these commands any moresince they have been replaced by @LOGIN and @CLOSE.     As we warned in TIP Letter 1, the @LOGIN command will be given aparameter soon, the Host number up to now given with the @HOSTcommand.  At the same time, @HOST will be changed so it does asimultaneous @RECEIVE FROM HOST and @SEND TO HOST.  Presently, @HOSTis the same as @SEND TO HOST.     Several changes will be made to the @TRANSMIT commands very soon.First @TRANSMIT ON NO CHARACTERS and @TRANSMIT ON EVERY CHARACTER willbe removed. Their functions will be covered by the other @TRANSMITcommands. @TRANSMIT NOW will continue to function as at present; itwill cause the one message presently being accumulated to be sent assoon as possible.  @TRANSMIT ON LINEFEED and @TRANSMIT ON MESSAGE-ENDwill continue to cause the message being accumulated to be sent onlinefeed and CONTROL-S. However, they will additionally cause themessage being accumulated to be sent when the character buffer isalmost full. Thus, it will no longer be necessary to give a @TRANSMITEVERY <big number> with @TRANSMIT ON LINEFEED and @TRANSMIT ONMESSAGE-END.  @TRANSMIT EVERY # will continue to cause the messagebeing accumulated to be sent as near as possible to every #thcharacter.  However, values of # which are bigger than the size of the                                                                [Page 1]RFC # 386                                                     NIC #11358input buffer will cause transmission when the buffer is almost full;and a value of 0 for # will reset the terminal to its initial setting-- TRANSMIT-ON-LINEFEED mode off, TRANSMIT ON MESSAGE- END mode off,and transmitting every character. Thus, TRANSMIT EVERY 0 has theeffect of the removed @TRANSMIT ON NO CHARACTER command, and @TRANSMITEVERY 1 has the effect of the removed @TRANSMIT ON EVERY CHARACTERcommand.     There are two ways outside of letters and the telephone tocommunicate your suggestions and complaints to us: log into BBN-TENEXand SNDMSG to WALDEN or use the NIC Journal system to send a messageto DCW3. Dave likes letters best, incidentally.     We are going to remove the "NEWS" herald from the TIP's HELLOmessage. The problem is that we don't know when everybody has read thelatest news so that we can turn off the herald.  Therefore, we can'tturn it off. Therefore, it is useless.  Check the NEWS every time youuse the TIP. If once the news begins printing you discover you havealready seen it, you can stop it by typing @CLOSE _LF_ (on a 2741 hit"attention" first).     A new TIP message will have been added by the time you get thisletter, the message TIP GOING DOWN. This message will be printed onevery TIP terminal shortly before the TIP is taken down for preventivemaintenance, new software releases, etc. (see RFC #381 for furtherdiscussion of this topic). When this message is printed, all TIP usersshould cleanly stop what they are doing with a Host. Eventually, thismessage will include information on how long until the TIP will godown, for how long it will be down, and why.     While we are on the subject of TIP messages, let us mention thatwe will be adding a number of new messages which we believe willremove some of the present confusion about what the TIP is doing.Unfortunately, we don't have the space to store the message textstrings, so, we will use numbers for the new messages. The format ofthese messages will probably be something like M46 for message 46.Perhaps when the TIPs get more core we can replace the number-messagesby text-messages.     We are thinking of changing all the TIP LOGIN commands to OPENcommands which would be more opposite to the CLOSE commands and not soliable to confusion with Host LOGIN.     On page 12 of the TUG is a description of how Hosts can sendcommands to a TIP terminal. Be warned, if you decide to use thisfacility, that we are changing the TIP command language slowly and wewill not be constrained in these changes by the fact that some Hostsare sending TIP commands.  Therefore, if a Host is going to send a                                                                [Page 2]RFC # 386                                                     NIC #11358command to a TIP it ought to implement this in a manner that can bechanged easily.     Some TIP users have been seeing the following problem.  They arecommunicating with a Host when suddenly they get the message DEAD. Ifthey try to LOGIN to the Host again they do not get the DEAD message,but the Host refuses to allow the LOGIN by either doing nothing,closing, or refusing. The problem was that occasionally the networkpartitioned briefly; for instance, one of the two cross-country lineswas down and the other got flaky for a few seconds. If, during aperiod when the network is partitioned, a TIP user sends a message toa Host which cannot be reached, the TIP types DEAD and closes theconnection to the Host. The Host, on the other hand, may not have beentrying to send to the TIP when the network partitioned; in that caseit might not have noticed that the network partitioned and thereforestill thinks it has an open connection to the TIP.  When the TIP thentries to re-LOGIN to the Host, the Host refuses because it already hasan open connection with that particular TIP device.     Now that we have three independent cross-country paths we do notexpect this problem to occur often, but if it does we see noshort-term solution. We can't just let a CLOSE reset the connectionsince the user's immediately preceeding LOGIN destroyed the Hostsupplied socket numbers. One can get out of this state by executingthe Host/Host protocol command from the TIP which resets _all_ TIPusers at the given TIP talking to the given Host; but this is a littlegross. What is maybe needed is a Host/Host protocol command to resetthe Host's connections with a particular user (TIP) socket; we willtry to understand the ramifications of such a command and perhapsundertake promotion of a Host/Host protocol change. In the meantime,frequently when the above problem happens some other TIP terminal canstill LOGIN to the Host and then halt the hung terminal's job from theHost side.  If it is not possible to get through on anotherconnection, a telephone call to the Host, asking them to log the jobout, may be necessary. Or, if there is really no other user talking tothe particular Host, the reset command can be executed -- this commandis not documented but we will tell a responsible person at each TIPsite how to execute the command.     There is a problem related to the above problem which some TIPusers have seen. Occasionally, an IMP crashes somewhere in the networkand takes a packet of a message along with it.  Eventually, the sourceof the message gets an incomplete transmission message from thenetwork. When the TIP gets this message, it closes the connection andcalls the destination dead. This is what most other Hosts do also, weunderstand. A more reasonable thing to do might be to retransmit themessage or to tell the user and then let him continue; we would liketo do one of these. But before retransmission or letting the user                                                                [Page 3]RFC # 386                                                     NIC #11358continue, the TIP and Host's allocate counters must be resynchronized.However, there is no Host/Host protocol way to synchronize simpleenough for the TIP to use. What may be needed is a simple Host/Hostprotocol reset allocate command. We will try to understand this issueand, again, perhaps undertake promotion of a Host/Host protocolchange.     The above two problems explain part of the "lost allocates" butnot all. We have now instrumented the TIP program in a manner which wehope will help us find the rest of the lost allocate problem soon.     The TIP's logger (opener?) has been causing users some problems.Upon examination, the problems were seen to originate from basicdesign assumptions within the logger which we are working on changing.In the short term, however, we think that a discussion of what thelogger is doing and how it works will alleviate some of the grief.     For the user, opening proceeds in three phases. In the first, theuser is queued up waiting to "get" the TIP's logger.  In the second,the user has gotten the TIP's logger and is beginning the loginsequence. In the third, the user has completed the login sequence andis waiting for the Host to open up the actual data connections.  Manyof the problems stem from the fact that _only_one_user_ may beproceeding through phase 2 at a time.  Hence the need for the queue ofphase 1.  Any single user may tie up phase 2 for at most about 1minute.  This is the canonical "timeout" in the logger.  Notice thatthis does not include the times in either the first or third phases.Thus, the actual delay before you get a "timeout" after you type @Lcan be 1 minute, 2 minutes, 3 minutes...depending on how many otherpeople are having difficulty logging in at the same time.  Abort Login(@A L) does three different things depending on which phase of loggingin the user is in.  In phase 2 it resets the timer to be close tooverflowing so that it is responded to with a "timeout" shortly afterthe command is given.  In phase 3 it does nothing at all, and in phase1 it merely removes the user (silently) from the logging queue.     We will, medium term, have the TIP type out something like "YOURLOGGER" when you get off the queue and the logger begins trying toopen your connections.  This will at least alleviate user uncertaintyas to whether he is in phase 1 or phase 2.  Long term, we willprobably make the logging process reentrant so that users will notinteract with one another quite so destructively.  In the short term,here is a small "cookbook" on how to undo a login that seems to not beworking.     When you have waited as long as you would like to for the loginto take place, you may type "@A L".  If the TIP responds with"TIMEOUT" in a few second and has not typed T OPEN or R OPEN, then you                                                                [Page 4]RFC # 386                                                     NIC #11358are aborted and may attempt logging in again.  If it types "TIMEOUT"but has typed out T OPEN or R OPEN then you should type @C and waitfor that to be responded to (You _must_ wait.) If you get no responseat all to @A L, and the TIP has typed that one or the other connectionis open, you should type @C and wait, as above.  Finally, if the TIPmakes no response and has not opened any connection, than you are freeto proceed.     From now on the name of the DEVICE CODE EXECUPORT command will beDEVICE CODE EXTRA-PADDING, since there are a number of other terminalswhich require this feature.  The latest to be added to the list is theDATAPOINT 3300.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by BBN Corp. under the   ]       [ direction of Alex McKenzie.                      1/97 ]                                                                [Page 5]