Link Transmission Services

We propose here a software interface behind which sits code that knows all about the physical transmission links, referred to elsewhere in these pages as links. Issues such as link failure modes, including transmission error statistics and appropriate schemes for forward and backward error control. Depending on hardware this may also be the place for crypto in support of link encryption and authentication. I include exact numbers here to suggest magnitudes; none of them should be considered fixed, except, perhaps 8 bit bytes. It is not clear that stack discipline is suitable for node logic.

Node Integrity

By redundant information we mean extra information derived from the rest of the packet to detect transmission errors. Checksums and CRC values are redundant information. Corruption of link data between the neighbor nodes comes in several forms:
Ambient physical noise
Classical checksums will detect this and support backward error control (retransmission). For known error statistics there are forward error controls which are cheap in hardware and impose CPU and latency penalties only upon errors. IBM disk controllers did this in 1970.
Durations of no useful Data Transfer
A timeout must be established beyond which the link is declared down.
Malicious replacement of transmissions including consistent redundant information
This can be detected with secret salt added at each end of the link. It probably requires hardware mods for hardware computations of the redundant information. Such protection requires nonlinear redundant information, such as SHA.
Malicious duplication of past transmissions
Sequence numbers seem to suffice.
Detection of such link corruption is required for node integrity, but not network integrity, or customer integrity.

It is of critical importance that node behavior not be corrupted by bad data from the link lest a virus spread thru the net via the links. I think that corrupted node state is not sufficient for a virus. Distinguishing state from behavior is still an art.

I presume here to design code whose behavior is not corrupted even in the presence of malicious active agents in the links that somehow bypass the above protections and thus become part of a spreading network virus.

Code Orchestration

Stack discipline may not be suitable for scheduling the CPU. Certainly stack discipline will hold in the small as library routines are used normally. Continuation passing style or more particularly Flow Based Programming may be better. For now I use “entry” without committing as to whether a continuation is included. Here are comments about one real time communications app, and even earlier ones.

One entry to LTS delivers ownership of a 64KB buffer, by reference, to be transmitted on a particular link. Arguments:

Priority is some very small positive integer, probably not greater than 3. When the down stream node has acknowledged receipt, the buffer is returned to the general pool and some sort of signal is given to the executive code for the node—so far an obscure concept. The responsibility of LTS is to get the buffer contents to the other end of the link, error free, without duplication, and acknowledged, in the same order for a given priority as delivered to LTS.

LTS also calls on the buffer pool to get buffers into which incoming link traffic is to be placed. Such buffers are suitable for error control logic and crypto processing. LTS can assume that some small number of buffers for each link will be available.

I assume here that in an industrial grade node, heavy duty traffic will normally move from the fiber to the DRAM buffer, perhaps via non CPU crypto, and thence to some other fiber entirely bypassing any cache, except for about one cache line holding the buffer header, which will be flushed by logic outside LTR. We won’t soon have an industrial grade node. Indeed I suspect that ordinary memory busses will not have the necessary bandwidth. Conventional SDRAMs do. Here I speculate on how to get more of the power of modern SDRAMs that classic memory busses deliver.

Sorts of link messages