Summary

  • RFC 863 defined TCP and UDP services that consumed traffic on port 9, threw it away and returned no application response. In TCP, the caller—not the server—ended the test connection.
  • TCP state can show more than a bare UDP send, but a connection, local write return or transport acknowledgment is not an RFC 863 application receipt. The protocol supplies no receipt at all.
  • UDP silence is compatible with successful discard, loss, filtering or an absent service. Defensible measurement therefore requires an independent observation surface and a written statement of which inference each signal supports.

A test whose correct answer is empty

The operator has a payload with a known length and pattern. A remote endpoint is meant to accept it. The operator does not want an echo, a stored object or a calculated result; the receiving application should simply destroy the bytes. This sounds like the simplest possible measurement.

Then the test finishes without an application message. Was the sink reached? Did the receiving transport accept the whole stream? Did the server process read it? Did a firewall discard it first? With UDP, did the datagram even leave the first network? The blank answer contains none of these distinctions.

That emptiness is the design, not a bug. RFC 863 called the discard service useful for debugging and measurement. It defined a controlled absence of work beyond reception: no transformation to verify, no response data to compare, no server result to retain. Its historical value lies in how sharply it exposes an evidence rule that larger protocols often obscure. A network observation is authoritative only for the layer that generated it.

Two transports, one missing application reply

The TCP service listened on port 9. Once a connection was established, every received byte was thrown away, and no response was sent. The process continued until the calling user terminated the connection. The closing initiative matters. A client waiting for the server to declare “done” would wait for behavior RFC 863 assigned to nobody.

The UDP form was even smaller. The server listened for datagrams on UDP port 9. When one arrived, the server threw it away and sent no response. There was no request grammar, transaction identifier, byte count, checksum echo or negative status in the application protocol.

Both variants therefore standardized the sink but not a remote receipt. “No response” meant the application should remain quiet after a successful receive. It did not mean every silence on the path was successful Discard processing. Conformance defines what a real server does after arrival; it cannot make absence observed at the sender prove that arrival occurred.

RFC 880 placed Discard among the elective protocols later in 1983. Under that catalogue, elective meant a host could implement the service or not. The label recorded optional status, not a promise of universal presence. A port-9 timeout was never entitled to assume that a conforming server existed behind the address.

TCP can strengthen evidence without inventing a receipt

TCP gives the test a connection and an ordered byte stream. That is materially different from firing one datagram. A successful handshake establishes that a remote TCP endpoint accepted the connection tuple at that time. Sequence and acknowledgment state can show that the remote TCP endpoint took responsibility for a range of bytes. Retransmissions, resets and timeouts can expose failures that the Discard application itself will never describe.

RFC 9293 states the boundary carefully. When the receiving TCP endpoint takes responsibility for delivering data to its user, it acknowledges receipt. The acknowledgment is evidence about the remote TCP endpoint's responsibility. It is not a signed statement from the Discard process that a particular read call ran, an internal counter advanced, storage was untouched or policy accepted the test.

The sender's own API can expose an even earlier boundary. RFC 9293 discusses interfaces in which a SEND may return an immediate local acknowledgment although the distant TCP endpoint has not yet acknowledged the segment. A successful local write can therefore mean that the local stack accepted bytes, not that the network delivered them. The exact promise depends on the implementation and later errors.

Discard makes these distinctions visible because it has no higher-level success message to blur them. If an operator needs proof that the remote application read and destroyed exactly 10 million bytes, the operator needs another observation surface: a controlled server counter, process trace, packet capture tied to the endpoint, or test harness that reports completion out of band. Adding that evidence changes the experiment; it does not uncover a hidden RFC 863 receipt.

UDP silence cannot choose its own cause

UDP offers no connection establishment and no reliable-delivery machinery. RFC 768 describes it as transaction-oriented while explicitly withholding delivery and duplicate protection. An application that needs reliable delivery must add its own mechanism or use another transport.

