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/rfc64.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc64.txt (limited to 'doc/rfc/rfc64.txt') diff --git a/doc/rfc/rfc64.txt b/doc/rfc/rfc64.txt new file mode 100644 index 0000000..94535fb --- /dev/null +++ b/doc/rfc/rfc64.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group M. Elie +Request for Comments #64 UCLA + + + Getting Rid of Marking + + + Though we realize that this improvement is perhaps somewhat late +to be implemented, we believe that there exist better solutions than +marking and suggest a simple modification to the IMP-HOST interface +which would avoid it. + +1. The harm. + + Marking was introduced to suit the sending Host because it permits +the text of a message to start on a word boundary, however, it does not +suit the receiving Host with a different word length. Moreover,it +introduces in the message useless bits. Let us illustrate this by the +example of our Sigma 7, a 32 bit machine. + +1.1 Inefficiency in Computation + + Suppose we receive a message from an 18 bit machine (figure 1.1) +coded in 8 bit ASCII characters which will eventually become standard on +the network. In order to translate this message into our EBCDIC +internal code, for instance. + +0 17 0 31 +-------------------------- ------------------------------ +| leader | | leader | +-------------------------- ------------------------------ +| | 0 0 0 1| | 0 0 0 1 | | +-------------------------- ----------- | +| | | | +| | | | +| | | | +| message | | message | +| | | | +| | | | +| | | | +| | | | +| | | | +| | | | + + figure 1.1 + + + + + + + [Page 1] + +RFC 64 Getting Rid of Marking + + +we first have to shift the whole message. We must detect the firsl 1 +following the leader, and from this determine that we must shift the +message 4 bits to the left. This takes approximately 12 µsec per double +word, which makes 1,5 msec per full regular message. This is not huge, +but still it is about one-third of the time it will take to translate +the message in internal code. + +1.2 Inefficiency in transmission + + More important is the inefficiency resulting from adding +unnecessary bits to the message, especially if it turns out that one +character messages are used. Figure 1.2 shows the example of a 1 +character text sent by the sigma 7, which results in transmitting 112 +bits to carry 8 bits of information, thus leading to an efficiency +factor of 0.07. Supression of marking would + + ----------------------------------- + Sigma 7 | leader | + ----------------------------------- + Message |00000000000000000000000000000001 | + ----------------------------------- + | text | 000000000000000000000000 | + ----------------------------------- + 16 bits of padding | 1000000000000000 | + added by sending IMP -------------------- + + figure 1.2 + +increase this efficiency to 0.10. For a 32 bit text (length of some +control commands), it would increase the efficiency form 0.28 to 0.4. +For one packet messages, the efficiency would still be increased by 3%. + +2. A remedy. + + This is a suggested modification of the Host-Imp users interface +which has been tentatively sketched on diagrams extracted form BBN 1822 +report. + + + + + + + + + + + + + + + [Page 2] + +RFC 64 Getting Rid of Marking + + +2.1 Host to Imp + + The modification consists of adding a counter to 32, enabled +as the beginning of a message, and incremented at each bit passed to the +IMP; when it reaches 32 it forces a "word complete" signal asking for a +new word in the shift register and resetting the word length counter; +thus the unused bits in the last word of the leader are not transmitted +and the message starts with the next word (see figure 2.1) + + 0 23 + ------------------------------------------ + | leader | + | ---------------------- + | | XXXXXXXXXXXXXXXX | <- contents of + |----------------------------------------- sending Host memory + | | (24 bits) + | Message | + | | + + Corresponding message in the sending IMP memory + + + 0 15 + -------------------------------- + | | + | | + | leader | + | | + -------------------------------- + | | + | message | + | | + + + figure 2.1 + +2.2 Imp to Host + + The modification consists of adding a counter to 32. When 32 bits +have entered the shift register form the Imp at the beginning of a new +message, the counter allows the register to be shifted up to the point +to be full (which is detected by the word length counter) without +entering any new bit from the Imp. + + + + + + + + + [Page 3] + +RFC 64 Getting Rid of Marking + + +Thus, the next bit of the message which is the first bit of text will be +entered as the first bit of the next word (see figure 2.2). + +Message in receiving IMP memory Contents of receiving Host memory (35 +bits) + +0 15 0 35 +------------------------------ -------------------------------------- +| | | | +| leader | | leader | 0000 | +------------------------------ -------------------------------------- +| | | | +| message | | message | +| | | | +| | | | + + figure 2.2 + +Though the accumulated cost of useless marking bits sent over the +network plus computation to reshape received texts makes this +modification probably whorkwhile being considered, this decision is not +of our competence and we merely wanted to suggest a better solution then +marking. + + + Pages 5 and 6 contain a wire Diagram of a + + "IMP to Host" + + "Host's special Interface" + + + [ This RFC was put into machine readable form for entry ] +[ into the online RFC archives by Gottfried Janik 2/98 ] + + + + + + + + + + + + + + + + + + [Page 4] + -- cgit v1.2.3