RFC872 日本語訳

     RFC 872                                            September 1982
                                                                M82-48

RFC872 1982年9月のM82-48

                               TCP-ON-A-LAN

TCP ON-ラン

                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts

M.A.PADLIPSKY斜め継ぎ会社のベッドフォード(マサチューセッツ)

                                 Abstract

要約

          The sometimes-held position that the DoD Standard
     Transmission Control Protocol (TCP) and Internet Protocol (IP)
     are inappropriate for use "on" a Local Area Network (LAN) is
     shown to be fallacious.  The paper is a companion piece to
     M82-47, M82-49, M82-50, and M82-51.

通信制御プロトコル(TCP)とインターネットプロトコル(IP)が不適当であるDoD Standardがローカル・エリア・ネットワーク(LAN)が当てにならなくなるように示される“on"を使用するという時々保持された位置。 紙はM82-47、M82-49、M82-50、およびM82-51への姉妹編です。

                                     i

i

                              "TCP-ON-A-LAN"

「TCP ON-ラン」

                              M. A. Padlipsky

M.A.Padlipsky

     Thesis

論文

          It is the thesis of this paper that fearing "TCP-on-a-LAN"
     is a Woozle which needs slaying.  To slay the "TCP-on-a-LAN"
     Woozle, we need to know three things:  What's a Woozle?  What's a
     LAN?  What's a TCP?

それは「LANのTCP」を恐れて、殺す必要があるWoozleであるこの紙の論文です。 「LANのTCP」Woozleを殺すために、私たちは、3つのことを知る必要があります: Woozleは何ですか? LANは何ですか? TCPは何ですか?

     Woozles

Woozles

          The first is rather straightforward [1]:

1番目はかなり簡単な[1]です:

               One fine winter's day when Piglet was brushing away the
          snow in front of his house, he happened to look up, and
          there was Winnie-the-Pooh.  Pooh was walking round and round
          in a circle, thinking of something else, and when Piglet
          called to him, he just went on walking.
               "Hallo!" said Piglet, "what are you doing?"
               "Hunting," said Pooh.
               "Hunting what?"
               "Tracking something," said Winnie-the-Pooh very
          mysteriously.
               "Tracking what?" said Piglet, coming closer.
               "That's just what I ask myself.  I ask myself, What?"
               "What do you think you'll answer?"
               "I shall have to wait until I catch up with it," said
          Winnie-the-Pooh.  "Now look there."  He pointed to the
          ground in front of him.  "What do you see there?
               "Tracks," said Piglet, "Paw-marks."  he gave a little
          squeak of excitement.  "Oh, Pooh!  Do you think it's a--a--a
          Woozle?"

Pigletが彼の家の正面で雪を払いのけていたあるすばらしい冬の日、彼はたまたま見上げました、そして、くまのプーさんがいました。 くまのプーさんはぐるぐる輪になって歩いていました、そして、Pigletが彼に呼びかけたとき、他の何かを考えて、彼はただ歩き続けました。 Piglet、「あなたは何をしていますか?」を「呼んでください!」は言いました。 「狩り」と、くまのプーさんは言いました。 「狩って、何ですか?」 「何かを追跡します。」と、くまのプーさんは非常に神秘的に言いました。 近接していて、「追跡して、何ですか?」と、Pigletは言いました。 「それはちょうど私が自分に尋ねることです。」 「What?、私は自分に尋ねます」 「あなたは、何に答えるかと思いますか?」 「私はそれに追いつくまで待たなければならないでしょう。」と、くまのプーさんは言いました。 「今度は、そこを見てください。」 彼は彼の正面に地面を示しました。 「あなたはそこで何を見ますか?」 Pigletは、「トラックス」と言って、「足マーク」 彼は興奮の小さいキシリ音を与えました。 「おお、くまのプーさん!」 「あなたは、それのa(a)がWoozleであると思いますか?」

          Well, they convince each other that it is a Woozle, keep
     "tracking," convince each other that it's a herd of Hostile
     Animals, and get duly terrified before Christopher Robin comes
     along and points out that they were following their own tracks
     all the long.

