summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc64.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc64.txt')
-rw-r--r--doc/rfc/rfc64.txt227
1 files changed, 227 insertions, 0 deletions
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]
+