User-User Protocol (Proposal)

The following protocol is intended to apply to the data bits in messages between the end of the marking bits and the beginning of the padding bits. The present IMP-IMP and HOST-HOST protocols are unaffected by this proposal.

The general principle is that each segment (this is not a technical term) of data is preceded by control information specifying its nature and extent. The basic scheme has been evolved from that used in the SOS buffering system (see the papers in JACM, April 1959 and especially that by O.R. Mock).

Our point of view is that a link is a carrier of information. Information is carried in segments of a fixed maximum length called messages [1]. That this is so is an accident, from the user's point of view; when he wishes to transmit a contiguous stream of data, he will in general, segment it in a different (from the IMP-IMP or HOST-HOST protocol view) manner -- we will call his segment a record. It should be clear that this is entirely analogous between the notion of (physical) block and (logical) record. On the side, file storage systems also make use of control and status information; we will also.

At the USER-USER protocol level, all information transmitted over the link is a sequence of flags followed by (possibly null) data blocks.

The general format will be:

        OPERATION     COUNT     DATA

The OPERATION field is always present and is four bits long. The COUNT field, when present, gives the number of data bytes following in the data block. The byte size is set by the last preceding SIZE flag (in most cases). The byte may be between zero and 255 bits long (Yes, Virginia, zero is zero even when you have a System/360). The OPERATION field and the COUNT field (when present) are called the flag and the data bytes (when present) the data block. Flags followed by data blocks (even when null due to a zero count) are called block flags, and other flags are called whyte [2] flags.

It is to be noted that, since the SIZE flag sets the byte size for the following blocks, byte size may be set at that "natural" for the sending or for the receiving HOST, depending on local agreement between the sending and receiving processes. It is specifically required that a SIZE flag appear in each message prior to any block flag (except the ASCII flag); the SIZE flag may be introduced on a default basis by the routine(s) implementing the protocol and is intended partially as a means of detecting certain classes of error.

The COUNT field is 8 bits in length (except in the EOM flag, where it is 16 bits long). The flags are as follows:

Whyte Flags

Flag	Name	Meaning
0	NUL	No operation (consider next flag)
1	RS	Record Separator (end of record)
2	GS	Group Separator (end of group)
3	FS	File Separator (end of file)
4	ESC	Escape to local convention for flags
5		(reserved for later assignment)
6	EOM N	End of Message (N is total bit count)
7	SIZE N	Byte size is N bits
8	IGNORE N	Ignore following data bits

Block Flags

Flag	Name	Meaning
9	SYS N	N bytes of data for receiving HOST system
10	CONTROL N	N bytes of control data follow
11	STATUS N	N bytes of status data follow
12	LABEL N	N bytes of identification data follow
13	KEY N	N bytes of key data follow
14	ASCII N	N (8-bit) bytes of ASCII data follow
15	BLOCK N	N bytes of data follow

I have already mentioned the requirement for SIZE. Absence of the SIZE flag in any message containing block flags (except ASCII) is a definite error. EOM is partially another error-checking device and partially a device for bypassing the padding conundrum. A user program should never see EOM on input; the user may write an EOM to force transmission. EOM delimits the end of the useful information in the message and restates the total number of bits in the message, starting with the first bit following the marking and ending with the last bit of the EOM count field, to check possible loss of information. This is a check against errors in the IMP-HOST electrical interface and in the HOST mushyware. EOM must appear at the end of each messager, unless ESC has apeared.

ESC is intended as a (hopefully) unused escape hatch, for nonuse by those installations and/or applications wishing to avoid using more than four bits of the USER-USER protocol on any link. For instance, it may be desired to use a link as a bit stream, ignoring even message boundaries. If and when anarchists can achieve local agreement, more power to them!

NUL and IGNORE are intended to be space fillers, in case it is helpful to make the first bit of the subsequent data block occur on a convenient address boundary. (An especially helpful HOST interrupt routine might even paste a combination of NUL and IGNORE over the marking bits when receiving a message -- in which case, their bit count should be transmitted on to the GET routines to correct the EOM bit count check). The separator operations introduce the notions of logical record, group, and file. Specifically, there is no requirement that a record be contained entirely within a message or that only a single record be contained in a message! In addition, there is no requirement that only one file be transmitted during a connection. For instance, a user might wish to use a link to transmit a collection of rountines, and then do something else with the link.