さて、それらは、それがWoozleであると互いに納得させて、「追跡すること」を保って、それがHostile Animalsの群れであると互いに納得させて、クリストファー・ロビンが、やって来て、彼らがそれら自身次ののがすべての長さ追跡するということであったと指摘する前に正しく脅かされます。

          In other words, it is our contention that expressed fears
     about the consequences of using a particular protocol named "TCP"
     in a particular environment called a Local Area Net stem from
     misunderstandings of the protocol and the environment, not from
     the technical facts of the situation.

言い換えれば、それは状況の技術的な事実から使用するのではなく、プロトコルと環境の誤解から局部ネット軸と呼ばれる特定の環境で"TCP"という特定のプロトコルを使用する結果に関する恐怖を述べた私たちの主張です。

                                     1
     RFC 872                                            September 1982

1RFC872の1982年9月

     LAN's

LANのもの

          The second thing we need to know is somewhat less
     straightforward:  A LAN is, properly speaking [2], a
     communications mechanism (or subnetwork) employing a transmission
     technology suitable for relatively short distances (typically a
     few kilometers) at relatively high bit-per-second rates
     (typically greater than a few hundred kilobits per second) with
     relatively low error rates, which exists primarily to enable
     suitably attached computer systems (or "Hosts") to exchange bits,
     and secondarily, though not necessarily, to allow terminals of
     the teletypewriter and CRT classes to exchange bits with Hosts.
     The Hosts are, at least in principle, heterogeneous; that is,
     they are not merely multiple instances of the same operating
     system.  The Hosts are assumed to communicate by means of layered
     protocols in order to achieve what the ARPANET tradition calls
     "resource sharing" and what the newer ISO tradition calls "Open
     System Interconnection."  Addressing typically can be either
     Host-Host (point-to-point) or "broadcast." (In some environments,
     e.g., Ethernet, interesting advantage can be taken of broadcast
     addressing; in other environments, e.g., LAN's which are
     constituents of ARPA- or ISO-style "internets", broadcast
     addressing is deemed too expensive to implement throughout the
     internet as a whole and so may be ignored in the constituent LAN
     even if available as part of the Host-LAN interface.)

私たちが知るために必要とする2番目のものはいくらか簡単ではありません: LANは適切に2を話すコミュニケーションメカニズム(または、サブネットワーク)です二次的に比較的高いビット/秒における(通常数キロメートル)が比較的低い誤り率で評定する(1秒あたり数100のキロビットより通常すばらしい)比較的短い距離に適したトランスミッション技術(主として適当に付属しているコンピュータ・システム(または、「ホスト」)がビットを交換するのを可能にするために存在している)を使って; 必ずない、しかし、テレタイプとCRTの端末を許容するのは、Hostsとビットを交換するために属します。 Hostsは少なくとも原則として異種です。 すなわち、それらは同じオペレーティングシステムの単に複数の例ではありません。 Hostsが層にされたプロトコルによってアルパネット伝統が「リソース・シェアリング」と、より新しいISO伝統呼び出しどんな「開放形システム相互接続」と呼ぶことを達成するために交信すると思われます。 アドレシングは、通常、Host-ホスト(ポイントツーポイント)か「放送」のどちらかであることができます。 (いくつかの環境、例えば、イーサネットでは、ブロードキャスト・アドレッシングについておもしろい利点を活用できます; インターネット中で実行できないくらい高価であると全体で考えられるので、他の環境、例えば、ARPAかISO-スタイル「インターネット」の成分であるLANのものでは、Host-LANインタフェースの一部として利用可能であっても、ブロードキャスト・アドレッシングは、構成しているLANで無視されるかもしれません。)

          Note that no assumptions are made about the particular
     transmission medium or the particular topology in play.  LAN
     media can be twisted-pair wires, CATV or other coaxial-type
     cables, optical fibers, or whatever.  However, if the medium is a
     processor-to-processor bus it is likely that the system in
     question is going to turn out to "be" a moderately closely
     coupled distributed processor or a somewhat loosely coupled
     multiprocessor rather than a LAN, because the processors are
     unlikely to be using either ARPANET or ISO-style layered
     protocols.  (They'll usually -- either be homogeneous processors
     interpreting only the protocol necessary to use the transmission
     medium, or heterogeneous with one emulating the expectations of
     the other.)  Systems like "PDSC" or "NMIC" (the evolutionarily
     related, bus-oriented, multiple PDP-11 systems in use at the
     Pacific Data Services Center and the National Military
     Intelligence Center, respectively), then, aren't LANs.

