GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien201

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:
  1. IP
  1. ICMP
  1. TCP
  1. TELNET(User, Server)
  1. FTP(User, Server)
  1. 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.


/data/webs/external/dokuwiki/data/pages/rfc/ien/ien201.txt · Last modified: 2001/06/25 21:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki