RFC568 日本語訳

Received at NIC 21-Sept-73

NIC1973年9月21日に受信します。

Network Working Group                                  J. McQuillan
RFC #568                                               BBN-NET
NIC #18971                                             18 September 1973

ワーキンググループJ.マッキランRFC#568BBN-ネットNIC#18971 1973年9月18日をネットワークでつないでください。

         Response to RFC 567 -- Cross-Country Network Bandwidth

RFC567への応答--クロスカントリーのネットワーク回線容量

This note serves as a brief correction to several fundamental errors in
RFC 567 by L. Peter Deutsch.

注意がL.ピーターによるRFC567のいくつかの基本的な誤りへの簡潔な修正としてドイツ語に役立つこれ。

1.  Not all packets are 1000 bits long.  This is basic to the network
    design.

1. すべてのパケットがどんな長さ1000ビットであるというわけではありません。 これはネットワークデザインに基本的です。

2.  RFNMs are 152 bits long (72 bits of hardware framing and 80 bits of
    software identification and addressing). Host Host protocol messages
    such as single-characters and allocates are 216 bits long (40 bits
    of Host protocol, 8 bits for the character or ALL, and an additional
    16 bits of IMP software header).  This totals to 736 bits in each
    direction, not 4000.

2. RFNMsは長さ152ビットです(ソフトウェア識別とアドレシングのハードウェア縁どりと80ビットの72ビット)。 Hostプロトコルが単独のキャラクタなどのように通信して、割り当てるホストは長さ216ビットです(Hostプロトコルの40ビット、キャラクタかすべてのための8ビット、およびIMPソフトウェアヘッダーの追加16ビット)。 これは合計でビットに4000ではなく各方向に736までなります。

3.  The number of single-character messages that can be supported is
    therefore over 200 per second, not 37.5 per second.  Not only is
    such a traffic pattern unlikely, but it can be supported in the IMP
    subnetwork much more readily than in most Hosts.

3. したがって、サポートすることができる単独のキャラクタメッセージの数は1秒あたり37.5ではなく1秒あたり200以上です。 そのようなトラフィック・パターンがありそうもないだけではなく、ほとんどのHostsよりIMPサブネットワークではるかに容易にそれをサポートすることができます。

4.  Furthermore, if the demand for remote echoing ever exceeds network
    capacity, the TIPs and Hosts can simply buffer 2 characters per
    message, doubling the effective bandwidth of the network.  Of
    course, dozens of characters can be packed into a single message
    with nearly proportional increases in effective bandwidth, given the
    size of the overhead.  This buffering happens automatically and
    incrementally with increasing load as the natural consequence of
    slowed responses.

4. その上、リモート反響の要求がネットワーク容量を超えているなら、TIPsとHostsは単によりもみ皮製の1メッセージあたり2つのキャラクタに超えることができます、ネットワークの有効な帯域幅を倍にして。 もちろん、有効な帯域幅のほとんど比例している増加に伴うただ一つのメッセージに何十ものキャラクタに詰め込むことができます、オーバーヘッドのサイズを考えて。 このバッファリングは遅くされた応答の自然な結果として増加する負荷で自動的に、そして増加して起こります。

5.  It is most likely that the poor echoing response cited by Deutsch is
    not caused by peak network loads.  If echoing was coming in 5-
    character bursts, there would have to be _1000_ characters per
    second coming from users of remote-echo systems to use all the
    capacity of 3 50-kilobit paths.

5. 応答がドイツ語で引用した貧しい反響がピークネットワーク負荷によって引き起こされないのは、たぶんです。 反響が_3つの50キロビットの経路のすべての容量を使用するためにはそこでは、リモートエコーシステムのユーザからの再臨あたり1000の_キャラクタでなければならないだろうという5キャラクタ炸裂に入って、ことであったなら。

6.  This reasoning points up the more serious error in RFC 567:  the
    problems associated with bad echo response are delay problems, not
    bandwidth.  In designing the IMP software, we have used a bimodal
    model of traffic, and attempted to provide low delay for interactive

6. この推理はRFC567で、より重大な誤りを強調します: 悪いエコー応答に関連している問題は帯域幅ではなく、遅れ問題です。 IMPソフトウェアを設計する際に、私たちは、トラフィックの二つのモードのモデルを使用して、低い遅れをインタラクティブに提供するのを試みました。

RFC 568

RFC568

    traffic, and high throughput rates for bulk data transfers.  It is
    pointless to try for high data rates with short messages - the
    overhead in bits, and also in IMP and Host processor wake-ups, is
    too high.  The primary factor in echoing performance is delay.  As
    an extreme example, echoing over a megabit per second satellite link
    will lag a second or more behind input, with no bandwidth
    limitations at all.

トラフィック、およびバルク・データ転送の高生産性速度。 短いメッセージで高いデータ信号速度に挑戦するのは無意味です--ビット、およびIMPとHostプロセッサ航跡上でもオーバーヘッドは高過ぎます。 性能を鳴り響かせる主要な要素は遅れです。 極端な例として、2番目の衛星中継あたり1つのメガビットの上で反響するのは1秒以上に入力に後れを取るでしょう、全く帯域幅制限なしで。

7.  We agree that changes to TELNET protocol may well improve
    performance by reducing network traffic, and, more importantly,
    reducing demands for Host processing.  In cases of network paths
    with long delay, especially satellite links, such changes are
    essential for interactive echoing.

7. 私たちは、TELNETプロトコルへの変化がたぶんHost処理のネットワークトラフィックを減少させている、より重要に減少している要求による性能を向上させるだろうというのに同意します。 長時間の遅延、特に衛星中継があるネットワーク経路の場合では、対話的な反響に、そのような変化は不可欠です。

JMcQ/jm

JMcQ/jm

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.            10/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社10/99]