A common pattern in information technology is for a stream of data to flow thru a sequence of hardware or software modules. Such streams may branch and merge. The streams may be composed of bytes, or records.

Generally as a stream flows thru a software module it is transformed by the module by logic known to that module. Hardware stream modules may merely move data but the term “systolic array” describes a sequence of hardware modules, running on a shared clock, that process a stream of data where each module takes a unit of time to transform the element of stream data at hand and then hands it off to the next module for the next unit of time. The “Data Flow” scheme, by contrast processes the data as it becomes available, rather than on a shared clock. Both systolic arrays and data flow handle branching and merging. See streams for an application of continuations to stream processing.

Unix gained fame for its effective and clever use of software streams. Unix pipes are used to channel byte streams from one program to another. Sending data to and fetching data from pipes is enough like writing and reading files to make it unnecessary for most programs to distinguish these modes. Common Unix tools can be alternately instructed to use pipes or files by simple command syntax. Presotto & Ritchie’s Interprocess Communication in the Ninth Edition Unix System describes well these mechanisms and others that we shall discuss.

I think that Internet flow control mechanisms do a poor job. Perhaps they cannot be improved without revisiting the fundamental ArpaNet tenet that individual packets of a stream are conceptually routed individually. I shall say no more on that contentious subject here (except for this).

When I first began to use and design streams of software modules, I was blissfully unaware of the back-pressure problem. I would observe buffer overflows at a point in the stream and assume that the fix was to be applied somewhere near the leak. If I seem to make fun of systems that do the same I admit to having deployed some with the same problems, but I think that none of them remain in service. It soon dawned on me that piecemeal back-pressure design was prone to fatal leaks in the streams. Back-pressure must be continuous even if it is not uniform along the stream. Otherwise patching a leak may merely push the problem upstream.

On another subject here is a scheme that might serve ATM, Tymnet, and DSR well.

(2012 Sept) Tymnet has been shut down, DSR has not yet begun, I don’t know about ATM. Current DSR thoughts are spelled out better here. Still there may be ideas below.)

Suppose that when congestion arises the following sort of warning signal is sent in all directions from which data is arriving which contributes to the congestion. The signal would be processed by each node in the up-stream direction. The initial message would say that outgoing link j is badly congested and most packets for that link will either be dropped or buffered, depending on the protocol. In this message “link j” refers to a particular physical link connecting to the node that sends the message. The message might also include a bandwidth allocation for the recipient. The message is about traffic on link j but travels over link k, which is upstream from j. The allocation would refer to how much traffic, arriving on link k, the sender warrants to send on link j. If all such recipients of such messages restrain themselves then link j will not be overloaded. In this model it seems that the node to which the congested link is attached is best able to compare QoS parameters or SLAs for the various flows over that link.

As a counter-flow congestion message proceeds up-stream it gathers node IDs. Each node considers the message to decide if it is handling traffic contributing to the congestion and if so who further to inform. Such messages proceed only over links that contribute to the particular congestion. They eventually reach the edge of the network where agents concerned with alien congestion rules must determine actions.

For Tymnet the signal might be a bit map over a link with ones indicating circuits that should be slowed. This is much like current shorter term back-pressure signals. Here are more Tymnet details. ATM might require lists of circuits. For DSR there would be a variety of signal types depending on the protocols.

This could be adapted to IP but the messages would be more complex.