Error Control in Multi-Flow

CCITT standards were at the physical interface level and X.25 specified 56Kb/s DB-25 RS-232 plugs to interconnect to the host. It was soon evident that this was not fast enough and they invented a multi plug protocol that used several such plugs to serve one logical stream to deliver a sequence of blocks across the collective interface and adapted the flow and error control protocols that had been designed for a single link to multi links. I was surprised how smoothly the protocol was adapted. I think they used the term ‘multi-flow’ but that usage has been overwhelmed by other uses. I do not suggest that multiple plugs was the right answer for X.25 hosts, but given that the multi-flow protocol extensions seemed well thought out.

As in the single plug protocol blocks were numbered with a 3 or 7 bit number, and in multi-flow the numbering was global across all links. When the sender found a block to transmit, had clearance from the recipient to send, and found an idle plug, the block was sent on that plug. X.25 had a window scheme already suitable for satellites whereby acknowledgments could lag blocks by 7 or 127 blocks, depending on a negotiated parameter. When the sender failed to receive an acknowledgment after a set time, or received a negative acknowledgment, it sets its router back to one plus the last acknowledged block and began to retransmit. The choice to which plug to use was made again and a broken plug was merely taken out of service without impacting the larger flow. Acknowledgments did not need to return over the same plug as the block. The multi-flow specifications did not take much rewriting and the impact on the code presumably depended on coding style of the older single plug code.

X.25 error control was solely by retransmission but forward error control also works well with multi-flow. Erasure coding schemes that tolerate whole missing blocks serve well for either missing blocks or delayed blocks in extreme cases.