仮定が全く特定のトランスミッション媒体かプレーの特定のトポロジーに関してされないことに注意してください。 LANメディアは、ツイストペア線、CATV、他の同軸タイプケーブル、光ファイバ、または何でもであることができます。しかしながら、媒体がプロセッサからプロセッサへのバスであるなら、問題のシステムは適度に密接に結合した分配されたプロセッサかLANよりむしろいくらか緩く結合したマルチプロセッサを「いてください」に生産しそうでしょう、プロセッサがどちらのアルパネットも使用していそうにないか、またはISO-スタイルがプロトコルを層にしたので。 (通常、それらはそうするでしょう--、ある、トランスミッション媒体を使用するために必要であるか、またはもう片方への期待を見習っている1つの異種のプロトコルだけを解釈する均質のプロセッサ)。 そして、"PDSC"や"NMIC"(それぞれ太平洋のデータサービスセンターと国家の軍情報部センターで使用中の複数のevolutionarilyに関連して、バス指向のPDP-11システム)のようなシステムはLANではありません。

          LAN topologies can be either "bus," "ring," or "star".  That
     is, a digital PBX can be a LAN, in the sense of furnishing a
     transmission medium/communications subnetwork for Hosts to do
     resource sharing/Open System Interconnection over, though it
     might not present attractive speed or failure mode properties.
     (It might, though.)  Topologically, it would probably be a
     neutron star.

LAN topologiesはどちらかの「バス」である、「鳴る」か、または「主演できます」。 すなわち、デジタルPBXはLANであるかもしれません、Hostsがリソース・シェアリング/開いているSystem Interconnectionをやり直すようにトランスミッション媒体/コミュニケーションサブネットワークを提供するという意味で、魅力的な速度か故障モードの特性を提示しないかもしれませんが。 (それ、もっとも、力、) それはたぶん位相的に、中性子星でしょう。

                                     2
     RFC 872                                            September 1982

2 RFC872 1982年9月

          For our purposes, the significant properties of a LAN are
     the high bit transmission capacity and the good error properties.
     Intuitively, a medium with these properties in some sense
     "shouldn't require a heavy-duty protocol designed for long-haul
     nets," according to some.  (We will not address the issue of
     "wasted bandwidth" due to header sizes. [2], pp. 1509f, provides
     ample refutation of that traditional communications notion.)
     However, it must be borne in mind that for our purposes the
     assumption of resource-sharing/OSI type protocols between/among
     the attached Hosts is also extremely significant.  That is, if
     all you're doing is letting some terminals access some different
     Hosts, but the Hosts don't really have any intercomputer
     networking protocols between them, what you have should be viewed
     as a Localized Communications Network (LCN), not a LAN in the
     sense we're talking about here.

私たちの目的のために、LANの重要な特性は、高いビット伝送容量と良い誤りの特性です。 何らかの意味におけるこれらの特性がある媒体は直観的に、「長期ネットのために設計された強力プロトコルを必要とであるべきではありません」、いくつかに従って。 (私たちはヘッダーサイズによる「無駄な帯域幅」の問題を記述するつもりではありません。 [2]、ページ 1509f、その伝統的なコミュニケーション概念の十分な論破を提供します。) しかしながら、また、私たちの目的のために、付属Hostsの中の/の間のリソース・シェアリング/OSIタイププロトコルの仮定も非常に重要であることを覚えておかなければなりません。 すなわち、あなたがしているすべてがいくつかの端末をいくつかの異なったHostsにアクセスさせますが、Hostsの間には、intercomputerネットワーク・プロトコルが少しの本当にないなら、あなたが持っているものはLocalized Communications Network(LCN)(私たちがおよそここで話している意味におけるLANでない)として見なされるべきです。

     TCP

