[Info-vax] DECnet Fantasy Networking (was: Re: Networking Benchmarks)

[Stephen Hoffman]

On 2019-09-17 14:08:28 +0000, johnson.eric at gmail.com said:

> On Friday, September 13, 2019 at 12:35:57 PM UTC-4, Bill Gunshannon wrote:
> 
>> Has anyone ever done any benchmarking of TCPIP vs. DECNET under VMS?  
>> It seems that there should be less overhead and therefore greater 
>> throughput using DECNET.

That would have been an interesting comparison back in the 1980s and 
1990s and the last millennium, but DECnet lost the plan in the 1990s 
with the missed-the-market OSI efforts, and neither DECnet via DDCMP 
nor DECnet via OSI, nor DECnet via OSI via IP, are going to arise anew.

DECnet is an unmitigated disaster for security.  Assuming and 
maintaining an actually-isolated link is getting tougher over time, too.

> I believe your greatest bottleneck will be the  amount of time it takes 
> to shovel ethernet frames through the underlying machinery that is 
> shared in common. So it's not about TCPIP vs DECNET. It's about what 
> kind of performance do non VMS systems see with their networking gear 
> vs. what VMS systems see.
> 
> As I believe you will see, VMS falters here.

Ayup.  Those performance limits have been discussed previously around 
here, too.  The processing time available for 40 GbE frames is getting 
pretty tight for Linux, too.  This driver performance limit hits all 
networking on OpenVMS, too.

> Perhaps that will be cleaned up by VSI.

The whole driver stack is going to be a project, yes.  A big one. 
Whether the IP networking gets offloaded, or gets re-designed and 
re-written, or whatever.  Fewer or no buffer copies, etc.  Adding BPF 
and maybe a JIT, for that matter.

> When that happens, I believe the choice will be clear. Stick with TCP 
> as its widely understood by all.

SCTP, QUIC, MPQUIC, and ilk will be the likely comparisons and probable 
upgrade paths for those that are running out of performance with TCP, 
and seeking to re-work their apps.  Not DECnet.  OpenVMS does have SCTP 
with TCP/IP Services.  AFAICT, neither VSI TCPIP nor MultiNet offers 
SCTP, and QUIC is too new for any of these stacks.  (Now adding a 
networking layer into OpenVMS—on the way to these sorts of protocol 
upgrades—would be helpful in the longer term, dealing with 
authentication, encryption, DNS, and the rest. But that's been 
mentioned, too. libtls is something to look at here while designing 
this, as would be Secure Transport and its replacement Network 
framework.)

Falling back to DECnet and its lack of encryption and authentication 
will mean partitioning the traffic and keeping it local, and keeping a 
second set of interfaces for secure paths, and quite possibly a third 
set for when you're interoperating.  That all atop even having a DECnet 
stack available on the target platform, and the Linux DECnet stack was 
orphaned a ~decade ago.

I remember this let-us-do-our-own-network-transports stuff back in the 
1980s.  I wrote a couple back then, too.  All sorts of "fun" with 
network multicasts and frames and the rest. That worked decently well, 
but most of the work went into the common transports, and those then 
outstripped what the proprietary transports offered, and we all had the 
choice of maintaining and updating our own transports, or migrating to 
the available commodity transports.  And VSI is not big enough nor 
funded enough nor positioned to create and maintain a competitive 
transport.  They really shouldn't be spending very much on DECnet, save 
to help folks migrate off.




-- 
Pure Personal Opinion | HoffmanLabs LLC