Getting rid of marking
RFC 64

Document Type RFC - Unknown (July 1970; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 64 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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)
Show full document text