Talk:Network Control Protocol

How to ICP

I find it infuriating how no single document clearly and unambiguously lays out the steps to do an ICP in terms of the Host-Host protocol. I'm about to test what the ITS NCP does, and I will be sure to document it here. Larsbrinkhoff (talk) 16:09, 20 December 2024 (CET)

RFC-165 doesn't do it? I have a hard-copy of the ARPANET Protocol Handbook, and RFC-165 is just about identical to NIC 7101 ("Official Initial Connection Protocol") from the APH. (Actually, I see a scan of the APH is available online now, here; NIC 7101 is on pp 91-95 of the scan, so you can see it's almost identical.

Now, NIC 7101 may not provide a clear and unambiguous description of the steps needed; I can't help you there! (If so, take it up with the ghost of Postel!) That's all the documentation we had! Jnc (talk) 17:29, 20 December 2024 (CET)

For one thing, it seems like the "Logger" has a dual status as a TELNET server, and a part of ICP. What's up with that?! Larsbrinkhoff (talk) 17:15, 20 December 2024 (CET)

I suspect that's due to the weirdness of the NCP, and its ICP. That's basically because NCP HHP connections are unidirectional (in terms of data flow) - so a bi-directional connection (like what TCP gives you - I'm not sure NCP has a term for 'a bidirectional pair of HHP connections') actually involves two separate HHP connections. And remember that in NCP, the software on the host isn't really involved in data flow - it just sends packets to a specified 'socket' at the destination, and the IMP does all the work. Also, only a single distant socket can send packets to a local socket at a time.

So, to get everything for a 'bi-directional connection' set up (chose the sockets at each end, and let the other end know what they are), the host does have to get involved; so the ICP 'protocol' has to be done in the host. So the server, on hearing from the user what socket they're going to use ('U'), it picks the local socket it's going to use ('S'), and sends that to the user; each can then set up the two unidirectional connections. RFC-165 does explain this all pretty well - once you get your mind wrapped around the fact that HHP connections are so very different from TCP connections.

Which explains why "the 'Logger' has a dual status as a TELNET server, and a part of ICP". The ICP is a whole separate protocol; so one could do two separate modules - one for the TELNET protocol, and one for the ICP - or one could combine them, as they have done.

Does this all make sense, now? If my explanation is clear, and correct, I'll add it to the article, because I don't think this is all explained there (yet). Jnc (talk) 19:36, 23 December 2024 (CET)

Thanks, I appreciate the help. Unfortunately, to me it's mostly a rephrasing of RFC 165. I still don't understand how a client is supposed to set up a connection to some particular server socket. Say, e.g. FTP on socket 21. Is the Logger on server socket 1 still involved in ICP for that service? If so, how does the client ask to get FTP? RFC 165 only says Logger is listening on socket "L" = 1. If the Logger is involved setting up an FTP connection, I don't see where the number 21 is passed from the client. Is it "U" (of the correct socket gender) in the RTS message? If FTP is the same as the Logger except L=21, that's fine, but I can't seem to find anything that says so. Various sources allude to the Logger being involved always in ICP. Larsbrinkhoff (talk) 16:03, 27 December 2024 (CET)

Ah, I see what you didn't get. I had to do some reading to bring this all back (although some of it I never knew). (Reading early RFC's is like a modern animal, with DNA, being teleported back to the RNA - or even pre-RNA - age. Or perhaps a better analogy would be listening to a conversation where the Bronze Age participants are deciding on how to do writing, which did not yet exist. So many things that we take for granted now, they had no idea about; they were just stumbling around, knocking into them.)

