RFC 852

ARPANET short blocking feature

📅 published April 1983, from ietf

RFC 852: The ARPANET Short Blocking Feature 🦋

okay bestie, let's get into this 🎀 Request for Comments: 852, and the title is The ARPANET Short Blocking Feature ✨

The author is Andrew G. Malis 💅, reachable at ARPANET Mail: malis@bbn-unix. He wrote it while at Bolt Beranek and Newman Inc. in Cambridge, MA, at 50 Moulton St. (02238 🌸). The date is April 1983 🍓.

On the "obsoletes" front, this RFC was once part of RFC 802, and RFC 802 is now obsolete 💀. It got replaced by this RFC plus RFC 851, The ARPANET 1822L Host Access Protocol [2] 🧚. The title block doesn't list anything it updates, and it doesn't name a category either. The abstract tells us it's a solicitation of comments, so the vibe is "tell us what you think" 🫶.

The abstract is basically the whole pitch 💜. This RFC specifies the ARPANET Short Blocking Feature, which lets ARPANET hosts optionally shorten the IMP's host blocking timer ⭐. It's a replacement for the ARPANET non-blocking host interface, which was never implemented 😭. It's available to hosts using either the 1822 or 1822L Host Access Protocol 🌈. The RFC is also asking for comments on the Short Blocking Feature, especially from host network software implementers and maintainers 🔥.

1. Introduction ✨

okay so this RFC specifies the ARPANET Short Blocking Feature, and it lets a host shorten how long its IMP is allowed to block it after the host presents a message to the network 🦋. Right now, the IMP can block further input from a host for up to fifteen seconds, and that's a lot of waiting 💀.

The Feature is an addition to the ARPANET 1822 and 1822L Host Access Protocols 🎀. It replaces the non-blocking host interface described in section 3.7 of BBN Report 1822 [1], which, sadly, was never implemented 😭. This Feature is only available to hosts on C/30 IMPs 🌸. For the ARPANET, that's not a problem, because the ARPANET only has C/30 IMPs ✨. But hosts on non-C/30 IMPs in networks that mix C/30 and non-C/30 IMPs won't be able to use the Short Blocking Feature 🙈.

The RFC's terminology matches what Report 1822 uses, and any new terms get defined the first time they show up 💅. Familiarity with Report 1822 (section 3 in particular) is assumed, so go read it first, bestie 📚.

This RFC was once part of RFC 802, which is obsolete now 💀. It's been replaced by this RFC together with RFC 851, The ARPANET 1822L Host Access Protocol [2] 🧚. The Short Blocking Feature will be available to all hosts on C/30 IMPs, no matter whether they use the 1822 or the 1822L host access protocol to talk to the IMP 🌈.

2. The ARPANET Short Blocking Feature 💜

The Short Blocking Feature of the 1822 and 1822L protocols lets a host hand messages to the IMP without the IMP refusing further messages from that host for long stretches of time (up to fifteen seconds) 😤. It's a replacement for the non-blocking host interface described in section 3.7 of Report 1822, and that description should be ignored 🚫.

2.1. Host Blocking 🧠

Usually, when a source host submits a message to an IMP, the IMP immediately processes it and sends it on its way to its destination host ✨. Sometimes, though, the IMP can't process the message right away 😬. Processing a message takes a significant number of resources, and when the network is heavily loaded, there can be a long delay before those resources free up 🐢. In those cases, the IMP has to decide what to do while it's trying to gather the resources 🤔.

One option is for the IMP to stop accepting messages from the source host until it has gathered the resources it needs to process the message just submitted 🔒. This strategy is called blocking the host, and it's basically the strategy the ARPANET has used up to now 🕰️. When a host submits a message to an IMP, all further transmissions from that host to that IMP are blocked until the message can be processed 🚧.

Here's the tea ☕. Not every message needs the same set of resources to be processed by the IMP 💁. The resources needed depend on the message type, the message length, and the destination host of the message 📦. So it might take a long time to gather the resources for one message, but only a short time for another one 🏃. This exposes a big disadvantage of blocking the host 😩. A blocked host might have lots of other messages that could be processed immediately if only they could be submitted 🙃. It's "unfair" for the IMP to refuse them until it has gathered resources for some other, unrelated message 😤. Why should messages the IMP has plenty of resources for get delayed for an arbitrarily long time just because the IMP lacks resources for a different message? 🥺

A simple fix would be to put a limit on how long a host can be blocked ⏱️. That limit should be long enough that, in most circumstances, the IMP can gather the resources it needs to process the message within the given time period ✅. But if the resources can't be gathered in that time, the IMP will flush the message 🗑️. It sends a reply to the source host saying the message was rejected and giving the reason it couldn't be processed 📬. The resource gathering process keeps going, though 🔄. The idea is that the host resubmits the message in a short time, when hopefully the resource gathering has finished successfully 🤞. In the meantime, the host can submit other messages, which may get processed sooner 🚀. This strategy doesn't get rid of host blocking, it just limits how long a host gets blocked 🫶. This shorter time limit will always be less than or equal to two seconds ⭐.

