Kx10: Host-to-IMP interface supporting NCP

[larsbrinkhoff]

I have another cart to put before a horse: doing NCP from the IMP.

I'd like to hear your thoughts on this and discuss the options.

[larsbrinkhoff]

My primary interest is talking NCP directly to other hosts. Much like how we can speak Chaosnet now.

[rcornwell]

NCP can only talk to 256 hosts, Therefore it will require a mapping table. My thoughts on this are that IMP will package up the NCP packets into a UDP packet and send it to a gateway program. This program will handle ICP and translation to TCP. Also NCP sockets were unidirectional so the NCP daemon will have to de-multiplex the TCP connection.

[larsbrinkhoff]

256 IMPs (or thereabouts, dunno if 0 and/or 255 are special), and each IMP could have multiple hosts.

[rcornwell]

Host tables only had a single byte for host number so not sure how you could have more then 255 hosts. And several hosts were special for testing.

[larsbrinkhoff]

You're right. It was actually a 6-bit IMP number and a 2-bit host number. For example, MIT-MULTICS was IMP 6, host 0, or in octal 006. MIT-DM was IMP 6, host 1: 106. MIT-AI 206, and MIT-ML 306.

This was reflected in the transition to IP. The addresses became 10.0.0.6, 10.1.0.6, 10.2.0.6, and 10.3.0.6.

[larsbrinkhoff]

I took a look at Bob Armstrong's H316 IMP code in SIMH. If I understand correctly, it should be able to talk to a host through UDP. I emailed Bob asking for clarifications.

[rcornwell]

Adding a UDP mode for IMP would not be hard to do. IMP could also wrap packets up into UDP packets and send them out itself. All the logic for generating IP packets is in the code now.

[larsbrinkhoff]

Here's what Bob Armstrong says:

The simh IMP version simulates the host interface for the H-316 side, but currently it always pretends that the host is offline (powered down). I thought that someday somebody might want to make it talk to another simulator so I put hooks in there for an eventual connection to a host, but AFAIK you're the first one to actually do that. My assumption was that there would be some kind of TCP or UDP connection between the IMP simh and the host simh, but exactly how that would work is to be determined.

I'll be glad to help you if I can, and I might even be able to write the IMP side of the connection for you, time and schedule permitting.

[larsbrinkhoff]

I got a SIMH patch from @charlesUnixPro to add an IMP host interface to H316. It encapsulates 1822 messages in UDP packets.

CC @markpizz. Summary: at some point, I would like to see ITS hooked up to a simulated ARPANET.

[larsbrinkhoff]

Here's the patch.
imp_fixes.txt

[larsbrinkhoff]

By the way, I call dibs on IMP number 6!

[markpizz]

I'm not sure what the functionality that is being implemented here.

As I understand it, Rich's kx10_imp.c imbeds what the simulated system more or less thinks is an connecction to a IMP. Where the IMP is effectively a what we think of today as a router.

As I understood things, the IMPs were implemented on H316 hardware with several point to point connections.

The existing H316 has what seems to be a stub IMP device which I don't understand the point of given the above "understandings", and it has a h316_udp.c module which implements MAXLINKS point to point connection between two systems that can make sense of the data being exchanged.
This device actually uses TMXR to deliver UDP packets.

So, I don't understand how any of this has anything to do with Rich's IMP device.

[larsbrinkhoff]

At this point, the exact functionality or implementation is not decided.

kx10_imp.c currently only does TCP/IP through the IMP interface on the PDP-10 end, and Ethernet frames on the host end. The H316 simulator is not involved.

What I'm proposing is to add... something... to support the Arpanet NCP protocols. These also involves IMPs, but in a slightly different way. And of course the NCP protocols are mostly incompatible with TCP/IP.

Since people have already used the H316 simulator to run the IMP software and recreate an ARPA network, it would be possible to build on this. There is also Charle's patch to implement the host interface in H316. kx10_imp.c would have to be updated to talk to this host interface.

Another possibility would be to have kx10_imp.c talk directly to a peer, similar to how Chaosnet is implemented.

[markpizz]

