[HECnet] Old protocols in new ones

[Johnny Billquist]

On 2021-03-28 15:48, Paul Koning wrote:
> 
> 
>> On Mar 27, 2021, at 2:54 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> Paul and me have lamented over this many times.
>>
>> DDCMP assumes that the underlying transport mechanism is reliable. Both in terms of the ordering of data, the reliability of getting all data across, and no duplication, and so on...
>>
>> UDP does basically not fulfill any of these requirements, making UDP a very unsuitable transport for DDCMP links.
> 
> No, you're confusing DDCMP and Multinet.

Yes. You are right.
The thing is, Multinet claims to DECnet that it is a some kind of 
point-to-point link. But it's not actually DDCMP. My fault.
But it expects the same kind of service from the link as DDCMP will 
provide, which is where the problem is.

> Multinet isn't a datalink protocol; it's merely a wrapper for the routing layer packets.  In particular, it wraps routing layer point-to-point sublayer packets.  THAT assumes a reliable data link.

Well, Multinet is actually a data link protocol. Just as DDCMP is. But 
it is not DDCMP, my bad.

The Multinet link layer is rather simple, though. As you know. If using 
UDP, there is a sequence number to each packet, and with TCP it just 
have a framing with length information.
The rest just pass through without any further processing. But multinet 
do not try to actually deal with loss and retransmission anyway, so that 
sequence number is of limited use. (Not sure if it is actually used at 
all by the VMS Multinet.)

And at least in RSX, there is no generic "point-to-point" type of link.
The types that exist are:
. DDCMP
. Bisync
. SDLC/ADCCP/HDLC
. X.25
. Ethernet
. Hardware protocol

Where hardware is a bit like just saying that the hardware does 
something, and it's good enough. No software required, and it will work.
But all except ethernet are more or less point-to-point. But DDCMP can 
also be used for multidrop connections. The others would imply 
point-to-point, but will have possibly have different other software 
layers added to handle the specifics of that link protocol.

And in my case, I chose to claim to DECnet that the Multinet links are 
DDCMP, but without having a software DDCMP layer required. But that was 
just because I had to pick something in RSX. And this adds to my 
occasional confusion about DDCMP and DECnet link management.

> DDCMP is en entirey different beast.  It provides that reliable data link, and it sits on top of an unreliable physical layer.  It handles packet loss mostly because it handles bit error, which causes packet CRC error and is handled by timeout and retransmit ("ARQ").

Right. Well... It handles transmission errors through CRC. It handles 
packet loss also by using sequence numbers for packets. (Otherwise, a 
fully lost packet would not be detected. CRC don't spot such things.)

>> ...
>> But as far as DDCMP goes, you should essentially not use UDP as a transport. That is just bad. Use TCP instead. And then you're good.
> 
> No.  It's certainly ok to use DDCMP over TCP -- except that it has to deal with the oddity of doing both connect and listen concurrently.  But UDP works fine.

Right. My bad. I was totally mixing up DDCMP with the DECnet routing 
layer and link managment.

As far as using TCP, that comes down to the problem of how to establish 
the link in the first place. It's outside of DDCMP itself, and is no 
different than if you were to run DDCMP over a dial up line. Only one 
side is supposed to dial the number, while on the other side you would 
be answering the incoming call.
But yes, you need some way to tell which end should be listening, and 
which end should do the connecting.

   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