RFC 996

Statistics Server ✨

Okay bestie, let's get into it 🎀. This is RFC 996, written by D.L. Mills at the University of Delaware in February 1987 🦋. It's from the Network Working Group, and the header doesn't list anything it obsoletes or updates, so it's a clean slate 🧚.

Status of This Memo 📜

This RFC is a standard for the ARPA Internet community 👑. Hosts and gateways on the DARPA Internet that want a remote statistics monitoring facility can use this protocol to send statistics data on request to a monitoring center or debugging host 💅. Distribution of this memo is unlimited 🌈.

Discussion 💭

Okay so, a LOT of host and gateway implementations come with a facility that records traffic stats 📊. We're talking packet counters, error counters, and significant event counters, all for debugging and performance evaluation 🔍. Simple data-access and formatting programs can show these stats alongside connection status and stuff 💖. Several operating systems, including the various Unix systems and Fuzzball systems, already have big-brain tools for capturing and displaying this for local users and/or operators ✨.

But here's the thing: it's super useful to watch stats on remote hosts and gateways from a monitoring center or debugging host 🫶. Several protocols have been built and used for exactly this, see [1-6] 🍓. Sometimes you can grab the data with normal services like remote login or even file transfer 🙈. BUT ngl, those heavyweight mechanisms are awkward and intrusive if you're doing it on a regular, frequent basis 💀. And if you try to retrofit them onto existing systems, they can cause a LOT of intrusion in the operating system 😭.

Enter the Statistics Server (STATSRV) protocol 🧚‍♀️🔥. It's a lightweight mechanism, similar in spirit to NETSTAT [7], and it's complementary to it, so they're besties 👯. STATSRV is designed to capture statistics data with minimal intrusion on existing systems or networks 🌸. It's meant for existing hosts and gateways, mainly for casual monitoring and debugging 💅. It is NOT a full-function monitoring protocol [1,5,6] with detailed, standardized reports suitable for machine analysis, for example 🙅‍♀️. It could still be useful in exploratory development that leads to enduring systems of this type 🦋.

The STATSRV model is based on the native host command language used for statistics monitoring and display 💜. The client sends a null-terminated ASCII command to the server, and the server replies with a null-terminated ASCII response that's ready for a printer or CRT display 🖨️. Even though STATSRV could run over TCP in principle, it's less intrusive and more efficient over UDP, so UDP is the move 🏃‍♀️💨. With UDP, commands and responses must fit into a single 576-octet IP datagram 📦. In both UDP and TCP, the assigned port number is 133 (decimal) 🎀.

Also, as is conventional for lightweight services like this (NETSTAT, FINGER, etc.), STATSRV has no access control or authentication 🙈. If you need it, each command could include a password or some other mechanism to discourage casual abuse 🔒. Not perfect, but it's giving "thoughtful" 💅.

Example 🎀

The Fuzzball system has lots of local commands for showing internal data structures 🧁. One of them prints a billboard for each network device. Here's what it looks like for "dm0" on host "udel2.udel.edu" 👀:

     Process type: 000027  options: 040000
     Subnet: DMV  status: 376  hello: 15  timeout: 2000
     Foreign address: [192.5.39.87]  max size: 576
     Input packets      3645    Output packets  3690
       bad format       0       ICMP msgs       0
       bad checksum     0       Input errors    0
       returned         0       Output errors   0
       dropped          2       No buffer       0
       HELLO msgs       2286    Preempted       0

Now here's the magic ✨. The same billboard comes back as a null-terminated ASCII string in a UDP datagram when you send the null-terminated ASCII command dm0 in a UDP datagram to the host 🦋. Similar billboards can be made for most processes in the system 🌈. People have built Unix programs and shell scripts that send commands like these to selected hosts on a periodic basis, which gives you a simple, ad-hoc monitoring setup 🫶. Iconic, honestly 👑💖.

References 📚

[1] Flood Page, D.,"Gateway Monitoring Protocol", DARPA Network Working Group Report IEN-131, Bolt Beranek and Newman, February 1980. 🧚

[2] Flood Page, D., "The CMCC Terminal Process", DARPA Network Working Group Report IEN-132, Bolt Beranek and Newman, February 1980. 🌸

[3] Flood Page, D., "CMCC Performance Measurement Message Formats", DARPA Network Working Group Report IEN-157, Bolt Beranek and Newman, September 1980. 📊

[4] Jones, R.G., "A Proposal for Simple Measurement Support for Users", DARPA Network Working Group Report IEN-161, University College London, November 1980. 💅

[5] Littauer, B.M., A.J. Huang and R.M. Hinden,"A Host Monitoring Protocol", DARPA Network Working Group Report IEN-197, Bolt Beranek and Newman, September 1981. 🦋

[6] Hinden, R.M.,"A Host Monitoring Protocol", DARPA Network Working Group Report RFC-869, BBN Communications Corporation, December 1983. 💜

[7] Reynolds, J.K., and J. Postel, "Assigned Numbers", DARPA Network Working Group Report RFC-990, USC Information Sciences Institute, November 1986. 🎀