TCP

          The third thing we have to know can be either
     straightforward or subtle, depending largely on how aware we are
     of the context estabished by ARPANET-style prococols:  For the
     visual-minded, Figure 1 and Figure 2 might be all that need be
     "said."  Their moral is meant to be that in ARPANET-style
     layering, layers aren't monoliths.  For those who need more
     explanation, here goes:  TCP [3] (we'll take IP later) is a
     Host-Host protocol (roughly equivalent to the functionality
     implied by some of ISO Level 5 and all of ISO Level 4).  Its most
     significant property is that it presents reliable logical
     connections to protocols above itself.  (This point will be
     returned to subsequently.)  Its next most significant property is
     that it is designed to operate in a "catenet" (also known as the,
     or an, "internet"); that is, its addressing discipline is such
     that Hosts attached to communications subnets other than the one
     a given Host is attached to (the "proximate net") can be
     communicated with as well as Hosts on the proximate net.  Other
     significant properties are those common to the breed:  Host-Host
     protocols (and Transport protocols) "all" offer mechanisms for
     flow Control, Out-of-Band Signals, Logical Connection management,
     and the like.

私たちが知らなければならない3番目のことは、簡単であるか、または微妙である場合があります、主に私たちがアルパネットスタイルprococolsによってestabishedされた文脈をどれくらい意識しているかによって: 視覚志向に関しては、図1と図2は「言われていなければならない」すべてであるかもしれません。 それらの教訓はアルパネットスタイルレイヤリングでは、層がモノリスでないということであることが意味されます。 ここで、より多くの説明を必要とする人のために、行きます:。 TCP[3](私たちは後でIPを取るつもりです)はHost-ホストプロトコル(およそいくらかのISO Level5とISO Level4のすべてによって含意された機能性に同等な)です。 最も重要な特性はそれ自体の上のプロトコルに頼もしい論理的な接続を紹介するということです。 (このポイントを次に返すでしょう。) 次の最も重要な特性がそれが"catenet"で作動するように設計されているということである、(また、知っている、「インターネット」)、。 すなわち、規律を記述するのは、与えられたHostが取り付けられるもの(「最も近いネット」)以外のコミュニケーションサブネットに取り付けられたHostsが最も近いネットのHostsと同様にコミュニケートされることができるようにものです。 他の重要な特性は種類に共通のそれらです: ホスト兼ホストプロトコル(そして、Transportプロトコル)「すべて」は流れControl、バンドのOut Signals、Logical Connection管理、および同様のもののためにメカニズムを提供します。

          Because TCP has a catenet-oriented addressing mechanism
     (that is, it expresses foreign Host addresses as the
     "two-dimensional" entity Foreign Net/Foreign Host because it
     cannot assume that the Foreign Host is attached to the proximate
     net), to be a full Host-Host protocol it needs an adjunct to deal
     with the proximate net.  This adjunct, the Internet Protocol (IP)
     was designed as a separate protocol from TCP, however, in order
     to allow it to play the same role it plays for TCP for other
     Host-Host protocols too.

TCPにはcatenet指向のアドレシングメカニズムがあるので(Foreign Hostが最も近いネットに取り付けられると仮定できないので、すなわち、それは「二次元」の実体Foreignネット/外国のHostとして外国Hostアドレスを表します)、それは完全なHost-ホストプロトコルに、なるように最も近いネットとの取引への付属物を必要とします。 この付属物、しかしながら、インターネットプロトコル(IP)は、他のHost-ホストプロトコルのためにも、TCPのために果たす同じ役割を果たすのを許容するように別々のプロトコルとしてTCPから設計されました。

                                     3
     RFC 872                                            September 1982

3 RFC872 1982年9月

          In order to "deal with the proximate net", IP possess the
     following significant properties:  An IP implementation maps from
     a virtualization (or common intermediate representation) of
     generic proximate net qualities (such as precedence, grade of
     service, security labeling) to the closest equivalent on the
     proximate net. It determines whether the "Internet Address" of a
     given transmission is on the proximate net or not; if so, it
     sends it; if not, it sends it to a "Gateway" (where another IP
     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.)

「最も近いネットに対処する」ために、IPには、以下の重要な特性があります: IP実現はネットの品質(先行、サービス、セキュリティラベリングのグレードなどの)をジェネリック最も近いことの仮想化(または、共通中間体表現)から最も近いネットで最も近い同等物に写像します。 それは、与えられたトランスミッションの「インターネットアドレス」が最も近いネットにあるかを決定します。 そうだとすれば、それを送ります。 そうでなければ、それは「ゲートウェイ」(別のIPモジュールがあるところ)にそれを送ります。 すなわち、IPはインターネットルーティングを扱いますが、TCP(または、ある他のHost-ホストプロトコル)はインターネットアドレシングだけを扱います。 いくつかの最も近いネットが他のものより小さいトランスミッション(「パケット」)を受け入れるので、プロトコル資格で、IPにはパケットがcatenetにある間、断片化されて、それらの目的地で組み立て直されるのを許容するための規律がまた、あります。 最終的に(私たちの目的のために)、受信機はIP-レベル情報だけに基づく「反-マルチプレックス」トランスミッションを提供できて、IPが、それが呼ばれた特定のプロトコル(与えられたパケットのための)が特定されるのを許容するためにメカニズムを提供します。 (LayeringのPrincipleによると、これはあります: あなたは、IPがそれで何をしたらよいかを見つけるために伝えているデータを見なければならなくて欲しくはありません。)

          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.)

