View source for 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. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk: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, [https://ntrl.ntis.gov/NTRL/dashboard/searchResults/titleDetail/ADA052594.xhtml 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! [[User:Jnc|Jnc]] ([[User talk: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?! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk: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). [[User:Jnc|Jnc]] ([[User talk: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.  [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk: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.
::: [https://www.rfc-editor.org/rfc/rfc127.txt 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:
<pre>
    Listen for Connection on L
                                               RTS, U, L, l
                                                           A
     STR, L, U, 32
</pre>
:::* The "l<sub>A</sub>" is not the link used to ''send'' the RTS message (I believe that message, being an HHP message, goes over link 0); the "l<sub>A</sub>" 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 [https://www.rfc-editor.org/rfc/rfc739.txt 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<sub>A</sub>" referred to) - ICP is kind of a semi-layer ''on top of'' HHP, apparently. [[User:Jnc|Jnc]] ([[User talk: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. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk: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 [https://www.rfc-editor.org/info/rfc542 RFC-542]). I don't know if the ICP socket for FTP was actually ever changed back to 3; as of [https://www.rfc-editor.org/info/rfc739 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! [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 22:51, 28 December 2024 (CET)

::::: The UNIX NCP implementation/distribution (below) has some interesting insight on whether or not the 'new' FTP ever came into use. If you look at [https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/new/dist.log dist.log], it was in active maintenance through mid-1979; RFC-542, the 'new' FTP spec, came out in August, 1973, but... If you look at the Server TELNET ([https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpp/tel-s/svrtel.c svrtel.c]), it's #ifdef'd to use either socket 23 or socket 1; the Server FTP ([https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpp/ftp-s/srvrdaemon.c srvrdaemon.c]), it's only set up to use socket 3. So either they made the transition, and ''did'' go back to 3, or nobody ever othered to upgrade. If I were energetic, I'd look at the FTP server code ([https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpp/ftp-s/srvrftp.c srvrftp.c]) and see if they had added any of the changes - but I'm too lazy! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:06, 31 December 2024 (CET)

==A new RFC==

Hey, can we... er, issue a new RFC?  "Obsoletes RFC 165." [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk: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! [[User:Jnc|Jnc]] ([[User talk: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. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 13:06, 30 December 2024 (CET)

::: Well, if you want to do this (best if you take the lead; I'm not good with finishing things off - although it would be fun to be a co-author; that would probably set a record for the gap between first and last RFC's :-), I'd start by sending a short note to the RFC editor, asking how you should proceed. Maybe they'd agree to allocate RFC-9999 to it; if you go for April 1, they should be close by then! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:06, 31 December 2024 (CET)

:::: I got an ok from the RFC editor, and he suggested the RFC should also urge to supplant TCP/IP with the "updated" NCP. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 15:29, 1 January 2025 (CET)

== How to ICP! ==

A concrete example of how to execute the initial connection protocol for TELNET on socket 23. AHHP messages (STR, RTS, ALL) sent on link 0; others sent on specified link. This is taken from actual sessions with ITS.  (As far as I have got so far; more to come.)

{| class="wikitable"
! Sent from client
! Sent from server
|-
| RTS receive socket ''U'', send socket 23, ''link<sub>1</sub>''
|-
| &nbsp; || STR send socket 23, receive socket ''U'', byte size 32
|-
| &nbsp; || STR send socket ''S''+1, receive socket ''U''+2, byte size ''B<sub>1</sub>'' <br> RTS receive socket ''S'', send socket ''U''+3, ''link<sub>2</sub>''
|-
| ALL ''link<sub>1</sub>''
|-
| &nbsp; || Data on link<sub>1</sub>: socket number ''S''
|-
| STR send socket ''U''+3, receive socket ''S'', byte size ''B<sub>2</sub>'' <br> RTS receive socket ''U''+2, send socket ''S''+1, ''link<sub>3</sub>''
|-
| CLS send socket 23, receive socket ''U'' || CLS send socket 23, receive socket ''U''
|}

: If the server doesn't send its socket number ('S') to the client in a data message, then how does the client find out what socket number the server is using? (Pretty much proof that the server ''does'' have to send that message.)

:: I'm aware of this conundrum, but I'm basing my notes on what ITS actually does.  It's still an ongoing investigation, because no one has used NCP in decades and it's not always obvious how things should fit together.  It may be that some configuration is off, or that NCP has bit rotted in ITS.  For what it's worth, we can recognize the new connection based on U, which derives U+2 and U+3 paired with S and S+1. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 08:14, 31 December 2024 (CET)

::: Yes, but that still doesn't give you 'S'. Maybe try an older ITS (from the time when NCP was still in use, in case someone 'broke' ICP, after it was no longer in use - to be able to send up a flag that a mistake had been made)? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:06, 31 December 2024 (CET)

:::: Having now understood regular data messages ''also'' carry the byte size and byte count fields, I can now see ITS does send 'S'.  It's just that it sends it ''after'' sending RTS and STR using the 'S' and 'S'+1 sockets.  So that remains a mystery for now. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 15:29, 1 January 2025 (CET)

: Also, which message gets sent first - the data message with S in it, or the ALL? (I need to go read up on how ALL works, to see if one needs to be sent before the socket number is sent.) Or maybe they can be sent in either order - unless the ALL ''has'' to be sent before 'S' can be sent. Interestingly, RFC-127 doesn't show ''any'' ALL messages being sent until much later, after the data connections are set up! Duhh - now that I think about it (see below), the ALL probably has to be sent before 'S' - because nothing happens on that link after 'S' is sent; both sides send a CLS. So either the ALL is not needed (and the one you see being sent is some sort of brain bubble), or it has to be sent first.

:: I believe ALL must be sent first, to indicate to the other side that space is available for data.  Some of my experiments are based on my own implementation of NCP, which in turn is based on an evolving understanding of how NCP (probably) works as per the available documentation.  So there's certainly room for errors there.  Other experiments involve two ITS hosts talking to each other, but then, I'm not sure they are set up correctly and have a working NCP.  I may try a 1982 version of ITS at some point.  [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 08:14, 31 December 2024 (CET)

: Oddly enough, it seems that the 'S' message is sent on a different link from the one(s) later used by the data connection - see RFC-127! Of course, RFC-127 is fairly early - they may have changed things again before things finally settled down. So your archaeology in ITS may be useful, in showing something that's not documented. We may also want to look at the UNIX NCP ([https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC here], to see what another NCP does; the stuff we're talking about here is all done in the NCP daemon.) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:05, 30 December 2024 (CET)

:: It seems to me that ICP opens up a temporary unidirectional link just for sending S, which is then closed.  Then a new pair or RTS-STR are exchanged for the real bidirectional connection.  Maybe an email to '''internet-history''' can solicit comments and help? [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 08:14, 31 December 2024 (CET)

::: Yes, that's my understanding, from RFC-127.
::: Good idea to try 'internet-history'; I'll do that next. [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:06, 31 December 2024 (CET)

== Should we have an AHHP page? ==

Should we have a page for the AHHP? I had thought about it, and decided it would be superfluous, since we have a link to the original document; but I suppose it might be useful? Not very long, mind; just a few sentences describing what it does, and then a table of the AHHP messages (with arguments, a brief description of what they do, etc). [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:02, 30 December 2024 (CET)

: Maybe so, and then we can include an errata.  The ALL message is wrong on page 27. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 17:12, 30 December 2024 (CET)

:: OK, I'll start that after I ping 'internet-history' Yes, ALL on page 27 of the AHHP document is definitely wrong; the 'link' field should be 8 bits (as on page 23). [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 15:06, 31 December 2024 (CET)