rfc872.txt

RFC 相关的技术文档

     module resides).  That is, IP handles internet routing, whereas
     TCP (or some other Host-Host  protocol) handles only internet
     addressing.  Because some proximate nets will accept smaller
     transmissions ("packets") than others, IP, qua protocol, also has
     a discipline for allowing packets to be fragmented while in the
     catenet and reassembled at their destination.  Finally (for our
     purposes), IP offers a mechanism to allow the particular protocol
     it was called by (for a given packet) to be identified so that
     the receiver can demultiplex transmissions based on IP-level
     information only. (This is in accordance with the Principle of
     Layering:  you don't want to have to look at the data IP is
     conveying to find out what to do with it.)

          Now that all seems rather complex, even though it omits a
     number of mechanisms.  (For a more complete discussion, see
     Reference [4].)  But it should be just about enough to slay the
     Woozle, especially if just one more protocol's most significant
     property can be snuck in.  An underpublicized member of the
     ARPANET suite of protocols is called UDP--the "User Datagram
     Protocol."  UDP is designed for speed rather than accuracy.  That
     is, it's not "reliable."  All there is to UDP, basically, is a
     mechanism to allow a given packet to be associated with a given
     logical connection. Not a TCP logical connection, mind you, but a
     UDP logical connection.  So if all you want is the ability to
     demultiplex data streams from your Host-Host protocol, you use
     UDP, not TCP.  ("You" is usually supposed to be a Packetized
     Speech protocol, but doesn't have to be.)  (And we'll worry about
     Flow Control some other time.)

     TCP-on-a-LAN

          So whether you're a Host proximate to a LAN or not, and even
     whether your TCP/IP is "inboard" or "outboard" of you, if you're
     talking to a Host somewhere out there on the catenet, you use IP;
     and if you're exercising some process-level/applications protocol
     (roughly equivalent to some of some versions of ISO L5 and all of
     L6 and L7) that expects TCP/IP as its Host-Host protocol (because
     it "wants" reliable, flow controlled, ordered delivery [whoops,
     forgot that "ordered" property earlier--but it doesn't matter all
     that much for present purposes] over logical connections which
     allow it to be




                                     4
     RFC 872                                            September 1982


     addressed via a Well-Known Socket), you use TCP "above" IP
     regardless of whether the other Host is on your proximate net or
     not.  But if your application doesn't require the properties of
     TCP (say for Packetized Speech), don't use it--regardless of
     where or what you are.  And if you want to make the decision
     about whether you're talking to a proximate Host explicitly and
     not even go through IP, you can even arrange to do that (though
     it might make for messy implementation under some circumstances).
     That is, if you want to take advantage of the properties of your
     LAN "in the raw" and have or don't need appropriate applications
     protocols, the Reference Model to which TCP/IP were designed
     won't stop you.  See Figure 2 if you're visual.  A word of
     caution, though:  those applications probably will need protocols
     of some sort--and they'll probably need some sort of Host-Host
     protocol under them, so unless you relish maintaining "parallel"
     suites of protocols....  that is, you really would be better off
     with TCP most of the time locally anyway, because you've got to
     have it to talk to the catenet and it's a nuisance to have
     "something else" to talk over the LAN--when, of course, what
     you're talking requires a Host-Host protocol.

          We'll touch on "performance" issues in a bit more detail
     later. At this level, though, one point really does need to be
     made:  On the "reliability" front, many (including the author) at
     first blush take the TCP checksum to be "overkill" for use on a
     LAN, which does, after all, typically present extremely good
     error properties. Interestingly enough, however, metering of TCP
     implementations on several Host types in the research community
     shows that the processing time expended on the TCP checksum is
     only around 12% of the per-transmission processing time anyway.
     So, again, it's not clear that it's worthwhile to bother with an
     alternate Host-Host protocol for local use (if, that is, you need
     the rest of the properties of TCP other than "reliability"--and,
     of course, always assuming you've got a LAN, not an LCN, as
     distinguished earlier.)

          Take that, Woozle!

     Other Significant Properties

          Oh, by the way, one or two other properties of TCP/IP really
     do bear mention:

          1.   Protocol interpreters for TCP/IP exist for a dozen or
               two different operating systems.

          2.   TCP/IP work, and have been working (though in less
               refined versions) for several years.





                                     5
     RFC 872                                            September 1982


          3.   IP levies no constraints on the interface protocol
               presented by the proximate net (though some protocols
               at that level are more wasteful than others).

          4.   IP levies no constraints on its users; in particular,
               any proximate net that offers alternate routing can be
               taken advantage of (unlike X.25, which appears to
               preclude alternate routing).

          5.   IP-bearing Gateways both exist and present and exploit
               properties 3 and 4.

          6.   TCP/IP are Department of Defense Standards.

          7.   Process (or application) protocols compatible with
               TCP/IP for Virtual Terminal and File Transfer
               (including "electronic mail") exist and have been
               implemented on numerous operating systems.

          8.   "Vendor-style" specifications of TCP/IP are being
               prepared under the aegis of the DoD Protocol Standards
               Technical Panel, for those who find the
               research-community-provided specs not to their liking.

          9.   The research community has recently reported speeds in
               excess of 300 kb/s on an 800 kb/s subnet, 1.2 Mb/s on a
               3 Mb/s subnet, and 9.2 kbs on a 9.6 kb/s phone
               line--all using TCP.  (We don't know of any numbers for
               alternative protocol suites, but it's unlikely they'd
               be appreciably better if they confer like
               functionality--and they may well be worse if they
               represent implementations which haven't been around
               enough to have been iterated a time or three.)

          With the partial exception of property 8, no other
     resource-sharing protocol suite can make those claims.

          Note particularly well that none of the above should be
     construed as eliminating the need for extremely careful
     measurement of TCP/IP performance in/on a LAN.  (You do, after
     all, want to know their limitations, to guide you in when to
     bother ringing in "local" alternatives--but be very careful:  1.
     they're hard to measure commensurately with alternative
     protocols; and 2.  most conventional Hosts can't take [or give]
     as many bits per second as you might imagine.)  It merely
     dramatically refocuses the motivation for doing such measurement.
     (And levies a constraint or two on how you outboard, if you're
     outboarding.)





                                     6
     RFC 872                                            September 1982


     Other Contextual Data

          Our case could really rest here, but some amplification of
     the aside above about Host capacities is warranted, if only to
     suggest that some quantification is available to supplement the a
     priori argument:  Consider the previously mentioned PDSC.  Its
     local terminals operate in a screen-at-a-time mode, each
     screen-load comprising some 16 kb.  How many screens can one of
     its Hosts handle in a given second?  Well, we're told that each
     disk fetch requires 17 ms average latency, and each context
     switch costs around 2 ms, so allowing 1 ms for transmission of
     the data from the disk and to the "net" (it makes the arithmetic
     easy), that would add up to 20 ms "processing" time per screen,
     even if no processing were done to the disk image.  Thus, even if
     the Host were doing nothing else, and  even if the native disk
     I/O software were optimized to do 16 kb reads, it could only
     present 50 screens to its communications mechanism
     (processor-processor bus) per second.  That's 800 kb/s. And
     that's well within the range of TCP-achievable rates (cf.  Other
     Significant Property 9).  So in a realistic sample environment,
     it would certainly seem that typical Hosts can't necessarily
     present so many bits as to overtax the protocols anyway.  (The
     analysis of how many bits typical Hosts can accept is more
     difficult because it depends more heavily on system internals.
     However, the point is nearly moot in that even in the intuitively
     unlikely event that receiving were appreciably faster in
     principle [unlikely because of typical operating system
     constraints on address space sizes, the need to do input to a
     single address space, and the need to share buffers in the
     address space among several processes], you can't accept more
     than you can be given.)

     Conclusion

          The sometimes-expressed fear that using TCP on a local net
     is a bad idea is unfounded.

     References

     [1]  Milne, A. A., "Winnie-the-Pooh", various publishers.

     [2]  The LAN description is based on Clark, D. D.  et al., "An
          Introduction to Local Area Networks,"  IEEE Proc., V. 66, N.
          11, November 1978, pp. 1497-1517, several year's worth of
          conversations with Dr. Clark, and the author's observations
          of both the open literature and the Oral Tradition (which
          were sufficiently well-thought of to have prompted The MITRE
          Corporation/NBS/NSA Local Nets "Brain Picking Panel" to have





                                     7
     RFC 872                                            September 1982


          solicited his testimony during the year he was in FACC's
          employ.*)

     [3]  The TCP/IP descriptions are based on Postel, J. B.,
          "Internet Protocol Specification," and "Transmission Control
          Specification" in DARPA Internet Program Protocol
          Specifications, USC Information Sciences Institute,
          September, 1981, and on more than 10 years' worth of
          conversations with Dr. Postel, Dr. Clark (now the DARPA
          "Internet Architect") and Dr. Vinton G. Cerf (co-originator
          of TCP), and on numerous discussions with several other
          members of the TCP/IP design team, on having edited the
          referenced documents for the PSTP, and, for that matter, on
          having been one of the developers of the ARPANET "Reference
          Model."

     [4]  Padlipsky, M. A., "A Perspective on the ARPANET Reference
          Model", M82-47, The MITRE Corporation, September 1982; also
          available in Proc. INFOCOM '83.

     ________________
     *  In all honesty, as far as I know I started the rumor that TCP
        might be overkill for a LAN at that meeting.  At the next TCP
        design meeting, however, they separated IP out from TCP, and
        everything's been alright for about three years now--except
        for getting the rumor killed.  (I'd worry about Woozles
        turning into roosting chickens if it weren't for the facts
        that:  1.  People tend to ignore their local guru; 2.  I was
        trying to encourage the IP separation; and 3.  All I ever
        wanted was some empirical data.)

     NOTE:  FIGURE 1. ARM in the Abstract, and FIGURE 2.  ARMS,
        Somewhat Particularized, may be obtained by writing to:  Mike
        Padlipsky, MITRE Corporation, P.O. Box 208, Bedford,
        Massachusetts, 01730, or sending computer mail to
        Padlipsky@USC-ISIA.

















                                     8