今、それですが、すべてがかなり複雑に見えるのが多くのメカニズムを省略します。. (より完全な議論に関して、Reference[4]を見てください。) しかし、Woozleを殺すのはほとんど十分であるべきです、特にちょうどもうひとつのプロトコルの最も重要な特性がそうであることができるなら。こっそり入りました。 プロトコルのアルパネットスイートのunderpublicized部材はUDPと呼ばれます--「ユーザー・データグラム・プロトコル。」 UDPは精度よりむしろ速度のために設計されています。 すなわち、それは「信頼できません」。 UDPにはそこのすべてがあって、基本的に、メカニズムは、与えられたパケットが与えられた論理的な接続に関連しているのを許容することになっていますか? どんなa TCPの論理的な接続もあなた方、しかし、UDPの論理的な接続を気にしないでください。 それで、あなたが欲しいすべてがあなたのHost-ホストプロトコルからの「反-マルチプレックス」データ・ストリームへの能力であるなら、あなたはTCPではなく、UDPを使用します。 プロトコルである必要はないこと以外の通常、」はPacketized Speechプロトコルであるべきです。(いてください、) (そして、私たちはいつか、Flow Controlを心配するでしょう。)

     TCP-on-a-LAN

LANのTCP

          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

それで、あなたがむこう、catenetのどこかでHostと話しているなら、あなたのTCP/IPがあなたがLANに最も近いHostであり、「内側に」あるか、またはあなたで「船外であること」にかかわらずさえあなたはIPを使用します。 そして、あなたが何らかの過程レベル/アプリケーションプロトコル(およそISO L5のいくつかのバージョンのいくつかとL6とL7のすべてに同等な)を運動させているなら、それはHost-ホストプロトコルとしてTCP/IPを予想します。(信頼できた状態で「欲しい」ので、流れが制御された、それを許容する論理的な接続の上の配送[大声をあげて、それは、より早く特性を「命令しました」--それだけが現在の目的のためにすべてあまりその重要でなかったのを忘れた]は命令します。

                                     4
     RFC 872                                            September 1982

4 RFC872 1982年9月

     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.

記述されたaを通してWellによって知られているSocket)、もう片方のHostがあなたの最も近いネットにあることにかかわらずあなたはTCP “above"IPを使用します。 しかし、アプリケーションがTCPの特性を必要としないなら(Packetized Speechには、言ってください)、あなたがどこか者であることにかかわらずそれを使用しないでください。 そして、明らかにあなたが最も近いHostと話すかどうかに関する決定をし、IPを通りたくなくてもさえ、あなたは、それをするように手配さえできます(乱雑ないくつかの状況の下での実現になるかもしれませんが)。 すなわち、あなたが「自然のままで」あなたのLANの特性を利用したくて、持つか、または適切なアプリケーションプロトコル、Reference Modelを必要としない、どのTCP/IPが設計されたかがあなたを止めないでしょう。 視覚であるなら、図2を見てください。 もっとも、警告の単語、: それらのアプリケーションはたぶんある種のプロトコルを必要とするでしょう--そして、彼らがたぶんそれらの下である種のHost-ホストプロトコルを必要とするので、あなたが味がしないなら、維持はプロトコルのスイートに「沿います」…。すなわち、あなたはTCPによって本当に局所的にとにかくたいてい暮らし向きが良いでしょう、catenetと話すためにあなたにはそれがなければならなくて、LANについて論議する「他の何か」を持つあなたが話していることがもちろんHost-ホストプロトコルを必要とするときの迷惑であるので。

          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.)

