RFC 928

Part 1 of 6 🎀

Okay bestie, here's the deal with this doc. It's RFC 928, written by M. A. Padlipsky of Mitre Corp. in December 1984, and the title is INTRODUCTION TO PROPOSED DOD STANDARD H-FP 💅. It's a proposal, not a finished standard. The header doesn't have a category line, and it doesn't list anything it obsoletes or updates, so it's just a standalone intro 🦋.

Status Of This Memo ✨

This RFC suggests a proposed protocol for the ARPA-Internet community, and it's literally asking for discussion and suggestions for improvements 💖 Distribution of this memo is unlimited, so share it with everyone 🌈

Important Prefatory Note 🫶

Okay so the broad outline of the Host-Front End Protocol (H-FP) that's introduced here, and described in RFC 929, came from a bunch of experienced H-FP designers. They sat as a committee of the DoD Protocol Standards Technical Panel, and the author chaired it 👑 The specific protocol in this doc came from a smaller ad hoc group that acted as a de facto subcommittee of that H-FP committee, also chaired by the author 🧚 It follows what the full group agreed the new H-FP should "look like," but it didn't get the super thorough study from a big crowd of experienced H-FP designers and implementers 😭 (Several of them did look at it before it went out as an RFC, though! 🙈)

Even if that hadn't happened, the designers always meant for this protocol to go through multiple test implementations and probably some iteration before anyone agreed on it as any sort of "standard" 💅 So the first order of business is to say it loud: > THIS IS A PROPOSAL, NOT A FINAL STANDARD 🚨 The second order of business is asking any readers who can do test implementations to (a) actually do them and (b) coordinate with the author at 617-271-2978 or Padlipsky@USC-ISI.ARPA. 📞🍓

Historical/Philosophical Context 🦋

Okay, story time. Late in May of 1971, the author was giving a status report on whether the Multics ARPANET implementation would be ready by the July 1 deadline the sponsor had announced earlier that month 📅 Things got a little messy because the Multics "NCP" (Network Control Program, which is actually a blanket term covering the Host-Host and Host-IMP protocol interpreters) didn't queue requests for connections 😬 The spec said that topic was up to implementors, so the author tried to dodge the argument by asking the interrogator what he was up to these days 🙈 The answer was, "Oh, I'm working on the High-Speed Modular IMP now" (which later became the Pluribus IMP) ✨ And then the proverbial coin dropped 🪙 The author replied, "I've got a great idea. Now that we've got some space to program in the IMP, why don't we separate out most of the NCP and do it outboard: the only thing that really matters in the Host is associating sockets with processes, and if we had common implementations of all the bit-diddling stuff in the IMPs, we wouldn't have disputes over the interpretation of the spec and we'd also save a lot of Host CPU cycles!" 🤯💜

As far as the author knows, that moment was the start of what became known as "Network Front-Ends" and, more recently, "Outboard Processing Environments" 🌸 The name change happened because people kept mixing up NETWORK Front Ends with traditional communications front-ends. NETWORK Front Ends were always meant as distributed processing setups for offloading intercomputer networking protocols from Hosts, while traditional communications front-ends had no connotation of protocol interpreters that Host-side programs could invoke 💅 The idea was originally his, and he later became a principal designer and the primary author of the first Host-Front End Protocol 👑 So yeah, this doc might be a little marred by parental pride 🙈 but if you like primary sources.... 🫣📚

The evolution of the outboard processing idea has been covered elsewhere [1]. For now, it's enough to know that about half a dozen implementors of "NFE's" of various kinds have been successful, as far as the author knows ✨ The question of why you'd use an explicit protocol in the first place (instead of emulating a device, or devices, the Host and operating system already know about) deserves a bit of explanation too 🧐 [2] covers it in more general terms. The big deal is that in the general case you end up "not doing real networking" if you hook a Host up to a network through known device emulation 😭 Here, real networking means what the ARPANET literature calls "resource sharing," and what the ISO literature seems to call "open system interconnection" 🌐 Operating systems have built-in assumptions about known devices (terminals, terminal controllers, or RJE stations), and those assumptions get in the way of the process-process and eventually procedure-procedure communication that's the basis for apps more interesting than simple remote login 💀 If you haven't done outboard processing, the idea that you should attach through an explicit protocol might be hard to swallow, but if you've done it, it makes perfect sense 🫶

Now, to the people who've worked on intercomputer networking with inboard (Host-side) protocol suites: yes, outboard processing often seems to give less than optimal results, especially for maximizing throughput 🤔 And it's hard to argue that a Host that's properly fine-tuned to "do networking" could somehow get better networking by adding an extra processor 💅 BUT, for Hosts where conserving CPU cycles is an issue, or where memory is scarce (meaning it's worth conserving the resources being shared), outboarding is clearly the way to go 👑 Also, if you view outboard processing correctly, as a form of distributed processing, then even for super powerful "intelligent work stations"/"personal computers" with resources to spare, it still makes sense to outboard. That way you don't have to write brand new implementations of entire protocol suites for every new system 🎀 This is always assuming, of course, that the Host-Front End protocol in play is noticeably less complex than the protocols being offloaded ✨

None of this means outboard processing is the ONLY way to do intercomputer networking, obviously 🙃 It does mean outboard processing can be really advantageous in a bunch of different contexts 🌈