The existing logic provides an equivalent point to point device which would allow bot separate 'IMP H316' simulators to talk exchange packets via the h316_udp.c and if a 'Arpanet' capable host wanted to participate in these conversations, the kx10_imp could be slightly enhanced to be able to exchange packets with an H316 IMP via its h316_udp device. The kx10_imp already leverages sim_ether for packet transport and one of the transport options is UDP as a point to point circuit. kx10_imp would have to be enriched to just be a raw packet transport which really means side stepping much of the internal IP magic it currently is somewhat optionally doing.

I still don't get what the IMP device would be in the H316 simulator.

[larsbrinkhoff]

There's not exactly an IMP device in H316. There's HI (h316_hi.c) which is the host interface. It's currently an empty stub, but @charlesUnixPro's patch makes it talk UDP.

[rcornwell]

It should not be hard to modify the IMP device to just package up whatever the remote gives it and generate a UDP packet out of it. Same as inbound. Simh might already have this built in in the sim_ether device.

[markpizz]

There's not exactly an IMP device in H316.

Look at line 104 of H316/h316_imp.c, you'll find a IMP device.

There's HI (h316_hi.c) which is the host interface. It's currently an empty stub, but @charlesUnixPro's patch makes it talk UDP.

The patch supplied is not a patch against the current code in the master branch. The H316 simulator code hasn't seen any changes in 6-7 years so that is surprising. A zip or tarball of the @charlesUnixPro's H316 working directory would be sufficient.

The current code in his patch seems to be trying to manage link speeds. The underlying TMXR layer which h316_udp.c is using should be used for that. This would remove complexity from that code.

[rcornwell]

In order to support NCP I am going to have to package up what the PDP10 is giving me and send it off to a server. Who would then convert it to TCP request. Problem is the NCP is very different from IP. The IMP managed socket allocation and endpoint management. You basically had a bunch of numbered hosts, 256 or 64k if I remember from the specs. These would have to be mapped into IP address by the NCP server. NCP support is useful for WAITS, since that is currently all the KA version supported. Implementing this with a network of simulators might be interesting.

kx10_imp.c could be configured to either directly encapsulate what it receives form the 10 into a UDP packet and send it out, or it could use read/write requests to send what it gets out. The IMP to host interface was basically a packet based protocol, each packet had a header on it telling the IMP what type of packet this was. When IP support was added, they just sent IP out as a packed. All the IMP device does is put a Ethernet header on the packet and send it out, or remove the Ethernet header when it receives a packet. The rest of the logic is to deal with routing of the IP packet to the correct remote host (i.e. correct MAC), and managing the fact that ITS IP address is fixed at system generation time. This allows the system to be set up on a more modern network with little fuss.

[larsbrinkhoff]

Oh, there's a h316_imp.c. No, I don't know what it does either, but supposedly some hardware the IMP software relies on.

[larsbrinkhoff]

I applied the patch with some manual intervention. I put it on a branch in my SIMH fork:

larsbrinkhoff/old-simh@518f0e6

[larsbrinkhoff]

It compiles, but I didn't try to test it.

[markpizz]

The host IMP implementation has been added to the H316 in the github.com/simh/simh master branch along with portability cleanup and an extra readme file which explains the things in the H316/tests directory. I don't know why that readme never made it there before.

The H316 host interface is very much like the Chaosnet implementation. In order for this to make it into the KA/KI/KL, the kx10_imp would have to be extended to have a new functionally different internal modes. This mode would talk the UDP wire protocol that the H316 imp speaks when it uses UDP for a transport. The kx10_imp could indeed leverage the UDP support in sim_ether, but it would have to encapsulate the UDP traffic in a compatible way to how the H316 currently does. The encapsulation includes a sequence number outside of the data to assure proper sequence arrival and duplicate avoidance.

This provides Arpanet between PDP10's, but the PDP10's would either be TCP capable as they are now with the kx10_imp or they could talk to each other across an Arpanet, but not both. If someone could find later versions of the IMP software, maybe some of this would be easier.

[larsbrinkhoff]

Thanks Mark! I wasn't expecting things to happen so quickly. For what it's worth, I talked to Bob Armstrong and he agreed the host interface should do in.

