Internet Experiment Note No. 201
INTERNET SHORT-TERM SERVICE GOALS
David D. Clark
MIT Laboratory for Computer Science
Computer Systems and Communications Group
1. Introduction
The purpose of this document is to identify the milestones which must be met
in order to bring the current internet architecture to a stable service which
can be used while the next round of research development is undertaken. This
document describes the functionality associated with the service to be offered,
and identifies the work to be done in order to achieve that function. This
document discusses all aspects of the internet service, and is intended for
planning purposes within the internet research community. More detailed
documents are available as RFC's that discuss the specifics of host conversion
from NCP to TCP.
This document should be viewed in the larger context of the long-term project
planning which is now underway. An assumption underlying this document is that
it is necessary to identify carefully a service which we will provide in a
stable form at this time, in parallel with which a follow-on enhanced
capability will be designed and implemented in selected hosts and gateways.
This current service should more or less mimic the quality of service provided
today on the ARPANET by the NCP protocol, in terms of supported application
protocols, reliability, responsiveness, etc.
2. Service Milestones
There are five major milestones in the achievement of the current service
offering. Two of these relate to support of TCP on the ARPANET. The other
three relate to support of actual internet traffic. These milestones are as
follows:
1. First use of internet for service (now happening!)
2. NCP quality support for first TCP-only host on ARPANET (July 1982)
3. NCP quality service for internet (?)
2
4. Heavy load on internet (?)
5. Last NCP host removed from ARPANET (January 1983)
These five milestones are explained and elaborated in the following
paragraphs.
3. Milestone One: Minimal Support for Internet Service
Internet service is being used today, as part of the Fort Bragg packet radio
demonstration and by the machines at COMSAT, which are not connected directly
to the ARPANET. I would characterize the service currently available to these
users as somewhat less than minimal, in that it works only because certain
special case adjustments have been made to individual hosts. There are three
important components to this milestone:
a. Fragmentation and reassembly must be completely implemented through
the internet. It is repeatedly brought home that the failure to
implement this portion of the protocol causes important and
substantial confusion. At the last internet meeting, the failure of
the TIU to support reassembly once again prevented machines which
sent jumbograms from being used. There is no justification for
continuing to sidestep this problem.
b. Name tables on operational hosts must be upgraded so that they have
both the structure and capacity to name all of the hosts in the
internet. In the long term, we hope that it will not be necessary
for every host to maintain a complete internet table, since we
postulate the existence of name servers to which an individual host
can turn to convert a name to a number. However, name servers are
not currently available, and the requirement for this name conversion
is immediate.
c. ICMP must be supported. Without ICMP, one cannot achieve even a
minimal level of error recovery.
These subtasks must be completed quickly, because minimal service is
important for the sites in Europe who are momentarily being removed from the
ARPANET. If the only requirement of the European community is user telnet, then
the name table problem on server hosts such as TOPS 20 can be momentarily
sidestepped, but the lack of fragmentation will prove totally unworkable, as it
already has.
3
4. Milestone Two: NCP Quality Support for TCP on ARPANET
Today, there exist hosts on the internet that speak only TCP. However, these
hosts are very substantially limited as to what they can do. The intent of
this milestone is to define a point at which a TCP-only host connected to the
ARPANET can obtain a level of service to all other hosts directly connected to
the ARPANET that it might achieve using NCP today. This goal is for the
ARPANET only, not the general internet. This restriction is important, because
it defines the point at which a host converting from NCP to TCP can obtain a
reasonable service to other hosts to which it previously had NCP access.
In order to achieve this goal, there must be conversion facilities available
so that the TCP host can communicate with NCP-only hosts, and symmetric
conversion routines must be available to permit NCP only hosts to have access
to the TCP host. The exact function required for conversion in each direction
is slightly different, since the protocols available on the TCP side are
sometimes somewhat more powerful, as in SMTP, and we are interested in
providing a better level of service for the TCP only host than we are for the
unconverted NCP only host. The specific requirements for this milestone are:
a. Telnet forwarding in both directions. This is a machine which speaks
both TCP and NCP, to which a user can log in using one protocol and
then request an outgoing telnet connection using the other protocol.
b. FTP staging facility. It appears to be rather difficult to build an
automatic facility for linking two FTP transfers together end to end.
The FTP syntax is not rich enough so that one can describe to a
forwarder where the ultimate destination of the transmission is to
be. Thus, since this is only a transition mechanism, it seems
sufficient to create an FTP facility which is operated manually.
First the user transfers this file to an intermediate point, and then
he manually logs in to this intermediate point (or to the final
destination machine) to transfer the file to its ultimate
destination.
c. Mail forwarding. This is a very important facility, since mail is a
very important part of the day to day business of the ARPANET, and
because it will be a highly visible means by which we will make
conversion to TCP popular. SMTP has been specifically implemented to
make possible the use of forwarders to provide automatic protocol
conversion. As originally proposed, automatic forwarding of mail was
to be implemented by causing every host on the ARPANET, whether or
not it supported TCP, to implement SMTP by this milestone. It is not
clear that universal conformence can be achieved. I propose that
this strategy be modified to permit an alternative in which a more
4
sophisticated forwarder will permit mail to flow from an NCP to a TCP
host if the sender of the mail manually constructs a special
destination string which triggers forwarding.
In order to achieve SMTP service, the following sub-milestones must
occur. First, the definition of the protocol must be stabilized.
This is now being done. Secondly, mail forwarders must be
implemented and brought to a service level.
d. The TCP-only hosts must be identified and brought to a full,
functional level. Full function includes the following:
-IP
-ICMP
-TCP
-TELNET(User, Server)
-FTP(User, Server)
-SMTP(Sender, Receiver, Composer)
As part of implementing this rather ambitious list of protocols, it
is important to identify and eliminate certain popular deficiencies
which appear in some existing implementations. For example, the
structure which exists between the protocol layers for reporting
errors must be rich enough that network conditions such as host-dead
or imp-dead correctly terminate the network connection with the
appropriate message for the user. For another example the name table
must be upgraded from an ARPANET only to an internet facility.
There is a great deal of work implied by the above list. Currently none of
the forwarders, either TELNET, FTP, or SMTP, exist except in experimental
forms, and it is not clear that these experimental forms in fact provide the
basis for a service offering. This milestone is seven months away, and it will
require prompt effort to achieve it.
It is not the purpose of this milestone to encourage (or permit) a
"preliminary" host implementation suitable only for the relatively benign
ARPANET environment. The host implementor should be working toward all of
these goals at once. It is in the networks that these milestones can be
distinguished.
5
5. Milestone Three: NCP Level Service Over Internet
This is a somewhat vague milestone, and items which appear only on this list
have a habit of being repeatedly postponed in task schedules. Nonetheless,
this is an important goal, because it will establish the point at which we can
stop tinkering with the service we provide and proceed on to the next level of
design. It is important not to include too many items in this list, less the
list grow so big that we never complete its implementation. On the otherhand,
if we do agree to include something on this list, then we must be consistent
and sincere about implementing it in all the relevant machines. Partial
implementation is not a useful middle ground. The following functions are
nominated for this category.
a. Robustness features. Included in this category are replication of
hardware to provide an alternative path in the case of a single
component failure. This is particularly important in the SATNET link
to Europe. Dual gateways may be required in other locations, where
important acces nets enter the transport core.
b. Fault detection and isolation. "Dissapearing packets" are still an
overly common aspect of internet communication. It is important that
every host be equipped with suitable tools to detect and, to the
extent possible, recover from internetwork outages. At a minimum,
all hosts must use the ICMP facilities of host unreachable and
redirect to recover from gateway outages or at least notify the user
that further communication is impossible. It is also important that
tools be put in place so that proper repair procedures are instituted
properly when a portion of the internet fails.
c. Proper handling of option fields in the protocols. Currently,
options are most commonly processed by ignoring them. We must decide
which options we are really serious about and implement them. An
obvious topic for discussion is the set of options that deal with the
source route function. This is a good example of where we must do an
all or nothing implementation. Isolated implementation of source
route is demonstrably useless.
d. Access control. Certain mechanisms for controlling access to the
internet must be implemented as part of the interim service. At a
minimum, these include login features in the TAC. It may be
necessary to implement some further controls inside the gateway, but
as yet no one has conceived of what those mechanisms could be. This
topic requires consideration.
e. Name servers. The number of hosts, and thus the number of names in
6
the internet is much larger than that of the ARPANET. Many name
tables are overflowing. One way to avoid this problem is by providing
name servers to which a host can turn in order to translate an
unknown name into an internet address. In some respects, a namer
server is a very simple mechanism, but it is very easy to develop a
name server mechanism which is so complicated as to be unrealizable.
Some firm decision must be made as to the level of service to be
provided by name servers in the internet, and then to provide an
implementation strategy whereby name servers are universally
available.
6. Milestone Four: Heavy Traffic Over the Internet
This is difficult milestone to quantify, since we do not know the rate at
which traffic will build up, nor what maximum traffic level we must support.
Nonetheless, it seems clear that the existing gateway implementations will not
support the expected load. There are three improvements which have been
proposed to address this topic. All of these depend on replacement of existing
gateways with C/70 gateways or recoding of the existing software, so that there
is additional space available.
a. Upgrade the net interface software so that it shows more intelligence
about interacting with the support network. For example, the driver
for the ARPANET should count RFNMs, and the driver for the SATNET
should interact properly with the selective refusal mechanism of the
SATNET's non blocking interface.
b. More buffers in the gateway.
c. Improved instrumentation in the gateway, so that it is possible to
determine where bottlenecks are.
In addition to gateway tuning, we need to achieve a minimum level of TCP
"good behavior". The occurrence of Silly Window Syndrome under heavy load must
be avoided, or the net will clog up totally. Hosts must provide sufficient
buffering to obtain reasonable throughput under long-delay situations.
Finally, we must begin to plan for substantial congestion control problems in
the internet. The existing algorithm, which is based on a source quench
message from the gateway to the host, has not been shown to work well. In the
short run, we have not identified any alternative mechanism which will work
better. At a minimum, every host and gateway should implement ICMP, so that
source quench messages can at least be sent and received. More work is
required in this area to determine what the proper action should be.
7
Milestones three and four are closely related, and could have been combined.
The distinction is that milestone three contains things that must be done even
if the offered load is small. Adequate performance may depend on new gateway
hardware, which may delay milestone four. If this is so, users will be
interested in milestone three as a separate goal.
7. Milestone Five: NCP Service is Discontinued in the ARPANET
This milestone has occasionally been described as a very important one for
the internet implementors. In fact, most of the work necessary at the internet
level to achieve this goal will have been done as part of the previous
milestones. There are essentially two important subcomponents of this
milestone:
a. The TCP TAC must be deployed. This is very important, and should be
done somewhat in advance of this actual milestone to allow for the
following point.
b. Facilities for testing and debugging new TCPs must be conveniently
available on the ARPANET, so that hosts converting from NCP to TCP
can verify the correct operation.
The major effort in achieving this milestone is the implementation of the
previously itemized list of protocols on every host attached to the ARPANET.
This task will require substantial effort, but this effort is provided by the
system maintainers for the systems in question. Our responsibility is to
provide the proper support for those implementors.
In addition to the testing and debugging facility provided above, the other
important requirement is informal documentation that provides help and guidance
to implementors beyond the actual protocol specification. A number of ways
have been proposed to provide this informal help. One easy strategy is to
distribute a collection of TCP design documents for the TCPs that have already
been implemented. I am currently preparing a number of reports that attempt to
gather together the insights about TCP and IP which are well understood in the
implementation community but may not be obvious to first time implementors.
First topics include strategies for reassembly and packet resequencing,
management of window and acknowledgement algorithms, and proper management of
names, addresses, routes, and ports. Anyone wishing to contribute to this work
should contact me. A table of contents will be out soon.
There are a large number of preliminary milestones associated with the
upgrade of all ARPANET hosts to TCP, such as document distribution, and
interaction with the various host maintainers, and managers. These subgoals
are not outlined in this document, but are described in a separate document
recently released by Jon Postel.
8 8. Priorities The preceding discussion of the five service milestones has presented a rough outline of subtasks necessary to achieve these five goals. A separate project milestone document, now being prepared, lists these individual tasks in a more structured form, and provides dates and probabilities of success where known. -------
mirror server hosted at Truenetwork, Russian Federation.