What ever happened to Tandem and NonStop OS 2019

some amount of networking used to refer to (copper line, point-to-point) communication. it was one of the places that osi fell-down

,,, that, and iso mandating that it would only entertain protocol standards work for stuff that conformed to osi model. lots of posts about high-speed protocol work

and ISO not being able to consider because:

1) it violated OSI model because it went directly from transport to LAN interface (skiiping transport-network interface)

2) it supported internetworking (aka tcp-ip, internetworking and internet doesn't exist in the OSI model)

3) it went directly to LAN interface ... LAN inteface sits in the middle of network layer ... violating OSI, and therefor supporting LAN interface would also violate OSI.

one of the early (real) "networking" issues was intermediate node congestion ... which is actually a "rate" related problem (i.e. the arrival rate of stuff is higher than intermediate node can handle).

one of the things you saw was that adapting the windowing-ack paradigm ... which had been developed for latency compensation in communication point-to-point links ... to also handling the intermediate node congestion problem in networks. to the extent that there was also a end-to-end latency issue in networks, it had paradigm carry-over ... but to the extent that congestion was a rate issue ... rather than a latency issue ... it was attempting to use a control mechanism that only indirectly affected congestion.

for instance, one of the problems with intermediate node congestion is some sequence of multiple back-to-back packets. a rate-based control mechanism wouldn't have allowed transmission of multiple back-to-back packets. however, one of the ways that the windowing-ack protocol was inappropriate was that returning acks could bunch in real-world bursty network traffice. the result is delay when the "window" is totally full ... and then when bunch of multiple acks arrive essentially all at once, the window is opened wide and multiple back-to-back packets would be transmitted until the window is full. in theory, you could get into negative feedback control environment ... with multiple back-to-back packets filling the window, congestion and lost packets result, back-off to less aggresive window size, retransmission of lost packets and then quickly growing window size until the congestion repeats itself. recently i ran across some paper that showed that it only takes relatively light amount of congestion dropped packets to significantly reduce effective network thruput ... not so much because of the dropped packets themselves ... but because the congestion control mechanism then could get into these negative oscillations ... in part because the control mechanism paradigm used doesn't have direct correlation with the operations it is suppose to be controlling (allowing things to get out-of-sync, resulting in inefficientices).

misc. past rate-based postings.

--