RFC635 日本語訳
0635 Assessment of ARPANET protocols. V. Cerf. April 1974. (Format: TXT=338, PDF=3208268 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Vinton G. Cerf Request for Comments: 635 Stanford University NIC: 30489
コメントを求めるワーキンググループビントンG.サーフの要求をネットワークでつないでください: 635 スタンフォード大学NIC: 30489
An Assessment of ARPANET Protocols
アルパネットプロトコルの査定
ABSTRACT
要約
This paper presents some theoretical and practical motivations for the redesign of the ARPANET communication protocols. Issues concerning multipacket messages, Host retransmission, duplicate detection, sequencing, and acknowledgment are discussed. Simplifications to the IMP/IMP protocol are proposed on the assumption that new Host level protocols are adopted. Familiarity with the current protocol designs is probably necessary since many of the arguments refer to details in the present protocol design.
この紙はアルパネット通信プロトコルの再設計に関するいくつかの理論上的、そして、実際的な動機を提示します。 「マルチ-パケット」メッセージ、Host retransmission、写し検出、配列、および承認に関する問題について議論します。 IMP/IMPプロトコルへの簡素化は新しいHost平らなプロトコルが採用されるという前提で提案されます。 議論の多くが現在のプロトコルデザインにおける詳細を示すので、現在のプロトコルデザインへの親しみがたぶん必要です。
[Page 0]
[0ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
Introduction.
序論。
The history of the Advanced Research Project Agency resource
sharing computer network (ARPANET) [6] is in many ways a history of
the study, development, and implementation of protocols. During the
early development of the network many important concepts were dis-
covered and introduced into the protocol design effort. Protocol
layering (functional separation of different levels of network trans-
mission), the notion of bilateral rendezvous to set up Host-to-Host
connections [l,2], and the definition of a Network Virtual Terminal
to aid in the specification of a Terminal-to-Host protocol [3,14] are
all examples of important early ideas. The tasks facing the ARPANET
design teams were often unclear, and frequently required agreements
which had never been contemplated before (e.g., common protocols to
permit different operating systems and hardware to communicate). The
success of the effort, seen in retrospect, is astonishing, and much
credit is due to those who were willing to commit themselves to the job
of putting the ARPANET together.
Advanced Research Project Agencyリソース・シェアリングコンピュータネットワーク(アルパネット)[6]の歴史は多くの方法でプロトコルの研究、開発、および実現の歴史です。 ネットワークの初期発生の間、多くの重要な概念が、不-カバーされ、プロトコルデザインの努力に取り入れられました。 Terminalからホストへのプロトコル[3、14]の仕様に基づき支援するプロトコルレイヤリング(異なったレベルのネットワークの機能分離を移-使節を務める)、Hostからホストとの接続に設定する双方のランデブーの概念[l、2]、およびNetwork Virtual Terminalの定義はすべて重要な早めの考えに関する例です。 アルパネットデザインチームに面しているタスクは、しばしば不明瞭であり、頻繁に以前一度も熟考されたことがなかった協定(例えば異なったオペレーティングシステムとハードウェアがコミュニケートすることを許可する一般的なプロトコル)を必要としました。 追憶で見られた努力の成功は驚異的です、そして、多くのクレジットがアルパネットをまとめる仕事に専念しても構わないと思っていた人のためです。
Over the intervening five years since the ARPANET was first begun,
we have learned a great deal about the design and behavior of the proto-
cols in use. The Imp-to-Imp protocol [4] has undergone continuous re-
vision, and the HOST/IMP interface specification [5] has been modified
slightly. In retrospect and in the light of experience, it seems
reasonable to reconsider some of the aspects of the designs and implemen-
tations currently in use. Furthermore, the rapid development of national
アルパネットが最初に始められて以来の介入している5年間、私たちは使用中のprotoあん部のデザインと振舞いに関して多くを学びました。 Impから悪童へのプロトコル[4]は連続した再ビジョンを受けました、そして、HOST/IMPインターフェース仕様[5]はわずかに変更されました。 追憶と経験の見地から、デザインと現在使用中のimplemen- tationsの局面のいくつかを再考するのは妥当に思えます。 その上、国家の急速現像
[Page 1]
[1ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
computer network projects around the world emphasizes the need for international cooperation in the design of communication protocols so that international connections can be accomplished.
世界中のコンピュータネットワークプロジェクトは、国際的な接続を実行できるように通信プロトコルのデザインへの国際協力の必要性を強調します。
This paper deals with the motivations for the redesign of the
HOST-to-HOST, IMP-to-IMP, and HOST/IMP communication protocols in the
ARPANET. Analyses of theoretical throughput and delay available from
existing protocols, and a discussion of some weaknesses in them, are
included.
この紙はアルパネットにおけるHOSTへのHOST、IMPへのIMP、およびHOST/IMP通信プロトコルの再設計に関する動機に対処します。 既存のプロトコルから利用可能な理論上のスループットと遅れの分析、およびそれらでのいくつかの弱点の議論は含まれています。
The basic conclusions reached in this report are:
このレポートで達した基本的な結論は以下の通りです。
a) Multipacket message facilities can be eliminated without loss
of potential throughput, and with a concurrent simplification of
IMP software. [8]
a) 潜在的スループットの損失なしでIMPソフトウェアの同時発生の簡素化でMultipacketメッセージ施設を排除できます。 [8]
b) Ordering by the destination IMP of messages delivered to a destina-
tion HOST can lead to a lockup condition similar to the reassembly
lockup experienced in an earlier version of the IMP protocol in
connection with multipacket message reassembly [7]. Hosts must
order arriving messages anyway, so the IMP need not do it.
b) destina- tion HOSTに渡されたメッセージの目的地IMPのそばで注文するのは「マルチ-パケット」メッセージ再アセンブリ[7]に関するIMPプロトコルの以前のバージョンで経験された再アセンブリ留置所と同様の留置所状態に通じることができます。 ホストがとにかく到着にメッセージを注文しなければならないので、IMPはそれをする必要はありません。
c) HOST/IMP protocol could be changed to allow arbitrarily long
messages to be sent from HOST to IMP, as long as the destination
IMP need not reassemble or re-order the arriving packets before
delivery to the HOST.
c) HOSTからIMPに送られるべき任意に長いメッセージを許容するためにHOST/IMPプロトコルを変えることができました、目的地IMPが配送の前に到着パケットをHOSTに組み立て直す必要はありませんし、また再注文する必要はない限り。
d) Host level retransmission, positive end-to-end acknowledgments,
error detection, duplicate detection, and message ordering, can
eliminate the need for many of these features in the IMP/IMP
protocol, and the Request for next Message (RFNM) facility in the
present HOST/IMP protocol.
d) 終わりから終わりへの承認(誤り検出)が検出、およびメッセージ注文をコピーするのを確信しているホストレベル「再-トランスミッション」はIMP/IMPプロトコル、およびRequestで現在のHOST/IMPプロトコルで隣のMessage(RFNM)施設にこれらの特徴の多くの必要性を排除できます。
[Page 2]
[2ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
e) The flow control mechanism in the current HOST-HOST protocol can
lose synchronization owing to message loss or duplication.
e) 現在のHOST-HOSTプロトコルのフロー制御メカニズムはメッセージの損失か複製による同期を失う場合があります。
f) Host level connections should be full duplex.
f) ホストレベル接続は全二重であるべきです。
g) The need for a separate HOST/HOST control connection can be
eliminated by carrying control information in the header of each
Host transmission.
g) それぞれのHostトランスミッションのヘッダーで制御情報を運ぶことによって、別々のHOST/HOSTコントロール接続の必要性を排除できます。
Throughput Considerations.
スループット問題。
In spite of the fact that the IMP subnet can deliver up to 80 kb/sec
between pairs of Hosts^, virtually no application using Host software
has achieved this figure. An experiment between Tinker and McClellan
Air Force Bases in 1971 achieved burst rates as high as 40 kb/sec, but
this was achieved by the use of a non-standard Host/Host protocol which
transmitted data over multiple logical connections, and which used Host
level re-assembly and acknowledgement to achieve reliable, ordered trans-
mission ^^. The following analysis shows that the current Host/Host
protocol cannot offer more than 40 kb/sec on a single connection owing
to message format overhead, and that this figure drops hyperbolically
if the communicating Hosts are separated by several IMPs.
IMPサブネットが最大80kb/秒をHosts^の組の間に送ることができるという事実にもかかわらず、実際にはHostソフトウェアを使用するどんなアプリケーションもこの図を実現していません。 1971年のTinkerとマクレラン空軍基地の間の実験は炸裂率を40kb/秒と同じくらい高く実現しました; しかし、これは、信頼できて、規則正しい移-任務^^を達成するために複数の論理的な接続の上にデータを送って、Hostの平らな再アセンブリと承認を使用した標準的でないHost/ホストプロトコルの使用で実現されました。以下の分析は、現在のHost/ホストプロトコルがメッセージ・フォーマットオーバーヘッドのために単独結合の40kb/秒以上を提供できないで、交信しているHostsが数個のIMPsによって切り離されるならこの図が大げさに低下するのを示します。
The single major reason for the distance (hop) dependent behavior
of Host/Host throughput is the "message-at-a-time" Host/Host
protocol. This means that, on a given connection between processes in
______________________________
^ Unpublished measurement experiments at UCLA run by R. Kahn and V.
Cerf confirmed this.
^^ Unpublished measurement data obtained by V. Cerf at the ARPA Network
Measurement Center, UCLA.
Host/ホストスループットの距離(飛び越す)の依存する振舞いのただ一つの主要な理由は「一度にメッセージ」Host/ホストプロトコルです。 これは過程の間の当然のことの関係のときに中でそれを意味します。______________________________ ^UCLAでの未発表の測定実験はR.カーンで走りました、そして、V.サーフはこれを確認しました。 ^^アーパネットMeasurementセンター、UCLAでV.サーフによって得られた未発表の測定データ。
[Page 3]
[3ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
the Hosts, only a single message ranging from 0-8063 bits of data can be outstanding at any moment. When the Host/Host protocol was originally designed, the IMPs provided up to 256 simplex 1ogical links between pairs of Hosts. If a message was sent over a link (there was a one to one relationship between a link and a connection), the link was blocked until a RFNM was received from the destination IMP indicating that the message had been delivered to the Host. Of course, the mechanism was protected by a time-out in case the RFNM failed to appear.
Hostsであり、0-8063 ビットのデータから変化するただ一つのメッセージだけがいつ何時、傑出している場合があります。 Host/ホストプロトコルが元々設計されたとき、IMPsは組のHostsの間の最大256個のシンプレクス1ogicalリンクを提供しました。 リンクの上にメッセージを送ったなら(リンクと接続との1〜1つの関係がありました)、メッセージがHostに渡されたのを示す目的地IMPからRFNMを受け取るまでリンクを妨げました。 もちろん、RFNMが欠場するといけなかったので、メカニズムはタイムアウトによって保護されました。
The IMP protocol has since been changed considerably and now permits
up to n messages^ to be outstanding between pairs of IMPs, regardless
of the links used and regardless of which Hosts are communicating.
IMPプロトコルは、以来かなり変えられていて、現在、組のIMPs、使用されるリンクにかかわらずどのHostsが交信する予定であるかおよびにかかわらず^が傑出していることをnメッセージまで許可します。
This last point means that there can be some interference among Hosts
connected to the same IMP if the Hosts are communicating with the same
destination IMP.
この最後のポイントは、Hostsが同じ目的地IMPとコミュニケートしているなら同じIMPに接続されたHostsの中に何らかの干渉があることができることを意味します。
The Host/Host protocol has not been changed to take advantage of the
possibility of multiple messages and is unable to achieve maximum possible
throughput. In figure 1, the time behavior of a multipacket message is
shown as it passes through several IMPs from source to destination.
Host/ホストプロトコルは、複数のメッセージの可能性を利用するために変えられていなくて、最大の可能なスループットを達成できません。 中では、1、それがソースから目的地まで数個のIMPsを通り抜けるとき「マルチ-パケット」メッセージの振舞いが示される時は計算します。
------------------------------------
IMP(0) | pkt(0) | pkt(1) | ... | pkt(m-1) |
------------------------------------
| | ------------------------------------
IMP(1) | | | pkt(0) | pkt(1) | ... | pkt(m-1) |
| | ------------------------------------
| | | :
| | | :
| | | ------------------------------------
IMP(h-1)| | | | pkt(0) | pkt(1) | ... | pkt(m-1) |
|<------>| |<- ------------------------------------
\ \
\ `---> propagation delay from IMPO to IMPl
`--> packet transmission delay
------------------------------------ 悪童(0)| pkt(0)| pkt(1)| ... | pkt(m-1)| ------------------------------------ | | ------------------------------------ 悪童(1)| | | pkt(0)| pkt(1)| ... | pkt(m-1)| | | ------------------------------------ | | | : | | | : | | | ------------------------------------ 悪童(h-1)| | | | pkt(0)| pkt(1)| ... | pkt(m-1)| | <、-、-、-、-、--、>| | <、- ------------------------------------ \ \ \ `--->伝播遅延、IMPOからIMPlまで、'-->パケット伝送は延着します'。
Packet handling by h IMPs for an m-packet message
mパケットメッセージのためのh IMPsによるパケット取り扱い
Figure 1
______________________________
^ currently four, this limit being imposed by IMP buffer space.
図1______________________________ ^現在のこの限界がIMPバッファ領域によって課される4。
[Page 4]
[4ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
Figure 1 is naive in several ways. First, it does not show any interfering traffic, nor have any packets gotten out of order or been routed on alternate paths. Second, all packets are assumed to be the same maximum size. Furthermore, the figure does not show the transmission delay to and from the Hosts. Thus, the results of the analysis will be slightly optimistic.
図1はいくつかの方法でナイーブです。 まず最初に少しの干渉交通も示さないで、どんなパケットも、故障するようになるか、または代替パスで発送されていません。 2番目に、すべてのパケットが同じ最大サイズであると思われます。 その上、図はHostsとHostsからトランスミッション遅れを示しません。 したがって、分析の結果はわずかに楽観的になるでしょう。
The logical connection between Hosts will be busy only for m packet
times out of h+m-l packet times. The source IMP will be busy for m
packet transmission times sending the message to a neighboring IMP. The
last bit of the first packet will arrive at the destination IMP after h
packet transmission times (not counting propagation delay) and the re-
maining m-1 packets will complete arrival after m-l packet transmission
times. The source Host will be permitted to transmit another message
after it receives a RFNM from the destination IMP. The RFNM is actually
sent after the message has been reassembled, the first packet has been
delivered, and the destination IMP has sufficient free buffer space for
another maximum length multipacket message.^ Thus a new transmission
cannot occur until h+m-1 packet times, at least, so the fraction of busy
time is just m/(h+m-l).
なるlパケット回数と忙しくするのにHostsの間の論理的な接続がh+mからのmパケット回数のためだけに。 ソースIMPはmのために隣接しているIMPにメッセージを送るパケット伝送回と忙しくするためにことになるでしょう。 最初のパケットの最後のビットはhパケット伝送回数(伝播遅延を数えない)の後の目的地IMPとm-lパケット伝送回数の後のm-1を再mainingするパケットが完成する到着に届くでしょう。 目的地IMPからRFNMを受けた後にソースHostが別のメッセージを送ることが許可されるでしょう。 メッセージを組み立て直した後に実際にRFNMを送って、最初のパケットを届けて、目的地IMPには. ^新しいトランスミッションがm-1h+パケット回まで起こることができないという別の最大の長さの「マルチ-パケット」メッセージThusに、十分な自由なバッファ領域があるので、繁忙期の部分はただ少なくとも、m/です(h+m-l)。
The actual bandwidth between IMPs is reduced from 50 kb^^ to 40 kb
by overhead bits needed for Host/Host, IMP/IMP control. IMPs send periodic
routing messages to all their neighbors (every .640 seconds)^^^ and these
consume further bandwidth. We can estimate the nominal fraction of 50 kb/sec
bandwidth available from source to destination IMP and multiply this by the
fractional busy time per connection to obtain an optimistic bound on maximum
throughput per connection.
______________________________
^ If after 1 second no space is available, the RFNM is sent anyway.
^^ Some IMPs have 230 kb/sec lines, or 9.6 kb/sec, but most have 50 kb/sec.
^^^This interval is a function of line speed and load and may be as low as 128 ms.
IMPsの間の実際の帯域幅はHost/ホスト(IMP/IMPコントロール)に必要である頭上のビットによって50kb^^から40kbに変えられます。 IMPsはそれらのすべての隣人(.640秒毎)^^^に周期的なルーティング・メッセージを送ります、そして、これらは一層の帯域幅を消費します。 私たちは、50kb/秒の間のソースから目的地IMPまで利用可能な帯域幅の名目上の部分を見積もって、1接続あたりの最大のスループットで楽観的なバウンドを得るために1接続あたりの断片的な繁忙期をこれに掛けることができます。 ______________________________ ^どんなスペースも1秒後に利用可能でないなら、とにかくRFNMを送ります。 ^^いくつかのIMPsには、50kb/秒は、230のkb/秒の線、または9.6kb/秒持っていますが、最もあります。 ^^^この間隔は、ライン・スピードの関数であり、ロードして、128原稿と同じくらい低いかもしれません。
[Page 5]
[5ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
Analysis of Expected Throughput Bounds.
予想されたスループットの分析はバウンドしています。
Let T be the number of bits of text to be transmitted by a Host
whose natural word length is W bits. The Host/Host message format
includes a 32 bit leader followed by a 40 bit prefix, followed by the
text to be sent. We will assume that a sending Host will transmit an
integral number of its words, including the 72 bits preceding the text
of the message. Furthermore, the Host/IMP interface appends a one bit
to each message, followed by as many zeroes as are needed to make the
ensemble an integral number of 16 bit IMP words (the IMP is a Honeywell
316 or 516 computer).
Tがテキストのビットの数であることをさせて、自然な語長がWビットであるHostによって伝えられてください。 Host/ホストメッセージ・フォーマットは32ビットのリーダーを含んでいます、続いて40ビットの接頭語を含んでいます、続いて、送られるテキストを含んでいます。 私たちは、送付Hostが単語の整数を伝えると思うつもりです、メッセージの本文に先行する72ビットを含んでいて。 その上、Host/IMPインタフェースはアンサンブルを整数の16ビットのIMP単語にするのが必要であるのと同じくらい多くのゼロがあとに続いた各メッセージに1ビット添えます(IMPはハネウェル316か516コンピュータです)。
The total number of bits in a Host message whose text contains T
bits is given by equation 1.
方程式1でテキストがTビットを含むHostメッセージのビットの総数を与えます。
M(T,W) = B1 (T) + B2 (T,W) + B3(T,W) (1)
where B1(T) = T + 72
B1(T)がT+72と等しいB1(T)+B2(T、W)+B3(T、W)M(T、W)=(1)
B2(T,W) = - B1(T) mod W
B2(T、W)=--B1(T)モッズW
B3(T,W) = 1 + (-B1(T) - B2(T,W) - 1) mod 16
B3(T、W)=1+(-B1(T)--B2(T、W)--1)モッズ風の16
B1(T) is the number of bits in the Host message including leader,
prefix, and text. B2(T,W) is the number of bits needed to make B1(T)
an integral number of Host words, and B3(T,W) is the number of bits needed
to make the total an integral number of 16 bit IMP words.
B1(T)はリーダー、接頭語、およびテキストを含むHostメッセージのビットの数です。 B2(T、W)はB1(T)をHost単語の整数にするのが必要であるビットの数です、そして、B3(T、W)は合計を整数の16ビットのIMP単語にするのが必要であるビットの数です。
The M(T, W) bits are converted to packets in the following
way. The 32 bit leader is removed and the remaining words are divided
into packets containing no more than 1008 bits of data, each preceded
by an 96 bit header which includes the data from the 32 bit leader. When
these packets are transmitted to a neighboring IMP, they are enclosed
M(T、W)ビットは以下の方法でパケットに変換されます。 32ビットのリーダーを免職します、そして、残っている単語をデータの1008ビットだけを含むパケットに分割します、32ビットのリーダーからのデータを含んでいる96ビットのヘッダーによって先行されたそれぞれ。 これらのパケットが隣接しているIMPに伝えられるとき、それらは同封されています。
[Page 6]
[6ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
in a line control envelope consisting of 48 bits of control octets and a 24 bit cyclic checksum. We can compute the number of bits required to carry all the packets as follows:
並んで、コントロール八重奏の48ビットと24ビットの周期的なチェックサムの封筒の成ることを制御してください。 私たちは以下のすべてのパケットを運ばなければならなかったビットの数を計算できます:
P(T,W) =( (M(T,W)-33)/1008 + 1 ) x 168 + M(T,W) - 32 (2)
P(T、W)=((M(T、W)-33)/1008+1)x168+M(T、W)--32(2)
The line transmission efficiency when transmitting T bits of Host
text is given by.
Hostテキストの伝わっているTビットであるときに、線伝達効率を与えます。
LTE(T,W) = T/P(T,W) (3)
LTE(T、W)はT/P(T、W)と等しいです。(3)
The expected fraction of time a logical link, which is H hops long,
can be busy carrying a Host message of T text bits is given by
論理的なリンク(長い間、Hホップである)がビットが与えられるTテキストに関するHostメッセージを伝えることで忙しい場合がある時の予想された部分
P(T,W)
EBF(T,W,H) = _____________________________
H*min[P(T,W) , 1176]+ max [P(T,W)-1176 ,0] (4)
P(T、W)EBF(T、W、H)=_____________________________ H*分[P(T、W)、1176]+最大[P(T、W)-1176、0](4)
EBF(T,W,H) is a refinement of the fraction computed earlier (m/(m+h-1)).
EBF(T、W、H)は、より早く計算された断片(m/(m+h-1))の気品です。
The numerator of EBF(T,W,H) is just the number of bits which must be
transmitted from the source IMP. The denominator uses the min and max
functions to deal with the case that a message is less than a full single
packet in length. In any case, it takes H hops to deliver the first
packet, and the remaining bits follow this packet until the entire message
has arrived at the destination IMP. (Note that DLE may be doubled on the
line so that this calculation assumes 'DLE' never sent as data.)
EBF(T、W、H)の分子はソースIMPから伝えなければならないビットの数です。 分母は長さにメッセージが完全な単一のパケット以下であるというケースとの取引に分と最大機能を使用します。 どのような場合でも、最初のパケットを届けるのにHホップを要します、そして、全体のメッセージが目的地IMPに到着するまで、残っているビットはこのパケットに続きます。 (この計算が、'DLE'がデータとして決して送られないと仮定するように、DLEが線の上で倍にされるかもしれないことに注意してください。)
The routing messages require 1024 bits of text and 136 bits of packet
header and line control, and are sent by each IMP to all its adjacent
neighbors every .640 seconds. The bandwidth required for routing messages
is thus (1160)/.640 = 1.8 kb/sec.
ルーティング・メッセージは、テキストの1024ビットとパケットのヘッダーとライン制御の136ビットを必要として、.640秒毎に各IMPによってすべての隣接している隣人に送られます。 その結果、ルーティング・メッセージに必要である帯域幅は=1.8kb/秒(1160)/.640です。
Thus the bandwidth which can be expected for Host messages containing
T text bits, sent over H hops, is expressed in equation (5) below.
したがって、Hホップの上に送られたTテキストビットを含むHostメッセージのために予想できる帯域幅は以下の方程式(5)で言い表されます。
B(T,W,H) = EBF(T,W,H) x LTE(T,W) x (50-1.8) kb/sec (5)
B(T、W、H)=EBF(T、W、H)x LTE(T、W)x(50-1.8)kb/秒(5)
B(T,W,H) ignores a number of complicating factors:
B(T、W、H)は多くの複雑にする要素を無視します:
[Page 7]
[7ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
a) delay for sending RFNM and implicit space reservation for
multipacket messages to source IMP.
a) 「マルチ-パケット」メッセージのRFNMと暗黙の宇宙の予約をソースIMPに送るには、延着してください。
b) propagation delays between Host/IMP and IMP/IMP
Host/IMPとIMP/IMPの間のb)伝播遅延
c) queueing delays at intermediate IMPs
中間的IMPsのc)待ち行列遅れ
d) retransmission delays
Nevertheless, B(T,W,H) offers an optimistic estimate of the bandwidth
that can be expected using the current ARPANET Host/Host protocol.
d)「再-トランスミッション」遅れNevertheless、B(T、W、H)は現在のアルパネットHost/ホストプロトコルを使用することで予想できる帯域幅の楽観値を提供します。
There is an implicit assumption that packets of a multipacket message
are not sent over alternate routes (e.g., two 50 kb/sec paths). Since
alternate routing in the IMP subnet is used to avoid congested areas
and not to improve bandwidth, this assumption is probably valid for the
low traffic densities presently found in the ARPANET.
「マルチ-パケット」メッセージのパケットが代替経路の上に送られないという暗黙の仮定(例えば、50kb/秒の2つの経路)があります。 IMPサブネットにおける迂回中継が過密地域を避けて、帯域幅を改良しないように使用されるので、現在アルパネットで見つけられている低交通密度には、この仮定はたぶん有効です。
B(T,W,H) has been plotted in figure 2 for a 32 bit Host (W=32), and
a range of message text lengths and Hops. As can be seen, the effect
of single message at a time transmission on a single logical connection
is very marked for longer and longer hops. The curves would be even
lower in the case of a satellite channel owing to the long propagation
delay (1/4 second up and down) for both the message and the returning RFNM.
B(T、W、H)はさまざまな図の32ビットのHost(W=32)のための2、メッセージ・テキストの長さ、およびホップスで企まれました。 見ることができるように、ただ一つのメッセージの効果はシングルにおける論理的な接続が、より長い間非常に著しい時間送信においてより長い間、跳びます。 長い伝播遅延(上下に1/4秒)のために、カーブはメッセージと戻っているRFNMの両方のために衛星チャンネルの場合で低くさえあるでしょう。
[Page 8]
[8ページ]
42 ||
||
40 |||
|||
38 |||8
1||78
36 12|78
12||78
34 123|678
123456 78
32 1 23456 78
1 2 3456 78
30 1 2 3 45 6 7 8
1 2 3 45 6 7 8
28 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
26 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
24 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
22 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
20 1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 (8 Packets, 7992 bits)
18 1 2 3 4 5 6 7 (7 Packets, 7000 bits)
1 2 3 4 5 6 (6 Packets, 5976 bits)
16 1 2 3 4 5
1 2 3 4 5 (5 Packets, 4984 bits)
14 1 2 3 4
1 2 3 4 (4 Packets, 3960 bits)
12 1 2 3
1 2 3 (3 Packets, 2968 bits)
10 1 2
1 2
8 2 (2 Packets, 1944 bits)
1
6
1
4 1 (1 Packet, 952 bits)
42 || || 40 ||| ||| 38 |||8 1||78 36 12|78 12||78 34 123|678、123456 78 32、1、23456 78、1 2、3456 78 30、1 2 3、45、6 7 8 1 2 3、45、6 7 8、28、1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8、26、1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8、24、1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8、22、1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8、20、1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8(8つのパケット、7992ビット); 18 1 2 3 4 5 6 7(7つのパケット、7000ビット)1 2 3 4 5 6(6Packets、5976ビット)16 1 2 3 4 5 1 2 3 4 5(5Packets、4984ビット)14 1 2 3 4 1 2 3 4(4Packets、3960ビット)12 1 2 3 1 2 3(3Packets、2968ビット)10 1 2 1 2 8 2(2Packets、1944ビット)1 6 1 4 1(1つのパケット、952ビット)
2 1 2 3 4 5 6 7 8 9 10
2 1 2 3 4 5 6 7 8 9 10
Number of Hops
ホップスの数
Single Link Source to Destination Host Throughput (32 bit word Host)
Figure 2
Destination Host Throughput(32ビットの単語Host)数値2への独身のLink Source
[Page 9]
[9ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
The Multipacket Message Issue.
Multipacketメッセージ問題。
The original IMP system permitted only one message at a time on a
single link, and thus some means was needed to allow for higher bandwidth
than single packet messages could provide. This was achieved, to some
extent, by permitting up to eight packets in a single message.
オリジナルのIMPシステムは単一のリンクの上に一度に1つのメッセージだけを可能にしました、そして、その結果、いくつかの手段が、ただ一つのパケットメッセージが提供できたより高い帯域幅を考慮するのに必要でした。 これは、ただ一つのメッセージの最大8つのパケットを可能にすることによって、ある程度達成されました。
It was soon discovered, however, that a Host transmitting multipackets
on separate logical links could cause a lockup condition at the destination,
and was first described by R. Kahn and W. Crowther [7].^ Essentially,
inadequate space might exist at the destination to reassemble all multi-
packets in transit on several links. The condition was self-sustaining
if the Host continued transmission, although the destination could
discard unassembled multipackets after a time-out. The condition either
backed up into the rest of the network, or at best caused loss of
messages in the network.
しかしながら、すぐ、別々の論理的なリンクの上に「マルチ-パケット」を伝えるHostが目的地で留置所状態を引き起こしたかもしれなくて、最初にR.カーンとW.クラウザー[7]によって説明されたと発見されました。^Essentially、不十分なスペースは、数個のリンクの上にトランジットですべてのマルチパケットを組み立て直すために目的地に存在するかもしれません。 目的地はタイムアウトの後にunassembled multipacketsを捨てることができましたが、Hostがトランスミッションを続けていたなら、状態は自己持続型でした。 ネットワークの残りに支援されるか、またはネットワークのメッセージの損失がせいぜい引き起こされた状態。
The solution to the multipacket reassembly lockup problem that was
eventually implemented required the source IMP to reserve reassembly
buffer space at the destination IMP before transmitting the multipacket.
結局実行されたmultipacket reassembly留置所問題の解決は、「マルチ-パケット」を伝える前にソースIMPが目的地IMPで再アセンブリバッファ領域を予約するのを必要としました。
Actually, this problem is just a case of a more general problem which can
be caused by the destination IMP sequencing of messages delivered to the
Host.
実際に、この問題はただHostに渡されたメッセージの目的地IMP配列で引き起こされる場合があるより一般的な問題に関するケースです。
Ordering of Messages.
メッセージを注文します。
The IMP system guarantees that messages wi1l be delivered to a
destination Host in the same order that they left a source Host. This
service can cause a lockup similar to reassembly lockup if enough messages
arc in transit to the destination IMP. Single packet messages are sent
without prior reservation to the destination and, if space is available
for them, a RFNM is returned to the source IMP. In the event that no
______________________________
^ Kahn actually knew in 1967 that the condition could occur, but was unable
to convince his colleagues until he actually locked up the network by using
a message generator to flood the network in March, 1970.
IMPシステムは、メッセージwi1lがそれらがソースHostを残した同次で目的地Hostに渡されるのを保証します。 このサービスは目的地IMPへのトランジットにおける十分なメッセージアークであるなら留置所を再アセンブリするように同様の留置所を引き起こす場合があります。 先の予約なしでただ一つのパケットメッセージを目的地に送ります、そして、スペースがそれらに利用可能であるなら、ソースIMPにRFNMを返します。 no______________________________ ^カーンは、1967年に状態が起こることができましたが、1970年3月にネットワークをあふれさせるのにメッセージジェネレータを使用することによって彼が実際にネットワークに鍵をかけたとき初めて彼の同僚に納得させることができるのを実際に知っていました。
[Page 10]
[10ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
room is available, an implicit reservation request is queued at the destination IMP. When space is available, an allocation message is sent to the source IMP which retransmits the single packet message. The source IMP keeps a copy of the single packet message for retransmission until it either receives a RFNM from the first copy transmitted or an allocate message indicating that there is now room available for a second copy to be accepted.^
余地が利用可能である、暗黙の予約の要請は目的地IMPに列に並ばせられます。 スペースが利用可能であるときに、ただ一つのパケットメッセージを再送するソースIMPに配分メッセージを送ります。 または、伝えられた第一刷からRFNMを受けるまでソースIMPが「再-トランスミッション」に、ただ一つのパケットメッセージの写しを取っておく、2番目のコピーを受け入れるために利用可能な余地が現在あるのを示すメッセージを割り当ててください、^
This scheme can fail if either a given Host has too many messages in transit, or if many Hosts, served by different IMPs, have too many messages in transit for the same destination. This is so because the destination IMP will accept packets which arrive out of order and buffers them until they can be re-ordered for transmission to the destination Host.
与えられたHostがトランジットであまりに多くのメッセージを持っているか、または異なったIMPsによって役立たれた多くのHostsが同じ目的地のためのトランジットであまりに多くのメッセージを持っているなら、この計画は失敗できます。 これは、したがって、目的地IMPが、到着するパケットが故障していると受け入れるのでであるそれらが目的地への伝送のため再命令されたHostであるかもしれないまでそれらをバッファリングします。
Presently, a source IMP only permits up to four messages (regardless
of length) to be in transit for a given destination at a time. This
essentially reduces the probability of a lockup, but it is not zero,
since sufficient messages may be outstanding from different IMPs for the
same destination to cause a lockup.
現在、ソースIMPは、最大4つのメッセージ(長さにかかわらず)が一度に与えられた目的地のためのトランジット中であることを可能にするだけです。 これは留置所の確率を本質的には減少させますが、それはゼロではありません、同じ目的地が留置所を引き起こすように十分なメッセージが異なったIMPsから傑出しているかもしれないので。
Such lockups are protected against as well, by timing out undelivered
messages at the destination and discarding them. The timeout is on the
order of tens of seconds. Even though the IMP subnet can recover from
such conditions, it is apparent that Hosts must be prepared to retransmit
messages occasionally to recover from message loss caused by deliberate
discarding of messages at the destination or by catastrophic failures in
which an IMP loses all its packets upon crashing.
______________________________
^ R. Kahn, L. Kleinrock, and H. Opderbeck point out that IMPs do not accept
out-of-order packets, but do send allocates back for them. If room is also
allocated for unreceived but anticipated in-order packets, no lockup will
occur. If this step is omitted, then the implementation may fail.
そのような留置所は、タイミングで良い状態で守られて、目的地のメッセージが外で「非-渡」したということであり、それらを捨てています。 何十秒もの注文にはタイムアウトがあります。 IMPサブネットはそのような状態から回復できますが、クラッシュのときに目的地のメッセージを慎重な捨てるかIMPがすべてのパケットを失う突発故障によって引き起こされたメッセージの損失から回復するために時折メッセージを再送するようにHostsを準備しなければならないのは明らかです。 ______________________________ ^R.カーン、L.クラインロック、およびH.Opderbeckは、IMPsが故障しているパケットを受け入れませんが、発信すると指摘します。それらのために、割り当てて戻します。 また、オーダーにおける非落手されましたが、予期されたパケットのために余地を割り当てると、留置所は全く現れないでしょう。 このステップが省略されるなら、実現は失敗するかもしれません。
[Page 11]
[11ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
Host Retransmission, Sequencing, and Duplicate Detection.
Retransmission、配列、および写し検出を主催してください。
The Host/Host protocol docs not provide for retransmission. If it
did, however, then this would require that the destination Host detect
duplicate transmissions and also verify sequencing of arriving messages
since the destination IMP cannot, in the current scheme, detect that a
Host has sent a duplicate message.
Host/ホストプロトコルdocsは「再-トランスミッション」に備えません。 しかしながら、するなら、これは、目的地Hostが写し送信を検出して、また、Hostが写しメッセージを送った目的地IMP以来のメッセージが現在の計画で検出できない到着の配列について確かめるのを必要とするでしょうに。
If this line of reasoning is pursued, it becomes evident that
sequencing of messages by the destination IMP is redundant and could be
eliminated. Furthermore, with the elimination of ordering, multipacket
messages could also be eliminated so long as Hosts were permitted to
transmit a sufficient number of single packet messages to achieve maximum
potential bandwidth.
推理のこの線が追求されるなら、目的地IMPによるメッセージの配列は余分であり、排除できたのは明白になります。 その上、また、注文の除去で、Hostsが最大の潜在的帯域幅を達成するただ一つのパケットメッセージの十分な数を伝えることが許可された限り、「マルチ-パケット」メッセージを排除できました。
Along with Host retransmission, it is necessary to introduce some
kind of end-to-end positive acknowledgment. The RFNM is currently sent
by the destination IMP to the source Host and is taken to mean that a
message has been successfully delivered to the destination Host (for
multipacket messages, the RFNM is sent after the first packet has been
delivered). It seems sensible to arrange a Host level acknowledgment
which confirms delivery. In this case, the RFNM could also be eliminated.
Host retransmissionと共に、終わりから終わりへのある種の肯定応答を導入するのが必要です。 RFNMは、現在、目的地IMPによってソースHostに送られて、メッセージが首尾よく目的地Hostに渡されたことを意味するために連れて行かれます(「マルチ-パケット」メッセージに関して、最初のパケットを届けた後にRFNMを送ります)。 配送を確認するHostの平らな承認をアレンジするのは分別があるように思えます。 また、この場合、RFNMを排除できました。
One might use RFNM's optionally as a debugging tool, to be turned off
and on at will.
1つは、断続的に自由自在にターンされるのにデバッグ用ツールとして任意にRFNMのものを使用するかもしれません。
Statistics taken from the ARPANET indicate that Host retransmission
would rarely be required on account of message loss, but this is partly
because of the retransmission and reservation facilities in the current
IMP system.
アルパネットから取られた統計は、Host retransmissionはメッセージの損失のためにめったに必要でないでしょうが、これが一部「再-トランスミッション」と予約施設のためにそうであることを現在のIMPシステムで示します。
[Page 12]
[12ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
Flow Control.
フロー制御。
If all end-to-end retransmission, duplicate, detection, and sequencing
are performed by Hosts, then it is essential that the source and destina-
tion Hosts agree upon a maximum number of packets (or bits, octets, etc.)
that can be outstanding at one time. Otherwise, the destination Host
may experience lockup problems similar to those found now in the destination
IMP.
すべての終わりから終わりへの「再-トランスミッション」、写し、検出、および配列がHostsによって実行されるなら、ソースとdestina- tion Hostsが最大数のひところ傑出する場合があるパケット(または、ビット、八重奏など)に同意するのは、不可欠です。 さもなければ、目的地Hostは今目的地IMPで見つけられたものと同様の留置所問題を経験するかもしれません。
The current Host/Host flow control scheme has several weaknesses.
現在のHost/ホストフロー制御計画には、いくつかの弱点があります。
First, it requires that special control messages be sent on a control
connection which is distinct from the connection on which data is transmitted.
まず最初に、それは、特別なコントロールメッセージがデータが送られる接続と異なったコントロール接続に送られるのを必要とします。
Second, it is an incremental scheme in which the destination Host allocates
a certain number of bits and messages which may be sent by the source.
2番目に、ソースによって送られるかもしれないのは、目的地Hostが、ある数のビットとメッセージを割り当てる増加の計画です。
Both source and destination Hosts decrement these counts as messages are
sent and received. To maintain throughput, the destination must periodi-
cally send allocations to the source to replenish its available buffer
space. Destinations with small amount of buffer space (e.g., Terminal
IMPs or TIPs) must do this fairly frequently and thus generate considerable
control traffic. Third, the loss of an allocation or the duplication of
one can cause loss of synchrony between source and destination.
ソースと目的地Hostsの両方がメッセージを送って、受け取るようにこれらのカウントを減少させます。 スループットを維持するために、目的地は警察署が利用可能なバッファ領域を補給するためにソースへの配分を送るperiodiがそうしなければなりません。 少量のバッファ領域(例えば、Terminal IMPsかTIPs)がある目的地は、かなり頻繁にこれをして、その結果、かなりのコントロール交通を発生させなければなりません。 3番目に、配分の損失か1の複製が、ソースと目的地の間の同期の損失をもたらすことができます。
In an earlier paper [9], the author and R. Kahn propose a more robust
flow control scheme including ideas found in the French CYCLADES network
[10]. Essentially, the receiver allocates a window representing the span
of sequence numbers that the sender may transmit. Acknowledgments from
the receiver to the sender indicate the largest sequence number received
so far (implicitly acknowledging all those preceding), and also indicate
the .current width of the window. The sender immediately knows which sequence
以前の紙[9]では、作者とR.カーンはフランスのキクラデス諸島ネットワーク[10]で見つけられた考えを含むより強健なフロー制御計画を提案します。 本質的には、受信機は送付者が伝えるかもしれない一連番号の長さを表す窓を割り当てます。 受信機から送付者までの承認は、今までのところ(それとなく、すべての前のそれらを承認する)受け取られている中で最も大きい一連番号を示して、また、窓の.current幅を示します。 送付者はすぐに、どの系列を知っているか。
[Page 13]
[13ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
numbers can be sent next. The scheme also allows for duplicate detection and reordering of messages.
次に、数を送ることができます。 また、計画はメッセージに関する写し検出と再命令を考慮します。
Acknowledgment and flow control information' is sent "piggy-back"
with data flowing in the reverse direction of a full duplex logical
connection so that a separate control connection is not needed for this
purpose. For example, a message is sent with sequence number M and
length L in octets. The receiver will respond with acknowledgment of
sequence number M+L and window size W. The sequence number of each
message is the sequence number of the previous message plus its length
in octets.
データが全二重の論理的な接続の反対の方向に流れていて、別々のコントロール接続はこのために必要でないように、'承認とフロー制御情報'に「ピギーバック」を送ります。 例えば、一連番号Mと長さLと共に八重奏でメッセージを送ります。 受信機は一連番号M+LとウィンドウサイズW.の承認で応じるでしょう。それぞれのメッセージの一連番号は、前のメッセージの一連番号と八重奏でその長さです。
The receiver can vary the size of W without any serious adverse
effect, and can survive the receipt of duplicates or the loss of messages
due to the retransmission and duplicate detection permitted by the scheme.
受信機は、少しも重大な悪影響なしでWのサイズを変えることができて、「再-トランスミッション」のため写しの領収書かメッセージの損失を乗り切っていて、計画によって受入れられた検出をコピーできます。
The sender is not permitted to transmit a message whose sequence number
would exceed the sum of the last sequence number acknowledged plus the
current window size, W, modulo the maximum sequence number plus one.
Arbitrary Message Lengths.
送付者はW、送信することは許可されていなくて、だれの一連番号が最後の一連番号を超えているだろうかがそのうえ、現在のウィンドウサイズを承認して、法が最大の一連番号と1であるということです。 任意のメッセージ長。
Until now, it has been implicit that multipacket messages are unneces-
sary for maintaining high throughput, as long as sufficient packets can
be sent to fill the delay pipeline from source to destination Host. If
the IMP system were programmed with knowledge of the Host/Host protocol
so that it could create a properly formatted Host/Host header for each
packet it transmits, given the initial header of an arbitrarily long
message, then packets could be delivered out of order to the destination
Host, so long as each correctly identified the range of sequence numbers
contained in each packet. Since each octet of a message has an implicit
sequence number, this would not be difficult to compute. An idea similar
現在まで、「マルチ-パケット」メッセージが高生産性を維持するためのunneces- saryであることは内在しています、ソースから目的地Hostまで遅れパイプラインをいっぱいにするために十分なパケットを送ることができる限り。 目的地Hostに故障していた状態でパケットを届けることができました、IMPシステムが任意に長いメッセージの初期のヘッダーを考えて、伝える各パケットのために適切にフォーマットされたHost/ホストヘッダーを創造できるようにHost/ホストプロトコルに関する知識でプログラムされたならそれぞれが正しく各パケットに含まれた一連番号の範囲を特定した限り。 メッセージの各八重奏には暗黙の一連番号があるので、これは計算するのが難しくないでしょう。 考え同様
[Page 14]
[14ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
to this is found in the Very Distant Host Reliable Transmission Package: [appendix F, 5] in the current ARPANET, except in this case, a Host must know about IMP packet format. It is debatable whether this would be a good idea, since changes in Host/Host protocol would require changes in IMP programming, but if it were implemented, then Hosts could send arbitrarily long messages. The destination Host would receive a collec- tion of single packet messages which it would then sequence as if they had been sent that way by the source Host in the first place.
Very Distant Host Reliable Transmissionパッケージでこれに見つけられます: [付録F、この場合Host以外の現在のアルパネットにおける5は]IMPパケット・フォーマットに関して知らなければなりません。 Host/ホストプロトコルにおける変化がIMPプログラミングで釣り銭がいるでしょうが、それが実行されるならHostsが任意に長いメッセージを送るかもしれないので、それはこれが名案であるだろうか否かに関係なく、論争の余地があります。 まるでそれらが第一にそのようにソースHostによって送られたかのように目的地Hostは次にそれが配列するただ一つのパケットメッセージのcollec- tionを受けるでしょう。
Simplex versus Full-Duplex Logical Connections
The present Host/Host protocol implements simplex connections. The
usage over the last five years seems to indicate that most often, two
simplex connections are set up to act as a full duplex connection.
シンプレクス対現在のHost/ホストが議定書の中で述べるFull-デュプレックスLogicalコネクションズはシンプレクス接続を実行します。 ここ5年間の用法はたいてい、2つのシンプレクス接続が全二重接続として機能するようにセットアップされるのを示すように思えます。
If Host level acknowledgments and flow control are implemented, then it
is natural for them to be carried in the reverse direction of a full
duplex logical connection. Furthermore, terminal to Host connections
are necessarily full-duplex to allow for data to move in both directions.
Hostの平らな承認とフロー制御が実行されるなら、それらが全二重の論理的な接続の反対の方向に運ばれるのは、当然です。 その上、Host接続への端末は必ずデータが両方の指示に入って来るのを許容する全二重です。
Finally, by embedding control in the headers of returning traffic on the
full duplex connection, the need for a separate control connection could
be eliminated.
最終的に、全二重接続における戻っている交通のヘッダーにコントロールを埋め込むことによって、別々のコントロール接続の必要性を排除できるでしょう。
Connection Set-up.
接続セットアップ。
The current Host/Host protocol uses control messages sent on a special control connection to establish new connections,. The procedure is called the Initial Connection Protocol or ICP [11]. The protocol is symmetric and requires that information be exchanged by both Hosts as to the names of the sockets at either end of the connection. This exchange precedes any flow of data. Other control messages are exchanged which determine the buffer space available at the receiver.
コントロールメッセージが新しい接続を証明するために特別なコントロール接続に送った現在のHost/ホストプロトコル用途. 手順はInitial ConnectionプロトコルかICP[11]と呼ばれます。 プロトコルは、左右対称であり、情報がソケットの名前に関して両方のHostsによって接続のどちらの終わりとも交換されるのを必要とします。 この交換はデータのどんな流れにも先行します。 受信機で利用可能なバッファ領域を決定する他のコントロールメッセージを交換します。
[Page 15]
[15ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
A proposal by D. Walden [12] suggests that this is largely unnecessary,
as long as both sides can simultaneously send data identifying the source
and destination sockets (Walden calls them Ports) along with the text of
the messages.
D.ウォルデン[12]による提案は、これが主に不要であると示唆します、データが同時に両側で、メッセージのテキストに伴うソースと目的地ソケット(ウォルデンは、それらをPortsと呼ぶ)を特定できる限り。
A post office analogy is useful to describe what is intended. The
source Host writes a letter and encloses it in an envelope addressed to
the destination port with a return port address. Either the destination
port is willing to receive or it is not (e.g. it may not even be known
to the destination Host). In the former case, the letter is acknowledged
in the usual fashion. In the latter case, the letter is not acknowledged
(port unprepared to receive), or it is rejected ("address unknown").
郵便局類推は、意図することについて説明するために役に立ちます。 ソースHostはリターンポートアドレスがある仕向港に記述された封筒に、手紙を書いて、それを同封します。 仕向港が、受信しても構わないと思っているか、または思っていません(例えばそれは目的地Hostにおいて知られてさえいないかもしれません)。 前の場合では、手紙は普通のファッションで受け取ったことを知らせられます。 後者の場合では、手紙が受け取ったことを知らせられないか(受けるために用意ができていていないポート)、またはそれは拒絶されます(「住所不明」)。
Since port addresses may be dynamically assigned to processes in a
destination Host, it will probably be necessary to include a formal con-
trol exchange which indicates to the sender that a receive port is being
closed, and the sender would be expected to acknowledge this. Similarly,
the sender may end a transmission with the indication that the send port
is being closed and the receiver would similarly acknowledge. Since
Hosts do the sequencing, there can be no confusion as to when the closure
is to take place. The rejection of an initial transmission can be made
to look like the closure of the destination port so that the number of
distinct control messages can be kept to a minimum. This method is
similar to the one currently used in the ARPANET, but could be carried
out via control bits in the Host level messages and thus eliminate the
need for a special control connection.
ポートアドレスがダイナミックにaの目的地Hostの過程に割り当てられるかもしれないので、aがポートを受けるのを送付者に示す正式なまやかしtrol交換が終えられていて、送付者がこれを承認すると予想されるのがたぶんインクルードに必要になるでしょう。 同様に、送付者が指示でトランスミッションを終わらせるかもしれない、それ、閉じられて、受信機が同様に承認するポートを送ってください。 Hostsが配列するので、閉鎖が行われることになっている時に関して混乱が全くあるはずがありません。 異なったコントロールメッセージの数を最小限に保つことができるように仕向港の閉鎖に似ているのを初期のトランスミッションの拒絶をすることができます。 この方法は現在アルパネットに使用されているものと同様です、Hostの平らなメッセージのコントロールビットで行われて、その結果、特別なコントロール接続の必要性を排除できました。
[Page 16]
[16ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
Summary.
概要。
Arguments have been presented in this paper which show that multi-
packet reassembly is not the best vehicle for achieving high throughput
from Host to Host. The elimination of IMP reassembly as well as message
sequencing by the destination IMP can permit considerable simplification
of the IMP protocols, while simultaneously placing the. burden of buffering,
duplicate detection, and sequencing of messages on the Hosts which have
the buffer space for this purpose.
議論はこの論文に示されました(マルチパケット再アセンブリがHostからHostまで高生産性を達成するための最も良い乗り物でないことを示します)。 目的地IMPによるメッセージ配列と同様にIMP reassemblyの除去が同時に入賞する間、IMPプロトコルのかなりの簡素化を可能にすることができる. このためにバッファ領域を持っているHostsでのバッファリングの負担と、写し検出と、メッセージの配列。
Arbitrarily long messages could be sent by Hosts, at the expense of
IMP knowledge of Host protocol. Eliminating the ordering requirement
at the destination IMP also eliminates serious potential lockup conditions.
任意に長いメッセージはHostプロトコルに関するIMP知識を犠牲にしてHostsによって送られるかもしれません。 また、目的地IMPで注文要件を排除すると、重大な潜在的留置所状態は排除されます。
Host level positive acknowledgments can eliminate the erroneous use
of the RFNM for this purpose, and permit a more robust protocol which
need not depend upon perfect performance without message loss by the
IMP subnet.
承認がこのためにRFNMの誤った使用を排除できるのを確信しているレベルを接待してください、そして、IMPサブネットでメッセージの損失なしで完全な性能に依存する必要はないより強健なプロトコルを可能にしてください。
Full duplex logical connections between ports in Hosts are more
natural than the simplex connections presently used, and facilitate the
elimination of the special control connection required in the current
Host protocol.
Unresolved Problems and Issues.
Hostsのポートの間の全二重の論理的な接続は、現在使用されているシンプレクス接続より自然であり、現在のHostプロトコルで必要である特別なコントロール接続の除去を容易にします。 未解決の問題と問題。
Even if a source and destination Host have adequate buffer space to
permit a large number of messages (or packets, or octets) to be outstanding
between them, the IMP subnet must have a way of combating congestion
which may result from too rapid influx of data from a source Host, or
from momentary congestion owing to the confluence of excessive traffic
heading, in the same direction, possibly to the same destination. Alternate
ソースと目的地Hostにそれらの間で傑出している多くのメッセージ(または、パケット、または八重奏)を可能にする適切なバッファ領域があっても、IMPサブネットには、ソースHostか、瞬間の混雑からデータの急速過ぎる流入から生じるかもしれない混雑と戦う方法が同じ方向に向かう過度の交通の合流のためになければなりません、ことによると同じ目的地に。 補欠
[Page 17]
[17ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
routing strategies can help, but not completely solve the problem. One possibility is to insist that source Hosts monitor actual throughput achieved over the last few seconds (milliseconds?) and adjust output rate accordingly. Destination Hosts can monitor this throughput as well, and adjust the receive buffer space it allocates to the sender to reduce unnecessary retransmissions. The IMPs can simply discard traffic which cannot be buffered, knowing that the source will retransmit. IMPs which discard packets to eliminate congestion could even send short warning messages to source or destination (or both) to stimulate adjust- ment. This is a very sticky problem and involves issues such as payment by Hosts for retransmission. Most strategies in use today involve limiting, a priori, the amount of data which a source Host is allowed to send (e.g., isarhythmic network proposed by Davies [13]; maximum of n messages allowed by ARPANET IMPs). Measurement of throughput achieved by source and destination Hosts may be a good strategy in any case since it serves as a measure of qua1ity of service provided by the packet switchtng network.
ルーティング戦略は、助けますが、完全に問題を解決できるというわけではありません。 1つの可能性はソースHostsが最後の数秒(ミリセカンド?)の上達成された実際のスループットをモニターして、それに従って、出力率を調整すると主張することです。 目的地Hostsは、不要な「再-トランスミッション」を減少させるようにまた、このスループットをモニターして、それが送付者に割り当てる受信バッファスペースを調整できます。 IMPsは単に、情報筋が再送するのを知っていて、バッファリングできない交通を捨てることができます。 混雑を排除するためにパケットを捨てるIMPsが短い警告メッセージをソースに送りさえするかもしれませんか、または刺激する目的地(ともに)はmentを調整します。 これは、非常にねばねばする問題であり、「再-トランスミッション」のためにHostsによる支払いなどの問題にかかわります。 使用中のほとんどの戦略が、今日制限することを伴います、先験的です、ソースHostが送ることができるデータ量(例えばデイヴィース[13]によって提案されたisarhythmicネットワーク; アルパネットIMPsによって許容されたnメッセージの最大)。 パケットswitchtngネットワークによって提供されたサービスのqua1ityの測定として機能するので、どのような場合でも、ソースと目的地Hostsによって実現されたスループットの測定は優れた戦略であるかもしれません。
In the ARPANET, the TELNET protocol [14] for terminal to Host com-
munication has needed some way of signalling the Host in which the serving
process resides that any accumulated data should be discarded up to the
point of the "interrupt signal." This facility permits a remote user
to abort or recapture control from an uncooperative serving process
which has stopped accepting data. The current scheme involves the use
of a special interrupt signal sent on the control connection, but there
is a problem of synchronizing the interrupt request with the data in the
pipeline. This signal could be carried in the control field of a Host
message and would participate in the sequence numbering of the data, thus
アルパネットでは、Host com- municationへの端末へのTELNETプロトコル[14]はどんな累積データも「割り込み信号」のポイントまで捨てられるべきであると給仕の過程があるHostに合図する何らかの方法を必要としました。 この施設は、リモート・ユーザーがデータを受け入れるのを止めた非協力的な給仕の過程からコントロールを中止になるか、または取り戻すことを許可します。 現在の計画はコントロール接続に送られた特別な割り込み信号の使用にかかわりますが、割り込み要求をデータと同期させるという問題がパイプラインにあります。 この信号は、Hostメッセージの制御フィールドで運ぶことができて、その結果、データの系列付番に参加するでしょう。
[Page 18]
[18ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
providing for synchronization. Since the Host operating system would process the message header before passing the data to the receiving port, the interrupt could bypass processing by the receiving process and thus provide the desired interrupt-like effect.
同期に備えます。 受流口にデータを向かわせる前にHostオペレーティングシステムはメッセージヘッダーを処理するでしょう、中断が受信工程で処理を迂回させて、その結果、したがって、必要な中断のような効果を供給するかもしれません。
There are undoubtedly many other problems and issues which could
not be mentioned in the scope of this paper, and the author would be
pleased if these and the preceding commentary will stimulate discussion
and thus further the general understanding of protocol requirements for
distributed computer networks.
これらと前の論評は、他の確かに多くの問題とこの紙の範囲で参照できなかった問題があって、作者は嬉しくて、議論を刺激して、その結果、分散コンピュータネットワークのためのプロトコル要件の一般的な意味解釈を促進するでしょう。
Acknowledgments:
承認:
Throughput and delay analysis: some of the basic ideas in this analysis are due to J. McQuillan (Bolt, Beranek, and Newman). Single packet re-ordering lockup: first called to the author's attention by P. Higginson (University 6f London). Host-Host Protocol Design: developed largely under the auspices of the International Network Working Group (IFIP TC6.1), and the author especially acknowledges contributions by R. Kahn, R. Metcalfe, L. Pouzin and H. Zimmerman, as well as S. Crocker, A. McKenzie, and R. Scantlebury. Numerous omissions and misstatements were detected by R. Kahn, L. Kleinrock and H. Opderbeck.
スループットと遅れ分析: この分析における基本的な考え方のいくつかがJ.マッキラン(ボルト、Beranek、およびニューマン)のためです。 単一のパケット再注文留置所: 1番目はP.ヒギンソン(大学6fロンドン)による作者の注意に呼びかけました。 ホスト兼ホストプロトコルデザイン: そして、主に国際Network作業部会(IFIP TC6.1)の前兆で開発されている、作者はR.カーン、R.メトカルフェ、L.Pouzin、およびH.ジンマーマンによる貢献を特に承諾します、S.クロッカー、A.マッケンジー、およびR.Scantleburyと同様に。 頻繁な省略と言い違えはR.カーン、L.クラインロック、およびH.Opderbeckによって検出されました。
The author is grateful for the support of the Defense Advanced
Research Projects Agency under contract DAHC-15-73C-0435.
作者は契約DAHC-15-73C-0435に国防高等研究計画庁のご支援に感謝しています。
[Page 19]
[19ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
References
1. McKenzie, A. "HOST/HOST Protocol for the ARPA Network," Current Network
Protocols, Network Information Center, Stanford Research Institute,
Menlo Park, California, January 1972 (NIC8246).
参照1。 マッケンジー、A. 「アーパネットのためのホスト/ホストプロトコル」、現在のネットワーク・プロトコルはインフォメーション・センターをネットワークでつなぎます、スタンフォード研究所、メンローパーク(カリフォルニア)1972(NIC8246)年1月。
2. Carr, S. and S. Crocker, V. Cerf, "HOST-HOST Communication Protocol
in the ARPA Network, AFIPS 1970, SJCC Proceedings, Vol. 36, Atlantic
City, AFIPS Press, New Jersey, pp. 589-597 [somewhat out of date].
2. カーとS.とS.クロッカー、V.サーフ、「アーパネット、AFIPS1970、SJCC議事、Vol.36、アトランティックシティー、AFIPSプレス、ニュージャージー、ページのホスト兼ホスト通信プロトコル」 589-597 [いくらか時代遅れの。]
3. Crocker, S. D., and J. Heafner, R. Metcalfe, J. Postel, "Function-
Oriented Protocols for the ARPA Computer Network," AFIPS 1972 SJCC
Proceedings, Vol. 40, Atlantic City. AFIPS Press, New Jersey,
pp. 271-279.
3. クロッカー、S.D.、およびJ.Heafner、R.メトカルフェ、J.ポステル、「アルパコンピュータネットワークのための機能の指向のプロトコル」、AFIPS1972SJCC議事、Vol.40、アトランティックシティー。 AFIPS Press、ニュージャージーのページ 271-279.
4. Heart, F. E., and R. E. Kahn, et al, "The Interface Message Processor
for the ARPA Computer Network, AFIPS 1970 SJCC Proceedings, Vol. 36,
Atlantic City, AFIPS Press, New Jersey, pp. 551-567.
4. 心臓、F.E.、およびR.E.カーン、他、「アルパコンピュータネットワーク、AFIPS1970SJCC議事、Vol.36、アトランティックシティー、AFIPSプレス、ニュージャージー、ページのためのインタフェース・メッセージ・プロセッサ」 551-567.
5. Bolt, Beranek and Newman, Inc., "Specification for the Interconnection
of a Host and an IMP," BBN Report 1822, April 1973 (Revised).
5. ボルトとBeranekとニューマンInc.、「ホストと悪童のインタコネクトのための仕様」、BBNは1822を報告します、1973(改訂される)年4月。
6. Roberts, L. and B. Wessler, "Computer Network Development to Achieve
Resource Sharing," AFIPS 1970, SJCC Proceedings, Vol. 36, Atlantic City,
AFIPS Press, New Jersey, pp. 543-549.
6. ロバーツ、L.とB.Wessler、「リソース・シェアリングを達成するコンピュータネットワーク開発」AFIPS1970、SJCC Proceedings、Vol.36、アトランティックシティー、AFIPS Press、ニュージャージーのページ 543-549.
7. Kahn, R. E. and W. Crowther, "Flow Control in a Resource Sharing
Computer Network," Second Symposium on Problems in the Optimization of
Data Communications Systems, Palo Alto, October 1971, p. 108-116
[also IEEE Transactions on Communication, June 1972].
7. カーンとR.E.とW.クラウザー、「リソース・シェアリングコンピュータネットワークのフロー制御」、Data Communications Systems、パロアルト、1971年10月(p)のOptimizationのProblemsの上のSecond Symposium。 108-116 [1972年6月のコミュニケーションにおけるIEEE取引も。]
8. Kahn, R. E., "Resource Sharing Communication Networks," IEEE
Proceedings, Nov. 1972.
8. カーン、R.E.、「リソース・シェアリング通信ネットワーク」、IEEE議事、1972年11月。
9. Cerf, V. G. and R. E. Kahn, "A Protocol for Packet Network Inter-
communication," IEEE Transactions on Communication, vol. COM-22
No. 5, May 1974 p 637-641.
9. サーフとV.G.とR.E.カーン、「Packet Network Interコミュニケーションのためのプロトコル」、Communication、vol.COM-22No.5、1974年5月のp637-641のIEEE Transactions。
[Page 20]
[20ページ]
RFC 635 An Assessment of ARPANET Protocols May 1974
RFC635 アルパネットプロトコル1974年5月の査定
10. Pouzin, L., "Presentation and Major Design Aspects of the CYCLADES
Computer Network," Data Networks: Analysis and Design, Third Data
Communications Symposium, St. Petersburg, Florida, November 1973,
pp. 80-87.
10. Pouzin、L.、「プレゼンテーションとメージャーはキクラデス諸島コンピュータネットワークの局面を設計する」データ網: 分析とDesign、Third Data Communications Symposium、サンクトペテルブルグフロリダ1973年11月、ページ 80-87.
11. Postel, J., "Official Initial Connection Protocol," Current Network
Protocols, Network Information Center, Stanford Research Institute,
Menlo Park, California, January 1972 (NIC 7101).
11. ポステル、J.、「公式の初期の接続プロトコル」、現在のネットワーク・プロトコルはインフォメーション・センターをネットワークでつなぎます、スタンフォード研究所、メンローパーク(カリフォルニア)1972(NIC7101)年1月。
12. Walden, D., 'A System for Interprocess Communication in a Resource
Sharing Computer Network, Communications of the ACM, 15, 4, April 1972,
pp. 221-230 (NIC 9926).
12. ウォルデン、D.、'Resource SharingコンピュータNetworkのInterprocess CommunicationのためのSystem、ACM、15、4、1972年4月のCommunications、ページ' 221-230 (NIC9926。)
13. Davies, D., "Communication Networks to Serve Rapid Response
Computers," Information Processing 68, Proceedings of IFIP Congress
1968, Vol. 2, Edinburgh, Scotland, 1968, North-Holland Publishing
Co., Amsterdam, 1969, p. 650-658.
13. デイヴィース、D.、「サーブの急速な応答コンピュータへの通信ネットワーク」、情報Processing68、IFIP議会1968、Vol.2、エディンバラ、スコットランド1968、北部オランダ出版社のProceedings、アムステルダム1969、p。 650-658.
14. McKenzie, A. "TELNET Protocol Specification," Current Network Protocols,
Network Information Center, Stanford Research Institute, Menlo Park,
California, August 1973 (NIC 18639, NIC 18638 - Revisions).
14. マッケンジー、A.「telnetプロトコル仕様」、現在のネットワーク・プロトコルはインフォメーション・センターをネットワークでつなぎます、スタンフォード研究所、メンローパーク(カリフォルニア)1973年8月、(NIC18639、NIC18638--、改正)
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Roger D. Moore, with ]
[ assistance from William M. Stewart on Figures 1 and 2,]
[ 11/2006 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ ロジャー・D.ムーアによるオンラインRFCアーカイブに] [ 図1と2のウィリアム・M.スチュワートからの支援] [ 11/2006 ]
Notes by Roger D. Moore regarding copy and formatting changes:
コピーと形式変化に関するロジャー・D.ムーアによる注意:
A] Page numbers zero and one added to text
A] テキストに追加されたページ番号ゼロと1
B] Paragraph indent in pages 1-3 is five; it is four spaces in pp 4++
B] 1-3ページのパラグラフインデントは5です。 それはpp4++で4つの空間です。
C] All pen marked underlining from paper copy has been discarded.
C] 紙のコピーからアンダーラインを引きながらマークされたすべてのペンが捨てられました。
D] Footnotes: The original text used a sequence of superscript asterisks to mark a footnote. I have replaced all of these with the character "^" which does not otherwise appear in the document. I have used a sequence of underscore characters to to seperate text and notes at bottom of pages 3 4 5 10 11.
D] 脚注: 原本は、脚注をマークするのに上付き文字のアスタリスクの系列を使用しました。 私はこれらをすべて、そうでなければドキュメントに現れないキャラクタ"^"に取り替えました。 私は、10 11に実は3 4 5ページのテキストと注意をseperateするのに強調キャラクタの系列を使用しました。
E] Formulae: On page six I have replaced symbols of the form "B subscript digit" with "Bdigit"
E] 公式: 6ページでは、私はフォーム「B添字ケタ」のシンボルを"Bdigit"に置き換えました。
F] Forumla [2] page seven: I have rewritten this to eliminate horizontal line (division symbol).
F] Forumla[2]7ページ: 私は、水平な線(分割シンボル)を排除するためにこれを書き直しました。
G] Quarter symbol: page eight (last line) had a special symbol which I have replaced with "1/4"
G] 4分の1シンボル: 8ページ(最終ライン)には、私が「1/4インチ」に置き換えた特別なシンボルがありました。
H] Marginal notes: I have preserved formulae notes from page six. Others have been discarded.
H] 傍注: 私は6ページからの公式注意を保存しました。 他のものは捨てられました。
I] Page numbers: I have left two blank lines after page header. Page footer is incomplete but has the form [Page 9] or [Page 99]. RFCs in the archive have between the footer and header (ASCII formfeed?). I was unable to enter this character.
I] ページ番号: 私はページ後の2つの空白行をヘッダーに残しました。 ページフッターは、不完全ですが、フォーム[9ページ]か[99ページ]を持っています。 アーカイブのRFCsはフッターとヘッダーの間に何らかの特殊文字を持っています(ASCIIはformfeedされましたか?)。 私はこのキャラクタに入ることができませんでした。
J] Reference 9: I have included page numbers since this paper is now published.
J] 参照9: この論文が現在発行されるので、私はページ番号を入れました。
K] Figure 2 on page nine originally contained continuous curves in heavy pencil, redrawn in ASCII.
K] 9ページの図2は元々、重い鉛筆、ASCIIにおけるredrawnに連続したカーブを含みました。
一覧
スポンサーリンク