In addition to the restriction that only a single distant socket can send packets to a given local socket at a time (a restriction that I'm not sure I understand the thinking behind, but never mind), which is important to keep in mind when trying to understand this generation of protocol operation, there's something else that's really important to remember, but isn't specifically written about anywhere (RFC-165 almost doesn't mention it at all): there's another namespace that's used all the time, which is 'links'. Links are used all the time, because socket numbers aren't included in most packets! (Very important!) But the link number is always included.

RFC-127 may be useful, as it gives a step-by-step example of a user and server trying to go through an ICP. It's valuable in part because it mostly does give the link numbers used for each packet (remember that they called them 'messages' then - a 'packet' then was what we call a 'fragment' now; hosts didn't see them). A couple of comments about it, though:

• The "Listen for Connection on L" means 'socket L'; the link used to send that is link 0 (permanently allocated to "HHP Control Messages"). The odd thing there is that 'L' is a transmit socket - but the first thing that happens is that the server gets a 'connection open' request' for it - i.e. an in-bound packet!
• There's a step sort of not explicitly listed after the "Listen for Connection" initial step on the server side; roughly 'Receive a connection open, from foreign socket U'. (There ought to be a blank line above the 'STR', to emphasize that there may be a considerable time gap in between that and the "Listen for Connection"; I have submitted an errata for that RFC). I.e. the formatting should be:

    Listen for Connection on L
                                               RTS, U, L, l
                                                           A
     STR, L, U, 32

• The "l_A" is not the link used to send the RTS message (I believe that message, being an HHP message, goes over link 0); the "l_A" is data carried in the RTS message. (I was wondering how they worked out the link to use for the connection; that only became clear when I read the HHP spec.)

I'm a little confused by your references to "FTP on socket 21" and "the Logger on server socket 1". According to the list of Assigned Socket Numbers in RFC-739, socket 1 is "Old Telnet". From reading through the old RFC's, the term 'logger socket' appears to basically mean what we would call the 'well-known' socket (AKA 'assigned socket').

I think that what happens, to open an FTP connection, is that the user sends an 'open connection' message ("RTS") on link 0 to the well-known socket for FTP (21. for New File Transfer), and things go from there, as shown in RFC-127; the server's socket number, S, is sent in a data packet, after the STR (except that with FTP, actual file data uses yet another different connection, set up after the FTP control connection is set up, as above). Did that answer your query? If not, keep firing queries!

You're right, the whole opening sequence is poorly documented! I think it's probably very useful, in understanding it, to first understand the Host-Host Protocol, which ICP uses (e.g. my initial misunderstanding of what the "l_A" referred to) - ICP is kind of a semi-layer on top of HHP, apparently. Jnc (talk) 20:23, 27 December 2024 (CET)

If it is the case that ICP for, say, FTP is to send the initial RTS with L=21, that's fine with me. But I can't see that stated anywhere. As luck would have it, I have just now been able to see what ITS does when opening an TELNET connection. Indeed L is 23 for this case. (Unfortunately ICP got stuck there so I can't see further messages.)

As for "Logger", early RFCs seem to use the term for what we would now call the "TELNET server". I suppose it was the first and most important application-level protocol at the time, which may explain why many sources mentions it specially. Larsbrinkhoff (talk) 13:07, 28 December 2024 (CET)

"we have assigned a new socket, decimal 21, as a temporary logger socket for the new version and a change-over date of 1 February 1974. Until that date the old .. version of FTP will be available on Socket 3 and the new version .. should be implemented on Socket 21. On 1 February the new version will shift to Socket 3 and the old disappear from view." (per RFC-542). I don't know if the ICP socket for FTP was actually ever changed back to 3; as of RFC-739, the 'Old File Transfer' was still 3, and the 'New File Transfer' was still 21.

I'm glad to see that you appear to have gotten through the barrier on understanding NCP connection opens! Jnc (talk) 22:51, 28 December 2024 (CET)

A new RFC

Hey, can we... er, issue a new RFC? "Obsoletes RFC 165." Larsbrinkhoff (talk) 13:50, 28 December 2024 (CET)

Your comment ("Maybe on April 1") confuses me somewhat. Is this suggestion purely a joke, or are you actually interested in producing a new RFC? If the latter, would the contents be humorous (as April 1 RFCs are), or did you have a serious goal in mind (e.g. rectifying the poor documentation of the packet exchanges involved in an NCP connection open)?

Sorry if I have overthought this! Jnc (talk) 22:51, 28 December 2024 (CET)

It's a "ha ha only serious", i.e. both a joke and a (semi-)serious suggestion. The contents would be factual; the "humor" would be in issuing an update of an ancient and obviously now useless document. Except to people who really want to implement ICP, to whom it would be useful. It does rectify an actual weakness, so I figure in that sense it would be in the spirit of the RFC process. Larsbrinkhoff (talk) 13:06, 30 December 2024 (CET)