私たちは後でもう少しの詳細に「性能」問題に触れるつもりです。 もっとも、このレベルでは、1ポイントは、本当に作られている必要があります: 「信頼性」前部では、多く(作者を含んでいる)が、LANにおける使用のための「過剰殺傷」になるように一見TCPチェックサムを取ります。LANは結局通常現在の非常に良い誤りの特性をします。 しかしながら、十分おもしろく、研究団体のいくつかのHostタイプの上のTCP実現の計量は、TCPチェックサムで費やされた処理時間がとにかく1トランスミッションあたりの処理時間のおよそ12%にすぎないことを示します。 それで、一方、地方の使用のために交互のHost-ホストプロトコルを苦にする価値があるのは、明確ではありません。(すなわち、あなたが「信頼性」を除いたTCPの特性の残りを必要とするか、そして、もちろんいつもあなたを仮定するのにおいて、LCNではなく、LANがあります、より早く区別されるように。)

          Take that, Woozle!

Woozle、それを取ってください!

     Other Significant Properties

他の重要な特性

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

ところで、おお、TCP/IPの他の1か2つの特性が本当に言及に堪えます:

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

1. TCP/IPのためのプロトコルインタプリタは1ダースか2台の異なったオペレーティングシステムのために存在しています。

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

2. TCP/IP仕事と、数年間働いています(もっともそれほど洗練されていないバージョンで)。

                                     5
     RFC 872                                            September 1982

5 RFC872 1982年9月

          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).

3. IPは最も近いネットによって提示されたインタフェースプロトコルに規制を全く徴収しません(そのレベルにおけるいくつかのプロトコルが他のものより無駄ですが)。

          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).

4. IPは規制を全くユーザに徴収しません。 特に、迂回中継を提供するどんな最も近いネットも利用できます(X.25と異なって)。X.25は迂回中継を排除するように見えます。

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

5. IP-ベアリングGatewaysは特性3と4を存在していて、提示して、利用します。

          6.   TCP/IP are Department of Defense Standards.

6. TCP/IPは国防総省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.

7. Virtual TerminalとFile Transfer(「電子メール」を含んでいる)における、TCP/IPとのコンパチブル過程(または、アプリケーション)プロトコルは、存在していて、多数のオペレーティングシステムで実行されました。

          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.

8. TCP/IPの「業者スタイル」仕様はDoDプロトコルStandards Technical Panelのアイギスの下で準備されます、研究共同体が提供された仕様を彼らの好みでないのに見つける人のために。

          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.)

9. TCPをすべて使用して、研究団体は、最近、サブネット、3Mb/sのサブネットの1.2Mb/s、および9.6kb/sの9.2kbsが電話をする800kb/sの300kb/sを超えた速度が立ち並ぶと報告しました。 (私たちは代替のプロトコル群の少しの数も知りませんが、同様の機能性を与えるなら彼らがかなり良いだろう、彼らが繰り返されたa時間か3つであることができたなかった実現を表すならそれらがたぶんより悪いだろうというのは、ありそうもないです。)

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

特性8の部分的な例外で、他のものでないリソース・シェアリングプロトコル群はそれらのクレームをすることができます。

          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.)

上記のどれかがLANで/でのTCP/IP性能の非常に慎重な測定の必要性を排除するのに理解されるべきでないことに特によく注意してください。 (あなたが彼らの制限を知って、結局(「地方」の代替手段を迎え入れるのをいつ苦しめるかのあなたを);非常に注意してください: 1 代替のプロトコルで等しく測定しにくい--誘導したがっていて、2最も従来のHostsが取ることができない、[付与、]、あなたが想像するかもしれないのと同じくらい多くのbps)。 それは劇的に単にそのような測定をすることに関する動機の焦点を再び合わせます。 (1か2つの規制を差し押さえする、どのように、あなた、あなたであるなら外到達が船外では、そうであるか、)

                                     6
     RFC 872                                            September 1982

6 RFC872 1982年9月

     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.)

