Heading:

Pup Error Protocol

Page Numbers: Yes X: 527 Y: 10.5"

Copyright Xerox Corporation 1979

Inter-Office Memorandum

ToCommunication ProtocolsDateJuly 1, 1978

FromEd TaftLocationPalo Alto

SubjectPup Error ProtocolOrganizationPARC/CSL

XEROX

Filed on: [Maxc1]<Pup>Error.bravo

This is a revision of a memo of the same title dated October 17, 1975.

When a Pup is discarded by any agent (either the destination process or any intermediary such as a gateway), that agent may optionally generate an Error Pup notifying the source process of the reason for the Pup’s demise. While Pup-based protocols are designed to work correctly without any form of negative acknowledgment, the Error Protocol is provided to permit more intelligent handling of exceptional conditions and possibly better performance.

The Error Protocol makes use of a single registered Pup type. It is intended that this protocol be able to coexist with all other Pup-based protocols (e.g., Rendezvous/Termination, BSP), but it is not specifically associated with any of them.

All numbers are decimal.

Error Pup Format

An Error Pup is constructed in the following manner:

Pup TypeSet to type ‘‘Pup Error’’ (4).

Pup IdentifierSet equal to the Pup Identifier of the original Pup.

Destination PortSet equal to the Source Port of the original Pup.

Source PortIf the agent generating the Error is the destination of the original Pup, then its address (i.e., the original Destination Port) should be used. If the agent is an intermediary (e.g., a gateway), then the Source Port should reflect that agent’s address in some reasonable way (e.g., the Network and Host set to the hardware address at which the Pup was received and the Socket set to zero).

Pup ContentsWords 0-9 are a copy of the Pup Header of the original Pup (some of this information is redundant, but this convention is chosen for simplicity). Word 10 is a registered Error Code indicating the type of error. Word 11 is reserved for an optional machine-readable argument. The remainder of the Pup is optional human-readable text.

Error Codes

The following Error Codes generally indicate that the Pup was received at its intended destination, but was discarded for the given reason before any logical processing was performed on it.

1The Pup Checksum was incorrect, or the Pup had some other serious inconsistency.

2No process existed to receive packets at the given Pup Destination.

3The Pup was correctly addressed but failed to reach its destination due to some resource limitation in the destination host.

The following Error Codes generally indicate that the Pup was discarded before reaching its intended destination.

513The Pup had some serious inconsistency.

514The Pup Destination Network could not be reached from here.

515The Pup Destination Host was known to be down or nonexistent.

516The Pup had been forwarded by 16 gateways without reaching its destination.

517The Pup was too large to be forwarded through some intermediate network. The argument word contains the Pup Length of the largest Pup that can be accomodated.

518The Pup was received by some non-gateway host to which it was not addressed.

519The Pup failed to be forwarded by a gateway due to some resource limitation.

Notes

An Error Pup should never be sent in response to a Pup of type Error or to a broadcast Pup of any type.

Existing implementations of higher-level protocols make use of only a few of the Error Codes and ignore the rest. In particular, the Rendezvous/Termination protocol handlers treat sub-type 2 (‘‘No such port’’) the same as an Abort.

The Bcpl Byte Stream Protocol handler responds to Error Codes 3 (‘‘Port input queue overflow’’) and 519 (‘‘Gateway queue overflow’’) by modifying its transmission strategy to send fewer packets at a time. This permits it to adapt to varying conditions of load and congestion.