Also, with microprocessors and Local Area Networks both showing up, a generic bus interface unit that also plays the role of an NFE (an Outboard Processing Environment) makes the original goal of "offloading to the IMP" actually happen 🦋 That means you don't need a free-standing, possibly pricey NFE sitting between the Host and the net 💖 Oh, and nothing in the OPE approach says that ALL Hosts have to use OPEs 💅 The only protocols "seen" past the Comm Subnet Processor are the common intercomputer networking protocols (for example, all DDN IMPs see and read IP datagrams) 👀 H-FP is strictly between a Host and its OPE 🫶

It's also important to know that with several different protocol suites out there in the networking world, the only reasonable way to get "interoperability" might be to use a suitable H-FP (like the one presented in the companion RFC) plus an Outboard Processing Environment that can invoke protocol suites in parallel 🧚 The choice of suite for a given connection would depend on the native suite of the target Host and/or application, of course 🍓

Okay, so the unquestionable advantages of this approach, based on ten or more years of experience and analysis, are as follows 📚 (Always remember the assumption that the work to implement and run the H-FP in play is small compared to the full protocol suite in question 🙈) First, a common implementation of a protocol suite has the automatic advantage of mutual consistency ✨ Second, especially in the DOD context, it's way easier to procure common implementations of standard protocols than to procure different ones for each Host type 💸 Also, if the resources being shared are the participating Hosts' CPU cycles and memories, those get conserved by doing as much of the networking protocols as possible in an OPE instead of the mainframe 🧠 Another, less obvious advantage is that having an OPE effectively insulates a Host from changes in the outboarded/offloaded protocols 🛡️ Or even changes of protocols, in case the nascent international protocol standards ever mature enough to replace the DOD standards in place 🌍 For example, given an abstract enough interface (in the spirit of the Principle of Layering), a Host could go from doing TCP as its "Host-Host" protocol to, say, ECMA Class 4 as its "Transport" protocol without really noticing the change 😳 That's true even though the change would be pretty unattractive to fans of the APRANET Reference Model, like the author. See [3] for more on the implied "Reference Model" issues 📖 Finally, there are a few more specialized points too, but it's worth noting that for network security architectures that depend on controlling all means of egress from and ingress to "the net," uniform use of OPEs is clearly desirable 🔐🔥

So if we agree an OPE is, or can be, a good thing, the remaining question is what protocol a Host and its OPE should interpret 💭 A standard protocol is desirable so there can be as much commonality as possible among Host-side interpreters of it 🫶 The goal is paradigmatic H-FP PIs that can be integrated fairly straightforwardly with various operating systems 🎀 It also means being able to transplant an H-FP PI from one instance of a given operating system to other instances of the same system, much like what's currently being attempted in the DODIIS NFE program ✨ Again, the main motivation in the DOD context is minimizing procurement problems 💅💖

Technical Context ✨

okay so bestie, quick recap of the backstory 💅. Some half-a-dozen Host-Front End protocols (H-FPs) had been seen by the author 👀. Then in December of 1982, a meeting got called so the people who built those H-FPs could compare notes 📝. The goal was a proposal for a DOD standard H-FP, and this paper is the direct result of that meeting 🦋. In this section we're sharing what the meeting agreed on for the broad outline of the protocol. The accompanying document has the current version of the proposed protocol in full detail, written up by the author and Richard Mandell and Joel Lilienkamp (both of SDC) 🎀.

Okay, side quest 🙈. We should probably have renamed H-FP to H-OPEP (or something) since we're trying to stop saying "NFE" and start saying "OPE" 🌸. But the habit of saying "H-FP" is too deeply ingrained at this point 😭. Also, H-OPEP looks rather silly, so, no hard feelings 💖.

Now, a final preliminary, and it's an important one 🔥. All the designers and implementors of H-FPs at the December meeting agreed that the true test of any protocol is how well it actually implements ✨. So until several implementations of the "new" protocol have been built and assessed, the proposed protocol is precisely that: a proposal, not a standard 🫶. Not a finished product, babe.

Okay, here's the first thing everyone agreed on, and it's a big one 👑. An H-FP has three separable aspects, or "layers" 🧚. At the very bottom, there has to be some physical means of conveying bits from Host to OPE and from OPE to Host 🌈. Outboard processing has always been built on the premise that the Host's convenience is paramount, so the physical layer can vary. Typically a bit-serial interface is the norm 📟, but parallel/DMA interfaces are totally fair game, as long as the Host has them and they can be interfaced to a given OPE 💜. (Teleporting the bits would also count, for that matter 🛸.)

In the middle, there has to be a layer that manages multiplexing of network "connections" and controls the flow between Host and OPE 🍓. If we call the lowest layer the Link and the middle layer the Channel, then something really needs to be noted: between the two of them, the Link and Channel layers must be responsible for reliably conveying the bits between Host and OPE 💀. Think about it, bestie. An OPE'd Host shouldn't be "weaker" than one with an inboard implementation of a robust Host-Host protocol like TCP 😤. That would be so not iconic.

Here's a fun one 🦋. Any Host that "comes with" a suitable implementation of the X.25 interface protocol (and "suitable" is way too complex to unpack here 🙃) could, given an OPE set up to accept it, cheerfully satisfy the requirements of the lower two layers 💅. That does NOT mean X.25 is the mechanization of the H-FP's Link and Channel layers, though. It just means it could be used 🌸. The protocol spec itself will detail an alternative, less cumbersome channel layer for Hosts that don't have or want X.25 ✨.

