One of the important differences was that NCP (the Network
Control Protocol of the early ARPANET) depended on the
IMP subnetwork for all the communications functions,
while the TCP/IP protocol was a communications protocol.
The NCP would take the message from the sending HOST,
transport the message to the neighboring IMP
and the IMP would break it into packets, and then send
it on to the IMP nearest the destination HOST, which would
do the reassembly of packets and then pass it to the
destination HOST. Thus the IMP subnetwork basically
took care of the communications functions of breaking
the message into packets, routing them, checking to
see that they arrived at the destinaton IMP and reassembling
them.
In the concept for the Internet, the new protocol was to
be a communications protocol.
I am trying to understand what in the early design for
TCP/IP (it was originally called TCP) was different from NCP,
what was similar, and what in TCP/IP was new.
The May 1974 paper describing the design and philosophy for
TCP/IP "A Protocol for Packet Network Intercommunication"
by Kahn and Cerf (the protocol was called the Kahn-Cerf
protocol at one period), is helpful with regard to seeing
what TCP/IP would do. But it seems also important to understand
how this compares to NCP, and its harder to know where to
look for a description that will be helpful of NCP.
This paper will be part of a longer paper, earlier parts are
online at:
part I http://www.columbia.edu/~rh120/other/arpa_ipto.txt
part II http://www.columbia.edu/~rh120/other/basicresearch.txt
part III http://www.columbia.edu/~rh120/other/centers-excellence.txt
part IV http://www.columbia.edu/~rh120/other/computer-communications.txt
Thanks for any help on this.
Ronda
ro...@panix.com
Netizens: On the History and Impact
of Usenet and the Internet
http://www.columbia.edu/~hauben/netbook
also in print edition ISBN 0-8186-7706-6
http://www.garlic.com/~lynn/internet.htm
Much of the internet protocol (aka IP) activity went on in IEN in
77/78 time-frame (references to TCP & TCP as part of HOST/HOST shows
up earlier)
IEN-11 has interesting title ... but the file contents
IEN-11
Section 2.3.3.4 (IEN # 11) is titled "Internetting or Beyond NCP" by
Danny Cohen of ISI. Please obtain copies from the author.
This memo is also assigned the numbers PRTN 213 and NSC 106, and is dated
21 March 1977.
some number of the early (offline) RFCs just went online this week
but nothing new for NCP.
misc online
rfc60 ... A simplified NCP Protocol
rfc215 .. NCP, ICP, and TELNET:
rfc381 .. TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
rfc394 .. TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
rfc550 .. NIC NCP Experiment
rfc618 .. A Few Observations on NCP Statistics
rfc660 .. SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE
rfc687 .. IMP/Host and Host/IMP Protocol Change
rfc704 .. IMP/Host and Host/IMP Protocol Change
rfc773 .. COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY
rfc801 .. NCP/TCP TRANSITION PLAN
from rfc801 (nov, 81; catenet shows up in ien111, august, 1979) ...
It was clear from the start of this research on other networks that
the base host-to-host protocol used in the ARPANET was inadequate for
use in these networks. In 1973 work was initiated on a host-to-host
protocol for use across all these networks. The result of this long
effort is the Internet Protocol (IP) and the Transmission Control
Protocol (TCP).
These protocols allow all hosts in the interconnected set of these
networks to share a common interprocess communication environment.
The collection of interconnected networks is called the ARPA Internet
(sometimes called the "Catenet").
The Department of Defense has recently adopted the internet concept
and the IP and TCP protocols in particular as DoD wide standards for
all DoD packet networks, and will be transitioning to this
architecture over the next several years. All new DoD packet
networks will be using these protocols exclusively.
--
Anne & Lynn Wheeler | ly...@adcomsys.net, ly...@garlic.com
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
>I'm working on paper about the early development of the
>Internet, and the architectural conception that gave it
>birth.
>
>One of the important differences was that NCP (the Network
>Control Protocol of the early ARPANET) depended on the
>IMP subnetwork for all the communications functions,
>while the TCP/IP protocol was a communications protocol.
Rhonda,
I think you're missing an important word here: HOST, as in HOST
communications protocol, independent of the underlying network
implementation.
>The NCP would take the message from the sending HOST,
>transport the message to the neighboring IMP
>and the IMP would break it into packets, and then send
>it on to the IMP nearest the destination HOST, which would
>do the reassembly of packets and then pass it to the
>destination HOST. Thus the IMP subnetwork basically
>took care of the communications functions of breaking
>the message into packets, routing them, checking to
>see that they arrived at the destinaton IMP and reassembling
>them.
Maybe read some basic stuff about layered network architecture,
ISO 7 layers, and all that, to get a background for understanding
and commentary.
AFAIK the hosts used the NCP host protocol to talk to each other
and the IMPs, the IMPs used a protocol similar to the later X.25
standard to send packets between each other, and they all used
more or less the same modems, connected to LD leased lines.
The hosts sent the IMPs messages, the IMPs broke those into
packets, the modems turned them into tones, and the tones went
over the LD network.
I am not sure where the routing was done, it may have been mixed
up between the layers.
>In the concept for the Internet, the new protocol was to
>be a communications protocol.
>
>I am trying to understand what in the early design for
>TCP/IP (it was originally called TCP) was different from NCP,
>what was similar, and what in TCP/IP was new.
>
>The May 1974 paper describing the design and philosophy for
>TCP/IP "A Protocol for Packet Network Intercommunication"
>by Kahn and Cerf (the protocol was called the Kahn-Cerf
>protocol at one period), is helpful with regard to seeing
>what TCP/IP would do. But it seems also important to understand
>how this compares to NCP, and its harder to know where to
>look for a description that will be helpful of NCP.
The early RFCs < ~1000? describe various details about NCP --
ISTR http://www.ietf.org may be the location that maintains them.
>This paper will be part of a longer paper, earlier parts are
>online at:
>
>part I http://www.columbia.edu/~rh120/other/arpa_ipto.txt
>part II http://www.columbia.edu/~rh120/other/basicresearch.txt
>part III http://www.columbia.edu/~rh120/other/centers-excellence.txt
>part IV http://www.columbia.edu/~rh120/other/computer-communications.txt
>
>
>Thanks for any help on this.
>
>
>Ronda
>ro...@panix.com
>
> Netizens: On the History and Impact
> of Usenet and the Internet
> http://www.columbia.edu/~hauben/netbook
> also in print edition ISBN 0-8186-7706-6
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian_...@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
use address above to reply
NCP and TCP/IP have very little in common.
This is from memory, and is information that I haven't needed for 17
years, so I'm fuzzy on the details:
There was no host addressing in NCP. All of it was done by the IMP/host
communication protocol (1822). NCP leaders were 40 bits, which, when
combined with the 32-bit IMP leader, make two 36-bit words on a PDP-10.
Later, with long-leaders, it was 96-bit IMP leaders and not so nice. I
wrote the first PDP-10 long leader NCP on the ARPAnet, at a time when only
the TIPs and one UNIX system supported long leaders. BBN refused to
believe that I had done it. Dave Moon followed on ITS about a week later.
It wasn't until quite some time later that BBN released on for Tenex.
NCP connections were unidirectional. Sockets, the NCP predecessor to TCP
ports, were 32-bits long and had gender; odd socket numbers were "send
sockets" and even socket numbers were "receive sockets".
Unlike TCP, only one connection could exist to a socket at a host;
consequently, an elaborate procedure called "ICP" (Initial Connection
Protocol) existed to establish a connection to a service such as Telnet.
The client would open a connection from a receive socket N to a send
socket on the server; the server would then send back 4 bytes identifying
a new socket on the server M. Both client and server would close this
connection (so other people could connect to the server's ICP socket) and
then open connections from N+1 to M and N+2 to M+1 (or something like
that).
Now you know what all of the TCP port numbers for the traditional services
are odd numbers. Even numbers could not be service sockets in NCP.
You also had to allocate buffer space for the connection. The other end
was forbidden from sending more data than you allocated. There was no
sliding windows; NCP was lockstep with the IMP RFNMs serving as
acknowledgements. But that was alright since the IMP basically guaranteed
reliable transmission; there was no retransmission, and if the IMP gave a
transmission error that meant the connection was hosed.
There was an error reporting mechanism in NCP, as well as a way to give
back buffer space. I forget the details.
The bottom line is that NCP depended completely upon the network to
provide reliable transmission and acknowledgement. All NCP did was
identify there the messages went to. But it was unnecessarily cumbersome
in doing that.
TCP was effectively a complete restart from scratch. The main lessons
from NCP was in what not to do.
-- Mark --
* RCW 19.190 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message. *
Science does not emerge from voting, party politics, or public debate.
from ... rfc1251 ... Who's Who in the Internet
Braden came to ISI from UCLA, where he had worked 16 of the preceding
18 years for the campus computing center. There he had technical
responsibility for attaching the first supercomputer (IBM 360/91) to
the ARPAnet, beginning in 1970. Braden was active in the ARPAnet
Network Working Group, contributing to the design of the FTP protocol
in particular. In 1975, he began to receive direct DARPA funding for
installing the 360/91 as a "tool-bearing host" in the National
Software Works. In 1978, he became a member of the TCP Internet
Working Group and began developing a TCP/IP implementation for the IBM
system. As a result, UCLA's 360/91 was one of the ARPAnet host
systems that replaced NCP by TCP/IP in the big changeover of January
1983. The UCLA package of ARPAnet host software, including Braden's
TCP/IP code, was distributed to other OS/MVS sites and was later sold
commercially.
from ... ien-166 Design of TCP/IP for the TAC
+---------+
+ +
+--------------- + Message + <-------------------+
|+-------------- + Buffers + <------------------+ \
|| + + \ \
VV +---------+ \ \
+---+ \ \
+--- + + Tumble \ \
|+-- + + Table +-----+ +----+ \ \
|| +---+ | | | | \ \
|| +>| TCP |<-->| IP |<-+ \ \
VV +--------+ | | | | | | +------+ \ \
+++++++ | | | +-----+ +----+ | | | +++++++
| MLC |<---->| Telnet |<-+ +-->| 1822 |<-->| IMP |
+++++++ | | | +-----+ | | | +++++++
|| +--------+ | | | | +------+ /\/\
|| +>| NCP |<-----------+ / /
|| +---+ | | / /
|+-->+ + Tumble +-----+ / /
+--->+ + Table / /
+---+ / /
|| +----------+ / /
|| + + / /
|+-----------> + Message + --------------------+ /
+------------> + Buffers + ---------------------+
+ +
+----------+
Figure 1.
This note addresses the problem of implementing a reliable out-of-band
signal for use in a host-to-host protocol. It is motivated by the fact
that such a satisfactory mechanism does not exist in the Transmission
Control Protocol (TCP) of Cerf et. al. [reference 4, 6] In addition to
discussing some requirements for such an out-of-band signal (interrupts)
and the implications for the implementation of the requirements, a
discussion of the problem for the TCP case will be presented.
While the ARPANET host-to-host protocol does not support reliable
transmission of either data or controls, it does meet the other
requirements we have for an out-of-band control signal and will be drawn
upon to provide a solution for the TCP case.
The TCP currently handles all data and controls on the same logical
channel. To achieve reliable transmission, it provides positive
acknowledgement and retransmission of all data and most controls. Since
interrupts are on the same channel as data, the TCP must flush data
whenever an interrupt is sent so as not to be subject to flow control.
http://www.garlic.com/~lynn/internet.htm
as mentioned the NCP -> TCP/IP transition included generic gateway for
heterogeneous network ... prior to that NCP/IMP was a homogeneous
network infrastructure ... which somewhat limited its extensibility.
The internal corporate network essentially included a gateway function
in every node from the beginning ... and also contributed to it being
larger than the Arpanet from ssentially the beginning until sometime
in the mid-80s (where the transition to tcp/ip w/gateways and the
advent of workstations as nodes help the arpanet/internet overtake the
internal corporate network in number of nodes).
random refs.
http://www.garlic.com/~lynn/99.html#7
http://www.garlic.com/~lynn/99.html#33
http://www.garlic.com/~lynn/99.html#39
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/99.html#124
& from rfc1705 ... Six Virtual Inches to the Left: IPng Problems
4.5 Compatibility Issues
The Internet community has a large installed base of IP users. The
resources required to operate this network, both people and machine,
is enormous. These resources will need to be preserved. The last
time a change like this took place, moving from NCP to TCP, there
were a few 100 nodes to deal with [Postel, 1981c]. A small close
knit group of engineers managed the network and mandated a one year
migration strategy. Today there are millions of nodes and thousands
of administrators. It will be impossible to convert any portion of
the Internet to a new protocol without effecting the rest of the
community.
>The best single paper I've seen on internetwork design issues is:
>
> Sunshine, Carl A., "Interconnection of computer networks,"
> Computer Networks 1, North-Holland Publishing Company, 1977,
> pp. 175-195.
>
>It took some time for me to read and understand it, but I think it
>was worth the effort and I recommend it. At roughly the same time
>that paper was published, DARPA and their associates began work on
>a specific approach for coherent interconnection of the myriad nets
>surrounding ARPANET. One result of their work is a large volume of
>documentation recording the design options that were taken and the
>reasons for taking them. If you're interested I can send you some
>of the pertinent documentation (most of which I have in soft copy),
>but there's a lot of it.
the complete archive is at:
http://www.edh.net/net_bakeoff.txt
an news article regarding the subject of the archive is at:
http://www.sjmercury.com/svtech/columns/gillmor/docs/dg092499.htm
random ref:
http://www.garlic.com/~lynn/99.html#140