Browse Prior Art Database

Few observations on NCP statistics (RFC0618)

IP.com Disclosure Number: IPCOM000003690D
Original Publication Date: 1974-Feb-19
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E.A. Taft: AUTHOR

Abstract

The NCP in use at HARV-10, CMU-10A, and CMU-10B collects a number of operating and error statistics, which may be typed out on demand by any user by means of the 'IMP ERROR' command, as shown on the sample typescript.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 61% of the total text.

Network Working Group Edward Taft (PARC-MAXC)

Request for Comments: 618 Feb 1974

NIC #21989

A Few Observations on NCP Statistics

The NCP in use at HARV-10, CMU-10A, and CMU-10B collects a number of

operating and error statistics, which may be typed out on demand by

any user by means of the 'IMP ERROR' command, as shown on the sample

typescript.

The figures shown cover the period since the system was last

restarted. They are not logged or recorded in any more permanent

form due to extremely limited on-line storage at HARV-10. where

the software was implemented. However, due to the small size of

the system and infrequent monitor development work, HARV-10 tends

to stay up for periods approaching the interval between hardware

maintenance, which is one week. The attached output was obtained

after 168 hours system uptime.

There are a few things I would like to point out that may be of

interest to NCP implementers.

First, note that the number of discarded (unexpected) RFNMs is equal

to the number of simulated (timed out) RFNMs. This has been the case

almost every time I have looked at these statistics. It suggests

that the RFNMs are not being lost but are rather delayed beyond the

NCP timeout interval, which I believe is 30 seconds.

I have heard talk among a few people in the Network community

about "lost RFNMs", and would like to suggest this as a possible

alternative explanation. Perhaps longer timeouts are in order.

Second, the observed ratio of received allocates to transmitted

allocates (on the order of two to one) is also fairly typical. I

believe this reflects differences in allocation strategies among

various hosts.

Many hosts appear to send out an allocate for every data message

received. While this is reasonable for connections such as FTP

data transfer connections, it imposes considerable extra traffic

in the case of the single character messages that seem to be the

most common on the network.

-1-

The strategy used by the Harvard NCP is to assign a "desired level

of allocation" figure to each socket (typically quite small for

Telnet connections and large for FTP data connections; it is a

user program settable parameter). When the actual allocation for

the socket falls below 50% of this level, enough additional

allocation is sent to bring it up to the full "desired level".

The effect of this strategy is to significantly reduce the number

of allocates returned for a given number of small messages

received. This reduces both network traffic and control message

overhead at the other end. The strategy has no effect on FTP data

messages, since each message is usually large enough to reduce

outstanding allocation by at least half at a single blow.

Finally, I should remark on the appallingly large number of NOPs

received (typically 25% of all control messages). M...