Now the top layer, which is the most important one, no cap 👑. We call it the Command layer 💖. This is where the peer H-FP modules in a Host and an OPE talk to each other 🫶. The reason the Channel layer is kept to JUST multiplexing, flow control, and reliability is partly that it's easier for Hosts that already have preexisting software or hardware that could be turned to the purpose 🎀. But it's also so we can be clear about "what the H-FP is" 🔥. It's the commands and responses of the Command layer that let the Host's processes manipulate the outboard implementations of the members of a protocol suite 🧚. And the phrase "commands and responses" is actually a big deal, as it happens 👀. For the protocol proposed for DOD standardization, unlike all but one of its predecessors, binary encoded "headers" are NOT employed 🙅‍♀️. Instead, the H-FP commands are ASCII strings, and the responses (following the practice of ARPANET FTP) are ASCII-encoded numbers 💜.

Why the departure? It started with a desire to have the same NFE be usable for terminal traffic as well as Host offloading 🌈. But the reason that dominated when consensus was reached on it as the basis for the new standard is that it's very much in the original spirit of H-FP 💅. If you want to "make things as easy as possible for the Host," it makes total sense to offload in a way that only requires some sort of scenario or script in the Host ("exec-com"/"command file"/"shell command" are approximations on some systems ✨). That's way better than requiring a program that might be more complex than anyone wants 😭. This doesn't mean we picture all, or even most, Hosts taking the scenario approach 🙈. It just means the command orientation makes that possibility available 🦋. (And it's worth remembering that the Channel layer handles all the multiplexing and demultiplexing, so each channel's state machine, at least on the Host side, really has very little to worry about other than "doing its thing" 💖.)

