Talk:Network Control Protocol - Revision history

Jnc: /* RFNM */ Un-RFNM'd message limits

2025-01-05T16:44:51Z

‎RFNM: Un-RFNM'd message limits

Larsbrinkhoff: /* RFNM */ Per link maybe?

2025-01-05T10:18:12Z

‎RFNM: Per link maybe?

Larsbrinkhoff: /* RFNM */ new section

2025-01-05T10:08:58Z

‎RFNM: new section

Larsbrinkhoff: /* How to ICP! */ Ok, we're good.

2025-01-01T17:23:27Z

‎How to ICP!: Ok, we're good.

Larsbrinkhoff: /* How to ICP! */ I think this is it; captured ICP between two ITS hosts.

2025-01-01T14:55:17Z

‎How to ICP!: I think this is it; captured ICP between two ITS hosts.

Larsbrinkhoff: Go-ahead on new RFC; ITS does send the data message with S.

2025-01-01T14:29:39Z

Go-ahead on new RFC; ITS does send the data message with S.

Jnc: Answers on a number of widely-scattered points; use the 'diff' link to see them all

2024-12-31T14:06:09Z

Answers on a number of widely-scattered points; use the 'diff' link to see them all

Larsbrinkhoff: /* How to ICP! */ Not sure, but maybe based on U. Or maybe NCP is broken.

2024-12-31T07:14:06Z

‎How to ICP!: Not sure, but maybe based on U. Or maybe NCP is broken.

Jnc: /* How to ICP! */ Then how does the client find out what socket number the server is using?

2024-12-30T18:05:09Z

‎How to ICP!: Then how does the client find out what socket number the server is using?

Larsbrinkhoff: Maybe, and then include ICP there?

2024-12-30T16:12:56Z

← Older revision		Revision as of 16:44, 5 January 2025
Line 108:		Line 108:

	Were RFNM at any point extended to be per link, instead of per host? [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 11:18, 5 January 2025 (CET)		Were RFNM at any point extended to be per link, instead of per host? [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 11:18, 5 January 2025 (CET)
		+
		+	: The exact algorithm as to how many un-RFNM'd messages were allowed to be outstanding at a time went, I think, through a number of changes - I have this vague memory that not all of them announced/visible to the hosts (since an IMP could always freeze the transmission of a packet from the host to the first-hop IMP, and, unless the host was watching carefully, it would not notice). To put it another way, if the limit was 'N', then going ''over'' N would ''guarantee'' that the host would be blocked - but staying ''under''' N did not guarantee that the host would ''not'' be blocked.
		+	: If you look at [https://walden-family.com/impcode/1972-improvements-paper.pdf Improvements in the design and performance of the ARPA network], it talks about how the limit was originally '1 per link (per destination host)', but they replaced that, apparently (if I understand this correctly) with '4 per destination host' ("the four messages that can be in the pipe"). I think that was later replaced with '8 per destination host'; if you look at the [[Port Expander]] [http://ana-3.lcs.mit.edu/~jnc/tech/gw/pe/ source], it is using '8 per destination host'.
		+	: To really see how it changed, one would probably have to read through the BBN QTR's to ARPA (which I think are available online).
		+	: Whether that was changed yet again, when they went to the C/30 IMPs (which supported the Native Mode Firmware System, supporting an improved IMP with a 20-bit rather than 16-bit address space), I have no idea. [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 17:44, 5 January 2025 (CET)

← Older revision		Revision as of 10:18, 5 January 2025
Line 106:		Line 106:

	The article hints that the "handling of the RFNM flow control was improved." I dimly recall seeing something about this. Maybe at first only one outstanding message was allowed? And it was updated to five per host? I would like to get a more firm handle on this, because it could be important for interacting with different era NCP and IMP software. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 11:08, 5 January 2025 (CET)		The article hints that the "handling of the RFNM flow control was improved." I dimly recall seeing something about this. Maybe at first only one outstanding message was allowed? And it was updated to five per host? I would like to get a more firm handle on this, because it could be important for interacting with different era NCP and IMP software. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 11:08, 5 January 2025 (CET)
		+
		+	Were RFNM at any point extended to be per link, instead of per host? [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 11:18, 5 January 2025 (CET)

← Older revision		Revision as of 10:08, 5 January 2025
Line 102:		Line 102:

	:: 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)		:: 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)
		+
		+	== RFNM ==
		+
		+	The article hints that the "handling of the RFNM flow control was improved." I dimly recall seeing something about this. Maybe at first only one outstanding message was allowed? And it was updated to five per host? I would like to get a more firm handle on this, because it could be important for interacting with different era NCP and IMP software. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 11:08, 5 January 2025 (CET)

← Older revision		Revision as of 17:23, 1 January 2025
Line 82:		Line 82:

	:::: 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)		:::: 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)
		+	:::: RFC 165 says "notice that at any time after S2 the server could initiate steps S7 and S8 in parallel with steps S3 through S6", so what ITS is doing is explicitly allowed. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 18:22, 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.		: 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.

@@ Line 63: / Line 63: @@
 |-
 | &nbsp; || STR send socket 23, receive socket ''U'', byte size 32
 |-
 | ALL ''link<sub>1</sub>''
 |-
-| &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>''
+| &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>''
 |}

@@ Line 49: / Line 49: @@
 ::: 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)
 == How to ICP! ==
@@ Line 74: / Line 76: @@
 ::: 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)
 : 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.

@@ Line 36: / Line 36: @@
 ::::: "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)
 ==A new RFC==
@@ Line 45: / Line 47: @@
 :: 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)
 == How to ICP! ==
@@ Line 68: / Line 72: @@
 :: 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)
 : 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.
@@ Line 76: / Line 82: @@
 :: 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)
 == Should we have an AHHP page? ==
@@ Line 82: / Line 91: @@
 : 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)

@@ Line 66: / Line 66: @@
 : 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.)
 : 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.
 : 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)
 == Should we have an AHHP page? ==

← Older revision		Revision as of 16:12, 30 December 2024
Line 64:		Line 64:
	\| 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>''		\| 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>''
	\|}		\|}
		+
		+	== 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)