RFC 863 deliberately added no such mechanism. After the sender transmits a port-9 datagram, the intended application result and common failure results look identical from the reply channel: nothing returns. The packet may have been discarded by the service, lost in transit, rejected by policy, sent to an address with no listener, or followed by an ICMP error that never reached the application.

Modern UDP guidance refuses to let ICMP repair this ambiguity. RFC 8085 notes that middleboxes increasingly filter ICMP and says UDP applications should not rely on ICMP delivery for correct and safe operation. An error that does arrive can be useful after validation; its absence is not a success certificate.

A UDP Discard experiment can still measure something when the observer controls both ends. The sender can count attempts while a receiver-side capture counts arrivals, or an independent device can observe a bounded path. What it cannot do is label sender-side silence “remote discard completed” without that corroboration. Silence is an observation; success is an inference that needs an authority chain.

The useful subtraction

Echo returns the request. Character Generator returns new data. Daytime returns a human-readable clock line. Discard subtracts the return path from the application contract. In a laboratory, that subtraction can isolate how fast a sender and path can feed a sink without paying for application response traffic.

It also removes information. An Echo comparison can reveal whether returned bytes differ, although it does not by itself authenticate the peer. A Discard client receives no bytes to compare. A TCP client can use transport evidence, but a UDP client must obtain evidence elsewhere. The absence is therefore both the feature under test and the main limit on what the test can establish.

This boundary distinguishes Discard from the Echo/Chargen loop. Those UDP services created replies that could become each other's next requests when source addresses were forged. RFC 863 sends no application reply, so it does not create that response cycle. The security question is not a reflection multiplier documented by the closed sources. It is whether an exposed sink consumes capacity, who authorized the workload and whether the measurement preserves enough evidence to attribute it.

A registered number does not run a service

IANA records discard on port 9 for TCP and UDP, the two transports defined by RFC 863. The registry also contains SCTP and DCCP rows with their own references. The registration makes the shared namespace legible. It lets an operator associate a number with an intended service convention.

RFC 6335 classifies port 9 inside the System Port range and explains registry states such as assigned, unassigned and reserved. “Assigned” is an administrative fact about the number. It does not prove a listener exists at a particular address, that a process behind the number follows RFC 863, that traffic is permitted or that public exposure remains useful.

This is crucial for tests designed around silence. If a scanner sees no response from UDP port 9, the registry cannot fill the evidentiary gap. If a TCP connection opens, the number helps identify the expected service, but only endpoint control or observable behavior can establish what process accepted it. Namespace authority and execution evidence solve different problems.

Write the claim before running the test

A useful Discard test begins by stating what must be proved. “The local kernel accepted the buffer” needs local API and queue evidence. “The remote TCP endpoint took responsibility for these bytes” needs connection and acknowledgment evidence. “The remote Discard process consumed the stream” needs a receiver-side application observation. “This UDP path delivered 99 percent of datagrams” needs a controlled arrival counter and a time-bounded denominator.

The statement should also name what remains unknown. A TCP acknowledgment does not identify a civil operator or authorize the load. A receiver packet capture does not prove that the application performed its intended action unless the capture point and process boundary are linked. A zero-response rate is not a delivery rate. The chosen endpoint may change between tests.

RFC 863's tiny contract makes overclaiming easy to detect. The standard promises silence, so a report cannot point to an application success reply. Every stronger conclusion must identify the separate evidence that supports it. That discipline is the protocol's enduring measurement lesson.

Sources and evidence limits

The TCP and UDP service behavior comes from RFC 863, and its 1983 elective classification from RFC 880. TCP connection, acknowledgment and user-interface boundaries come from RFC 9293. UDP's base non-guarantees are in RFC 768, with current application and ICMP cautions in RFC 8085.

Port-number governance is bounded by RFC 6335 and the IANA service registry. These sources do not measure current Discard deployment, traffic, performance or abuse. They do not identify any live implementation and do not establish what a specific socket API reports without implementation evidence.