Next up, the proposed protocol provides a mechanism for offloading "all" protocols 🔥. Most "first generation NFEs" only handled ARPANET Reference Model Layers II and I (Host-Host and Network Interface, roughly ISO levels 4-1, with some of L5's functionality included when it comes to service identification via Well-Known Sockets in L II) 🧚. But OPEs are assumed to evolve to handle L III offloading too (ISO 5-7) 🌸. Also, what's being addressed here is "the protocol," not "the" OPE 👑. More will be said on this below and in the protocol spec itself 📝. But it's important to get this from the start: the H-FP being proposed is meant to be implementable by any number of OPE suppliers and vendors 🫶. So "an" OPE may or may not choose to implement a given file transfer protocol, for example 🎀. As long as it says so in proper H-FP terms and offloads some other protocols, it's still an OPE in our sense of the term 💅. (Cf. "Issues" and "Non-Issues," below. 🌈)

Issues ✨

okay so bestie, here are the items that are either still open questions or that the author really wants you to look at 👀 💅

Command Approach

🎀 okay this one is the most striking thing about the new H-FP, especially if you've seen the older ones. Instead of the usual binary-style headers at the Command Layer, the new one uses character-oriented commands (text, basically) 📝 The main reason is that this approach worked really well in an H-FP for the Platform Network called NAP (Network Access Protocol) [4]. The author talked with NAP's originator, Gerry Bailey, and came away convinced it was fundamentally reasonable 🦋 (but ngl, that doesn't mean everyone else has to be convinced 🙈)

Then the author chatted with Gary Grossman, who came up with the DCA/DTI H-FP [5]. That one is probably the best-known current H-FP, and it's where the default Channel Layer for the new one came from 🌸 Gary's input gave a few more reasons:

• Parsing is easier. With text, it's simpler to find where variable-length parameters end. 💖
• Terminal-supporting OPEs get easy. If any OPE developer wants to make one, the text approach makes it very straightforward. (More on the difference between OPE developers and H-FP implementors below! 🧚)

And honestly? There's nothing sacred about binary headers. Just because text is different doesn't make it "wrong" ✨ So the new protocol could back off from text if reviewers or implementors come up with compelling reasons, but the very common reaction of "it feels funny" is not one of those reasons 😭 (It was the author's own first reaction too, tbh 🙈)

Also, "nobody" (not even Gary) really liked the top layer of the DCA/DTI H-FP. Iconic behavior from everyone 💀

X.25 Appropriateness

Okay, so how the text "feels" matters less than whether X.25 actually works 🔥 A lot of system proprietors would really love to use "off-the-shelf" software and hardware as much as possible and still do intercomputer networking according to DOD Standards. That's a big reason the team pulled the H-FP commands out of the Channel Layer of the DCA/DTI H-FP, even before deciding to encode them as text 💅

BUT. It is by no means clear that any random vendor-supplied "X.25" will automatically be usable as a new H-FP Channel and Link layer mechanization 😬 It all depends on how Host programs (the Command Layer/H-FP Protocol Interpreter in particular) are able to invoke X.25 on particular systems. There could also be weird quirks in how some constructs are handled. The Group and Member fields (or whatever they're called, lol) are a strong candidate for causing trouble, because they could get in the way of pulling just demultiplexing and flow control out of X.25-as-Channel Link/Layers 🙃 And on some systems, only one process can "own" the presumed DCE, but there's no interprocess communication between that process and the processes that want to use H-FP. Rude 💀

So the author isn't pretending to be an expert in every vendor-idiosyncratic X.25 implementation. The honest claim is just that we THINK the new H-FP Command Layer should fit "on top of" X.25 in a Host. A suitably crafted OPE could look like a DCE to the low-level Host software and still be an OPE in our sense of the term ✨ Last thing: some reports on bit-transfer rates through typical X.25 interfaces make it a little worried whether this whole setup would even be "good" if it were feasible 😭

DCA/DTI Channel Layer Appropriateness

The Channel Layer of the DCA/DTI H-FP has already been implemented for a few Host types, and it's being implemented for others (notably as part of the DODIIS NFE project) 🌈 Now here's the tricky decision: should the header structure change? For example, should the now-superfluous command and response fields be removed?

On the "con" side, implementations DO exist, and the spec is well specified 📚 On the "pro" side, keeping the header as it is feels kinda "wasteful," and somebody's going to have to go over the spec again anyway to remove the stuff that no longer applies 🧹

Fun fact: Gary Grossman was initially tempted to scuttle the Group and Member trick, but the presence of a similar dichotomizing in X.25 seems to rule that out 🤭

So one of the most interesting questions during the review phase will be which way to go on the Channel Layer header in its non-X.25 version. (NOBODY considers going X.25 only, just so you know 🙅‍♀️) Once the protocol is finalized, the protocol spec will make it clear. The author will probably still keep this discussion in the final version of the Introduction, just for historical interest 📜🦋

Syntax

Another thing that probably needs close scrutiny during review is the "syntax" of the command lines 👀 Basically, the team just took their best shot, without claiming it's the best possible way to express things 🤷‍♀️ So comments and/or alternatives are earnestly solicited on this one 🫶

L III Offloading

Plot twist: contrary to what some people expected, the new protocol does allow for offloading Process/Applications Layer (ARPANET Reference Model L III) protocols 🎉 Both Bailey and Grossman reported favorably on whether this is feasible. Two things to note, though:

• It's perfectly fair for a GIVEN OPE implementation not to offload a given L III protocol. It probably wouldn't sell as well as the ones that do, though 💸
• Just because the spec includes a mechanization of the feature doesn't mean we're forcing a constraint on everybody who implements "the protocol" 🙅‍♀️ (Cf. Fabrication under Non-Issues, below.)

Just like with syntax in general, the team is really still feeling their way on the L III stuff 🧭 (The author isn't even sure they managed to explain what they meant by "mediation level" to Joel and Dick 🙈) Again, suggestions are solicited 💜

Security

Okay, this one is serious, so buckle up 🔐 During the detailed design pass, the team had an intense discussion with some folks from the Blacker design team about how the new H-FP interacts with a meant-to-be multilevel-secure OPE like Blacker. The conclusion was that, by and large, "Security" is meant to be an aspect of an enhanced H-FP, not the standard one. The reasoning was pretty involved, but it seems to come down to this:

• Hosts that are NOT MLS (or "Compartmented") have two big properties in this context. First, they make up the vast majority of present-day systems 📊 Second, they have no legitimate need to even tell their OPEs what they "think" their current System High or Dedicated Mode level is. That info should come from some trusted part of a network security architecture (for example, a security enhanced OPE, or a table in a "secure" comm subnet processor) 🔒

So even having the optional security label/level field in the Begin command is kinda overkill 🙃 The author isn't sure of any sensible situation where it would be useful, but it went in "just in case" 🤞

On the flip side, Hosts that ARE MLS/Compartmented by definition can be allowed to assert what the level of a given transmission (or maybe a given connection) should be, and their OPEs need some way to learn this 👑 But it's not clear that a given Host (or even a given OPE) will be structured so that the H-FP PI, the Channel PI, and the Link PI are ALL trustworthy. That would have to be the case if the security labeling were part of H-FP, which is why the team instead envisions the labeling being handled by trusted code in both the Host and the OPE. That code would be inserted into the normal processing route at the right point for the given architecture (presumably "at the very bottom" of the Host and "the very top" of the OPE). It would then place the label in a convenient, known position in the Host-OPE transmission "chunk" (block/packet/data unit), depending on the circumstances 📦

(It's likely, but the author wouldn't swear to it, that a good spot is just before the H-FP command. If that's the case, then the security enhanced H-FP PIs would have to "make room" for it by handing the Channel Layer a suitably lengthened "chunk" 📏)

For the non-MLS/C case, the Host and its OPE should be viewed as a single entity when it comes to labeling requirements. Either the OPE will be conditioned to emit the right label, or the CSNP will "know" anyway 🧠

For the MLS/C case, it's just about impossible to imagine an outboarded MLS/C Host that DOESN'T have an MLS/C OPE 🙃 Whether each "chunk" needs labeling depends on the given security architectures. There COULD be trusted H-FP, Channel, and Link PIs, so that the label only needs to be passed at channel establishment time. But it seems likely that each "chunk" would need labeling, and the team can see how that would happen (as sketched above) 🎀

This is all subject to reappraisal when the full-time Security folks get involved 🫡 For now, though, H-FP per se is seen as playing no direct role in "Security," except indirectly, as noted below under the Symmetric Begins Non-Issue. (Also, in case anybody's worried about the case where the OPE is physically remote from its Host: that line would have to be protected anyway, so the view of the Host and OPE as a single unit should still hold up 🔏)

How It Implements

Last but definitely not least 🌟 One of the central premises of the Outboard Processing approach has always been that H-FPs can be invented that implement more compactly on the Host side than the code they're allowing to be offloaded 💪 The author definitely thinks the new H-FP will meet that condition. But if anyone has evidence to the contrary, they'd really like to hear it 👂💜

Non-Issues ✨

Okay bestie, this section is all about the stuff people kept stressing over that we're officially calling non-issues 💅. Some folks were genuinely worried about these, but we think they're either "not part of the protocol" or already sorted out for reasons the worriers just didn't clock 🙈

Fabrication

Who builds OPEs? Not our department 💁‍♀️ The only thing we're hoping for is that a few volunteers step up to do testcase implementations, because right now the whole thing is only a paper protocol 📄 We did agree that a few points should get marked as "Notes to Entrepreneurs" in the spec, but we didn't try to dictate how an OPE vendor behaves beyond what the protocol already says, explicitly or implicitly 🎀

For example, if an OPE doesn't offload SMTP, it jolly well ought to respond with the "Function not implemented" code 😤 And if a vendor claims to accept X.25, the question of what X.25 "is" for Channel and Link disagreements is the province of the vendor and the customer, not of the H-FP spec 🤷‍♀️ OPEs are supposed to be offloading COMMON protocols in a COMMON fashion, so an OPE should be able to interoperate with another Host whether or not that Host even has an OPE, and we definitely don't care whose OPE it is if it does 🫶 So even though you'd expect OPEs that "come with" their own LANs to be a pretty frequent product, we don't lean on that idea in the conceptual model, and we don't try to dictate "chunk" sizes at the Channel level either 🧚 A protocol spec isn't an implementation spec, babe 💜

Symmetric Begins

Ugh, this one has been fought over for basically as long as H-FPs have existed 😭 The debate is whether only the Host can begin a connection, or whether the OPE can take the initiative too. I'm SO happy to finally settle it ✨ There IS a compelling reason to make THE PROTOCOL include provision for OPE --> Host Begins, so it's "in" the protocol 🔥 But any Host that doesn't need to deal with them doesn't have to. It just has to spell the "Function not implemented" response code correctly 💅

(Okay, in case anyone's curious, the compelling reason is this 👀 If you had an MLS OPE that happened to use a security kernel and a process per level, IT would need to be listening for incoming connection requests "from the net," instead of having the Host tell it to do so, for various esoteric reasons 🧠 We still want the function in the protocol from the very beginning, because we can picture SOME other uses for it even in non-MLS environments. The security labeling trick from earlier is different, though 🙈 It only seems to make sense for MLS Hosts/OPEs. Rejecting a Begin every once in a while doesn't burden the Host, but going around labeling "chunks" unnecessarily all the time absolutely would, so no thank you 😩)

Routing

People have raised concerns about what the protocol should do when a Host, probably for traffic or load reasons, has multiple OPEs and has to figure out which OPE to route to 🚦 I'm calling this a non-issue at the protocol level 💖 If the Host-side H-FP PI gets a "No resources" response to a Begin, it can just go off and try another OPE if it wants to. Simple as that ✨

The conceptual model is a Host and AN OPE, and that OPE "ought to" be expandable to carry more load at some level 🌸 If you want multiple links for some reason, the simplest-looking solution would be to have multiple Channel Layers too, but honestly the whole thing gets too iffy to prescribe anything sensible in the protocol 😵‍💫 So extending the concept to discrete multiple OPEs is either a Fabrication sort of thing, or a Notes to Host-side Implementors sort of thing, handled on a per-specific-OPE basis 🍓

Operator Interface

This one is probably implied by everything above, but it's worth saying out loud 📣 The operator interface to a specific OPE is a non-issue in terms of the protocol 🦋 The only thing we did is make provision for "Shutdown coming" responses, which reflect a probable operator interface action that we imagine most operator interfaces would offer.

Also, if your Host does "color changes," your OPE had better have a trustworthy way of being told to change the label it plops on all IP datagrams it emits 🏷️ That one comes under the heading of an Aside to Specialized Implementors, so it's not in the main spec, but it's definitely a lowkey important vibe check 💀

Fine Points 👑

There are a couple of known "loose ends" that are exceedingly fine points in some sense, but they do deserve their own mention 🫶

The Allocate Event

While I was mentally testing whether the new H-FP would actually off-load TCP, we ran into an interesting question 🤔 If you view H-FP as "just an interface at a distance" to a TCP PI, then what about the Allocate "Interface Event" in the TCP spec? I think this one could honestly be classed as a non-issue, because the TCP spec is wrong to declare that there is such a thing as a MANDATORY Interface Event, where the user of a TCP PI lets the PI know how much data it can take 😤 Sure, most implementations probably have it. But what if you're in a virtual memory environment with segment sharing (or a distributed supervisor), and you want to avoid copies, so all that gets passed at the interface to the PI (or even at the interface from the PI) is a pointer? 🧚 The "DOD version" of the TCP spec fell into the trap of assuming things about the execution environment that it shouldn't have 💅

One moral of this is:

AN INTERFACE TO AN INTERPRETER OF A PROTOCOL IS N*O*T "THE PROTOCOL". 🚨

Another moral is that the interface to the Host-side H-FP PI is hard to say much about, but it's exactly where the equivalent functionality will show up if you've offloaded TCP 🎀 It's reasonable to let the user "tell" the outboard PI at Begin time whether big or small buffers are expected to be in play net-ward, as part of the protocol 🌈 The outboard PI is expected to deliver bits to the Host as they come, unless it gets throttled by the Channel Layer, or by some other discipline we haven't invented yet that forces the OPE to buffer. For now we're picturing the Channel Layer handling it, but nifty mechanizations of encouraging the OPE to "make like a buffer" would at least get looked at 🍭 As a Fabrication issue, "equity" has to be dealt with regarding the use of the OPE's resources (especially buffers) across H-FP connections/channels. That's a different issue anyway, and it gets touched on in the final fine point 💜

Precedence

Obviously, the existence of a notion of Precedence in DOD protocols has to get reflected in the outboard PI's implementations 🎖️ But what role it plays in the H-FP itself? Honestly, that's by no means clear 😵 Say the Host doesn't take Begins from the OPE, and it's "full up" on the number of Server Telnet connections it's willing to handle. What should happen if a high precedence SYN comes in on the Telnet Well-Known Socket (in present day terms)? 👀 Probably the OPE should arbitrarily close a low precedence connection to make room for the new one, and signal the Host. But even that assumes the Host will always hurry to be prepared to do a new passive Begin 😬 Maybe we've stumbled across yet another argument in favor of "Symmetric Begins"... 🔄 At any rate, Precedence does need further study. It shouldn't stop us from making "the rest" of the protocol work while we wait for inspiration on how to handle Precedence too ✨

A Note on Host Integration 🏠

The most important thing about Hosts in any intercomputer network is that they furnish the resources to be shared 🎁 The biggest obstacle to sharing those resources, though, is that almost invariably they were designed under the assumption that the Host was a fully autonomous entity 😤 Few operating systems currently deployed "expect" to be members of a heterogeneous community of operating systems. In a lot of cases, this built-in insularity goes so far that applications programs are cognizant of the particular type of terminal they'll be invoked from 🙃

Intercomputer networking protocols try to fix the heterogeneity problem by presenting common intermediate representations (or "virtualizations") of the constructs and concepts needed for resource sharing 🦄 A Host-Host protocol such as TCP "is" a virtual interprocess communication mechanism. A virtual terminal protocol such as Telnet is, obviously, a mechanism for defining and dealing with virtual terminals. FTP offers common representations of files, and so on 📂

I cannot stress this enough, though 🚨 This entire approach to intercomputer networking is predicated on the assumption that the modules which interpret the protocols (PIs, as we'll refer to them often) will be PROPERLY integrated into the various participating operating systems 💯 Even with powerful OPEs, where most of the work of the various PIs is performed outboard of the Host, the inboard "hooks" that interface the outboard PIs to the native system must not only be present, they must be "right" 🫠 This argument parallels the analysis of the flexible vs. rigid front-ending attachment strategy issue of [1] 📚 To borrow an example: if you try to integrate FTP by "looking like" a native terminal user, and the operator forces a message to all terminals, you've got an undetected pollution of your data stream 😱 So the key issue in attaching Hosts to networks isn't what sort of hardware is required, or what sort of protocol is interpreted by the Host and the OPE (or comm subnet processor, for that matter). It's how the PIs (full or partial) are made to interrelate with the pre-existing environment 🔑

It would be well beyond the scope of this document to even sketch (much less specify) how to integrate H-FP PIs into each type of operating system that will be found in the DoD 🙅‍♀️ But an example should be useful and interesting, so here's one 🎀 Because it's the implementation we're most intimately familiar with, even though it's been several years, we're going to sketch the Multics operating system integration of the original ARPANET Network Control Program (NCP), which is functionally equivalent to an H-FP PI for offloading ARM L II and L I, and Telnet 🧚 (A few comments will also be made about FTP.) Just a heads up: the sketch is for a "full-blown" H-FP. Shortcuts along the lines of the scenario-driven approach mentioned above are not dealt with here 💖

okay so bestie, Multics is genuinely iconic 👑 every process gets an extremely large segmented virtual memory, which is lowkey unreal. Memory references to any segment other than the one you're in (and a single segment can be up to 256K 36-bit words!! 😭) go through a descriptor segment. That descriptor segment is basically "just another segment," and you reach things by segment number and offset within the segment. So one process (aka a "scheduling and access control entity" 🧚) can hold seriously impressive amounts of code and data 💖

Since the code is "pure procedure" (aka "re-entrant") 🫶, a "distributed supervisor" approach is the natural move. Each process ends up with a copy of each procedure segment in its address space, and the system-wide and process-specific data segments get handled appropriately 🎀 Without going too far off track 🦋, the distributed supervisor approach means interrupts get processed by whichever process happens to be running at that moment. Of course, interprocess communication may well be a result of processing a particular interrupt ✨

A few other background points you need to know 🌸 There's a distinguished process called the Answering Service. It originally existed to field interrupts from terminals, and more generally to create processes after authenticating them 💅 Other shared resources, like line printers, are also managed by distinguished processes, which are generically called "Daemons" 😈🫶 Device driver code, like on lots of operating systems, lives at least partly in the supervisor (aka the hard core operating system) 🍓 Finally (for our purposes, at least), inside a process all interfaces are closed subroutine calls, and all I/O is done with generic function calls on symbolically named streams 🌈 Also, all system commands (and obviously user written programs that need to) use the streams "user_input" and "user_output" for the obvious purposes 💜 At normal process creation time, both user I/O streams are "attached" to the user's terminal. But either or both can be attached to any other I/O system interface module instead, including one that reads and writes files, which is super handy for consoleless processes 🙈

ngl this is all a LOT and it probably doesn't fully do Multics justice 😭 but it's more than most readers actually want to know, so let's hope it's enough to make the following integration sketch make sense. (There will be some conscious omissions in the sketch, and doubtless some unconscious ones, but if memory serves, no known lies have been included 🫶)

Okay, so, recalling that NCP is functionally equivalent to H-FP 🦋, let's start there. First up, the device driver for the 1822 spec hardware interface lives in the supervisor. (For most systems, the PI for H-FP's link protocol probably would too 💅) In Multics, interrupt time processing can only be done by supervisor segments. So for efficiency's sake, both the IMP-Host (1822 software) Protocol PI and the multiplexing/demultiplexing parts of the Host-Host Protocol PI also live in the supervisor ✨

An H-FP PI would probably also keep its multiplexing/demultiplexing there. That means the part of the Channel Layer code that mediates access to the OPE and/or decides which process a given message gets sent to might well be in the supervisor, for efficiency reasons 🌸 It's not a hard and fast rule though. The system's native interprocess communications mechanism's characteristics might let the whole Channel Layer live outside the supervisor 🧚

Even with a very large virtual memory, there are administrative biases against putting too much in the supervisor 😤 so "everything else" lives outside it. In fact, there are two places where the rest of the Host-Host Protocol gets interpreted on Multics. That said, an H-FP PI wouldn't necessarily follow the same partitioning, even on Multics, let alone on some other operating system 🙈 With NCP, though, there's a distinguished "control link" that Host-Host commands get sent over in NCP's Host-Host protocol. So the Multics IMP-Host Protocol PI hands that traffic off to a Network Daemon process, which is naturally a key element of the architecture 🔥 (Things would be more efficient if there weren't a separate Daemon, because other processes then have to get involved with interprocess communication to reach it. H-FP PI designers, take note 📝) To avoid going through the Daemon for all traffic, normal reads and writes (aka noncontrol link traffic) are done by the appropriate user process 💖 Thanks to the distributed supervisor approach, there's a supervisor call interface to "the NCP" that's available to procedures (programs) inside user processes ✨ (The Daemon process uses the same interface, but because of its ID, it can also exercise certain privileged primitives 👑)

If a native process (maybe one meaning to do "User Telnet", but not limited to that 🎀) wanted to use the network, it would call the open primitive of "the NCP", do reads and writes, and so on 💅 Here's the interesting part: how this interface works. The reads are inherently asynchronous, which means you don't know exactly when data from the net is going to be available 😭 In Multics, there's an "event" mechanism used in the NCP interface. It lets the calling process decide whether or not it'll block while waiting for input when it reads the net. (It might want to stay active so it can keep outputting, but still be ready for input too 🦋) So asynchrony can be dealt with 🫶 In the version of Unix (tm) that an early NFE was based on, though, native I/O was always synchronous. So to handle input from both the terminal and the net, that system's User Telnet had to consist of two processes, which is not very efficient with system resources 💀 Similar considerations might apply to other operating systems integrating H-FP. Native I/O and interprocess communication disciplines have to be taken into account when designing 🌈 (And you can't just posit a brand new approach for "the network," because Telnet is going to rely even more heavily on native mode assumptions 🙈)

The other part of NCP integration we should at least touch on is, honestly, the most important one, especially because process-level protocols make no sense without it 🔥 It's about how "Well-Known Sockets" (WKSs) work. Broadly speaking, on Multics the Network Daemon initially "owns" all sockets. For Well-Known Sockets, where a particular process-level protocol will be in effect after a successful connection to a given WKS, code gets added to the Answering Service. It calls upon the NCP at system initialization time so it becomes the process "listening" on the WKSs ✨ (This happens because the Answering Service is/was the only Multics process that can create processes. Strategies on other systems would differ based on their native process creation disciplines 🧚) How to get the "right kind of process" gets sketched in the discussions of the process level protocols. For now, the big idea is that SOME sort of prior arrangement would typically be done by any networked Host to associate the right kind of process with a WKS 💜

Now, we don't expect the stuff above to let even the world's greatest system jock design the integration of an H-FP PI for a system that had never been networked (in the ARPANET style of networking) before 😂 But we're going to stop there and turn to some comments on process level protocols, for two reasons. First, it would take us way too far off track to go into significantly greater detail 🙈 Second, because H-FP and NCP are functionally equivalent, and because of the number of operating systems that have integrated NCP and, for that matter, TCP/IP (also functionally equivalent to H-FP, used for offloading L II and L I), there are models available in the ARPANET community. Concerned H-FP PI implementors can follow them 🫶

Turning to Telnet integration, and coming back to Multics as an example, "User Telnet" is straightforward 💅 "All you need" (for small values of "all") from an INBOARD User Telnet is a command that gives the user some sort of interface. It converts between the native Multics character set and terminal discipline and the Network Virtual Terminal equivalents (and since Multics is very generic when it comes to I/O, that's not hard 🍓). It also writes and reads "the net" (more accurately, it calls upon the Host-Host protocol PI, or upon the H-FP PI to get at the H-HP, as appropriate ✨). (One point that's not obvious: make the Well-Known Socket "on the other side" a parameter, defaulting to the Telnet WKS, because you'll want the same command to reach other process-level protocols 🦋) If there's an OPE in play that offloads User Telnet, things can be even simpler. The inboard command just reads and writes the terminal and lets the OUTBOARD User Telnet PI handle the conversion to and from Virtual Terminal form (presumably from and to the desired local form) 🌸

When it comes to the incoming ("Server") aspects of Telnet, life can get complicated on some systems with an inboard implementation 😵 Fortunately for our purposes, though, Multics' native mechanisms lend themselves readily to integration 🎀 An awareness of the inboard issues will still be useful, even if the (Server) Host is obligated, in response to a connection attempt on the Telnet WKS, to associate the connection with a process prepared to translate between Telnet and native mode representations. (The actual logic is somewhat more complex under the ARPANET Host-Host Protocol, which uses paired simplex connections 🙈) That process should otherwise "look like" a local user process. In particular, the connection becomes an I/O source/sink for the native command processor on time-sharing systems 💖 As noted, on Multics process creation is handled by having the Answering Service process listen on the WKS 👑 Because the Answering Service is in some sense just another Multics process, it also does user I/O through the normal system mechanisms 🧚 So while local terminals get their user I/O streams attached through a module called "ttydim" (where "dim" stands for "device interface module"), NVTs get attached through a functionally equivalent, identically invoked module called "nttydim" 🌈 (The Answering Service knows which DIM to use based on the symbolic designator of the "line" on which it received the interrupt, as it happens 💅)

[The notion of "attaching" the streams bears a bit more explanation 🫶 Attach is a primitive of the Multics generic I/O mechanism. It associates a stream name with a particular DIM (or I/O system interface module, in later terminology). The other I/O primitives (read, write, etc.) are invoked with the stream name as a parameter, and an I/O "switch" causes the entry point corresponding to the primitive to be invoked in whichever DIM the stream is currently attached to. So a Server Telnet process starts life attached through nttydim to a particular network connection, while a local process starts life attached through ttydim to a particular physical line. Both processes then proceed indistinguishably (viewed from outside the I/O switch, anyway) 💜]

The pre-existing tidiness that makes everything easy on Multics 🧚 is, sadly, not in every operating system 😭. Sometimes you have to make a really delicate choice about WHICH native terminal to map to, especially on systems that don't do generic I/O in native mode. For some systems, the mapping Server Telnet uses might depend on which application program gets invoked 💅. This gets SO touchy when the application "expects" a "data entry terminal", like a DET 🫠. The Server Telnet on a system like that would naturally try to negotiate the "DET" option with the matching User Telnet. But the user might be sitting at a physical terminal that isn't in the DET class at all. So User Telnet has two choices: refuse to negotiate the option, or (and we'd strongly recommend this one, because it's so in the "spirit" of the protocol ✨) offer some kind of simulation of how a DET behaves, however crude 🎀. Also, something sensible has to happen on systems with no clear equivalent of the command processor that's supposed to be managing the Server process 🤔. An example is a system that always shows a "menu" of applications on an available terminal in native mode.

A final Telnet integration issue 🦋 (there are other points we could make, but we're not pretending to be exhaustive, so this should give you the vibe): the Telnet Interrupt Process generic function needs really careful integration. Its whole job is to virtualize the "quit button" some systems have. The user wants the system to interrupt their process (maybe it's stuck in a loop 🙃) and get back to the command processor, or "the system" itself. On native character-at-a-time systems, the native mechanism is usually entering a particular "control character" 💅. On native line-at-a-time systems, it's usually hitting the "ATTN" or Interrupt button or the "Break" key, sometimes more than once, so it isn't confused with a message to the executing program 👀. But native mechanisms typically involve interrupt time code, and Server Telnet typically isn't running at that level 💀. So the solution (skipping the intricacies of the interaction with the NCP or the H-FP PI, which also get involved 🙈) would be to use a pre-existing INTRAprocess signal in the Multics case, or to add such a mechanism yourself. The exception is an architecture with some kind of Server Telnet Daemon, in which case an INTERprocess signal would be needed 🧠.

Extending all of this to an outboard Server Telnet might not be obvious 🤷‍♀️, but we won't spend a ton of time on it here. Even if "the protocol" is being handled in an OPE, the Host-side software must be able to associate an H-FP connection with the command language interpreter of a user process, and respond appropriately if an H-FP Signal command arrives. The OPE must know not only the desired character set but also the local equivalents of Erase and Kill, at the minimum ⌨️.

---

We'll skip FTP integration because this note is already way too long 🙃. The one exception: in the OUTBOARD case, it's still necessary to pass the name of the right file and directory to and from some appropriate Host-side code 📁. (Similar problems have to be dealt with for outboard handling of "mail" if it isn't part of FTP 📬.)

One other "integration" issue has been hinted at earlier, and not much can be said about it beyond some general guidelines 💭. The "top edge" of a Host-side H-FP protocol interpreter is the Host user program interface. This matters for Hosts that are "doing real networking" rather than just using the OPE to reach User Telnet and/or FTP and to offer Server Telnet and/or FTP [and maybe "mail"], presumably in the "scenario-driven" fashion sketched earlier. That top edge MUST BE APPROPRIATE TO THE HOST. 🎯

In other words, on Multics, where "everything" is closed subroutines, there would presumably be a closed subroutine interface with event channels for reads, pointers to buffers, and all that sort of thing 🧩. On some other style of operating system, though, the interface to the H-FP PI might turn out to be "all" interprocess communication, or to "look like" a device of some special class, or "all" system calls/JSYSs/EOTs/Whatevers 🤪. We can't be much more specific, but we'd be remiss to give any impression that H-FP is a "free lunch" 🍕. As noted, an H-FP PI requires the same kind of integration as a generic NCP. It's just smaller, and it serves as insulation against changes in the offloaded protocols in general, or in the proximate comm subnet in particular 🛡️✨.

References 📚

(References [1]-[3] will be available in M. A. Padlipsky's "The Elements of Networking Style", Prentice Hall, 1985. 💖)

[1] Padlipsky, M. A., "The Host-Front End Protocol Approach", MTR 3996, Vol. III, MITRE Corp., 1980.

[2] Padlipsky, M. A., "The Elements of Networking Style", M81-41, MITRE Corp., 1981.

[3] Padlipsky, M. A., "A Perspective on the ARPANET Reference Model", M82-47, MITRE Corp., 1982.

[4] Bailey, G., "Network Access Protocol", S-216,718, National Security Agency Central Security Service, 1982.

[5] Day, J. D., G. R. Grossman, and R. H. Howe, "WWMCCS Host to Front End Protocol", 78012.C-INFE.14, Digital Technology Incorporated, 1979. 🌸