27 Mar
2021
27 Mar
'21
8:46 p.m.
Correct. I should not have said ?originally designed for?. The intelligent controllers
came in answer to some of the issues encountered in earlier versions of the protocol. All
of the DU-11s I ever saw, for example, were local to the site and required the processor
to do all of the work so they didn?t usually run very fast.. Although it was capable of
connecting to a modem, the modem required a special Wideband carrier circuit where you
could get either 230 Kbits, 50 Kbits, or 19.2 Kbits, depending on the type of Wideband
circuit. Such circuits used special provisioning to achieve reliable data transmission
and were not cheap. The intelligent controllers, IIRC, could use one or more channels out
of a standard T1 line and did not require special provisioning.
However, the rest of the statement stands. DDCMP needs a reliable transport if it is to
go any real distance (i.e. outside the local network) and UDP does not provide this. You
will encounter issues using DDCMP in UDP over the internet (again, unless you are talking
a short distance within the same carrier).
Mark
On Mar 27, 2021, at 1:06 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-27 18:59, John Forecast wrote:
Right. Smart controllers with DDCMP in firmware on the controller itself was definitely
not the first implementation.
But I don't have the full history of DDCMP as such. But it sounds reasonable that the
original DECnet could have been using DDCMP already. But was that the first implementation
of DDCMP? You mentioned V3.0, which would imply that there were even older versions since
before DECnet.
Did ANF-10 use DDCMP?
Johnny
On Mar
27, 2021, at 11:06 AM, Mark Berryman <mark at theberrymans.com <mailto:mark at
theberrymans.com> <mailto:mark at theberrymans.com <mailto:mark at
theberrymans.com>>> wrote:
DDCMP was originally designed to run over intelligent synchronous controllers, such as
the DMC-11 or the DMR-11, although it could also be run over async serial lines. Either
of these could be local or remote. If remote, they were connected to a modem to talk over
a circuit provided by a common carrier and async modems had built in error correction.
From the DMR-11 user manual describing its features:
DDCMP implementation which handles message sequencing and error correction by automatic
retransmission
No. DDCMP was designed way before any of those intelligent controllers. DDCMP
V3.0 was refined during 1974 and released as part of DECnet Phase I. The customer I was
working with had a pair of PDP-11/40?s, each having a DU-11 for DECnet communication at
9600 bps. DDCMP V4.0 was updated in 1977 and released in 1978 as part of DECnet Phase II
which included DMC-11 support. The DMC-11/DMR-11 included an onboard implementation of
DDCMP to provide message sequencing and error correction. Quite frequently, customers
would have a DMC-11 on a system communicating with a DU-11 or DUP-11 on a remote system.
John.
> In other words, DDCMP expected the underlying hardware to provide guaranteed
transmission or be running on a line where the incidence of data loss was very low. UDP
provides neither of these.
>
> DDCMP via UDP over the internet is a very poor choice and will result in exactly what
you are seeing. This particular connection choice should be limited to your local LAN
where UDP packets have a much higher chance of surviving.
>
> GRE survives much better on the internet than does UDP and TCP guarantees delivery.
If possible, I would recommend using one these encapsulations for DECnet packets going to
any neighbors over the internet rather than UDP.
>
> Mark Berryman
>
>> On Mar 27, 2021, at 4:40 AM, Keith Halewood <Keith.Halewood at pitbulluk.org
<mailto:Keith.Halewood at pitbulluk.org>> wrote:
>>
>> Hi,
>> I might have posted this to just Paul and Johnny but it?s probably good for a bit
of general discussion and it might enlighten me because I often have a lot of difficulty
in separating the layers and functionality around tunnels of various types, carrying one
protocol on top of another.
>> I use Paul?s excellent PyDECnet and about half the circuits I have connecting to
others consist of DDCMP running over UDP. I feel as though there?s something missing but
that might be misunderstanding. A DDCMP packet is encapsulated in a UDP one and sent. The
receiver gets it or doesn?t because that?s the nature of UDP. I?m discovering it?s often
the latter. A dropped HELLO or its response brings a circuit down. This may explain why
there?s a certain amount of flapping between PyDECnet?s DDCMP over UDP circuits. I notice
it a lot between area 31 and me but but much less so with others.
>> In the old days, DDCMP was run over a line protocol (sync or async) that had its
own error correction/retransmit protocol, was it not? So a corrupted packet containing a
HELLO would be handled at the line level and retransmitted usually long before a listen
timer expired?
>> Are we missing that level of correction and relying on what happens higher up in
DECnet to handle missing packets?
>> I?m having similar issues (at least on paper) with an implementation of the CI
packet protocol over UDP having initially and quite fatally assumed that a packet
transmitted over UDP would arrive and therefore wouldn?t need any of the lower level
protocol that a real CI needed. TCP streams are more trouble in other ways.
>> Just some thoughts
>> Keith
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> || Reading murder
books
pdp is alive! || tryin' to stay hip" - B. Idol