私たちのケースは本当にここに静止できましたが、Host能力に関する上の余談の何らかの増幅が保証されます、何らかの定量化がそれを示すためだけに先験的な議論に補足に利用可能であるなら: 以前に言及されたPDSCを考えてください。 ローカル・ターミナルは一度にスクリーンモード、およそ16kbを包括するそれぞれのスクリーン荷重で作動します。 Hostsの1つは与えられた2番目でいくつのスクリーンを扱うことができますか? さて、私たちはそれぞれのディスクフェッチが1スクリーンあたりの最大20ms「処理」時間の平均した潜在、それぞれの文脈スイッチコストおよそ2ms、したがって、ディスクからのデータの伝達のために1msを許容して、および「ネット」(それで、演算は簡単になる)へのそれが加える17msを必要とすると言われます、ディスクイメージに処理しなかったとしても。 したがって、Hostが他に何もをしていたとしても、固有のディスク入出力ソフトウェアが16のkb読書をするために最適化されたとしても、それは1秒あたりのコミュニケーションメカニズム(プロセッサプロセッサバス)に50個のスクリーンしか贈らないかもしれないでしょうに。 それは800kb/sです。 そして、TCP達成可能なレートの範囲のかなり中にそれはいます。(Cf。 他の重要な特性9). それで、確かに、現実的なサンプル環境で、典型的なHostsが必ずとても多くのビットをとにかくプロトコルを酷使するほど寄贈できるというわけではないように思えるでしょう。 (典型的なHostsがいくつのビットを受け入れることができるかに関する分析は、より大いにシステムインターナルによるので、より難しいです。 しかしながら、受信が原則として[アドレス空間サイズ、ただ一つのアドレス空間に入力する必要性、およびいくつかの過程の中でアドレス空間でバッファを共有する必要性で典型的なオペレーティングシステム規制のためにありそうもない]かなり速いというポイントはそれで直観的にありそうもない出来事でさえほとんど論争中です、とあなたがあなたを与えることができるほど受け入れることができません。)

     Conclusion

結論

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

ローカルのネットでTCPを使用するのが、悪い考えであるという時々言い表された恐れは無根拠です。

     References

参照

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

[1] ミルン、A.A.、「くまのプーさん」、様々な出版社。

     [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

[2] LAN記述はクラーク、D.D.他、「ローカル・エリア・ネットワークへの序論」に基づいています、IEEE Proc、V.66、N.11、1978年11月、ページ 1497-1517、数個の年のクラーク博士との会話の価値、および作者の開いている文学とOral Traditionの両方の観測、(どれが十分、そうかがよく考えた、MITRE社/NBS/NSA Localネット「脳の選択パネル」が持っているようにうながしました。

                                     7
     RFC 872                                            September 1982

7 RFC872 1982年9月

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

請求、彼がFACCのところで. *を使うことであった1年間の彼の証言)

     [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."

3 TCP/IP記述はDARPAインターネットProgramプロトコルSpecifications、1981年9月、10年以上のポステル博士、博士との会話の価値の上のUSC情報Sciences Instituteのポステル、J.B.、「インターネットプロトコル仕様」、および「転送管理仕様」に基づいています; TCP/IPデザインチームの数人の他のメンバーとの頻繁な議論と、PSTPのために参照をつけられたドキュメントを編集して、さらに言えば、アルパネット「規範モデル」の開発者のひとりであったことのクラーク(現在のDARPA「インターネット建築家」)とビントンG.サーフ博士(TCPの共同創始者)。

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

[4]Padlipsky、M.A.、「アルパネット規範モデルの上の見解」、M82-47、斜め継ぎ社、1982年9月。 また、Procでは、利用可能です。 INFOCOM83年。

     ________________
     *  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.)

________________ * 正直なところ、知っている限り、私はTCPがおまけにLANのための過剰殺傷であるかもしれないという噂を満たし始めました。 しかしながら、次のTCPデザインミーティングでは、彼らはTCPからIPを分離しました、そして、噂を殺させるのを除いて、すべてが現在、かれこれ3年の間問題ありません。 (私は、以下のことをそれが事実のためのものでなかったならねぐらについている鶏に変わるWoozlesに心配して、1 人々は、地元の導師を無視する傾向があって; 2 私はIP分離を奨励しようとしていました;、3 私が今までに欲しかったすべてがいくつかの実験によって得られるデータでした。)

     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.

以下に注意してください。 図1 要約、および図2で軍備してください。 以下のことのために書くことによって、ARMS(Somewhat Particularized)を入手するかもしれません。 マイクPadlipsky、MITRE社、私書箱208、ベッドフォード、マサチューセッツ、01730、またはコンピュータメールを Padlipsky@USC-ISIA に送ること。

                                     8

8