doc: Add RFC documents

1 files changed, 171 insertions, 0 deletions

diff --git a/doc/rfc/rfc690.txt b/doc/rfc/rfc690.txt
new file mode 100644
index 0000000..ce8fb90
--- /dev/null
+++ b/doc/rfc/rfc690.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                       Jon Postel
+RFC # 690                                                   USC-ISI
+NIC # 32699                                                 June 6, 1975
+
+
+           Comments on the proposed Host/IMP Protocol Change
+
+
+This is a set of comments on Dave Walden's RFC 687 suggesting a set of
+changes to the host--imp protocol.  Dave's points are reproduced here
+with my comments underneath.
+
+1. Expanded Leader Size.  The leader will be expanded from two to five
+16-bit words.  This will provide space for necessary field expansions
+and additions.
+
+    The existing protocols set the host header at 40 bits so that taken
+    together with the leader the length was 72 bits; a nice boundary for
+    both 8 bit and 36 bit machines.  This suggestion would result in a
+    prefix of 80 + 40 = 120 bits, not so nice (unless the host header is
+    extended to 64 bits for a total prefix of 144 bits).
+
+2. Expanded Address Field.  The address field will be expanded to 24
+bit, 16 bits of IMP address and 8 bits of host address.  This expansion
+is more than adequate for any foreseeable ARPA Network growth.
+
+    Just a few years ago 256 seemed like a lot of hosts, perhaps, a
+    extensible scheme might be more appropriate. (I concede 16,777,216,
+    is big)
+
+3. New Message Length Field.  A new field will be added which will allow
+the source host to optionally specify the message length (in bits) to
+the IMP subnetwork.  The IMP subnetwork may be able to use this
+information (when available) to better utilize network buffer storage.
+The destination host may also be able to use this information to better
+utilize its buffer storage.  This field will be 13 bits wide.
+
+    This sound very useful, but if we every want to have longer messages
+    than now the field should be wider, say 16 bits.
+
+4. Expanded Handling Type Field.  The handling type field which now is
+used to distinguish between priority and non-priority message streams,
+etc., will be expanded to eight bits.  This expanded field will provide
+for the possibility of a number of parallel message streams having
+different handling characteristics between pairs of hosts; e.g.,
+priority, non-priority, varying numbers of packets per message (see
+below), unordered messages (i.e. the present type-3 messages), a message
+stream requiring guaranteed capacity, etc, Note that only some of these
+
+
+
+Postel                                                          [Page 1]
+
+RFC 690    Comments on the proposed Host/IMP Protocol Change   June 1975
+
+
+facilities will be available in the near term.
+
+    This sounds like a good extension.
+
+5. Source Host Control of Packets per Message.  The possibility will
+exist for the source host to specify a message stream which will use a
+given number of packets per multi-packet message (e.g. two packets per
+message or five packets per message).  Since the IMP network will not
+have to use eight packet-buffers for reassembly purposes, as at present,
+this may result in better services for such messages.  This will help
+users who need both low delay and high throughput.
+
+    This seems strange, why not use the message length (as provided in 3
+    above) to determine the number of packets needed for this message.
+
+6. Unordered (type-3) Message Change.  Unordered messages will be
+indicated by a handling type rather than by a message type as at
+present.  This is compatible with the need to check the host access
+control capabilities of all messages.  This will provide a slight
+backward incompatibility for the three or so hosts which presently use
+type-3 messages in their research.
+
+    Good, a current special case becomes a general facility.
+
+7. Change in Format of Fake Host Addresses.  The For/From IMP bit will
+be eliminated.  The fake host addresses will be the four highest host
+numbers (e.g. IMP Teletype will be host 252).
+
+    Another change for the better.
+
+8. Addition of a Parameter to the IMP to Host NOP.  The IMP to host NOP
+will have added to it a parameter specifying the address (IMP and host
+number) of the host.
+
+    Ah, a clever touch, very handy.
+
+9. Backward Compatibility.  The old and new formats will be supported in
+parallel in the IMPs for the foreseeable future to allow gradual
+phaseover of host software.   A host will be able to specify to its IMP
+whether the old or new formats are to be used; thus, it will be possible
+for the host to specify switching back and forth between the two modes
+for debugging purposes.  The specification of the mode to be used will
+be possible via a proper choice of format in the host to IMP NOP
+message;  The IMP will use the mode of the Host to IMP NOP message the
+IMP has received.  Further, a host may select to use either the old or
+new format without needing to know more about the other format message
+than to discard them should they arrive.  The IMP will initialize by
+sending several NOP messages of each type to give the hosts its choice.
+
+
+
+Postel                                                          [Page 2]
+
+RFC 690    Comments on the proposed Host/IMP Protocol Change   June 1975
+
+
+Although a host not implementing the new format will not be able to
+address hosts on IMPs with IMP-number greater than 63, the IMPs will
+wherever possible do the conversion necessary to permit hosts using the
+old format to communicate with hosts using the new format and the
+reverse.  Finally, it will be possible to convert the leader format from
+old to new or the reverse without knowledge of the message type.
+
+    This sounds difficult to implement, but it is all in the imp, so
+    fine.  Of course, something along these lines is crucial in an
+    operating environment.  But I am beginning to get concerned about
+    changes to host--host protocol and network control programs.
+
+[What happened to 10?]
+
+11. Non-blocking Host Interface.  A mechanism will be provided which
+allows the IMP to refuse a message from a host without blocking the host
+interface.  This mechanism will permit the IMP to gather the necessary
+resources to send the refused message and then ask the host to resend
+the message.  Finally, the host will be permitted to ask to be able to
+send a message and be notified when it is possible without requiring the
+message to actually be sent and refused.
+
+    This is another welcome addition.
+
+12. Maximum Message Length.  The maximum number of bits of data in a
+message may be reduced by a few bits.
+
+    I don't see why, but it doesn't matter much.
+
+On the whole a fine set of suggestion, though I am concerned about
+changes to host--host protocol implied here or made more desirable by
+these suggestions.  A rough guess is that there is easily a couple of
+person-months of system programmer time for each operating system on the
+net implied here.  Say 24 systems times 2 person-months each equals 48
+person-months equals 4 person-years.  And this may be the lower bound.
+
+
+
+
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by Alex McKenzie with    ]
+       [ support from GTE, formerly BBN Corp.            11/99 ]
+
+
+
+
+
+Postel                                                          [Page 3]
+