RFC 550

RFC 550: NIC NCP Experiment 🎀

Bestie, this one is a whole vibe. 💖 Here's the title block: it's RFC 550, written by L.P. Deutsch of PARC-MAXC (with NIC # 17796), dated August 24, 1973, and filed under the Network Working Group. There's no category or status listed, and it doesn't obsolete or update anything. ✨

Okay so for the past couple of weeks, the NIC NCP has been keeping stats on total incoming messages, incoming host-host control opcodes, and the size of outgoing messages. 📊 The results are honestly so enlightening, and I think future NCP implementors for servers need to read them carefully. 🧚 The stats are kinda qualitative, since they got reset every time the system came up, but they add up to about 100 hours of uptime, mostly during the working day. 💅

The total incoming and outgoing message counts were almost identical! 🦋 There were about 5% more outgoing. Incoming control opcodes processed were slightly over half as many as incoming messages. So, assuming no incoming control message had more than one opcode, slightly over half the incoming messages were control messages. 🌸

The opcode stats were a little all over the place. ALL (ALL) was the main character basically every time 👑. It ranged from about 50% on weekends all the way up to 98% on a busy weekday 🔥. Almost everything else was NOPs (NOP), and no other opcode ever got above 5%. Literally nobody else showed up. 💀

For output message sizes, they logged log2(message size). That count included 1 word of buffer header, 1 word of IMP header, and 1 word of host header 🍓. As you'd kinda expect, 95% of all outgoing messages had 1 to 4 PDP-10 words (36-bit) of data 🙈. But here's the plot twist: if you multiply the count for each bucket by the average message size for that bucket, only 75% of all outgoing data was in the smallest size bucket. The rest of the data was spread out pretty evenly across the other buckets. 😭

Now the conclusions, bestie, pay attention. 🫶 First, about half the messages on the network are ALLs, so NCPs should think about processing control messages efficiently. 🔥 Second, 95% of the messages are super short, so fancy buffering and queuing schemes probably aren't worth it. The possible gain in efficient IMP use is likely swamped by the overhead inside the host. 💅 Third, a big enough chunk of all data is in large messages (presumably file transfers) that handling that efficiently matters too. Like, an NCP that always sent 1-character messages would not be satisfactory. 🙅‍♀️

Quick reality check: this part is an observation about the experiment, not a rule. The author's conclusions are what the numbers suggested. 🎀

RFC 550                    NIC NCP EXPERIMENT                August 1973

The ARPANET has been running vigorously for a year or two now, and tons of NCPs have been written in that time 🦋. That includes a rewrite of the TENEX NCP, which probably handles more traffic than all the other NCPs combined 👑. As far as the author knows, nobody had bothered to gather these stats before. 💀 Getting the measurements into the NIC system took about half an hour (10 instructions) ⭐.

The author honestly finds it kinda sad that even people who are presumably doing "computer science" haven't found it necessary to test their hypotheses about network operation with experiments, or to improve their theories based on evidence. 🥺 Like, come on, we can do better! 💜

       [ 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.            10/99 ]

The end, and honestly what a legend 🌈✨🫶