[ih] More topology

[Jack Haverty]

The PE behavior you describe:

"The way it handles RFNM's is that it has a database of "CONNECTION BLOCK"s
which record messages sent out to the IMP; when a RFNM arrives, it uses the
CB database to work out the downstream host which originated the message the
RFNM is for; the RFNM is then handed to it."

has a problem, if the host(s) attached to it did RFNM Counting.  Any host might try to get up to 8 "in-flight" messages.  If more than one such host is sending to the same destination, each expecting to be able to keep 8 messages in flight, the IMP would block the PE as it sent the 9th message.   It doesn't matter whether they were NCP or TCP hosts, just whether or not they were RFNM Counting and interacting with the same destination.

Such situations might have been rare, and for TCP of course, this would be mostly invisible, mitigated by retransmissions and duplicate removal as needed.   And perhaps some total pauses in traffic flow to the ARPANET if the IMP had to block the interface.

How's that for a 40+ year troubleshooting session...

BTW, you're right that the Unix TCP I wrote started with Jim Mathis' LSI-11 TCP.  IIRC, it didn't have any 1822/IMP interface code, so I had to write that (and hence learn about RFNMs et al).   Or perhaps it did but the code wasn't obviously compatible with the Unix kernel.

/Jack



On 8/30/21 12:02 PM, Noel Chiappa via Internet-history wrote:
>      > From: Jack Haverty
>
>      > I never did learn how the PE handled RFNMs, in particular how it
>      > interacted with its associated NCP host that it was "stealing" RFNMs
>      > from.
>
> I know a bit about the Port Expander; we were planning on using it at MIT at
> one point, since MIT had no spare IMP ports for an IP gateway (router). (We
> didn't get an IMP port for the MIT gateway until MIT got its third IMP, one
> of the first C/30's.) That didn't work out, as I'll explain later.
>
> The PE didn't share the NCP 'host' among connected hosts; all NCP traffic
> coming in from the IMP is sent to the 'main' subsidiary host's port:
>
>    ; WHEN A TYPE 0 OR TYPE 3 MESSAGE IS RECEIVED, FIRST CHECK THE MESSAGE'S
>    ; LINK NUMBER.  IF THE MSG IS NOT ON AN INTERNET LINK, THEN SEND THE MSG TO
>    ; THE PORT THAT RECEIVES ALL NON-INET TRAFFIC (PORT INDEX IS IN NCPPRT)
>
> For IP traffic, the PE acts as a gateway (i.e. router), and there's a table
> which says which downstream port various IP hosts are on.
>
> The way it handles RFNM's is that it has a database of "CONNECTION BLOCK"s
> which record messages sent out to the IMP; when a RFNM arrives, it uses the
> CB database to work out the downstream host which originated the message the
> RFNM is for; the RFNM is then handed to it.
>
>
> As the above excerpt probably made clear, I still have the PE code (it had
> been squirreled away on the MIT-CSR Unix - I made a full dump of that machine
> before it croaked, so we now have access to all that history; I guess I was
> concerned about history even back then).
>
> I don't think I have the _original_, unmodified PE code; what I have is a
> bodged version that I hacked to act as a gateway to the MIT 1 Mbit/sec ring
> LAN. I.e. it did't have any subsidiary hosts attached to 1822 ports; just the
> main 1822 port (connected to the IMP) and the LAN. I'm too lazy to
> see exactly what I did with RFNM's there; probably just pitched them
> (no RFNM's on a LAN :-).
>
> While I was looking for that, I ran across some other old code that
> might be interesing:
>
> - the TIU (kind of a predecessor to the TAC, a _very_ early implementation of
>    TCP in Macro-11 for the PDP-11, written by Jim Mathis, which I believe
>    was the basis for Jack's first UNIX TCP at BBN);
> - a couple of modules from the BCPL gateway code from BBN (the one that
>    ran under ELF); historically interesting, as it was the very first
>    IP router code _ever_.
>
> If anyone is interested in any of this stuff, let me know and I'll look
> into getting it uploaded and made available.
>
>
> The reason we couldn't get the PE to work was that the SRI 1822 interface
> (which is what were planning to use on our PE) didn't _exactly_ electrically
> duplicate the IMP 1822 interface; the latter used optp-isolators on the DH
> interface, and the SRI interface didn't have them.
>
> The plan was to put the PE in from of the DM ITS machine, but when
> we tried it, it didn't work. Ken Pogran looked into the issue, and
> discovered that the person who did DM's IMP interface (I wonder who
> that was :-) had done some 'trick' (the exact details of which now
> escape me - it was something to do with the ground he used for the
> DH interface signals),and without the opto-isolators the SRI
> 1822 interface wouldn't talk to it.
>
>
> 	Noel