I'm keen on trying the host side, but Rich is busy getting the KL10 simulator into shape for merging. So it's probably best to wait until after that.

According to Bob, no other working IMP software version has been found. I'm not sure the 1973 version will accommodate TCP? I would expect it to have only 1822 short leaders, and I have a vague memory TCP requires long leaders.

[markpizz]

I don't know what long or short leaders are. Napoleon was short, and Trump is somewhat tall, but I'm pretty sure this has nothing to do with them.

Can you elaborate about your view of leaders.

[larsbrinkhoff]

Of course. The original message protocol between the IMP and the host had a 32-bit "leader". This leader is just what we call header today. A later update extended this leader/header to 96 bits to accommodate more information.

[markpizz]

I would guess that the size of the header is only a small part of the problem of converting protocols. Whatever "conversion" will be done will be invisible to the endpoints, so the headers that traffic starts with really won't matter. I'm sure that we're not dealing with a simple 1<->1 packet translation, but effectively independent conversations that happen to contain more or less the same data.

[larsbrinkhoff]

I'm not sure what conversation you mean. Rich has sometimes hinted he wanted NCP guests be able to talk to TCP hosts. This is why I added "(to IP gateway)" in the issue title. If this is what you mean, then yes, leader size is only a small part of that problem.

For me, this conversation is not important. I mostly want NCP guest operating systems to talk between each other.

[markpizz]

@eswenson1 I understand how TAP works, and TCP/IP etc. However TUN does not make a huge amount of sense to me. With the appropriate route statements it might be possible to make FTP work. But to make TUN work requires putting in a bunch of route commands to point traffic around. A TAP device is just another network adapter.

Actually if you give a TUN device a network address (on the host system) and netmask that includes the simulator's IP address which must be different from the address used on the host, you've got an identical routing problem to a tap device. In either case, the host should be able to talk to the simulator with no special routes and the simulator should be able to talk to the host (both presuming the simulators gateway is the other end of the TAP or TUN). In both cases you won't be able to talk beyond the host machine until 1) the host machine's kernel is configured to route packets and 2) routes to the network segments being used by the TUN or TAP interface is somehow known around the network. Somehow could be by running a routing protocol.

@eswenson1 TUN can definitely transmit more the just Telnet. However FTP between different networks IP/IP requires that the PORT command be rewritten, and TUN by itself does not do this. Now routing might be able to these rewrites.

FTP port rewrites are only needed when transiting through a NAT. If the above mentioned routes are known, then the simulator is just on a different network segment that must route through the

[larsbrinkhoff]

TUN interface like Lars originally proposed would have only worked for Telnet. Also it would most likely have been just some ports on the local host.

These two statements are not true. TUN works for all TCP/UDP/IP protocols, and it's not restricted to some ports.

KLH10 is not very portable in how it configures the network.

This statement is true.

[larsbrinkhoff]

I am all for a separate device, I think it should talk to the H316 simulator over TCP. Chaosnet protocol was by itself unreliable, so ITS/Tops20 has to deal with lost packet.

That's a good point. I'm rather agnostic about UDP vs TCP.

BUT I'd like to get some input from Bob Armstrong and Charles Anthony if there's a specific need for the host interface which makes it better suited for one or the other. Such as things related to timing, which apparently is the case for the IMP-to-IMP interface.

[markpizz]

The kx10_ncpimp.c would only "need" to have a TUN type interface IF the sending system transporting data through it was transporting IP packets

I think you mean that the ncpimp would support both IP and NCP. But just in case, to be clear: NCP is not related to IP, but a separate stack of protocols.

That is not what what I meant to imply. I clearly understood that what NCP packets are, and therefore injecting them into a host system's IP stack via a TUN interface would be a useless activity.
Only if the IP traffic (originating from the simulated system) was being transported would a TUN connection be useful.

[larsbrinkhoff]

However FTP between different networks IP/IP requires that the PORT command be rewritten, and TUN by itself does not do this.

Ok, if you add NAT to the mix this alters the equation.

[larsbrinkhoff]

I think we are all mostly in violent agreement.

[rcornwell]

