Summary

  • RFC 3081 mapped a BEEP session to a single TCP connection but refused to treat TCP's connection-wide flow control as proof that each multiplexed channel could progress.
  • Every channel began with 4096 octets of receive credit. SEQ frames moved that local boundary and received scheduling priority; implementations were advised to serve channels in round-robin fashion.

Reliability did not decide whose work moved next

Suppose four application channels share a clean TCP connection. Three consumers read promptly. The fourth accepts data slowly while its sender has much more to deliver. TCP can continue doing exactly what it promises: order bytes, recover loss and regulate the connection against its peer's receive capacity. Yet the slow application can occupy enough of the common path that unrelated channels wait behind it.

Nothing in that incident requires a broken packet or a failed connection. It is a dispute about admission and service inside a reliable carrier.

Published in March 2001 on the Standards Track, RFC 3081 defined how the Blocks Extensible Exchange Protocol used TCP. Its mapping was spare: one BEEP session sat on one established TCP connection, and BEEP messages became payload octets in that stream. But the document did not mistake a simple mapping for a complete isolation policy. It identified starvation and deadlock as risks when several logical channels shared TCP's single flow-control context.

One connection had one TCP window

TCP reasons about sequence space and capacity for the connection. It does not know that some bytes belong to a management exchange, others to a rapid request, and others to a bulk application response. Those distinctions exist above TCP.

RFC 3081 therefore assigned a separate sliding window to each BEEP channel. On creation, a channel had permission to send 4096 payload octets. The receiver could later issue a SEQ frame containing the next sequence number it expected and the window size it was prepared to accept. Together those values advertised a channel-local upper edge.

The mechanism was not a second reliability protocol. TCP already retransmitted and ordered the underlying bytes. BEEP's sequence accounting answered another question: how much more application payload may this particular channel introduce into the shared connection? A sender that reached the edge had to stop that channel even when TCP itself remained writable.

Serial-number arithmetic mattered because counters wrap. RFC 3081 referred to RFC 1982's arithmetic and bounded the window so comparisons stayed unambiguous. The small formula was really a control boundary: a wrapped number could not be allowed to turn old credit into fresh authority.

Credit had to escape the queue it controlled

A flow-control update is useful only if it can reach the sender. If SEQ waited behind ordinary payload from the very channel or connection it was trying to release, the feedback loop could freeze. RFC 3081 consequently gave SEQ frames priority over other traffic.

That priority did not mean management was more valuable than application content. It meant control information was causally upstream of further transmission. The receiver had to be able to say “this lane may advance” before more material could be admitted to that lane.

The RFC also recommended round-robin servicing among channels of the same priority. The recommendation was intentionally modest. Round-robin did not promise identical latency, equal message sizes or perfect fairness under every operating-system buffer and congestion pattern. It gave implementations a baseline against an obvious failure mode: draining one busy channel indefinitely while ready neighbors received no turn.

The slow reader was outside the protocol boundary

The receiver could acknowledge that bytes had arrived in the BEEP channel and still have a slow application above it. That is where apparent success becomes misleading. TCP receipt, BEEP acceptance into a window and consumption by the destination application are three different observations.

RFC 1122 had already made clear that TCP presents a reliable byte-stream service, not application transaction completion. The modern TCP specification, RFC 9293, preserves that boundary. RFC 3081 built on it rather than asking TCP to recognize BEEP's channels.

Later mappings show why the separation mattered. Reliable syslog over BEEP in RFC 3195 used BEEP's exchange and transport machinery, while NETCONF over BEEP in RFC 4744 bound network-management semantics to a profile. Neither application could infer final operational effect merely because bytes crossed TCP or channel credit advanced.

A window was evidence, not an entitlement forever

The receiver owned the advertised capacity because it bore the cost of buffering and delivery. The sender owned the choice of which eligible channel to schedule next, constrained by each channel's current credit and the mapping's priority rules. TCP still controlled connection-level congestion and reliable transport. The application decided when received material had produced a meaningful effect.

Those authorities were adjacent but not interchangeable. An open TCP send buffer did not authorize BEEP payload beyond a channel window. New BEEP credit did not prove the application had processed previous data. A round-robin implementation could show that it offered turns without proving that downstream work completed.

This is the durable contribution of RFC 3081. Multiplexing does not create independence by naming lanes. Independence requires separate budgets, feedback that cannot be trapped behind the traffic it governs, and scheduling that prevents one lawful user of a shared substrate from silently becoming its owner.

Sources

  1. https://www.rfc-editor.org/info/rfc3081
  2. https://www.rfc-editor.org/rfc/rfc3081.html
  3. https://datatracker.ietf.org/doc/rfc3081/
  4. https://www.rfc-editor.org/rfc/rfc3080.html
  5. https://www.rfc-editor.org/rfc/rfc1982.html
  6. https://www.rfc-editor.org/rfc/rfc1122.html
  7. https://www.rfc-editor.org/rfc/rfc9293.html
  8. https://www.rfc-editor.org/rfc/rfc3195.html
  9. https://www.rfc-editor.org/rfc/rfc4744.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/