From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc102.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc102.txt (limited to 'doc/rfc/rfc102.txt') diff --git a/doc/rfc/rfc102.txt b/doc/rfc/rfc102.txt new file mode 100644 index 0000000..c6ddaf8 --- /dev/null +++ b/doc/rfc/rfc102.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group Steve Crocker, Chairman +Request for Comments: 102 at BBN, Cambridge +NIC#5763 22, 23 February 1971 + + + OUTPUT OF THE HOST/HOST PROTOCOL + GLITCH CLEANING COMMITTEE + + At the NWG meeting in Urbana on 17-19 February 1971, a + committee was established to look at the Host/Host protocol + and see what changes were immediately desirable or necessary. + + The committee is chaired by Steve Crocker, and has eight + other members: + + Ray Tomlinson BBN (Tenex) + + Jim White UCSB + + Gary Grossman Illinois + + Tom Barkalow Lincoln (TX2) + + Will Crowther BBN (IMPs) + + Bob Bressler MIT (Dynamic Modeling + + Doug McKay IBM (Yorktown) + + Dan Murphy BBN (Tenex) + + + A number of topics were discussed. On some of these topics, a + consensus was reached on whether or not to recommend a change, and if + so, what the change should be. On the remaining topics, specific + alternatives were proposed but no consensus was reached. + + The committee will immediately canvas the network community and + gather reaction to its recommendations and the proposed alternatives. + The committee will then reconvene at UCLA on 8 March 1971 and decide + on final recommendations. Steve Crocker will then write Document #2. + This sequence is in lieu of the change procedure outlined in NWG/RFC + 53. + + + + + + + + +Crocker [Page 1] + +RFC 102 HOST/HOST PROTOCOL GLITCH CLEANING COMMITTEE February 1971 + + + Specific Recommendations + + 1. The ECO and ERP command should each be 8 bits long. + + 2. The ERR command should be 96 bits long. + + 3. Message Data Types should be eliminated. Third-level protocol + people may reinstate such a mechanism. + + 4. The Cease mechanism should be discontinued. + + 5. A new pair of one byte commands RST (reset) and RRP (reset reply) + should be added. The RST should be interpreted as a signal to + purge the NCP tables of any existing entries which arose from the + sending Host. The RRP command should be returned to acknowledge + receipt of the RST. The Host sending the RST may proceed after + receiving either a RST or a RRP in return. A RST may be returned + if the second Host comes up after the first Host. + + 6. Although it was suggested at the Urbana meeting that connections + should be full-duplex, the committee recommends against this + change. + + 7. Messages should be an integral number of bytes, and the number of + bytes and the byte size should be specified in each message. The + marking convention should be abandoned and the padding ignored. + + The number of bytes in the message should be a 16-bit number + following the leader. The byte size should be in the next 8-bit + field. Two suggestions were generated for the starting point of + the text, and these are explained in the next session. + + For flow control purposes, the number of bits in a message is the + product of the number of bytes and the byte size. The leader and + other fixed format fields are not counted. + + 8. The problem of synchronizing the interrupt signal in a console + input stream was considered. We consider the console input + scanner as a process and note two reasonable implementations: it + may either read characters as fast as it can, looking for the + interrupt character and throwing away characters if there is no + room in the user process' input queue; it may read characters only + as fast as the user process can receive them, (or at least has + room for them). + + The first implementation guarantees that the interrupt character + (e.g., control - C on the PDP-10 10/50) will always be acted on, but + requires that the using process interpret the output stream to detect + + + +Crocker [Page 2] + +RFC 102 HOST/HOST PROTOCOL GLITCH CLEANING COMMITTEE February 1971 + + + when it is sending too fast. The second implementation avoids + overrun but may not allow for sending an interrupt code. Note that + in the first case, allocation is alway renewed as soon as possible by + the console input interpreter; whereas in the second case, allocation + is renewed only as the result of acceptance of data by the user + process. + + We decided that this is really a third-level protocol matter, viz, + use the INS to mean that a special code has been inserted into the + input stream. In conjunction with this, create the special code to + be put into the input sequence. + + This special code would be network-wide and independent of the + particular interrupt character peculiar to the serving system. The + scheme for interrupting a serving process is that the using process + inserts the serving Host's interrupt sequence, followed by the + network special code, and also issue the INS. + +UNRESOLVED ALTERNATIVES + + 1. Length of Control Messages + + In accordance with other specifications, control messages should be + an integral number of 8-bit bytes, the length should be specified in + the byte count field, and control commands should not be split across + messages. + + Unresolved was whether to specially limit the length of control + messages. The two choices are. + + a) no special limit ( ~ 1000 bytes) + + b) 120 bytes + + 2. Message Format + + It was agreed to abandon marking and include the text length in the + form of a byte count and byte size. Unresolved was where to begin + the first byte of data. The two choices are: + + a) have the first data byte begin after 72 bits of leader, byte + count, byte size and spacing. The message format would then be as + in the diagram: + + + + + + + + +Crocker [Page 3] + +RFC 102 HOST/HOST PROTOCOL GLITCH CLEANING COMMITTEE February 1971 + + + <------------16------------> + __________________________ + | | + |_ _ _ _ LEADER _ _ _ _ | + | | + |__________________________| + | | + | BYTE COUNT | + |__________________________| + | | | + BYTE SIZE-----|----> | | + |____________|_____________| + | | | + | |<------------|--Beginning of first + |____________|_____________| data byte + | | + | | + + b) use the double physical transmission scheme presented in + NWG/RFC 67. When sending a regular message, the Host would send a + leader, byte count and byte size and terminate transmission. The + second transmission would be the data. + + At the receiving end, the IMP would transmit 64 bits of leader, + byte count, byte size and spacing, and stop transmission. The + next transmission would be only the data. + +3. Allocation + + With respect to the allocation mechanism embodied in the ALL, GVB and + RET commands, two alternatives were proposed: + + a) make no change. + + b) The flow control algorithm should be changed to keep track of + two quantities: messages and bits. The ALL, GVB, and RET commands + each have two data fields. The ALL command allocates a message + limit and a bit limit. The GVB command contains two fractions, + and the RET command returns both messages and bits. When sending + a message, the sending NCP decrements its message counter by 1 and + its bit counter by the text length of the message. The sending + NCP may not cause either of its counters to go negative. The + message counter would be 16 bits long. + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Gottfried Janik 02/98 ] + + + + +Crocker [Page 4] + -- cgit v1.2.3