By local agreement, then, a single routine might consist of a number of records forming a group, the whole collection might form a file, and the link might remain connected after the FS flag is received.

The interpretation of the various block flags is similarly open to local agreement. The two flags intended to convey pure data are ASCII and BLOCK; the difference between them is only (as far as the protocol is concerned) that the byte size is implicit for ASCII (8 bits) and explicit for BLOCK (the count field of the next preceding SIZE flag). Beyond this, however, the semantic content of the block following ASCII is governed by the current standards for ASCII; EBCDIC information may not be transmitted in an ASCII block!!

CONTROL and STATUS are intended for communication of control information between user processes, and the interpretation of their accompanying data blocks is open to local agreement. Generically, CONTROL means "try to do the following" and STATUS means "but I feel this way, doctor." A CONTROL flag will prompt a returned STATUS flag, sooner or later, or never. LABEL is intended for use in identifying the following unit(s) of data, at the file or group level. Again, the specific interpretation is a matter of local agreement. KEY is intended to mimic the notion of address or key -- this is at the record, data item, or even physical storage block level. For the familiar with PDP-10 system and/or OS/360, the following parallels are offered for guidance:

   USER-USER protocol      OS/360            PDP-10
   __________________      ______            ______

     CONTROL               OPEN              OPEN

                           CLOSE             CLOSE

     LABEL                 DSCB              File retrieval information

     KEY                   KEY               USETI/USETO argument

     CONTROL               READ              IN/INPUT

                           WRITE             OUT/OUTPUT

                           ALLOCATE ?        ENTER

                           OPEN ?            LOOKUP

     STATUS                ?                 GETSTS

The "?" notations above indicate lack of a very direct parallel. It is worth noting that the OS/360 GET and PUT have direct parallels in any implementation of the USER-USER protocol that embodies the notion of record; our implementation of the protocol will lead to introduction of this notion for all PDP-10 input/output involving disc and tape storage, as well as IMP communication.

If I knew the MULTICS terminology, I could extend the set of parallels above with more precision. Although my terminology has been drawn from systems with explicit input/output imperatives, I wish to emphasize that this setup in intended to handle control and data communication in general; MULTICS is a system in which the classical distinction between external and internal storage is blurred (from the user's point of view) in a manner I wish it blurred in the USER-USER protocol. I offer SYS with only slight trepidation. The general notion is that one should be able to communicate directly with a foreign HOST rather than via a foreign user process as its intermediary. SYS is like a UUO or SVC, but for the foreign HOST's consumption rather than my HOST's. From the HOST's point of view, the problem in implementation is in establishing a process context record unconnected with any local user process. This, however, is strongly associated with our current LOGON conundrum. On the PDP-10, for instance, users are more or less identified with local teletype lines, and any link is not one of those! Hence, subterfuge is necessary to let a foreign user log on. OS/360 is as (actually, more) perverse in its own way.

The process of logging a foreign process onto my local system is not (except possibly for MULTICS) a simple matter of having a special (!!) user job present which is responsible for doing it. When and if anything else is possible, the HOST must provide a system instruction (UUO or SVC or whatever) that gives the requisite information establishing a process independent in all senses of the process that made the request. Otherwise, self-protection mechanisms which are reasonable for any system will make us all much more interdependent that we wish. To do this, there must exist in every system a UUO/SVC that does the right thing (ATTACH, but forget me). If this is true, then the LOGON process over the Network is tantamount to issuance of a foreign UUO/SVC by another node in the Network. I see no reasonable way around this. If that is the case, then SYS N is the kind of flag to use to convey the requisite data. If that is so, then it is only reasonable to let SYS convey a request for any OS instruction at the user program-operating system interface level!

The practical questions of implementation are something else! In the case of the PDP-10, I can pretty well see how to turn a SYS into either a LOGON request to execute a monitor command or UUO (would that they were the same) as the case might be. OS/360 is more sophisticated, unfortunately. MULTICS might make it. Naytheless, I hope that is clear that what we want to do, which is what the protocol should reflect, is quite a different question from that of how it is to be done in the context of a specific HOST system. What we want to do is, in general, rather independent of the system we are dealing with as far as the protocol is concerned, and we should not fail to introduce general notions into the protocol just because we are uncertain as to how they may have to be translated into particular implementation practice.