[HECnet] Network topology according to MIM.

[Johnny Billquist]

On 2016-01-15 14:50, Paul_Koning at Dell.com wrote:
>
>> On Jan 14, 2016, at 10:33 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> ...
>> DECnet does *not* deal gracefully with massive packet loss. :-/
>> Performance really goes down the drain. Doing morse with a flashlight bouncing off the moon will be faster.
>
> No ARQ protocol deals gracefully with significant packet loss.  There was a paper about TCP decades ago, way back when the Internet was still called "ARPAnet".  It showed that a 1% packet loss rate would cause a 50% performance drop.  With modern link speeds, the impact is far greater yet.  This is unavoidable because the response to packet loss is timeout and retransmission, and a timeout by definition has to take longer than the likely round trip latency.

TCP deals with it way better than DECnet, though. And various mechanisms 
for detecting packet loss exists, which do not rely on timeouts. I've 
implemented some in RSX, and it now usually holds up really well.

And with DECnet, a packet loss of, say, 10% will cause about a 99% 
degradation (or more) in performance.

> There do exist protocols designed for substantial packet loss, but they are far from mainstream.  (Basically, they use FEC -- redundancy in transmission -- rather than timeout and retry.)  You might find them in deep space satellite downlinks, for example, or shortwave or weak signal radio data networks like JT65.  But DDCMP, X.25, TCP, TP4, and DECnet are all examples of protocols designed with an assumption that packet loss is fairly rare.  It isn't usually stated explicitly, but as the ARPAnet paper showed, you really need to aim for well under 1 percent loss, especially on fast links.
>
> Many of these also assume that packet loss is random (caused by link error).  The exception is congestion control, which recent versions of DECnet have, and TCP as well (originally based in part on the DECnet work, and then extended further).

We can go on about techniques to improve life, as well as how TCP 
actually deal with this, which is way more than just timeouts. But my 
point was that for DECnet, the problem was so severe that I really had 
to do something at the bridge, or else the whole of HECnet turns useless 
using the bridge.	

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol