Summary

  • RFC 1190 let each ST-II hop acknowledge a CONNECT, negotiate a forwarding identifier and attempt resource reservation before the target application decided whether to join the stream.
  • HID-APPROVE closed a hop-local identifier exchange. The target's separate ACCEPT carried the FlowSpec actually accumulated along that branch back toward the origin.
  • A multi-target origin needed a result for every target and might drop a branch, split the stream or reduce excess reservations. Acceptance still did not prove later delivery or useful media.

An acknowledgement arrived before consent

RFC 1190 described the Experimental Internet Stream Protocol, Version 2, or ST-II. Published in October 1990, it was a limited-use experiment rather than an Internet Standard. Its RFC Editor record and IETF Datatracker entry now show that RFC 1819 obsoleted it; they do not turn its message diagrams into evidence of a live deployment.

The most revealing diagram starts with an ordinary-looking response. An intermediate ST agent receives CONNECT. Assuming no error, it selects its local virtual-link state and quickly answers the previous hop with ACK, HID-REJECT or HID-APPROVE. It can then invoke routing, reserve resources and send new CONNECT messages toward the relevant targets.

The reply proves that this neighbour processed one control request and, in the approval case, accepted a proposed Hop Identifier for efficient forwarding. The target application may still be several agents away. It has not seen the proposed stream, the accumulated FlowSpec or the identity of the application selector. A hop that owns a forwarding table cannot consent for an application it does not control.

Setup spent complexity before data moved

ST-II sat at the internet layer beside IP. Its model was not a sequence of independent datagrams. A stream was a directed, multi-destination tree with one origin, one or more targets, paths, per-agent state and allocated resources. Setup came first; data packets travelled only after the tree existed.

That choice moved work out of the fast path. Routing selected a next hop for each target subset. A proposed HID provided a short local handle for later data. Virtual-link identifiers directed control messages to the right state machine. Network multicast could let one transmitted copy reach several next hops, but its members still had to agree on a common HID.

The global stream Name, branch TargetList, hop-local HID and application service access point did different jobs. None was a human identity or authorization token. Their separation allowed fast forwarding, but only if an investigation kept the corresponding records separate too.

A requested FlowSpec changed as it crossed the tree

Resource reservation was broader than bandwidth. RFC 1190 listed forwarding state, packet-switch processing, buffer space, network capacity and multicast group identifiers. It did not specify one universal allocator underneath them. The memo openly noted that few contemporary networks offered reservation and that none known to the authors reserved the whole set.

The FlowSpec carried Desired values and protected Limits. When a branch could not provide everything desired but could remain within the Limits, an ST agent updated the request to the resources actually obtained. It could lower desired bandwidth, add delay or reduce the packet-size expectation before forwarding the next CONNECT. Intermediate and target agents could not rewrite the origin's minimum acceptable Limits.

That leaves several distinct facts: capacity described by a network, resources requested by the origin, allocation attempted at one agent, values obtained along one branch and the lower bound the origin refused to cross. “Reserved” without those coordinates is too vague to support a service claim.

Only the target application could answer for itself

At the target, the host ST agent first completed HID negotiation. It then presented the stream Name, FlowSpec, options, group and application selector to the specified process. The process could accept, refuse or reduce its desired service. Only after that decision did the agent send ACCEPT or REFUSE upstream.

The returned ACCEPT carried a new reference number and linked itself to the earlier CONNECT. Each intermediate agent verified that relationship, acknowledged the immediate response and propagated an individual ACCEPT along the reverse path. The FlowSpec came back with the result accumulated for that target.

This return journey was not ceremonial. It closed a different authority surface. The route function chose a branch. A resource owner decided what it could provision. A forwarding neighbour approved a local handle. The target application decided participation. The origin decided whether the returned terms were still useful. No actor silently inherited all five decisions.

One stream could contain several answers

An origin with three targets did not receive one global acceptance. It expected an ACCEPT, REFUSE or error for each target. As replies arrived, the application learned which resources each path had actually accumulated. Setup became complete only after every target had produced a result and identifier negotiation had finished.

The answers could be awkward. One branch might support a low rate of large packets; another, a higher rate of small packets. The origin might not find one safe combination. RFC 1190 therefore allowed it to remove targets, tear down the stream or create a second stream. A later CHANGE could release excess reservations after parameters were reconciled.

That is why one green branch cannot stand for the tree. Target B's ACCEPT is evidence about the path to B under its returned FlowSpec. It says nothing final about C, D or an aggregate rate the origin has not yet selected.

Acceptance could still be reversed before outcome

Even a returned ACCEPT needed reliable passage upstream. If an agent retransmitted it without receiving an acknowledgement, RFC 1190 eventually replaced it with REFUSE toward the origin and DISCONNECT toward the target. Higher-precedence streams could pre-empt resources after setup. A NOTIFY could report a reduced guarantee. A failed CHANGE could leave partially changed reservations and force recovery.

The protocol also supplied no security service by itself. It did not authenticate a human, authorize a payment or prove that an application's consent came from an institutional principal. And its setup state did not show that later packets arrived, voice decoded, video displayed or a participant experienced the promised quality.

The evidence ladder therefore continues beyond ACCEPT: settled origin parameters, current reservation state, transmitted packets, receiver observations, application processing and human or institutional outcome. The experimental protocol defined earlier rungs. It did not abolish the later ones.

Revision preserved the boundary and removed the shorthand

RFC 1819, with its RFC Editor and Datatracker records, revised the experiment as ST2+ in 1995. Its IESG note explicitly said that neither version was an Internet Standard or under consideration for that status.

ST2+ retained the important chain: an intermediate agent acknowledged CONNECT, asked a local resource manager, propagated the branch request, let the target application decide and returned ACCEPT to the origin. It removed HIDs, however, because their complexity had obstructed interoperability. It also removed subset implementations after experience showed that permitted subsets produced inconsistent capability.

The revision is a useful warning against reading the 1990 fields as timeless facts. A locally approved identifier could disappear from the next design while the application-consent boundary remained. Implementation compatibility, resource allocation and participation were separate problems.

The earlier RFC 1077 had framed high-bandwidth networking as more than fast media. Later, RFC 1633 and RFC 2212 defined other reservation and guaranteed-service surfaces. Similar questions do not prove direct descent. They do reinforce the distinction among physical capacity, a conditional service commitment and measured outcome.

Sources