I this so :-) NCPIMP will not support talking to a TCP connection, unless it is TCP connection to simulated IMP.

[markpizz]

BUT I'd like to get some input from Bob Armstrong and Charles Anthony if there's a specific need for the host interface which makes it better suited for one or the other. Such as things related to timing, which apparently is the case for the IMP-to-IMP interface.

I'm all for their involvement, but the H316/tests directory has tests that can validate the basic network functionality using the IMP software and the timing it depends on.

I'm cleaning up the h316_udp.c code so that this module can readily be included in a different simulator but still works for the H316, while doing this I'll add an option to the udp_create routine to specify an option for UDP or TCP.

[rcornwell]

@markpizz Injecting NCP packets into a TUN interface would do zero. NCP is just too different. However if ITS/Tops 20 was talking TCP/IP it might be possible to just inject them into the network. Then users could choose one or the other. This would depend on how TMXR is set up.

[rcornwell]

@larsbrinkhoff If you could clean up the pending KA10 issues that you have, that would be better. NCPIMP will not ship before KA10 moves to simH tree!

[markpizz]

@markpizz Injecting NCP packets into a TUN interface would do zero. NCP is just too different. However if ITS/Tops 20 was talking TCP/IP it might be possible to just inject them into the network. Then users could choose one or the other. This would depend on how TMXR is set up.

That is true, but it would then be equivalent to doing the exact same thing as can already be done with the current IMP only via a TUN vs a TAP. Solving the TAP configuration details is something that has to be done anyway. Adding a TUN capability to TMXR only "solves" this one problem and isn't going to be useful in any other near term (or far term) context.

[rcornwell]

@markpizz true. Perhaps something other than Slirp needs to be added to sim_ether.c to handle TUN type connections. Either way, my current plan for NCPIMP is to talk to TMXR packets to send and receive data. What protocol runs over that is up to others.

Note this might also be a good model for simulating synchronous links between systems like DECNET type interfaces and some RJE systems.

[larsbrinkhoff]

@rcornwell, don't worry. I'm not actively working on this.

[markpizz]

Note this might also be a good model for simulating synchronous links between systems like DECNET type interfaces and some RJE systems.

That is exactly the idea that I had back in the 2012 timeframe when I added the point to point capability and then a packet interface to TMXR. :-) The pdp11_dmc.c, pdp11_kdp.c and the pdp11_dup.c are current devices using these features. Folks have successfully run DECnet circuits using the point-to-point capabilities via pdp11_dz ports speaking asynchronous DDDMP between simulated systems.

[markpizz]

@rcornwell you did the right thing with the kx10_imp. The TUN subject keeps coming up since TUN was used on the KLH10 IMP with KLH10 IMP being a simple packet passer while you solved a pile of other problems. After reading all of the network stuff mentioned in https://github.com/PDP-10/klh10/blob/master/doc/install.txt essentially all of the problems simh has always had while Ken also had the point-to-point TUN device when we've never had to deal with. When I was looking at this I wasn't aware of all of these subtle details that he spells out. This info has to be translated into terms relevant to simh's network setup and to directly solve the TAP vs TUN configuration subtleties.

Meanwhile, in preparation for a kx10_ncpimp, I'm reworking the H316 pieces slightly so that the udp transport can readily be used by another simulator.

[rcornwell]

@markpizz Thanks I always felt that Ken's solution was a good one was not the right one for the problem. Mine was more work, but a more complete model of the problem.

Please make sure that H316 can use TCP to talk to a direct connect host. The direct connect host was 100% reliable. NCP will not resend dropped packets. Connection between IMP's can be use UDP or TCP. The IMP software would work with the need to re-transmit lost packets.

[larsbrinkhoff]

Here's what @charlesUnixPro wrote back:

I used UDP because I was able to largely copy the existing IMP-to-IMP code,
and I personally historically have had difficulties writing TCP code that was
well behaved in terms of robust error recovery. I did not do a analysis of
best solution; I got some code working for proof of concept.

I suspect that well written TCP code would probably be better; if only for
the reason that it makes it simple to implement the "Ready" bit in the
interface.

And BoB Armstrong:

Read the comments at the top of h316_udp.c…

