RFC 618

Few observations on NCP statistics

📅 published February 1974, from ietf

A Few Observations on NCP Statistics ✨

Network Working Group 🎀 Author: Edward Taft (PARC-MAXC). Request for Comments: 618. Dated Feb 1974. NIC #21989. The header doesn't list anything this one obsoletes or updates. 🦋

The Stats Themselves 📊

Okay so the NCP running at HARV-10, CMU-10A, and CMU-10B keeps track of a bunch of operating and error stats 👀 Anyone can print them whenever they want with the IMP ERROR command. There's a sample typescript further down so you can see what it looks like.

The numbers only count from the last time the system restarted 🕰️ Nothing gets logged or saved somewhere more permanent because HARV-10 (where the software was built) has super limited on-line storage 😭 But HARV-10 is small and the monitor doesn't get touched much, so it tends to stay up for about as long as the hardware maintenance gap, which is one week 🧚 The sample output was grabbed after 168 hours of uptime. Iconic stamina 💪

Observation One: The RFNMs Aren't Lost, They're Just Late 🙈

First things first 💅 The number of discarded (unexpected) RFNMs is equal to the number of simulated (timed out) RFNMs. This has been true pretty much every time the author checked. That's a big hint that the RFNMs aren't getting lost at all. They're just showing up after the NCP timeout, which the author thinks is 30 seconds ⏳

People in the Network community have been going on about "lost RFNMs" 👀 The author's like, what if they're just late? Maybe longer timeouts are the move 🌸

Observation Two: Allocates Are Being Over-Sent 🫶

The ratio of received allocates to transmitted allocates is around two to one, which the author says is pretty typical too. The author thinks this comes from different hosts using different allocation strategies 🍓

Lots of hosts send an allocate back for every single data message they get. That's totally fine for stuff like FTP data transfer connections 📁 But for single character messages, which seem to be the most common kind on the network, it adds a ton of extra traffic 😩

The Harvard NCP does things differently 💖 Every socket gets a "desired level of allocation" figure. It's usually pretty small for Telnet connections and big for FTP data connections, and a user program can set it. When a socket's actual allocation drops below 50% of that level, the NCP sends enough extra allocation to bring it back up to the full "desired level" ✨

The result is that way fewer allocates get sent back for the same number of small messages. That cuts down on both network traffic and control message overhead on the other end 🔥 The strategy does nothing for FTP data messages, though, since each one is usually big enough to cut the outstanding allocation by at least half in one go 💀

Observation Three: The NOP Situation Is Concerning 💜

The author has to talk about the "appallingly large" number of NOPs received 😭 They're typically 25% of all control messages. Most of them seem to be piggy-backed onto other control messages, so it's not as bad as the figures make it look. Still, the author is genuinely wondering why anyone would want to send that many 🙈

The Sample Typescript 🧾

TELNET typescript file started at THU 31 JAN 74 428:05

#harv-10 (settings loaded) is complete.#

Harvard 5.06A-18 7:28:38
Type "HELP" if you need it.

.login 62,#
JOB 2 Harvard 5.06A-18 TTY25
Your name please (last name first): Taft
You are logged in as 62,404000
0728 31-Jan-74 Thur
SCHEDULED PM ON THURSDAYS, 0830-1200 EOT

.imp error

NCP version 1573.1604 operating statistics

07:29:02 31-JAN-74


NCP (link 0) message errors:
Socket not found: 2184

Improper state: 323
Illegal message type: 2
Last discarded allocation from PARC-MAXC (XEROX) link 12
Timed-out exec ICPs: 3

NCP messages:
Type Received Sent
NOP 81850 0
RTS 3688 2507
STR 2388 3562
CLS 6055 6059
ALL 183050 101442
GVB 772 0
RET 0 772
INS 109 0
ECO 7472 15426
ERP 15065 7472
ERR 2 0
RST 2782 226
RRP 162 2782

Received NCP error messages:
Type Count
4 2

Most recent error: type 4 from UCLA-CCN
Data (octal) 4 74 0 10 0 0 74 254 0 200
(decimal)    4 60 0  8 0 0 60 172 0 128

IMP data message faults:
Hardware fault: 2
Link not found: 8
Discarded RFNMs: 10
Simulated (timed out) RFNMs: 10

Received IMP messages:
Regular 590812
Err w/o id 3
NOP 4
RFNM 490095
Dest dead 366
Inc trans 52
IMP reset 2

Histogram of received data message sizes
Bits Count
<1 3
<16 146834
<32 39751

72 free buffers
7% average buffer utilization

.kjob/k
Job 2, User [62,404000] Logged off TTY25 0729 31-Jan-74
Runtime 0 Min, 03.29 Sec
RFC>>>
📦 where this page comes from