rfc817.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

problems, there are some other, more subtle problems associated with  an

outboard implementation of a protocol.  We will return to these problems

later.


     There  is  a  way  of  attaching  a  communications  processor to a

mainframe host which  sidesteps  all  of  the  mainframe  implementation

problems, which is to use some preexisting interface on the host machine

as  the  port  by  which  a  communications processor is attached.  This

strategy is often used as a last stage of desperation when the  software

on  the host computer is so intractable that it cannot be changed in any

way.  Unfortunately, it is almost inevitably the case that  all  of  the

available  interfaces  are  totally  unsuitable for this purpose, so the

result is unsatisfactory at best.  The most common  way  in  which  this

form  of attachment occurs is when a network connection is being used to

mimic local teletypes.  In this case, the  front-end  processor  can  be

attached  to  the mainframe by simply providing a number of wires out of

the front-end processor, each corresponding to a connection,  which  are

                                   10


plugged  into teletype ports on the mainframe computer.  (Because of the

appearance  of  the  physical  configuration  which  results  from  this

arrangement,  Michael  Padlipsky  has  described  this  as  the "milking

machine" approach to computer networking.)   This  strategy  solves  the

immediate  problem  of  providing  remote  access  to  a host, but it is

extremely inflexible.  The channels  being  provided  to  the  host  are

restricted  by  the host software to one purpose only, remote login.  It

is impossible to use them for any other purpose, such as  file  transfer

or  sending mail, so the host is integrated into the network environment

in an extremely limited and inflexible manner.  If this is the best that

can be done, then it  should  be  tolerated.    Otherwise,  implementors

should be strongly encouraged to take a more flexible approach.


     4.  Protocol Layering


     The  previous  discussion suggested that there was a decision to be

made as to where a protocol ought to  be  implemented.    In  fact,  the

decision  is  much  more  complicated  than that, for the goal is not to

implement a single protocol, but to implement a whole family of protocol

layers, starting with a device driver or local  network  driver  at  the

bottom,  then  IP  and  TCP,  and  eventually  reaching  the application

specific protocol, such as Telnet, FTP and SMTP on the  top.    Clearly,

the bottommost of these layers is somewhere within the kernel, since the

physical  device  driver for the net is almost inevitably located there.

Equally clearly, the top layers of this package, which provide the  user

his  ability  to  perform the remote login function or to send mail, are

not entirely contained within the kernel.  Thus,  the  question  is  not

                                   11


whether  the  protocol family shall be inside or outside the kernel, but

how it shall be sliced in two between that part  inside  and  that  part

outside.


     Since  protocols  come  nicely layered, an obvious proposal is that

one of the layer interfaces should be the point at which the inside  and

outside components are sliced apart.  Most systems have been implemented

in  this  way,  and  many have been made to work quite effectively.  One

obvious place to slice is at the upper interface  of  TCP.    Since  TCP

provides  a  bidirectional byte stream, which is somewhat similar to the

I/O facility provided by most operating systems, it is possible to  make

the  interface  to  TCP  almost  mimic  the  interface to other existing

devices.  Except in the matter of opening a connection, and dealing with

peculiar failures, the software using TCP need not know  that  it  is  a

network connection, rather than a local I/O stream that is providing the

communications  function.  This approach does put TCP inside the kernel,

which raises all the problems addressed  above.    It  also  raises  the

problem that the interface to the IP layer can, if the programmer is not

careful,  become  excessively  buried  inside  the  kernel.   It must be

remembered that things other than TCP are expected to run on top of  IP.

The  IP interface must be made accessible, even if TCP sits on top of it

inside the kernel.


     Another obvious place to slice is above Telnet.  The  advantage  of

slicing  above  Telnet  is  that  it solves the problem of having remote

login channels emulate local teletype channels.    The  disadvantage  of

putting  Telnet into the kernel is that the amount of code which has now

                                   12


been  included  there  is  getting  remarkably  large.    In  some early

implementations, the size of the  network  package,  when  one  includes

protocols  at  the  level  of Telnet, rivals the size of the rest of the

supervisor.  This leads to vague feelings that all is not right.


     Any attempt to slice through a lower layer  boundary,  for  example

between  internet  and  TCP,  reveals  one fundamental problem.  The TCP

layer, as well as the IP layer, performs a  demultiplexing  function  on

incoming  datagrams.   Until the TCP header has been examined, it is not

possible to know for which  user  the  packet  is  ultimately  destined.

Therefore,  if  TCP,  as  a  whole,  is  moved outside the kernel, it is

necessary to create one separate process called the TCP  process,  which

performs  the TCP multiplexing function, and probably all of the rest of

TCP processing as well.  This means that incoming data  destined  for  a

user  process  involves  not  just a scheduling of the user process, but

scheduling the TCP process first.


     This suggests an  alternative  structuring  strategy  which  slices

through  the  protocols,  not  along  an established layer boundary, but

along a functional boundary having to do with demultiplexing.   In  this

approach, certain parts of IP and certain parts of TCP are placed in the

kernel.    The amount of code placed there is sufficient so that when an

incoming datagram arrives, it is possible to know for which process that

datagram is ultimately destined.  The datagram is then  routed  directly

to  the  final  process,  where  additional  IP  and  TCP  processing is

performed on it.  This removes from the kernel any requirement for timer

based actions, since they can be done by the  process  provided  by  the

                                   13


user.    This  structure  has  the  additional advantage of reducing the

amount of code required in the  kernel,  so  that  it  is  suitable  for

systems where kernel space is at a premium.  The RFC 814, titled "Names,

Addresses,  Ports, and Routes," discusses this rather orthogonal slicing

strategy in more detail.


     A related discussion of protocol layering and multiplexing  can  be

found in Cohen and Postel [1].


     5.  Breaking Down the Barriers


     In  fact, the implementor should be sensitive to the possibility of

even more  peculiar  slicing  strategies  in  dividing  up  the  various

protocol  layers  between the kernel and the one or more user processes.

The result of the strategy proposed above was that part  of  TCP  should

execute  in  the process of the user.  In other words, instead of having

one TCP process for the system, there is one TCP process per connection.

Given this architecture, it is not longer necessary to imagine that  all

of  the  TCPs  are  identical.    One  TCP  could  be optimized for high

throughput applications, such as file transfer.  Another  TCP  could  be

optimized  for small low delay applications such as Telnet.  In fact, it

would be possible to produce a TCP which was  somewhat  integrated  with

the  Telnet  or  FTP  on  top  of  it.  Such an integration is extremely

important,  for  it  can  lead  to  a  kind  of  efficiency  which  more

traditional  structures are incapable of producing.  Earlier, this paper

pointed out that one of the important rules to achieving efficiency  was

to  send  the minimum number of packets for a given amount of data.  The

idea of protocol layering interacts very strongly (and poorly) with this

                                   14


goal,  because  independent  layers  have  independent  ideas about when

packets should be sent, and unless these layers can somehow  be  brought

into  cooperation,  additional  packets  will flow.  The best example of

this is the operation of server telnet in a character at a  time  remote

echo  mode  on top of TCP.  When a packet containing a character arrives

at a server host, each layer has a different response  to  that  packet.

TCP  has  an obligation to acknowledge the packet.  Either server telnet

or the application layer above has an obligation to echo  the  character

received  in the packet.  If the character is a Telnet control sequence,

then Telnet has additional actions which it must perform in response  to

the  packet.    The  result  of  this,  in most implementations, is that

several packets are sent back in response to the  one  arriving  packet.

Combining  all of these return messages into one packet is important for

several reasons.  First, of course, it reduces  the  number  of  packets

being sent over the net, which directly reduces the charges incurred for

many common carrier tariff structures.  Second, it reduces the number of

scheduling  actions  which  will  occur inside both hosts, which, as was

discussed above, is extremely important in improving throughput.


     The way to achieve this goal of packet sharing is to break down the

barrier between the layers of the protocols, in a  very  restrained  and

careful  manner, so that a limited amount of information can leak across

the barrier to enable one layer to optimize its behavior with respect to

the desires of the layers above and below it.   For  example,  it  would

represent  an  improvement  if TCP, when it received a packet, could ask

the layer above whether or not it would  be  worth  pausing  for  a  few

milliseconds  before  sending  an acknowledgement in order to see if the

                                   15


upper  layer  would  have  any  outgoing  data to send.  Dallying before

sending  the  acknowledgement  produces  precisely  the  right  sort  of

optimization  if  the client of TCP is server Telnet.  However, dallying

before sending an acknowledgement is absolutely unacceptable if  TCP  is

being used for file transfer, for in file transfer there is almost never

data  flowing  in  the  reverse  direction, and the delay in sending the

acknowledgement probably translates directly into a delay  in  obtaining

the  next  packets.  Thus, TCP must know a little about the layers above

it to adjust its performance as needed.


     It would be possible to imagine a general  purpose  TCP  which  was

equipped  with  all  sorts of special mechanisms by which it would query

the layer above and modify its behavior accordingly.  In the  structures

suggested above, in which there is not one but several TCPs, the TCP can

simply  be modified so that it produces the correct behavior as a matter

of course.  This structure has  the  disadvantage  that  there  will  be

several  implementations  of TCP existing on a single machine, which can

mean more maintenance headaches if a problem is found where TCP needs to

be changed.  However, it is probably the case that each of the TCPs will

be substantially simpler  than  the  general  purpose  TCP  which  would

otherwise  have  been  built.    There  are  some  experimental projects

currently under way which suggest that this approach may make  designing

of  a  TCP, or almost any other layer, substantially easier, so that the

total effort involved in bringing up a complete package is actually less

if this approach is followed.  This approach is by  no  means  generally

accepted, but deserves some consideration.

                                   16


     The  general conclusion to be drawn from this sort of consideration

is that a layer boundary has both a benefit and a penalty.    A  visible

layer  boundary,  with  a  well  specified interface, provides a form of

isolation between two layers which allows one to  be  changed  with  the

confidence  that  the  other  one  will  not  stop  working as a result.

However, a firm layer boundary almost inevitably  leads  to  inefficient

operation.    This  can  easily be seen by analogy with other aspects of

operating systems.  Consider, for example,  file  systems.    A  typical

operating  system  provides  a file system, which is a highly abstracted

representation of a disk.   The  interface  is  highly  formalized,  and

presumed  to  be highly stable.  This makes it very easy for naive users

to have access to  disks  without  having  to  write  a  great  deal  of

software.  The existence of a file system is clearly beneficial.  On the

other  hand,  it is clear that the restricted interface to a file system

almost inevitably leads to inefficiency.  If the interface is  organized

as  a  sequential read and write of bytes, then there will be people who

wish to do high throughput transfers who cannot achieve their goal.   If

the  interface  is  a  virtual  memory  interface, then other users will

regret the necessity of building a byte stream interface on top  of  the

memory  mapped file.  The most objectionable inefficiency results when a

highly sophisticated package, such as a data  base  management  package,

must  be  built  on  top  of  an  existing  operating  system.    Almost

inevitably, the implementors of the database system  attempt  to  reject

the  file  system  and  obtain  direct  access  to the disks.  They have

sacrificed modularity for efficiency.


     The same conflict appears in networking, in a rather extreme  form.

                                   17


The concept of a protocol is still unknown and frightening to most naive

programmers.   The idea that they might have to implement a protocol, or

even part of a protocol, as part  of  some  application  package,  is  a

dreadful thought.  And thus there is great pressure to hide the function

of  the  net behind a very hard barrier.  On the other hand, the kind of

inefficiency which results from this is a particularly undesirable  sort

of  inefficiency, for it shows up, among other things, in increasing the

cost of the communications resource used up to achieve  the  application

goal.   In cases where one must pay for one's communications costs, they

usually turn out to be the dominant cost within the system.  Thus, doing

an excessively good job of packaging up the protocols in  an  inflexible

manner  has  a  direct  impact  on  increasing  the cost of the critical

resource within the system.  This is a dilemma which will probably  only

be solved when programmers become somewhat less alarmed about protocols,

so that they are willing to weave a certain amount of protocol structure

into their application program, much as application programs today weave

parts  of  database  management  systems  into  the  structure  of their

application program.


     An extreme example of putting the protocol package  behind  a  firm