Essentially the problem is that the latency with TCP is both unpredictable
and uncontrollable. Modems aren’t like that, and it makes the IMP code
unhappy. I don’t have direct knowledge of whether there would be a similar
problem with the host interface, but I’d be worried.

[markpizz]

I've read Bob's comments and I'm a little concerned, but:

1. TMXR's packet interface runs TCP circuits with Nagle disabled, so whole packets are very likely to be passed immediately.
2. Delays will not likely be a problem when the IMP and Host are on the same machine and also not likely to be a problem on the same LAN.
3. All of the TMXR socket I/O is non blocking, so that, combined with Nagle disabled should not suspend a transmitter. The timing he's concerned about is time to actually transmit or receive a given packet. That time is measured by the IMP system, but the way this part of the simh works, is that udp_send() will always return very quickly, so the only real worry about delays would possibly be related to round trip times. Since the IMP is just a packet transporter and not a circuit provider it doesn't even see round trips or am I missing something?

Charles used the existing h316_udp directly. That has made it easy to keep this all in one place. Since TMXR has the same interface to send and receive packets independent of whether they're transported by UDP or TCP, The current API names are udp_create (to open), udp_release (to close), udp_send and udp_receive. I've added a parameter to the udp_create to specify LINK_RELIABLE (TCP) or LINK_ORDERED (UDP without dups and order guaranteed, but lost packets OK.). The LINK_ORDERED is the original behavior. I was thinking of changing these names to a more generic name like link_open, link_close, link_send, and link_receive.

TMXR solves Charles' concern about robust error recovery. Simulation code isn't dealing with socket problems and it also solves the how to manage which side connects to open the channel.
Additionally it exposes link/modem state information which should be useful info to an IMP with modem and host connections.

If Bob's concerns about timing with TCP turn out to actually be a problem, forcing both to UDP and ignoring the possible packet loss would probably be just fine on almost all hosts and Local LAN setups.

[eswenson1]

@eswenson1 I understand how TAP works, and TCP/IP etc. However TUN does not make a huge amount of sense to me. With the appropriate route statements it might be possible to make FTP work. But to make TUN work requires putting in a bunch of route commands to point traffic around. A TAP device is just another network adapter.

@rcornwell But if you remember, on a VPS host with one NIC and the limitations I had with additional IP addresses, I (with yours and Mark's help) was never able to get a TAP setup to work and had to resort to the NAT-based solution. In contrast, on the same host, with the same limitations I have no problem at all with my TUN-based KLH10 simulator. And unlike the NAT solution (and apparently the TAP solution), I also have no issues with FTP to/from my TUN-basd KLH10 simulator. Because of this, I reverted to that setup for both my ITS machines, since I didn't like living with a sub-par networking setup.

[rcornwell]

@eswenson1 I am not sure KLH10 is a true TUN interface. I believe He does some system calls to configure networking. This is not portable to windows (or all Unix machines).

For your usage a KS simulator is probably enough.

BTW the problem is with your desired way to run simulator and not with the simulator itself.

[eswenson1]

BTW the problem is with your desired way to run simulator and not with the simulator itself.

Can you elaborate? I'm not trying to do anything special. I just can't add additional external IPs with additional MAC addresses on this particular VPS host. I just want to "do networking". I don't care how I do it. I want FTP, TELNET, SMTP, etc. I was never able to get this to work with your TAP or NAT configuration.

[markpizz]

As I've said here in the last couple of weeks, I was unaware of the "extra" information and potential external setup that the KLH10 documents provide, and for reasons of lack of need (no device requires) a TUN based solution we haven't had to work out the potential subtleties to get things working.

Trying to invent solutions to problems like this at arms length (via email or chat sessions) is too slow and particularly not satisfying. If you want to either let me in to your VPS setup or you're willing to configure an identically configured VPS "Free Trial" that's setup to 1) run KLH10 and 2) has an identically configured simh disk image with the OS you want to run.

You say: "I'm not trying to do anything special." Well getting the potentially many different things you want to achieve with a single IP and MAC address is actually pretty special.