But heads up, there's a downside to short blocking times 🚨. Let's say the IMP accepts a message only if it has all the resources needed to process it 📋. The ARPANET provides a sequential delivery service, where messages with the same priority, source host, and destination host get delivered to the destination host in the same order they were accepted from the source host 📈. With short blocking times, though, the order the IMP accepts messages from the source host doesn't have to match the order the source host originally submitted them 🌀. The two data streams between the host and the IMP (one in each direction) aren't synchronized 🔀. So the host might not receive the reply to a rejected message before it submits later messages for the same destination host 😵. If a later message gets accepted, the acceptance order differs from the original submission order, and the ARPANET won't provide the same kind of sequential delivery it used to 💔. If sequential delivery by the subnet is a strict requirement, then the Short Blocking Feature should not be used 🛑. For messages without that requirement, though, the Short Blocking Feature can be used 💖.

Up until now, type 0 (Regular) messages only had sub-types available to request the standard blocking timeout, which is fifteen seconds 🕒. The Short Blocking Feature adds new sub-types that let the host request short blocking for messages 🎉. With those, the host only gets blocked for two seconds at most if the message can't be processed right away 🦋.

Type 0 messages now have the following subtypes 🌈:

  • 0: Standard: This subtype tells the IMP to use its full message and error control facilities. The host may be blocked for up to fifteen seconds during message submission 🧱.
  • 1: Standard, Short Blocking: The IMP tries to use the same facilities as for subtype 0, but it will block the host for a maximum of two seconds ⚡.
  • 3: Uncontrolled Packet: The IMP performs no message-control functions, and the packet isn't guaranteed to be delivered 🫠. The host may be blocked for up to fifteen seconds during packet submission, though any blockage is unlikely 🎲.
  • 4: Uncontrolled, Short Blocking: The IMP treats the packet similarly to subtype 3, but it will only block the host for a maximum of two seconds 💨. Again, actual blockage is unlikely 🙌.

2.2. Reasons for Host Blockage 🚦

There are a bunch of reasons a message could cause a long blockage in the IMP 😱. That blockage would lead to the rejection of a short (or even non-short) blocking message 💔. The IMP signals this rejection with the Incomplete Transmission (Type 9) message, and it uses the sub-type field to say why the message was rejected 📝. These are the sub-types that already existed for the type 9 message 📜:

  • 0: The destination host didn't accept the message quickly enough 🐌.
  • 1: The message was too long 📏.
  • 2: The host took more than fifteen seconds to transmit the message to the IMP ⏳. This time is measured from the last bit of the leader through the last bit of the message 🎯.
  • 3: The message was lost in the network due to IMP or circuit failures 🔌.
  • 4: The IMP couldn't accept the entire message within fifteen seconds because of unavailable resources 🫤. This sub-type is only used in response to non-short blocking messages 🙅. If a short blocking message timed out, it gets responded to with one of sub-types 6-10 🔁.
  • 5: A source IMP I/O failure happened while this message was being received 💥.

These are the new sub-types that apply to the Short Blocking Feature 🆕:

  • 6: Connection set-up delay: Even though the IMP presents a simple message-at-a-time interface to the host, it provides an internal connection-oriented (virtual circuit) service, except for uncontrolled packets 🧵. Two messages count as being on the same connection if they have the same source host (meaning they're submitted to the same IMP over the same host interface), the same priority, and the same destination host name or address 🤝. The subnet handles internal connection set-up and tear-down procedures 🛠️. Connections get set up as needed, and they're only torn down after a period of inactivity 😴. Sometimes, network congestion or a resource shortage causes a lengthy delay in connection set-up 🐢. During that period, no messages for that connection can be accepted, but other messages can still be accepted 🌟.
  1. End-to-end flow control: 💅 For every message a host submits to an IMP (except uncontrolled packets), the IMP eventually sends back a reply telling the host what happened to the message. The stretch between submitting the message and the host getting that reply is called the message being outstanding. ✨ The ARPANET only allows eight outstanding messages on any given connection. So if there are already eight outstanding and a ninth gets submitted, it cannot be accepted 🙅‍♀️. If a message gets refused because its connection is blocked by flow control, messages on other connections can still be accepted 🦋. Okay, this one is lowkey the biggest reason hosts get blocked on the ARPANET right now 😭.
  2. Destination IMP buffer space shortage: 🎀 If the host submits a message longer than 1008 bits (not counting the 96-bit leader), buffer space at the destination IMP has to be reserved before the message can be accepted. This buffer space is always reserved per connection 🧚. If the destination IMP is heavily loaded, the wait for buffer space can be super long, and that's another super common cause of blocking on today's ARPANET 🥱. Messages get rejected for this reason based on their length and connection. Messages of 1008 or fewer bits, or messages for other connections, may still be acceptable 💖.
  3. Congestion control: 🌊 A message may be refused for reasons of congestion control if the path through the intermediate IMPs and lines to the destination IMP is too heavily loaded to take on any more traffic. Messages to other destinations may be acceptable, though 🌈.
  4. Local resource shortage: 🍓 Sometimes the source IMP itself is short on buffer space, table entries, or some other resource it needs to accept a message. Unlike the other reasons for rejection, this kind of shortage affects all messages equally, except uncontrolled packets 🙈. The message's size or connection doesn't matter here 💜.

The Short Blocking Feature is available to all hosts on C/30 IMPs, whether they're using the 1822 or 1822L protocol 🌸. You get to it through Type 0, sub-type 1 and 4 messages ✨. A host using these sub-types should be prepared to correctly handle the Type 9 (Incomplete Transmission) messages from the IMP 🫶.

3. References 📚

[1] Specifications for the Interconnection of a Host and an IMP, BBN Report 1822, December 1981 Revision.

[2] A. Malis, The ARPANET 1822L Host Access Protocol, Request for Comments 851, April 1983. 🦋

📦 where this page comes from