home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc64.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  7.6 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  M. Elie
  8. Request for Comments #64                               UCLA
  9.  
  10.  
  11.                          Getting Rid of Marking
  12.  
  13.  
  14.       Though we realize that this improvement is perhaps somewhat late
  15. to be implemented, we believe that there exist better solutions than
  16. marking and suggest a simple modification to the IMP-HOST interface
  17. which would avoid it.
  18.  
  19. 1. The harm.
  20.  
  21.       Marking was introduced to suit the sending Host because it permits
  22. the text of a message to start on a word boundary, however, it does not
  23. suit the receiving Host with a different word length. Moreover,it
  24. introduces in the message useless bits. Let us illustrate this by the
  25. example of our Sigma 7, a 32 bit machine.
  26.  
  27. 1.1 Inefficiency in Computation
  28.  
  29.       Suppose we receive a message from an 18 bit machine (figure 1.1)
  30. coded in 8 bit ASCII characters which will eventually become standard on
  31. the network.  In order to translate this message into our EBCDIC
  32. internal code, for instance.
  33.  
  34. 0                        17           0                           31
  35. --------------------------            ------------------------------
  36. |        leader          |            |           leader           |
  37. --------------------------            ------------------------------
  38. |               | 0 0 0 1|            | 0 0 0 1 |                  |
  39. --------------------------            -----------                  |
  40. |                        |            |                            |
  41. |                        |            |                            |
  42. |                        |            |                            |
  43. | message                |            | message                    |
  44. |                        |            |                            |
  45. |                        |            |                            |
  46. |                        |            |                            |
  47. |                        |            |                            |
  48. |                        |            |                            |
  49. |                        |            |                            |
  50.  
  51.                             figure 1.1
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC 64                   Getting Rid of Marking
  61.  
  62.  
  63. we first have to shift the whole message. We must detect the firsl 1
  64. following the leader, and from this determine that we must shift the
  65. message 4 bits to the left. This takes approximately 12 ╡sec per double
  66. word, which makes 1,5 msec per full regular message. This is not huge,
  67. but still it is about one-third of the time it will take to translate
  68. the message in internal code.
  69.  
  70. 1.2 Inefficiency in transmission
  71.  
  72.       More important is the inefficiency resulting from adding
  73. unnecessary bits to the message, especially if it turns out that one
  74. character messages are used. Figure 1.2 shows the example of a 1
  75. character text sent by the sigma 7, which results in transmitting 112
  76. bits to carry 8 bits of information, thus leading to an efficiency
  77. factor of 0.07. Supression of marking would
  78.  
  79.                             -----------------------------------
  80.    Sigma 7                  |           leader                |
  81.                             -----------------------------------
  82.    Message                  |00000000000000000000000000000001 |
  83.                             -----------------------------------
  84.                             | text | 000000000000000000000000 |
  85.                             -----------------------------------
  86.    16 bits of padding       | 1000000000000000 |
  87.    added by sending IMP     --------------------
  88.  
  89.                                 figure 1.2
  90.  
  91. increase this efficiency to 0.10. For a 32 bit text (length of some
  92. control commands), it would increase the efficiency form 0.28 to 0.4.
  93. For one packet messages, the efficiency would still be increased by 3%.
  94.  
  95. 2. A remedy.
  96.  
  97.       This is a suggested modification of the Host-Imp users interface
  98. which has been tentatively sketched on diagrams extracted form BBN 1822
  99. report.
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. RFC 64                   Getting Rid of Marking
  117.  
  118.  
  119. 2.1 Host to Imp
  120.  
  121.       The modification consists of adding a counter to 32, enabled
  122. as the beginning of a message, and incremented at each bit passed to the
  123. IMP; when it reaches 32 it forces a "word complete" signal asking for a
  124. new word in the shift register and resetting the word length counter;
  125. thus the unused bits in the last word of the leader are not transmitted
  126. and the message starts with the next word (see figure 2.1)
  127.  
  128.    0                                       23
  129.    ------------------------------------------
  130.    |             leader                     |
  131.    |                   ----------------------
  132.    |                   | XXXXXXXXXXXXXXXX   | <- contents of
  133.    |-----------------------------------------    sending Host memory
  134.    |                                        |    (24 bits)
  135.    |            Message                     |
  136.    |                                        |
  137.  
  138.    Corresponding message in the sending IMP memory
  139.  
  140.  
  141.    0                             15
  142.    --------------------------------
  143.    |                              |
  144.    |                              |
  145.    |         leader               |
  146.    |                              |
  147.    --------------------------------
  148.    |                              |
  149.    |   message                    |
  150.    |                              |
  151.  
  152.  
  153.                                 figure 2.1
  154.  
  155. 2.2 Imp to Host
  156.  
  157.       The modification consists of adding a counter to 32. When 32 bits
  158. have entered the shift register form the Imp at the beginning of a new
  159. message, the counter allows the register to be shifted up to the point
  160. to be full (which is detected by the word length counter) without
  161. entering any new bit from the Imp.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. RFC 64                   Getting Rid of Marking
  173.  
  174.  
  175. Thus, the next bit of the message which is the first bit of text will be
  176. entered as the first bit of the next word (see figure 2.2).
  177.  
  178. Message in receiving IMP memory  Contents of receiving Host memory (35
  179. bits)
  180.  
  181. 0                        15      0                                   35
  182. ------------------------------   --------------------------------------
  183. |                            |   |                                    |
  184. |       leader               |   |     leader                  | 0000 |
  185. ------------------------------   --------------------------------------
  186. |                            |   |                                    |
  187. | message                    |   | message                            |
  188. |                            |   |                                    |
  189. |                            |   |                                    |
  190.  
  191.                                figure 2.2
  192.  
  193. Though the accumulated cost of useless marking bits sent over the
  194. network plus computation to reshape received texts makes this
  195. modification probably whorkwhile being considered, this decision is not
  196. of our competence and we merely wanted to suggest a better solution then
  197. marking.
  198.  
  199.  
  200.             Pages 5 and 6 contain a wire Diagram of a
  201.  
  202.                     "IMP to Host"
  203.  
  204.                 "Host's special Interface"
  205.  
  206.  
  207.        [ This RFC was put into machine readable form for entry ]
  208. [ into the online RFC archives by Gottfried Janik 2/98 ]
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228.