Please also describe exactly what you mean when you say: "I want FTP, TELNET, SMTP, etc." Are you using the OS running in the simulator (KLH10 or Rich's) to make:

1. outbound connections from the simulator to these services on
   1a) the host system, or
   1b) the outside world

And/Or

2. inbound connections to the simulator from
   2a) the host system, or
   2b) the outside world

When you describe what you "want" here, realize that what you "get" will not be more than what KLH10 can achieve under these conditions.

Our goal is to produce documents and potential scripts that configure a host system to solve network problems like this.

[eswenson1]

You say: "I'm not trying to do anything special." Well getting the potentially many different things you want to achieve with a single IP and MAC address is actually pretty special.

Well, I don't consider it special. When I created the TUN device (or let KLH10 create the tun device), I had configured a non-routable IP address. I never had to tell my VPS provider about it, since it was non-routable. Doing just that, I was able to telnet and ftp to/from my KLH10-hosted ITS system.

Then, I wanted to access this ITS system from the outside. There, I had to configure iptables with NAT rules so that it would forward packets destined to/from my ITS system over the single external IP address my VPS provider gave me. In my book, doing this iptables config is pretty "normal" and "straightforward". Anyone who sets up backoffice hosts on servers has to do this if they want external access (over limited ports) to those backoffice hosts.

Please also describe exactly what you mean when you say: "I want FTP, TELNET, SMTP, etc."

I want to be able to TELNET (actually SUPDUP) and FTP to/from my ITS system from hosts on the internet (from which I've allowed that traffic). I also want email sent to my ITS systems to actually reach the SMTP server on my ITS systems, and email sent to the Internet from my ITS system to actually reach SMTP servers on the Internet.

All of the above works perfectly fine with KLH10/tun/ITS now. I never was able to get this all working working with TAP/NAT configured in SIMH.

Are you using the OS running in the simulator (KLH10 or Rich's) to make:

outbound connections from the simulator to these services on
1a) the host system, or
1b) the outside world

yes and yes.

And/Or

inbound connections to the simulator from
2a) the host system, or
2b) the outside world

yes and yes. And all this works fine with KLH10.

When you describe what you "want" here, realize that what you "get" will not be more than what KLH10 can achieve under these conditions.

KLH10 is able to achieve all of this and does. My ES-ITS.SWENSON.ORG machine is "on the internet". It sends and receives SMTP email. It supports inbound and outbound SUPDUP. I currently have TELNET and FTP limited to just my home external IP address, however.

Our goal is to produce documents and potential scripts that configure a host system to solve network problems like this.

That would be great.

[markpizz]

Well, I don't consider it special.

I always thought you didn't consider it special since it "just worked" for you.

Given what you've described, your host system (probably prior to adding KLH10 or as part of it's initial setup) is already configured internally to route your internal "non-routable" within your host system AND to NAT (Network Address Translation) its traffic as it leaves your system. Your iptables additions explicitly extended the already active NAT functionality to allow outside connections to reach the simulated KLH10.

When I install Linux on a system on a computer that is connected to my LAN, it doesn't start out the way yours did, so getting to where your's is at least part of the "special" that I was referring to. Since you don't believe you did anything special, the only way I'm willing to chase this down is by directly looking at either your system or one which is identically configured. Let me know if you can do this. Private email is preferred.

[larsbrinkhoff]

My possibly not very useful feedback is that in 2001, I had to get a second network card dedicated to KLH10 to be able to talk to it from my host computer. But in recent years, I have not had this problem. I don't know what changed in the meantime. I haven't manually changed any Linux configuration for this.

[larsbrinkhoff]

Veering a little bit off topic here, I'm considering which Arpanet nodes could conceivably be reinstated with emulated hosts. Here's a 1973 map.

Here are some I think are feasible:

• MIT: ITS
• BBN, CCA, USC-ISI: TENEX
• Illinois: Unix
• Stanford: WAITS

I don't think I have seen anything for Sigma-7 or TX-2, much less IBM or PDP-15.

I think Utah ran TOPS-10 in the beginning. Do we have any NCP for that?

[larsbrinkhoff]

I talked to the UCLA people. They confirmed the Sigma-7 software is gone. Too bad, since it was the very first host on the ARPANET.