RFC1263 日本語訳
1263 TCP Extensions Considered Harmful. S. O'Malley, L.L. Peterson. October 1991. (Format: TXT=54078 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. O'Malley
Request for Comments: 1263 L. Peterson
University of Arizona
October 1991
コメントを求めるワーキンググループS.オマリー要求をネットワークでつないでください: 1263 L.ピーターソンアリゾナ大学1991年10月
TCP EXTENSIONS CONSIDERED HARMFUL
有害であると考えられたTCP拡張子
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this document is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このドキュメントの分配は無制限です。
Abstract
要約
This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. Its purpose is to stimulate discussion in the Internet community.
このRFCはTCPを広げるという最近の提案を批評します。 それは、RFCの1072年と1185年に提案された後方のコンパチブル拡大が追求されるべきでないと主張して、インターネット・プロトコル群を発展する代替の方法を提案します。 目的はインターネットコミュニティで議論を刺激することです。
1. Introduction
1. 序論
The rapid growth of the size, capacity, and complexity of the Internet has led to the need to change the existing protocol suite. For example, the maximum TCP window size is no longer sufficient to efficiently support the high capacity links currently being planned and constructed. One is then faced with the choice of either leaving the protocol alone and accepting the fact that TCP will run no faster on high capacity links than on low capacity links, or changing TCP. This is not an isolated incident. We have counted at least eight other proposed changes to TCP (some to be taken more seriously than others), and the question is not whether to change the protocol suite, but what is the most cost effective way to change it.
インターネットのサイズ、容量、および複雑さの急速な成長は既存のプロトコル群を変える必要性につながりました。 例えば、最大のTCPウィンドウサイズは、高容量が現在計画されて、組み立てられるリンクであると効率的にサポートするためにもう十分ではありません。 そして、1は低い容量リンクより高容量リンクで速く、プロトコルを放っておいて、TCPが稼働するという事実を認めないか、またはTCPを変えることの選択に直面しています。 これは孤立した事件ではありません。 私たちはTCP(他のものより真剣に取られるべきいくつか)への他の少なくとも8回の変更案を数えました、そして、質問は何がプロトコル群を変えるかどうかではなく、ずっとそれを変えるために最も費用効率がよいかということです。
This RFC compares the costs and benefits of three approaches to making these changes: the creation of new protocols, backward compatible protocol extensions, and protocol evolution. The next section introduces these three approaches and enumerates the strengths and weaknesses of each. The following section describes how we believe these three approaches are best applied to the many proposed changes to TCP. Note that we have not written this RFC as an academic exercise. It is our intent to argue against acceptance of the various TCP extensions, most notably RFC's 1072 and 1185 [4,5], by describing a more palatable alternative.
このRFCはこれらの変更を行うことへの3つのアプローチのコストと恩恵を比較します: 新しいプロトコル、後方のコンパチブルプロトコル拡大、およびプロトコル発展の作成。 次のセクションは、これらの3つのアプローチを導入して、それぞれの長所と短所を列挙します。 私たちが、これらの3つのアプローチが最も上手にTCPへの多くの変更案に適用されるとどう信じているかを以下のセクションは説明します。 私たちがアカデミックな運動としてこのRFCに書いていないことに注意してください。 様々なTCP拡張子、最も著しくRFCの1072、および1185年[4、5]の承認について反対の議論をするのは、私たちの意図です、よりおいしい代替手段を説明することによって。
O'Malley & Peterson [Page 1] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[1ページ]RFC1263TCP拡張子
2. Creation vs. Extension vs. Evolution
2. 拡大対発展への作成
2.1. Protocol Creation
2.1. プロトコール作成
Protocol creation involves the design, implementation, standardization, and distribution of an entirely new protocol. In this context, there are two basic reasons for creating a new protocol. The first is to replace an old protocol that is so outdated that it can no longer be effectively extended to perform its original function. The second is to add a new protocol because users are making demands upon the original protocol that were not envisioned by the designer and cannot be efficiently handled in terms of the original protocol. For example, TCP was designed as a reliable byte-stream protocol but is commonly used as both a reliable record- stream protocol and a reliable request-reply protocol due to the lack of such protocols in the Internet protocol suite. The performance demands placed upon a byte-stream protocol in the new Internet environment makes it difficult to extend TCP to meet these new application demands.
プロトコール作成は完全に新しいプロトコルのデザイン、実装、標準化、および分配にかかわります。 このような関係においては、新しいプロトコルを作成する2つの根本的な理由があります。 1番目は元の機能を実行するためにもう事実上それを広げることができないくらい時代遅れであることの古いプロトコルを置き換えることです。 2番目はユーザがオリジナルのプロトコルでの要求をそれにしているので、新しいプロトコルをデザイナーが思い描かないで、オリジナルのプロトコルで効率的に扱うことができないと言い足すことです。 例えば、TCPは信頼できるバイト・ストリームプロトコルとして設計されましたが、信頼できる記録ストリームプロトコルと信頼できる要求回答の両方がインターネット・プロトコル群のそのようなプロトコルの不足のため議定書を作るとき、一般的に使用されます。 要求が新しいインターネット環境でバイト・ストリームプロトコルに置いた性能で、これらの新しいアプリケーション需要にこたえるためにTCPを広げるのは難しくなります。
The advantage of creating a new protocol is the ability to start with a clean sheet of paper when attempting to solve a complex network problem. The designer, free from the constraints of an existing protocol, can take maximum advantage of modern network research in the basic algorithms needed to solve the problem. Even more importantly, the implementor is free to steal from a large number of existing academic protocols that have been developed over the years. In some cases, if truly new functionality is desired, creating a new protocol is the only viable approach.
新しいプロトコルを作成する利点は複雑なネットワーク問題を解決するのを試みるとき紙の清潔なシートから始まる能力です。 既存のプロトコルの規制を持っていないデザイナーは問題を解決するのに必要である基本的なアルゴリズムにおける現代のネットワーク研究について最大の利点を活用できます。 さらに重要に、作成者は数年間開発されている多くの既存のアカデミックなプロトコルから自由に盗むことができます。 いくつかの場合、本当に新しい機能性が望まれているなら、新しいプロトコルを作成するのは、唯一の実行可能なアプローチです。
The most obvious disadvantage of this approach is the high cost of standardizing and distributing an entirely new protocol. Second, there is the issue of making the new protocol reliable. Since new protocols have not undergone years of network stress testing, they often contain bugs which require backward compatible fixes, and hence, the designer is back where he or she started. A third disadvantage of introducing new protocols is that they generally have new interfaces which require significant effort on the part of the Internet community to use. This alone is often enough to kill a new protocol.
このアプローチの最も明白な不都合は完全に新しいプロトコルを標準化して、分配する高い費用です。 2番目に、新しいプロトコルを信頼できるようにする問題があります。 新しいプロトコルが何年ものネットワーク圧力テストを受けていないので、しばしば後方のコンパチブルフィックスを必要とするバグを保管しています、そして、したがって、デザイナーはその人が出発したところに戻っています。 新しいプロトコルを紹介する3番目の不都合は一般に、それらには使用するインターネットコミュニティ側の重要な取り組みを必要とする新しいインタフェースがあるということです。 これだけが、新しいプロトコルを殺すためにしばしば十分です。
Finally, there is a subtle problem introduced by the very freedom provided by this approach. Specifically, being able to introduce a new protocol often results in protocols that go far beyond the basic needs of the situation. New protocols resemble Senate appropriations bills; they tend to accumulate many amendments that have nothing to do with the original problem. A good example of this phenomena is the attempt to standardize VMTP [1] as the Internet RPC protocol. While
最終的に、このアプローチで提供されたまさしくその自由によって紹介された微妙な問題があります。 明確に、新しいプロトコルを紹介できるなら、遠くに状況の基本的ニーズを越えるプロトコルがしばしばもたらされます。 新しいプロトコルは上院計上請求書に類似しています。 それらは、オリジナルの問題と関係ない多くの修正を蓄積する傾向があります。 この現象の好例は[1] インターネットRPCが議定書を作るときVMTPを標準化する試みです。 while
O'Malley & Peterson [Page 2] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[2ページ]RFC1263TCP拡張子
VMTP was a large protocol to begin with, the closer it got to standardization the more features were added until it essentially collapsed under its own weight. As we argue below, new protocols should initially be minimal, and then evolve as the situation dictates.
VMTPによる初めにそれが、より近くより多くが特徴とする標準化に得た大きいプロトコルがそれ自身の重さの下で本質的には崩れるまで加えられたということでした。 私たちが以下で論争するように、状況が決めるように、新しいプロトコルは、初めは、最小量であり、次に、発展するべきです。
2.2. Backward Compatible Extensions
2.2. 後方のコンパチブル拡大
In a backward compatible extension, the protocol is modified in such a fashion that the new version of the protocol can transparently inter-operate with existing versions of the protocol. This generally implies no changes to the protocol's header. TCP slow start [3] is an example of such a change. In a slightly more relaxed version of backward compatibility, no changes are made to the fixed part of a protocol's header. Instead, either some fields are added to the variable length options field found at the end of the header, or existing header fields are overloaded (i.e., used for multiple purposes). However, we can find no real advantage to this technique over simply changing the protocol.
後方のコンパチブル拡大では、プロトコルはプロトコルの新しいバージョンがプロトコルの既存のバージョンで透過的に共同利用できるくらいのファッションで変更されます。 一般に、これはプロトコルのヘッダーへの変化を全く含意しません。 TCP遅れた出発[3]はそのような変化に関する例です。 後方の互換性のわずかに伸びやかなバージョンでは、変更は全くプロトコルのヘッダーの固定一部まで行われません。 代わりに、いくつかの分野がヘッダーの端で見つけられた可変長オプション分野に加えられるか、または既存のヘッダーフィールドは積みすぎられます(すなわち、複数の目的のために、使用されます)。 しかしながら、単にプロトコルを変える上で私たちはこのテクニックのどんな本当の利点も見つけることができません。
Backward compatible extensions are widely used to modify protocols because there is no need to synchronize the distribution of the new version of the protocol. The new version is essentially allowed to diffuse through the Internet at its own pace, and at least in theory, the Internet will continue to function as before. Thus, the explicit distribution costs are limited. Backward compatible extensions also avoid the bureaucratic costs of standardizing a new protocol. TCP is still TCP and the approval cost of a modification to an existing protocol is much less than that of a new protocol. Finally, the very difficulty of making such changes tends to restrict the changes to the minimal set needed to solve the current problem. Thus, it is rare to see unneeded changes made when using this technique.
後方のコンパチブル拡張子は、プロトコルの新しいバージョンの分配を同時にさせる必要は全くないのでプロトコルを変更するのに広く使用されます。 新しいバージョンはインターネットを通して本質的にはマイペースで拡散できます、そして、インターネットは少なくとも理論上、従来と同様機能し続けるでしょう。 したがって、明白な分配コストは限られています。 また、後方のコンパチブル拡大は新しいプロトコルを標準化する官僚のコストを避けます。 それでも、TCPがTCPであり、既存のプロトコルへの変更の承認の費用は新しいプロトコルのものよりはるかに少ないです。 最終的に、そのような変更を行うというまさしくその困難は、現在の問題を解決するのが必要である極小集合への変化を制限する傾向があります。 したがって、このテクニックを使用するとき、不要な変更が行われるのを見るのはまれです。
Unfortunately, this approach has several drawbacks. First, the time to distribute the new version of the protocol to all hosts can be quite long (forever in fact). This leaves the network in a heterogeneous state for long periods of time. If there is the slightest incompatibly between old and new versions, chaos can result. Thus, the implicit cost of this type of distribution can be quite high. Second, designing a backward compatible change to a new protocol is extremely difficult, and the implementations "tend toward complexity and ugliness" [5]. The need for backward compatibility ensures that no code can every really be eliminated from the protocol, and since such vestigial code is rarely executed, it is often wrong. Finally, most protocols have limits, based upon the design decisions of it inventors, that simply cannot be side-stepped in this fashion.
残念ながら、このアプローチには、いくつかの欠点があります。 まず最初に、プロトコルの新しいバージョンをすべてのホストに分配する時間はかなり長い場合があります(いつまでも、事実上)。 これは長期間の間、種々雑多な状態でネットワークを出ます。 古くて新しいバージョンの間には、最もわずかであるのが相容れないほどにあれば、カオスは結果として生じることができます。 したがって、このタイプの分配の暗黙の費用はかなり高い場合があります。 2(新しいプロトコルへの後方のコンパチブル変化を設計するのが非常に難しく、実装は「複雑さと醜さの傾向がある」という[5])番目。 後方の互換性の必要性が、どんなコードもそうすることができないのを確実にする、あらゆる、それがプロトコルから排除されて、実行されて、めったにそのようななごりのコードがそうのでしばしば間違っているという本当にことになってください。 発明者、最終的に、ほとんどのプロトコルには、限界があって、それのデザイン決定に基づいて、こんなやり方でそれは絶対にかわすことができません。
O'Malley & Peterson [Page 3] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[3ページ]RFC1263TCP拡張子
2.3. Protocol Evolution
2.3. プロトコル発展
Protocol evolution is an approach to protocol change that attempts to escape the limits of backward compatibility without incurring all of the costs of creating new protocols. The basic idea is for the protocol designer to take an existing protocol that requires modification and make the desired changes without maintaining backward compatibility. This drastically simplifies the job of the protocol designer. For example, the limited TCP window size could be fixed by changing the definition of the window size in the header from 16-bits to 32-bits, and re-compiling the protocol. The effect of backward compatibility would be ensured by simply keeping both the new and old version of the protocol running until most machines use the new version. Since the change is small and invisible to the user interface, it is a trivial problem to dynamically select the correct TCP version at runtime. How this is done is discussed in the next section.
プロトコル発展は新しいプロトコルを作成するコストのすべてを被らないで後方の互換性の限界から逃げるのを試みる変化について議定書の中で述べるアプローチです。 基本的な考え方は、プロトコルデザイナーが変更を必要とする既存のプロトコルを取って、後方の互換性を維持しないで必要な変更を行うことです。 これはプロトコルデザイナーの仕事を抜本的に簡素化します。 例えば、ヘッダーとのウィンドウサイズの定義を16ビットから32ビットに変えて、プロトコルを再コンパイルすることによって、限られたTCPウィンドウサイズを修理できるでしょう。 両方がほとんどのマシンが新しいバージョンを使用するまでプロトコルが稼働する新しくて古いバージョンであることを単に保つことによって、後方の互換性の効果は確実にされるでしょう。 変化がユーザーインタフェースに小さくて、目に見えないので、ランタイムのときにダイナミックに正しいTCPバージョンを選択するのは、些細な問題です。 次のセクションでこれがどう完了しているかについて議論します。
Protocol evolution has several advantages. First, it is by far the simplest type of modification to make to a protocol, and hence, the modifications can be made faster and are less likely to contain bugs. There is no need to worry about the effects of the change on all previous versions of the protocol. Also, most of the protocol is carried over into the new version unchanged, thus avoiding the design and debugging cost of creating an entirely new protocol. Second, there is no artificial limit to the amount of change that can be made to a protocol, and as a consequence, its useful lifetime can be extended indefinitely. In a series of evolutionary steps, it is possible to make fairly radical changes to a protocol without upsetting the Internet community greatly. Specifically, it is possible to both add new features and remove features that are no longer required for the current environment. Thus, the protocol is not condemned to grow without bound. Finally, by keeping the old version of the protocol around, backward compatibility is guaranteed. The old code will work as well as it ever did.
プロトコル発展には、いくつかの利点があります。 まず最初に、それが断然プロトコルにする最も純真なタイプの変更であり、したがって、変更は、より速く作ることができて、バグをより含みそうにはありません。 プロトコルのすべての旧バージョンへの変化の効果を心配する必要は全くありません。 また、プロトコルの大部分は新しいバージョンに変わりがない状態で持ち越されます、その結果、デザインを避けて、完全に新しいプロトコルを作成する費用をデバッグして。 2番目に、プロトコルにすることができる変更の量へのどんな人工の限界もありません、そして、結果として、役に立つ生涯は無期限に広げることができます。 一連の進化論のステップでは、インターネットコミュニティを大いにひっくり返さないでプロトコルへの根本的な変更を公正に作るのは可能です。 明確に、新機能を加えて、現在の環境のためにもう必要でない特徴を取り除くのは可能です。 したがって、プロトコルは、バウンドなしで成長するように非難されません。 最終的に、プロトコルの古いバージョンを置くことによって、後方の互換性は保証されます。 旧法は今までにしたのと同じくらいよく働くでしょう。
Assuming the infrastructure described in the following subsection, the only real disadvantage of protocol evolution is the amount of memory required to run several versions of the same protocol. Fortunately, memory is not the scarcest resource in modern workstations (it may, however, be at a premium in the BSD kernel and its derivatives). Since old versions may rarely if ever be executed, the old versions can be swapped out to disk with little performance loss. Finally, since this cost is explicit, there is a huge incentive to eliminate old protocol versions from the network.
以下の小区分で説明されたインフラストラクチャを仮定して、プロトコル発展の唯一の本当の不都合が同じプロトコルのいくつかのバージョンを実行するのに必要であるメモリー容量です。 幸い、メモリは現代のワークステーションで最も不十分なリソース(しかしながら、プレミアムにはそれがBSDカーネルとその派生物にあるかもしれない)ではありません。 今までに実行されるなら古いバージョンがめったに交換するかもしれないので、ディスクへの外で小さい性能の損失で古いバージョンを交換できます。 最終的に、この費用が明白であるので、ネットワークから古いプロトコルバージョンを排除する巨大な誘因があります。
O'Malley & Peterson [Page 4] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[4ページ]RFC1263TCP拡張子
2.4. Infrastructure Support for Protocol Evolution
2.4. プロトコル発展のインフラ支援
The effective use of protocol evolution implies that each protocol is considered a vector of implementations which share the same top level interface, and perhaps not much else. TCP[0] is the current implementation of TCP and exists to provide backward compatibility with all existing machines. TCP[1] is a version of TCP that is optimized for high-speed networks. TCP[0] is always present; TCP[1] may or may not be. Treating TCP as a vector of protocols requires only three changes to the way protocols are designed and implemented.
プロトコル発展の有効な使用は、各プロトコルが同じトップ平らなインタフェース、およびほかの恐らくそうしていない多くを共有する実装のベクトルであると考えられるのを含意します。 TCP[0]は、TCPの現在の実装であり、すべての既存のマシンを後方の互換性に提供するために存在しています。 TCP[1]は高速ネットワークのために最適化されるTCPのバージョンです。 TCP[0]はいつも存在しています。 TCP[1]はそうです。 プロトコルのベクトルとしてTCPを扱うのはプロトコルが設計されていて、実装される方法への3回の変化だけを必要とします。
First, each version of TCP is assigned a unique id, but this id is not given as an IP protocol number. (This is because IP's protocol number field is only 8 bits long and could easily be exhausted.) The "obvious" solution to this limitation is to increase IP's protocol number field to 32 bits. In this case, however, the obvious solution is wrong, not because of the difficultly of changing IP, but simply because there is a better approach. The best way to deal with this problem is to increase the IP protocol number field to 32 bits and move it to the very end of the IP header (i.e., the first four bytes of the TCP header). A backward compatible modification would be made to IP such that for all packets with a special protocol number, say 77, IP would look into the four bytes following its header for its de-multiplexing information. On systems which do not support a modified IP, an actual protocol 77 would be used to perform the de- multiplexing to the correct TCP version.
まず最初に、ユニークなイドはTCPの各バージョンに割り当てられますが、このイドはIPプロトコル番号として与えられていません。 (これはIPのプロトコルナンバーフィールドが長さ8ビットであるだけであり、容易に消耗できたからです。) この制限への「明白な」ソリューションはIPのプロトコルナンバーフィールドを32ビットまで増強することです。 しかしながら、この場合明らかな解決法が間違っている、単にあるのでIPを変えるのにおいて、難しく、aにアプローチするほうがよいです。 この問題に対処する最も良い方法は、IPプロトコルナンバーフィールドを32ビットまで増強して、IPヘッダー(すなわち、TCPヘッダーの最初の4バイト)の最後の最後に動かすことです。 逆多重化情報のためのヘッダーに続いて、IPがたとえば、特別なプロトコル番号があるすべてのパケット、77のために4バイトを調べるように、後方のコンパチブル変更をIPにするでしょう。 変更されたIPをサポートしないシステムの上では、実際のプロトコル77は、正しいTCPバージョンに反-マルチプレクシングを実行するのに使用されるでしょう。
Second, a version control protocol, called VTCP, is used to select the appropriate version of TCP for a particular connection. VTCP is an example of a virtual protocol as introduced in [2]. Application programs access the various versions of TCP through VTCP. When a TCP connection is opened to a specific machine, VTCP checks its local cache to determine the highest common version shared by the two machines. If the target machine is in the cache, it opens that version of TCP and returns the connection to the protocol above and does not effect performance. If the target machine is not found in the cache, VTCP sends a UDP packet to the other machine asking what versions of TCP that machine supports. If it receives a response, it uses that information to select a version and puts the information in the cache. If no reply is forthcoming, it assumes that the other machine does not support VTCP and attempts to open a TCP[0] connection. VTCP's cache is flushed occasionally to ensure that its information is current.
2(VTCPと呼ばれるバージョン制御プロトコル)番目は、特定の接続のためにTCPの適切なバージョンを選択するのに使用されます。 VTCPは[2]で導入するように仮想のプロトコルに関する例です。 アプリケーション・プログラムはVTCPを通してTCPの様々なバージョンにアクセスします。 TCP接続が特定のマシンに開かれるとき、VTCPは、2台のマシンによって共有される中で最も高い一般的なバージョンを決定するためにローカルなキャッシュをチェックします。 キャッシュにターゲットマシンがあるなら、それは、TCPのそのバージョンを開いて、上のプロトコルに接続を返して、性能に作用しません。 ターゲットマシンがキャッシュで見つけられないなら、VTCPはそのマシンがTCPのどんなバージョンをサポートするかを尋ねるもう片方のマシンにUDPパケットを送ります。 応答を受けるなら、それは、バージョンを選択するのにその情報を使用して、キャッシュに情報を入れます。 どんな回答も用意されていないなら、それは、もう片方のマシンが、VTCPをサポートしないで、TCP[0]接続を開くのを試みると仮定します。 VTCPのキャッシュは、情報が確実に現在になるようにするために時折洗い流されます。
Note that this is only one possible way for VTCP to decide the right version of TCP to use. Another possibility is for VTCP to learn the right version for a particular host when it resolves the host's name. That is, version information could be stored in the Domain Name
これがVTCPが使用するTCPの正しいバージョンについて決める1つの可能な方法にすぎないことに注意してください。 別の可能性はホストの名前を決議するとVTCPが特定のホストのために正しいバージョンを学ぶことです。 Domain Nameにすなわち、バージョン情報を保存できました。
O'Malley & Peterson [Page 5] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[5ページ]RFC1263TCP拡張子
System. It is also possible that VTCP might take the performance characteristics of the network into consideration when selecting a version; TCP[0] may in fact turn out to be the correct choice for a low-bandwidth network.
システム。 また、バージョンを選択するとき、VTCPがネットワークの性能の特性を考慮に入れるのも、可能です。 事実上、TCP[0]は、低バンド幅ネットワークに、正しい選択であると判明するかもしれません。
Third, because our proposal would lead to a more dynamically changing network architecture, a mechanism for distributing new versions will need to be developed. This is clearly the hardest requirement of the infrastructure, but we believe that it can be addressed in stages. More importantly, we believe this problem can be addressed after the decision has been made to go the protocol evolution route. In the short term, we are considering only a single new version of TCP--- TCP[1]. This version can be distributed in the same ad hoc way, and at exactly the same cost, as the backward compatible changes suggested in RFC's 1072 and 1185.
私たちの提案はダイナミックにより変化しているネットワークアーキテクチャにつながるでしょう、したがって、3番目に、新しいバージョンを分配するためのメカニズムが開発される必要があるでしょう。 これは明確にインフラストラクチャの最も確実な要件ですが、私たちは、段階でそれを記述できると信じています。 より重要に、私たちは、決定をプロトコル発展が発送する碁にした後にこの問題を記述できると信じています。 短期で、私たちはTCPのただ一つの新しいバージョンだけを考えています。--- TCP[1]。 同じくらいでずっと、そして、まさに同じ費用においてこのバージョンを臨時に分配できます、後方のコンパチブル変化がRFCの1072年と1185年に示したように。
In the medium term, we envision the IAB approving new versions of TCP every year or so. Given this scenario, a simple distribution mechanism can be designed based on software distribution mechanisms that have be developed for other environments; e.g., Unix RDIST and Mach SUP. Such a mechanism need not be available on all hosts. Instead, hosts will be divided into two sets, those that can quickly be updated with new protocols and those that cannot. High performance machines that can use high performance networks will need the most current version of TCP as soon as it is available, thus they have incentive to change. Old machines which are too slow to drive a high capacity lines can be ignored, and probably should be ignored.
中期で、私たちは、IABが毎年のTCPかそうの新しいバージョンを承認するのを思い描きます。 このシナリオを考えて、簡単な分配メカニズムは他の環境のために開発されたソフトウェア配布メカニズムに基づいて設計される場合があります。 例えば、Unix RDISTとマッハSUP。 そのようなメカニズムはすべてのホストで利用可能である必要はありません。 代わりに、ホストは2セット(新しいプロトコルとそうすることができないそれらですぐにアップデートできるもの)に分割されるでしょう。 それが利用可能である、その結果、それらに変化する誘因があるとすぐに、高性能ネットワークを使用できる高性能マシンがTCPの最新版を必要とするでしょう。 高容量が裏打ちするドライブに遅過ぎる古いマシンは、無視できて、たぶん無視されるべきです。
In the long term, we envision protocols being designed on an application by application basis, without the need for central approval. In such a world, a common protocol implementation environment---a protocol backplane---is the right way to go. Given such a backplane, protocols can be automatically installed over the network. While we claim to know how to build such an environment, such a discussion is beyond the scope of this paper.
長期で、私たちは、プロトコルがアプリケーションのときにアプリケーション基礎によって設計されるのを思い描きます、主要な承認の必要性なしで。 そのような世界、一般的なプロトコル実現環境で---プロトコルバックプレーン---正しい道は行くことになっていますか? そのようなバックプレーンを考えて、自動的にネットワークの上にプロトコルをインストールできます。 私たちは、そのような環境を築き上げる方法を知ると主張しますが、そのような議論はこの紙の範囲を超えています。
2.5. Remarks
2.5. 注意
Each of these three methods has its advantages. When used in combination, the result is better protocols at a lower overall cost. Backward compatible changes are best reserved for changes that do not affect the protocol's header, and do not require that the instance running on the other end of the connection also be changed. Protocol evolution should be the primary way of dealing with header fields that are no longer large enough, or when one algorithm is substituted directly for another. New protocols should be written to off load unexpected user demands on existing protocols, or better yet, to
それぞれのこれらの3つの方法には、利点があります。 組み合わせに使用されると、結果は低い全費用において、より良いプロトコルです。 後方のコンパチブル変化は、プロトコルのヘッダーに影響しない変化のために予約するのが最も良く、また、接続のもう一方の端で走る例が変えられるのを必要としません。 プロトコル発展は十分、または直接別のものに1つのアルゴリズムを代入するときもう大きくないヘッダーフィールドに対処する第一の方法であるべきです。 新しいプロトコルは予期していなかったユーザが既存のプロトコル、またはさらに良く要求するオフ負荷まで書かれているべきです。
O'Malley & Peterson [Page 6] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[6ページ]RFC1263TCP拡張子
catch them before they start.
彼らが始まる前にそれらを捕らえてください。
There are also synergistic effects. First, since we know it is possible to evolve a newly created protocol once it has been put in place, the pressure to add unnecessary features should be reduced. Second, the ability to create new protocols removes the pressure to overextend a given protocol. Finally, the ability to evolve a protocol removes the pressure to maintain backward compatibility where it is really not possible.
相乗効果もあります。 それがいったん適所に置かれると私たちが、新たに作成されたプロトコルを発展するのが可能であることを知っているので、まず最初に、不要な特徴を加える圧力は減少するべきです。 2番目に、新しいプロトコルを作成する能力は与えられたプロトコルを過度に拡張する圧力を取り除きます。 最終的に、プロトコルを発展する能力は後方の互換性を維持する圧力をそれが本当に可能でないところに移します。
3. TCP Extensions: A Case Study
3. TCP拡張子: ケーススタディ
This section examines the effects of using our proposed methodology to implement changes to TCP. We will begin by analyzing the backward compatible extensions defined in RFC's 1072 and 1185, and proposing a set of much simpler evolutionary modifications. We also analyze several more problematical extensions to TCP, such as Transactional TCP. Finally, we point our some areas of TCP which may require changes in the future.
このセクションはTCPへの変化を実行するのに私たちの提案された方法論を使用するという効果を調べます。 私たちは、RFCの1072年と1185年に定義された後方のコンパチブル拡大を分析して、1セットのはるかに簡単な進化論の変更を提案することによって、始めるつもりです。 また、私たちはいくつかの、より問題の多い拡大をTransactional TCPなどのTCPに分析します。 最終的に、私たちが指す、私たち、将来釣り銭がいるかもしれないTCPのいくつかの領域。
The evolutionary modification to TCP that we propose includes all of the functionality described in RFC's 1072 and 1185, but does not preserve the header format. At the risk of being misunderstood as believing backward compatibility is a good idea, we also show how our proposed changes to TCP can be folded into a backward compatible implementation of TCP. We do this as a courtesy for those readers that cannot accept the possibility of multiple versions of TCP.
私たちが提案するTCPへの進化論の変更は、RFCの1072年と1185年に説明された機能性のすべてを含んでいますが、ヘッダー形式を保存しません。 互換性が名案であると後方に信じていると誤解されるというリスクのために、また、私たちはどうTCPへの私たちの変更案をTCPの後方のコンパチブル実現に折り重ねることができるかを示しています。 私たちはTCPの複数のバージョンの可能性を受け入れることができないそれらの読者のための礼儀としてこれをします。
3.1. RFC's 1072 and 1185
3.1. RFCの1072と1185
3.1.1. Round Trip Timing
3.1.1. 周遊旅行タイミング
In RFC 1072, a new ECHO option is proposed that allows each TCP packet to carry a timestamp in its header. This timestamp is used to keep a more accurate estimate of the RTT (round trip time) used to decide when to re-transmit segments. In the original TCP algorithm, the sender manually times a small number of sends. The resulting algorithm was quite complex and does not produce an accurate enough RTT for high capacity networks. The inclusion of a timestamp in every header both simplifies the code needed to calculate the RTT and improves the accuracy and robustness of the algorithm.
RFC1072では、それぞれのTCPパケットがヘッダーでタイムスタンプを運ぶことができる新しいECHOオプションは提案されます。 このタイムスタンプは、いつセグメントを再送するかを決めるのにRTT(周遊旅行時間)の、より正確な見積りを使用しておくのに使用されます。 オリジナルのTCPアルゴリズム、送付者、手動、回のa少ない番号、発信します。 結果として起こるアルゴリズムは、かなり複雑であり、高容量ネットワークのために十分正確なRTTを生産しません。 すべてのヘッダーでのタイムスタンプの包含は、RTTについて計算するのに必要であるコードを簡素化して、アルゴリズムの精度と丈夫さを改良します。
The new algorithm as proposed in RFC 1072 does not appear to have any serious problems. However, the authors of RFC 1072 go to great lengths in an attempt to keep this modification backward compatible with the previous version of TCP. They place an ECHO option in the
RFC1072で提案される新しいアルゴリズムはどんな深刻な問題も持っているように見えません。しかしながら、RFC1072の作者は後方にTCPの旧バージョンと互換性があった状態でこの変更を保つ試みで力を尽くします。 彼らはECHOオプションを置きます。
O'Malley & Peterson [Page 7] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[7ページ]RFC1263TCP拡張子
SYN segment and state, "It is likely that most implementations will properly ignore any options in the SYN segment that they do not understand, so new initial options should not cause problems" [4]. This statement does not exactly inspire confidence, and we consider the addition of an optional field to any protocol to be a de-facto, if not a de-jure, example of an evolutionary change. Optional fields simply attempt to hide the basic incompatibility inside the protocol, it does not eliminate it. Therefore, since we are making an evolutionary change anyway, the only modification to the proposed algorithm is to move the fields into the header proper. Thus, each header will contain 32-bit echo and echo reply fields. Two fields are needed to handle bi-directional data streams.
SYNセグメントと状態(「初期のオプションが彼らは分かりません、非常に新しいので問題を起こさないのは、ほとんどの実現がSYNセグメントで適切にどんなオプションも無視しそうである」[4])。 この声明はまさに信用を奮い立たせないで、私たちは、どんなプロトコルへの任意の分野の追加もデファクト、または法律上のaであると考えます、進化論の変化に関する例。 任意の分野は、プロトコルで基本的な不一致を隠すのを単に試みて、それはそれを排除しません。 したがって、提案されたアルゴリズムへの唯一の変更は私たちがとにかく進化論の変更を行っているので野原をヘッダー自体に動かすことです。 したがって、各ヘッダーは32ビットのエコーとエコー・リプライ分野を含むでしょう。 2つの分野が、双方向のデータ・ストリームを扱うのに必要です。
3.1.2. Window Size and Sequence Number Space
3.1.2. ウィンドウサイズと一連番号スペース
Long Fat Networks (LFN's), networks which contain very high capacity lines with very high latency, introduce the possibility that the number of bits in transit (the bandwidth-delay product) could exceed the TCP window size, thus making TCP the limiting factor in network performance. Worse yet, the time it takes the sequence numbers to wrap around could be reduced to a point below the MSL (maximum segment lifetime), introducing the possibility of old packets being mistakenly accepted as new.
長いFat Networks(LFNのもの)(非常に高い潜在がある非常に高い容量線を含むネットワーク)はトランジット(帯域幅遅れ製品)における、ビットの数がTCPウィンドウサイズを超えるかもしれない可能性を導入します、その結果、TCPをネットワーク性能における限定因子にします。 巻きつけるのに一連番号を要する時をMSL(最大のセグメント生涯)の下のポイントまで短縮できました、まだより悪くて新しいとして誤って認められて、古いパケットの可能性を導入して。
RFC 1072 extends the window size through the use of an implicit constant scaling factor. The window size in the TCP header is multiplied by this factor to get the true window size. This algorithm has three problems. First, one must prove that at all times the implicit scaling factor used by the sender is the same as the receiver. The proposed algorithm appears to do so, but the complexity of the algorithm creates the opportunity for poor implementations to affect the correctness of TCP. Second, the use of a scaling factor complicates the TCP implementation in general, and can have serious effects on other parts of the protocol.
RFC1072は暗黙の一定のけた移動子の使用でウィンドウサイズを広げています。 この要素は、本当のウィンドウサイズを得るためにTCPヘッダーのウィンドウサイズに掛けられます。 このアルゴリズムには、3つの問題があります。最初に、いつも、送付者によって使用された暗黙のけた移動子が受信機と同じであると立証しなければなりません。提案されたアルゴリズムはそうするように見えますが、アルゴリズムの複雑さは不十分な実現がTCPの正当性に影響する機会を作成します。 2番目に、けた移動子の使用は、一般に、TCP実現を複雑にして、プロトコルの他の部分に重大な影響を与えることができます。
A final problem is what we characterize as the "quantum window sizing" problem. Assuming that the scaling factors will be powers of two, the algorithm right shifts the receiver's window before sending it. This effectively rounds the window size down to the nearest multiple of the scaling factor. For large scaling factors, say 64k, this implies that window values are all multiples of 64k and the minimum window size is 64k; advertising a smaller window is impossible. While this is not necessarily a problem (and it seems to be an extreme solution to the silly window syndrome) what effect this will have on the performance of high-speed network links is anyone's guess. We can imagine this extension leading to future papers entitled "A Quantum Mechanical Approach to Network Performance".
最終的な問題は私たちが「量子ウィンドウサイズ処理」問題として特徴付けることです。 けた移動子が2人の強国になると仮定して、それを送る前に、アルゴリズム権利は受信機の窓を移動させます。 事実上、これはウィンドウサイズをけた移動子の最も近い倍数まで一周させます。 これは、窓の値がすべて64kの倍数であることを含意します、そして、大きいけた移動子には、64kを言ってください、そして、最小のウィンドウサイズは64kです。 より小さい窓の広告を出すのは不可能です。 これは必ず問題であるというわけではありません(それは愚かな窓のシンドロームの極端な解決策であるように思える)が、高速ネットワークリンクの性能のときに、これにはどんな効果があるかは、全くの当て推量です。 私たちは、この拡大が「ネットワークパフォーマンスへの量子機械的手法」と題する将来の書類につながると想像できます。
O'Malley & Peterson [Page 8] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[8ページ]RFC1263TCP拡張子
RFC 1185 is an attempt to get around the problem of the window wrapping too quickly without explicitly increasing the sequence number space. Instead, the RFC proposes to use the timestamp used in the ECHO option to weed out old duplicate messages. The algorithm presented in RFC 1185 is complex and has been shown to be seriously flawed at a recent End-to-End Research Group meeting. Attempts are currently underway to fix the algorithm presented in the RFC. We believe that this is a serious mistake.
RFC1185はあまりにすばやく一連番号スペースを明らかに増加させないでウィンドウラッピングの問題を逃れる試みです。 代わりに、RFCは、古い写しメッセージを取り外すのにECHOオプションに使用されるタイムスタンプを使用するよう提案します。 RFC1185に提示されたアルゴリズムは、複雑であり、Endから終わりへのResearch Group最近のミーティングでひどく失敗するように示されました。 試みは、現在、RFCに提示されたアルゴリズムを修理するために進行中です。 私たちは、これが重大な誤りであると信じています。
We see two problems with this approach on a very fundamental level. First, we believe that making TCP depend on accurate clocks for correctness to be a mistake. The Internet community has NO experience with transport protocols that depend on clocks for correctness. Second, the proposal uses two distinct schemes to deal with old duplicate packets: the sliding window algorithm takes care of "new" old packets (packets from the current sequence number epoch) and the timestamp algorithm deals with "old" old packets (packets from previous sequence number epochs). It is hard enough getting one of these schemes to work much less to get two to work and ensure that they do not interfere with one another.
私たちは非常に基本的なレベルにこのアプローチに関する2つの問題を認めます。 まず最初に、私たちは、作成TCPが正当性が誤りであるために正確な時計によると信じています。 インターネットコミュニティには、正当性のために時計によるトランスポート・プロトコルの経験が全くありません。 2番目に、提案は古い写しパケットに対処するのに2つの異なった計画を使用します: 引窓アルゴリズムは古い「新しい」パケット(現在の一連番号時代からのパケット)の世話をします、そして、タイムスタンプアルゴリズムは古い「古い」パケット(前の一連番号時代からのパケット)に対処します。 まして、これらの計画の1つを2が、お互いを妨げないのを扱って、保証するのを得るために働かせるのがそれは十分困難です。
In RFC 1185, the statement is made that "An obvious fix for the problem of cycling the sequence number space is to increase the size of the TCP sequence number field." Using protocol evolution, the obvious fix is also the correct one. The window size can be increased to 32 bits by simply changing a short to a long in the definition of the TCP header. At the same time, the sequence number and acknowledgment fields can be increased to 64 bits. This change is the minimum complexity modification to get the job done and requires little or no analysis to be shown to work correctly.
RFC1185では、「一連番号スペースを循環させるという問題のための明白なフィックスはTCP一連番号分野のサイズを増加させることです」という声明は出されます。 プロトコル発展を使用して、また、明白なフィックスは正しい方です。 ウィンドウサイズは、単にショートをTCPヘッダーの定義における長さに変えることによって、32ビットまで増加できます。 同時に、一連番号と承認分野は64ビットまで増加できます。 この変化は、仕事を完了させる最小の複雑さ変更であり、正しく働くために分析がまず示されないのを必要とします。
On machines that do not support 64-bit integers, increasing the sequence number size is not as trivial as increasing the window size. However, it is identical in cost to the modification proposed in RFC 1185; the high order bits can be thought of as an optimal clock that ticks only when it has to. Also, because we are not dealing with real time, the problems with unreliable system clocks is avoided. On machines that support 64-bit integers, the original TCP code may be reused. Since only very high performance machines can hope to drive a communications network at the rates this modification is designed to support, and the new generation of RISC microprocessors (e.g., MIPS R4000 and PA-RISC) do support 64-bit integers, the assumption of 64-bit arithmetic may be more of an advantage than a liability.
64ビットの整数を支持しないマシンでは、一連番号サイズを増加させるのはウィンドウサイズを増加させるほど些細ではありません。 しかしながら、それはRFC1185で提案された変更への費用が同じです。 考えられなければならないときだけ、カチカチする最適の時計として高位のビットを考えることができます。 また、私たちがリアルタイムに対処していないので、頼り無いシステムクロックに関する問題は避けられます。 64ビットの整数を支持するマシンの上では、元のTCPコードは再利用されるかもしれません。 非常に高い性能マシンだけが、64ビットの整数を支持するようにコミュニケーションがこの変更が支持するように設計されていて、RISCマイクロプロセッサ(例えば、MIPS R4000とPA-RISC)の新しい世代がそうする速度でネットワークでつなぐドライブに望むことができるので、64ビットの演算の仮定は責任より利点であるかもしれません。
O'Malley & Peterson [Page 9] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[9ページ]RFC1263TCP拡張子
3.1.3. Selective Retransmission
3.1.3. 選択しているRetransmission
Another problem with TCP's support for LFN's is that the sliding window algorithm used by TCP does not support any form of selective acknowledgment. Thus, if a segment is lost, the total amount of data that must be re-transmitted is some constant times the bandwidth- delay product, despite the fact that most of the segments have in fact arrived at the receiver. RFC 1072 proposes to extend TCP to allow the receiver to return partial acknowledgments to the sender in the hope that the sender will use that information to avoid unnecessary re-transmissions.
TCPのLFNのサポートに関する別の問題はTCPによって使用された引窓アルゴリズムがどんな形式の選択している承認も支持しないということです。 したがって、セグメントが無くなるなら、再送しなければならないデータの総量は帯域幅遅れ生成物の一定の数倍です、事実上、セグメントの大部分が受信機に到着したという事実にもかかわらず。RFC1072は、受信機が送付者が不要な再トランスミッションを避けるのにその情報を使用するという望みで部分的な承認を送付者に返すのを許容するためにTCPを広げるよう提案します。
It has been our experience on predictable local area networks that the performance of partial re-transmission strategies is highly non- obvious, and it generally requires more than one iteration to find a decent algorithm. It is therefore not surprising that the algorithm proposed in RFC 1072 has some problems. The proposed TCP extension allows the receiver to include a short list of received fragments with every ACK. The idea being that when the receiver sends back a normal ACK, it checks its queue of segments that have been received out of order and sends the relative sequence numbers of contiguous blocks of segments back to the sender. The sender then uses this information to re-transmit the segments transmitted but not listed in the ACK.
それは予測できるローカル・エリア・ネットワークにおける私たちの経験です。部分的な再トランスミッション戦略の性能は非常に非明白です、そして、一般に、きちんとしたアルゴリズムを見つけるのが1つ以上の繰り返しを必要とします。 したがって、RFC1072で提案されたアルゴリズムがいくつかの問題を持っているのは、驚くべきものではありません。提案されたTCP拡張子は、受信機があらゆるACKと共に容認された断片の短いリストを含んでいるのを許容します。 受信機が正常なACKを返送するとき、故障していた状態で受け取られたセグメントの待ち行列をチェックして、隣接のブロックのセグメントの相対的な一連番号を送付者に送って戻すということである考え。 そして、送付者は、伝えられますが、ACKに記載されなかったセグメントを再送するのにこの情報を使用します。
As specified, this algorithm has two related problems: (1) it ignores the relative frequencies of delivered and dropped packets, and (2) the list provided in the option field is probably too short to do much good on networks with large bandwidth-delay products. In every model of high bandwidth networks that we have seen, the packet loss rate is very low, and thus, the ratio of dropped packets to delivered packets is very low. An algorithm that returns ACKs as proposed is simply going to have to send more information than one in which the receiver returns NAKs.
指定されるように、このアルゴリズムには、2つの関連する問題があります: (1) (2) それは渡されて低下しているパケットの相対的な頻度を無視します、そして、オプション・フィールドに提供されたリストはたぶん大きい帯域幅遅れ製品でネットワークで多くを良くすることができないくらい不足しています。 私たちが見た高帯域ネットワークのすべてのモデルでは、パケット損失率は非常に低いです、そして、その結果、低下しているパケット対渡されたパケットの比率は非常に低いです。 提案されるようにACKsを返すアルゴリズムは単に受信機がNAKsを返すものより多くの情報を送らなければならないでしょう。
This problem is compounded by the short size of the TCP option field (44 bytes). In theory, since we are only worried about high bandwidth networks, returning ACKs instead of NAKs is not really a problem; the bandwidth is available to send any information that's needed. The problem comes when trying to compress the ACK information into the 44 bytes allowed. The proposed extensions effectively compresses the ACK information by allowing the receiver to ACK byte ranges rather than segments, and scaling the relative sequence numbers of the re- transmitted segments. This makes it much more difficult for the sender to tell which segments should be re-transmitted, and complicates the re-transmission code. More importantly, one should never compress small amounts of data being sent over a high bandwidth network; it trades a scarce resource for an abundant resource. On
この問題はTCPオプション・フィールド(44バイト)の短いサイズによって悪化させられます。 理論上、私たちが高帯域ネットワークが心配であるだけであるので、NAKsの代わりに戻っているACKsは本当に問題ではありません。 帯域幅は、必要であるどんな情報も送るために利用可能です。 44バイトへの情報が許容したACKを圧縮しようとするとき、問題は来ます。 事実上、提案された拡大は、セグメントよりむしろACKバイト範囲に受信機を許容して、再伝えられたセグメントの相対的な一連番号をスケーリングすることによって、ACK情報を圧縮します。 これは、送付者が、どのセグメントが再送されるべきであるかを言うのをはるかに難しくして、再伝送コードを複雑にします。 より重要に、高帯域ネットワークの上に送られる少量のデータを決して圧縮するべきではありません。 それは豊富なリソースのための不十分なリソースを取り引きします。 オン
O'Malley & Peterson [Page 10] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[10ページ]RFC1263TCP拡張子
low bandwidth networks, selective retransmission is not needed and the SACK option should be disabled.
低い帯域幅ネットワークであり、選択している「再-トランスミッション」は必要ではありません、そして、SACKオプションは無効にされるべきです。
We propose two solutions to this problem. First, the receiver can examine its list of out-of-order packets and guess which segments have been dropped, and NAK those segments back to the sender. The number of NAKs should be low enough that one per TCP packet should be sufficient. Note that the receiver has just as much information as the sender about what packets should be retransmitted, and in any case, the NAKs are simply suggestions which have no effect on correctness.
私たちはこの問題の2つの解決を提案します。 まず最初に、受信機はそれらのセグメントが送付者に支持する推測の故障しているパケット、どのセグメントが落とされるか、そして、およびNAKのリストを調べることができます。 NAKsの数は十分低く、そのTCPパケットあたりの十分であるべきであるということであるべきです。 どんなパケットが再送されるべきであるかに関して受信機には送付者とちょうど同じくらい多くの情報があって、どのような場合でも、NAKsが単に正当性で効き目がない提案であることに注意してください。
Our second proposed modification is to increase the offset field in the TCP header from 4 bits to 16 bits. This allows 64k-bytes of TCP header, which allows us to radically simplify the selective re- transmission algorithm proposed in RFC 1072. The receiver can now simply send a list of 64-bit sequence numbers for the out-of-order segments to the sender. The sender can then use this information to do a partial retransmission without needing an ouji board to translate ACKs into segments. With the new header size, it may be faster for the receiver to send a large list than to attempt to aggregate segments into larger blocks.
私たちの2番目の提案された変更はTCPヘッダーのオフセット分野を4ビットから16ビットまで増強することです。 これは64キロバイトのTCPヘッダーを許容します。(ヘッダーは私たちにRFC1072で提案された選択している再トランスミッションアルゴリズムを根本的に簡素化させます)。 受信機は現在、不適切なセグメントのために単に64ビットの一連番号のリストを送付者に送ることができます。 そして、送付者は、oujiボードがACKsをセグメントに翻訳する必要はなくて部分的な「再-トランスミッション」をするのにこの情報を使用できます。 新しいヘッダーサイズで、より大きいブロックへのセグメントに集めるのを試みるより受信機が大きいリストを送るのは、速いかもしれません。
3.1.4. Header Modifications
3.1.4. ヘッダー変更
The modifications proposed above drastically change the size and structure of the TCP header. This makes it a good time to re-think the structure of the proposed TCP header. The primary goal of the current TCP header is to save bits in the output stream. When TCP was developed, a high bandwidth network was 56kbps, and the key use for TCP was terminal I/O. In both situations, minimal header size was important. Unfortunately, while the network has drastically increased in performance and the usage pattern of the network is now vastly different, most protocol designers still consider saving a few bits in the header to be worth almost any price. Our basic goal is different: to improve performance by eliminating the need to extract information packed into odd length bit fields in the header. Below is our first cut at such a modification.
上で抜本的に提案された変更はTCPヘッダーのサイズと構造を変えます。 これは提案されたTCPヘッダーの構造を再考える良い時間をそれにします。 現在のTCPヘッダーのプライマリ目標は出力ストリームでビットを節約することです。 TCPが開発されたとき、高帯域ネットワークは56kbpsでした、そして、TCPの主要な使用は端末の入出力でした。 両方の状況で、最小量のヘッダーサイズは重要でした。 残念ながら、ネットワークが性能を抜本的に増やして、ネットワークの用法パターンが今広大に異なっている間、ほとんどのプロトコルデザイナーが、ヘッダーで数ビットを節約するのはほとんどどんな価格も価値があるとまだ考えています。 私たちの基本的な目標は異なっています: 向上するために、変な長さに詰め込まれた情報を抜粋する必要性を排除するのによる性能はヘッダーの分野に噛み付きました。 以下に、そのような変更には私たちの最初のカットがあります。
The protocol id field is there to make further evolutionary modifications to TCP easier. This field basically subsumes the protocol number field contained in the IP header with a version number. Each distinct TCP version has a different protocol id and this field ensures that the right code is looking at the right header. The offset field has been increased to 16 bits to support the larger header size required, and to simplify header processing. The code field has been extended to 16 bits to support more options.
TCPへのさらなる進化論の変更をより簡単にするように、プロトコルイド分野はそこにあります。 この分野は基本的にIPヘッダーにバージョン番号で含まれたプロトコルナンバーフィールドを包括します。 それぞれの異なったTCPバージョンには、異なったプロトコルイドがあります、そして、この分野は正しいコードが右のヘッダーを見ているのを確実にします。 サイズが必要としたより大きいヘッダーを支えて、ヘッダー処理を簡素化するためにオフセット分野を16ビットまで増強してあります。 より多くのオプションをサポートするためにコード分野を16ビットまで広げてあります。
O'Malley & Peterson [Page 11] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[11ページ]RFC1263TCP拡張子
The source port and destination port are unchanged. The size of both the sequence number and ACK fields have been increased to 64 bits. The open window field has been increased to 32 bits. The checksum and urgent data pointer fields are unchanged. The echo and echo reply fields are added. The option field remains but can be much larger than in the old TCP. All headers are padded out to 32 bit boundaries. Note that these changes increase the minimum header size from 24 bytes (actually 36 bytes if the ECHO and ECHO reply options defined in RFC 1072 are included on every packet) to 48 bytes. The maximum header size has been increased to the maximum segment size. We do not believe that the the increased header size will have a measurable effect on protocol performance.
ソースポートと仕向港は変わりがありません。 一連番号とACK分野の両方のサイズを64ビットまで増強してあります。 開いている窓分野を32ビットまで増強してあります。 チェックサムと緊急のデータ指針分野は変わりがありません。 エコーとエコー・リプライ分野は加えられます。 オプション・フィールドは、残っていますが、古いTCPよりはるかに大きい場合があります。 すべてのヘッダーが32のビット境界に広げられます。 これらの変化が最小のヘッダーサイズを24バイト(ECHOとECHOが返答するなら、実際に36バイト、RFC1072で定義されたオプションはあらゆるパケットの上に含まれている)から48バイトまで増強することに注意してください。 最大のセグメントサイズに最大のヘッダーサイズを増強してあります。 私たちは、増強されたヘッダーサイズがプロトコル性能に測定できる影響を与えると信じていません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source | Dest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Echo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロトコルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 相殺されます。| コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース| Dest| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ack| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 窓| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 緊急| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エコー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エコー・リプライ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| パッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.5. Backward Compatibility
3.1.5. 後方の互換性
The most likely objection to the proposed TCP extension is that it is not backward compatible with the current version of TCP, and most importantly, TCP's header. In this section we will present three versions of the proposed extension with increasing degrees of backward compatibility. The final version will combine the same degree of backward compatibility found in the protocol described in
提案されたTCP拡張子への最もありそうな異論はそれが最も重要にTCPの最新版と互換性があった状態で後方でないということです、TCPのヘッダー。 このセクションでは、私たちは増加する度合いの後方の互換性で提案された拡大の3つのバージョンを提示するつもりです。 最終版は中で説明されたプロトコルで見つけられた同じ度合いの後方の互換性を結合するでしょう。
O'Malley & Peterson [Page 12] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[12ページ]RFC1263TCP拡張子
RFC's 1072/1185, with the much simpler semantics described in this RFC.
はるかに簡単な意味論がこのRFCで説明されているRFCの1072/1185。
We believe that the best way to preserve backward compatibility is to leave all of TCP alone and support the transparent use of a new protocol when and where it is needed. The basic scheme is the one described in section 2.4. Those machines and operating systems that need to support high speed connections should implement some general protocol infrastructure that allows them to rapidly evolve protocols. Machines that do not require such service simply keep using the existing version of TCP. A virtual protocol is used to manage the use of multiple TCP versions.
私たちは、後方の互換性を保存する最も良い方法がそれが必要である新しいプロトコルのわかりやすい使用にTCPだけとサポートのすべてを残すことであると信じています。 基本的な体系はセクション2.4で説明されたものです。 高速が接続であるとサポートする必要があるそれらのマシンとオペレーティングシステムは彼らが急速にプロトコルを発展できる何らかの一般的なプロトコルインフラストラクチャを実装するべきです。 単にそのようなサービスを必要としないマシンがTCPの既存のバージョンを使用し続けます。 仮想のプロトコルは、複数のTCPバージョンの使用を管理するのに使用されます。
This approach has several advantages. First, it guarantees backward compatibility with ALL existing TCP versions because such implementations will never see strange packets with new options. Second, it supports further modification of TCP with little additional costs. Finally, since our version of TCP will more closely resemble the existing TCP protocol than that proposed in RFC's 1072/1185, the cost of maintaining two simple protocols will probably be lower than maintaining one complex protocol. (Note that with high probability you still have to maintain two versions of TCP in any case.) The only additional cost is the memory required for keeping around two copies of TCP.
このアプローチには、いくつかの利点があります。 そのような実装が新しいオプションで奇妙なパケットを決して見ないので、まず最初に、それはすべての既存のTCPバージョンとの後方の互換性を保証します。 2番目に、それは小さい別途費用でTCPのさらなる変更をサポートします。 最終的に、私たちのTCPのバージョンが、より密接に存在に類似するので、TCPはRFCの1072/1185で提案されたそれより議定書を作ります、2つの簡単なプロトコルがたぶん1つの複雑なプロトコルを維持するよりさらに低くなると主張する費用。 (どのような場合でも、まだTCPの2つのバージョンを維持しなければならないという高い確率でそれに注意してください。) 唯一の別途費用がTCPの写しおよそ2部を取っておくのに必要であるメモリです。
For those that insist that the only efficient way to implement TCP modifications is in a single monolithic protocol, or those that believe that the space requirements of two protocols would be too great, we simply migrate the virtual protocol into TCP. TCP is modified so that when opening a connection, the sender uses the TCP VERSION option attached to the SYN packet to request using the new version. The receiver responds with a TCP VERSION ACK in the SYN ACK packet, after which point, the new header format described in Section 3.1.4 is used. Thus, there is only one version of TCP, but that version supports multiple header formats. The complexity of such a protocol would be no worse than the protocol described in RFC 1072/1185. It does, however, make it more difficult to make additional changes to TCP.
唯一の効率的な道に道具TCP変更には、TCPへの仮想のプロトコルがただ一つの一枚岩的なプロトコル、または2つのプロトコルのスペース要件がすばらし過ぎます、私たちが単に移行するということであると信じているものにあると主張するもののために。 TCPが変更されているので、接続を開くとき、送付者は新しいバージョンを使用することで要求するSYNパケットに付けられたTCP VERSIONオプションを使用します。 受信機はSYN ACKパケットのTCP VERSION ACKと共に応じます、どれが指したかの後にセクション3.1.4で説明された新しいヘッダー形式は使用されています。 したがって、TCPの1つのバージョンしかありませんが、そのバージョンは複数のヘッダー形式をサポートします。 そのようなプロトコルの複雑さはRFC1072/1185で説明されたプロトコルほど悪くないでしょう。 しかしながら、それで、付加的な変化をTCPにするのは、より難しくなります。
Finally, for those that believe that the preservation of the TCP's header format has any intrinsic value (e.g., for those that don't want to re-program their ethernet monitors), a header compatible version of our proposal is possible. One simply takes all of the additional information contained in the header given in Section 3.1.4 and places it into a single optional field. Thus, one could define a new TCP option which consists of the top 32 bits of the sequence and ack fields, the echo and echo_reply fields, and the top 16 bits of the window field. This modification makes it more difficult to take
最終的に、TCPのヘッダー形式の保存にはどんな実態価値(例えば、彼らのイーサネットモニターのプログラムを変えたがっていないもののための)もあると信じているものに関して私たちの提案のヘッダーコンパチブルバージョンは可能です。 1つは、単にセクション3.1.4で与えられているヘッダーに含まれた追加情報のすべてを取って、ただ一つの任意の分野にそれを置きます。 したがって、人は窓の分野の系列の32ビットの先端、ack分野、エコー、エコー_回答分野、および16ビットの先端から成る新しいTCPオプションを定義できました。 この変更で、取るのは、より難しくなります。
O'Malley & Peterson [Page 13] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[13ページ]RFC1263TCP拡張子
advantage of machines with 64-bit address spaces, but at a minimum will be just as easy to process as the protocol described in RFC 1072/1185. The only restriction is that the size of the header option field is still limited to 44 bytes, and thus, selective retransmission using NAKs rather than ACKs will probably be required.
処理するのが最小限でプロトコルがRFC1072/1185で説明したのとちょうど同じくらい簡単であるのを除いた64ビットのアドレス空間があるマシンの利点。 唯一の制限はヘッダーオプション・フィールドのサイズがまだ44バイトに制限されていて、その結果、ACKsよりむしろNAKsを使用する選択している「再-トランスミッション」がたぶん必要であるということです。
The key observation is that one should make a protocol extension correct and simple before trying to make it backward compatible. As far as we can tell, the only advantages possessed by the protocol described in RFC 1072/1185 is that its typical header, size including options, is 8 to 10 bytes shorter. The price for this "advantage" is a protocol of such complexity that it may prove impossible for normal humans to implement. Trying to maintain backward compatibility at every stage of the protocol design process is a serious mistake.
主要な観測は後方にそれを作ろうとする前に正しくて簡単なプロトコル拡大を互換性があるようにするべきであるということです。 私たちが判断できる限り、RFC1072/1185で説明されたプロトコルによって持たれていた唯一の利点は典型的なヘッダー(オプションを含むサイズ)が8〜10バイトより少ないということです。 この「利点」の価格は普通の人間が実装するのが、不可能であると判明するくらいの複雑さのプロトコルです。 プロトコルデザイン過程のあらゆる段階で後方の互換性を維持しようとするのは、重大な誤りです。
3.2. TCP Over Extension
3.2. 拡大の上のTCP
Another potential problem with TCP that has been discussed recently, but has not yet resulted in the generation of an RFC, is the potential for TCP to grab and hold all 2**16 port numbers on a given machine. This problem is caused by short port numbers, long MSLs, and the misuse of TCP as a request-reply protocol. TCP must hold onto each port after a close until all possible messages to that port have died, about 240 seconds. Even worse, this time is not decreasing with increase network performance. With new fast hardware, it is possible for an application to open a TCP connection, send data, get a reply, and close the connection at a rate fast enough to use up all the ports in less than 240 seconds. This usage pattern is generated by people using TCP for something it was never intended to do--- guaranteeing at-most-once semantics for remote procedure calls.
最近議論しましたが、RFCの世代ではまだ結果になっていないTCPの別の潜在的な問題はTCPが与えられたマシンの上にすべての2**16ポートナンバーをつかんで、保持する可能性です。 この問題は要求回答プロトコルとしてTCPの短いポートナンバー、長いMSLs、および誤用で引き起こされます。 そのポートへのすべての可能なメッセージが消え失せるまで、TCPは閉鎖の後に各ポートを握らなければなりません、およそ240秒。 さらにひどく、増加に従って、今回はネットワーク性能を減少させていません。 新しい速いハードウェアでは、アプリケーションが240秒未満ですべてのポートを使いきることができるくらい速くTCP接続を開いて、データを送って、回答を得て、レートで接続を終えるのは、可能です。 この用法パターンは、する決して意図しなかったことにTCPを使用することで人々によって作られます。--- 保証、大部分、一度、遠隔手続き呼び出しのための意味論。
The proposed solution is to embed an RPC protocol into TCP while preserving backward compatibility. This is done by piggybacking the request message on the SYN packet and the reply message on the SYN- ACK packet. This approach suffers from one key problem: it reduces the probability of a correct TCP implementation to near 0. The basic problem has nothing to do with TCP, rather it is the lack of an Internet request-reply protocol that guarantees at-most-once semantics.
提案されたソリューションは後方の互換性を保存している間、RPCプロトコルをTCPに埋め込むことです。 SYN- ACKパケットでSYNパケットと応答メッセージで要求メッセージを背負うことによって、これをします。 このアプローチは1つの主要な問題に苦しみます: それは正しいTCP実装の確率を近い0まで減少させます。 基本的問題がTCPと関係なく、むしろそれがそれが保証するインターネット要求回答プロトコルの不足である、大部分、一度、意味論。
We propose to solve this problem by the creation of a new protocol. This has already been attempted with VMTP, but the size and complexity of VMTP, coupled with the process currently required to standardize a new protocol doomed it from the start. Instead of solving the general problem, we propose to use Sprite RPC [7], a much simpler protocol, as a means of off-loading inappropriate users from TCP.
私たちは、新しいプロトコルの作成でこの問題を解決するよう提案します。 VMTPのVMTP、サイズ、および複雑さだけで既にこれを試みてあって、結合されて、現在新しいプロトコルを標準化していなければならないプロセスは始めからそれを運命づけました。 一般的問題を解決することの代わりに、私たちは、Sprite RPC[7]、はるかに簡単なプロトコルを使用するよう提案します、TCPから不適当なユーザを積み下ろす手段として。
O'Malley & Peterson [Page 14] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[14ページ]RFC1263TCP拡張子
The basic design would attempt to preserve as much of the TCP interface as possible in order that current TCP (mis)users could be switched to Sprite RPC without requiring code modification on their part. A virtual protocol could be used to select the correct protocol TCP or Sprite RPC if it exists on the other machine. A backward compatible modification to TCP could be made which would simply prevent it from grabbing all of the ports by refusing connections. This would encourage TCP abusers to use the new protocol.
基本的なデザインが、現在になるようにできるだけ多くのTCPインタフェースを保持するのを試みるだろう、TCP、(誤、)、先方においてはコード変更を必要としないで、ユーザをSprite RPCに切り換えることができました。 もう片方のマシンの上に存在しているなら、仮想のプロトコルは、正しいプロトコルTCPかSprite RPCを選択するのに使用されるかもしれません。 TCPへのそれが接続を拒否することによって単にポートのすべてがつかむことができない後方のコンパチブル変更はすることができました。 これは、TCP虐待者が新しいプロトコルを使用するよう奨励するでしょう。
Sprite RPC, which is designed for a local area network, has two problems when extended into the Internet. First, it does not have a usefully flow control algorithm. Second, it lacks the necessary semantics to reliably tear down connections. The lack of a tear down mechanism needs to be solved, but the flow control problem could be dealt with in later iterations of the protocol as Internet blast protocols are not yet well understood; for now, we could simple limit the size of each message to 16k or 32k bytes. This might also be a good place to use a decomposed version of Sprite RPC [2], which exposes each of these features as separate protocols. This would permit the quick change of algorithms, and once the protocol had stabilized, a monolithic version could be constructed and distributed to replace the decomposed version.
小妖精RPC(ローカル・エリア・ネットワークのために設計されている)には、インターネットに広げられると、2つの問題があります。 それには、最初に、aが有効にありません。フロー制御アルゴリズム。 2番目に、それは接続の下側まで確かに引き裂く必要な意味論を欠いています。 メカニズムの下側への裂け目の不足は、解決される必要がありますが、インターネット爆破プロトコルがまだよく理解されていないとき、プロトコルの後の繰り返しでフロー制御問題に対処できました。 当分、私たちはそれぞれのサイズが16kへ通信させる簡単な限界か32キロバイトをそうすることができました。 また、これは別々のプロトコルとしてそれぞれのこれらの特徴を暴露するSprite RPC[2]の分解しているバージョンを使用する良い場所であるかもしれません。 これがアルゴリズムの早変わりを可能にして、プロトコルがいったん安定していると、一枚岩的なバージョンは、分解しているバージョンを置き換えるために構成されて、分配されるかもしれません。
In other words, the basic strategy is to introduce as simple of RPC protocol as possible today, and later evolve this protocol to address the known limitations.
言い換えれば、基本戦略は、今日できるだけRPCで簡単なプロトコルを紹介して、後で知られている制限を扱うこのプロトコルを発展することです。
3.3. Future Modifications
3.3. 今後の変更
The header prediction algorithm should be generalized so as to be less sensitive to changes in the protocols header and algorithm. There almost seems to be as much effort to make all modifications to TCP backward compatible with header prediction as there is to make them backward compatible with TCP. The question that needs to be answered is: are there any changes we can made to TCP to make header prediction easier, including the addition of information into the header. In [6], the authors showed how one might generalize optimistic blast from VMTP to almost any protocol that performs fragmentation and reassembly. Generalizing header prediction so that it scales with TCP modification would be step in the right direction.
ヘッダー予測アルゴリズムは、それほどプロトコルヘッダーとアルゴリズムにおける変化に敏感にならないように広められるべきです。 後方にヘッダー予測と互換性があった状態でTCPへのすべての変更をする後方にTCPと互換性があった状態でそれらを作るためにあるのと同じくらい多くの取り組みがあるようにほとんど思えます。 答えられる必要がある質問は以下の通りです。 情報の追加をヘッダーに含めて、ヘッダー予測がTCPにより簡単にさせられて、私たちがそうすることができるいくつかの変化がありますか? [6]では、作者は1つにどう楽観的なVMTPから断片化を実行するほとんどどんなプロトコルまでの爆破も一般化して、再アセンブリされるかもしれないかを示しました。 ヘッダー予測を一般化して、したがって、TCP変更で比例するのは、正しい方向にステップでしょう。
It is clear that an evolutionary change to increase the size of the source and destination ports in the TCP header will eventually be necessary. We also believe that TCP could be made significantly simpler and more flexible through the elimination of the pseudo- header. The solution to this problem is to simply add a length field and the IP address of the destination to the TCP header. It has also
TCPヘッダーのソースと仕向港のサイズを増強する進化論の変化が結局必要になるのは、明確です。 また、私たちは、TCPを疑似ヘッダーの除去でかなり簡単でよりフレキシブルにすることができたと信じています。 この問題への解決は単に長さの分野と目的地のIPアドレスをTCPヘッダーに加えることです。 また、それはそうしました。
O'Malley & Peterson [Page 15] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[15ページ]RFC1263TCP拡張子
been mentioned that better and simpler TCP connection establishment algorithms would be useful. Some form of reliable record stream protocol should be developed. Performing sliding window and flow control over records rather than bytes would provide numerous opportunities for optimizations and allow TCP to return to its original purpose as a byte-stream protocol. Finally, it has become clear to us that the current Internet congestion control strategy is to use TCP for everything since it is the only protocol that supports congestion control. One of the primary reasons many "new protocols" are proposed as TCP options is that it is the only way to get at TCP's congestion control. At some point, a TCP-independent congestion control scheme must be implemented and one might then be able to remove the existing congestion control from TCP and radically simplify the protocol.
言及されて、そんなにより良くて、より簡単なTCPコネクション確立アルゴリズムは役に立つでしょう。 何らかのフォームの信頼できる記録的なストリームプロトコルは開発されるべきです。 バイトよりむしろ記録の上で引窓とフロー制御を実行するのは、多数の機会を最適化に与えて、TCPがバイト・ストリームプロトコルとして初心に戻るのを許容するでしょう。 最終的に、現在のインターネットふくそう制御方式がそれが混雑がコントロールであるとサポートする唯一のプロトコルであるのですべてにTCPを使用することであることは私たちにとって明確になりました。 多くの「新しいプロトコル」がTCPオプションとして提案されるプライマリ理由の1つはそれがTCPの輻輳制御に達する唯一の方法であるということです。 何らかのポイントでは、TCPから独立している輻輳制御体系を実装しなければならなくて、1つは、TCPから既存の輻輳制御を取り除いて、そしてときにプロトコルを根本的に簡素化できるかもしれません。
4. Discussion
4. 議論
One obvious side effect of the changes we propose is to increase the size of the TCP header. In some sense, this is inevitable; just about every field in the header has been pushed to its limit by the radical growth of the network. However, we have made very little effort to make the minimal changes to solve the current problem. In fact, we have tended to sacrifice header size in order to defer future changes as long as possible. The problem with this is that one of TCP's claims to fame is its efficiency at sending small one byte packets over slow networks. Increasing the size of the TCP header will inevitably result in some increase in overhead on small packets on slow networks. Clark among others have stated that they see no fundamental performance limitations that would prevent TCP from supporting very high speed networks. This is true as far as it goes; there seems to be a direct trade-off between TCP performance on high speed networks and TCP performance on slow speed networks. The dynamic range is simply too great to be optimally supported by one protocol. Hence, in keeping around the old version of TCP we have effectively split TCP into two protocols, one for high bandwidth lines and the other for low bandwidth lines.
私たちが提案する変化の1回の明白な副作用がTCPヘッダーのサイズを増強することになっています。 何らかの意味で、これは必然です。 ヘッダーのほとんどあらゆる野原がネットワークの急進的な成長によって限界に押されました。 しかしながら、私たちは、現在の問題を解決するために最小量の変更を行うためにほとんど取り組みにしていません。 事実上、私たちは、できるだけ長い間将来の変化を延期するためにヘッダーサイズを犠牲にする傾向がありました。 これに関する問題は名声へのTCPのクレームの1つが1バイトの小さいパケットを遅いネットワークの上に送ることにおいて効率であるということです。 TCPヘッダーのサイズを増強すると、オーバーヘッドの何らかの増加が遅いネットワークで小型小包で必然的にもたらされるでしょう。 クラークは、彼らがTCPが、非常に高い速度がネットワークであるとサポートするのを防ぐどんな基本的な性能制限も見ないと特に述べました。 これはある程度本当です。 ダイレクトトレードオフは高速ネットワークに関するTCP性能と遅い速度ネットワークに関するTCP性能の間であるように思えます。 ダイナミックレンジは単に1つのプロトコルで最適にサポートすることができないくらいすばらしいです。 したがって、TCPの古いバージョンの周りに保つ際に、事実上、私たちは2つのプロトコルへのTCP、高帯域系列のための1つ、および低い帯域幅系列のためのもう片方を分けました。
Another potential argument is that all of the changes mentioned above should be packaged together as a new version of TCP. This version could be standardized and we could all go back to the status quo of stable unchanging protocols. While to a certain extent this is inevitable---there is a backlog of necessary TCP changes because of the current logistical problems in modifying protocols---it is only begs the question. The status quo is simply unacceptably static; there will always be future changes to TCP. Evolutionary change will also result in a better and more reliable TCP. Making small changes and distributing them at regular intervals ensures that one change
別の潜在的議論は前記のように変化のすべてがTCPの新しいバージョンとして一緒にパッケージされるべきであるということです。 このバージョンを標準化できました、そして、私たちは皆、安定した変らないプロトコルの現状に戻ることができました。 ある程度これは必然ですが---現在のロジスティクスの問題のために、プロトコルを変更するのにおいて必要なTCP変化の予備があります。---それはそうです。論点を巧みに避けます。 現状は単に容認できないほど静的です。 TCPへの将来の変化がいつもあるでしょう。 また、進化論の変化は、より良くて、より信頼できるTCPをもたらすでしょう。 ばら銭を作って、それらを分配すると、その1回の変化が一定の間隔を置いて確実にされます。
O'Malley & Peterson [Page 16] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[16ページ]RFC1263TCP拡張子
has actually been stabilized before the next has been made. It also presents a more balanced workload to the protocol designer; rather than designing one new protocol every 10 years he makes annual protocol extensions. It will also eventually make protocol distribution easier: the basic problem with protocol distribution now is that it is done so rarely that no one knows how to do it and there is no incentive to develop the infrastructure needed to perform the task efficiently. While the first protocol distribution is almost guaranteed to be a disaster, the problem will get easier with each additional one. Finally, such a new TCP would have the same problems as VMTP did; a radically new protocol presents a bigger target.
実際に、次が作られている前に安定していました。 また、それはプロトコルデザイナーによりバランスのとれているワークロードを提示します。 彼が作る10年あたり1つの新しいプロトコルに例年のプロトコル拡大を設計するよりむしろ。 また、それで、プロトコル分配は結局、より簡単になるでしょう: 現在、プロトコル分配に関する基本的問題はだれもあまりにめったにそれをしないのでそれをする方法を知らないで、また効率的にタスクを実行するのに必要であるインフラストラクチャを開発する誘因が全くないということです。 最初のプロトコル分配が災害になるようにほとんど保証されている間、問題はそれぞれの追加もので、より簡単になるでしょう。 最終的に、そのような新しいTCPには同じ問題がVMTPが持っていたようにあるでしょう。 根本的に新しいプロトコルは、より大きい目標を提示します。
The violation of backward compatibility in systems as complex as the Internet is always a serious step. However, backward compatibility is a technique, not a religion. Two facts are often overlooked when backward compatibility gets out of hand. First, violating backward compatibility is always a big win when you can get away with it. One of the key advantages of RISC chips over CISC chips is simply that they were not backward compatible with anything. Thus, they were not bound by design decisions made when compilers were stupid and real men programmed in assembler. Second, one is going to have to break backward compatibility at some point anyway. Every system has some headroom limitations which result in either stagnation (IBM mainframe software) or even worse, accidental violations of backward compatibility.
いつもインターネットと同じくらい複雑なシステムにおける、後方の互換性の違反は重大なステップです。 しかしながら、後方の互換性は信仰ではなく、テクニックです。 後方の互換性が手に負えなくなるとき、2つの事実がしばしば見落とされます。 あなたがそれをうまくやることができるとき、まず最初に、いつも後方の互換性に違反するのは、思わぬ幸運です。 単に、CISCチップの上のRISCチップの主要な利点の1つはそれらが何とも互換性があった状態で後方でなかったということです。 コンパイラがアセンブラでプログラムされた愚かで本当の男性であったときに、したがって、それらは決定が作ったデザインによって縛られませんでした。 2番目、ものは何らかのポイントでとにかく後方の互換性を壊さなければならないでしょう。 あらゆるシステムには、後方の互換性の停滞(IBMメインフレームソフトウェア)か、より悪くて、偶然の違反のどちらかさえもたらすいくつかの空間制限があります。
Of course, the biggest problem with our approach is that it is not compatible with the existing standardization process. We hope to be able to design and distribute protocols in less time than it takes a standards committee to agree on an acceptable meeting time. This is inevitable because the basic problem with networking is the standardization process. Over the last several years, there has been a push in the research community for lightweight protocols, when in fact what is needed are lightweight standards. Also note that we have not proposed to implement some entirely new set of "superior" communications protocols, we have simply proposed a system for making necessary changes to the existing protocol suites fast enough to keep up with the underlying change in the network. In fact, the first standards organization that realizes that the primary impediment to standardization is poor logistical support will probably win.
もちろん、私たちのアプローチに関する最も大きい問題はそれが既存の標準化過程と互換性がないということです。 私たちは、許容できるミーティング時間に同意するのに規格委員会を要するより少ない時間プロトコルを設計して、分配できることを望んでいます。 ネットワークに関する基本的問題が標準化過程であるので、これは必然です。 ここ数年間、プッシュが軽量のプロトコルのための研究団体にあります、事実上、必要であるものが軽量の規格であるときに。 また、私たちが、いくつかの完全に新しい「優れた」通信規約を実装するよう提案していないことに注意してください、と存在への必要な改革にスイートについてネットワークにおける基本的な変化について行くことができるくらい速く議定書の中で述べさせながら、私たちは単にシステムを提案しました。 事実上、標準化のプライマリ障害が貧しい後方支援であるとわかる最初の規格組織はたぶん勝つでしょう。
5. Conclusions
5. 結論
The most important conclusion of this RFC is that protocol change happens and is currently happening at a very respectable clip. While all of the changes given as example in this document are from TCP, there are many other protocols that require modification. In a more
このRFCの最も重要な結論はプロトコル変化が起こって、現在非常に立派なクリップで起こっているということです。 例として与えられた変化のすべてがTCPから本書では来ていますが、変更を必要とする他の多くのプロトコルがあります。 a、 より多く
O'Malley & Peterson [Page 17] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[17ページ]RFC1263TCP拡張子
prosaic domain, the telephone company is running out of phone numbers; they are being overrun by fax machines, modems, and cars. The underlying cause of these problems seems to be an consistent exponential increase almost all network metrics: number of hosts, bandwidth, host performance, applications, and so on, combined with an attempt to run the network with a static set of unchanging network protocols. This has been shown to be impossible and one can almost feel the pressure for protocol change building. We simply propose to explicitly deal with the changes rather keep trying to hold back the flood.
平凡なドメイン、電話会社は電話番号を使い果たしています。 それらはファックス装置、モデム、および車によってオーバランさせられています。 これらの問題の根本にある原因は一貫した急激な増加がほとんどすべてのネットワーク測定基準であったなら見えます: ホストの数(帯域幅、ホスト性能、アプリケーションなど)は、静的な変らないネットワーク・プロトコルでネットワークを経営している試みに結合しました。 これは不可能になるように示されました、そして、人はプロトコル変化ビルに対する圧力をほとんど感じることができます。 明らかに、むしろ洪水を抑えようとする生活費は変化を取扱います私たちが、単に提案する。
Of almost equal importance is the observation that TCP is a protocol and not a platform for implementing other protocols. Because of a lack of any alternatives, TCP has become a de-facto platform for implementing other protocols. It provides a vague standard interface with the kernel, it runs on many machines, and has a well defined distribution path. Otherwise sane people have proposed Bounded Time TCP (an unreliable byte stream protocol), Simplex TCP (which supports data in only one direction) and Multi-cast TCP (too horrible to even consider). All of these protocols probably have their uses, but not as TCP options. The fact that a large number of people are willing to use TCP as a protocol implementation platform points to the desperate need for a protocol independent platform.
ほとんど等しい重要性は他のプロトコルを実装するためのプラットホームではなく、TCPがプロトコルであるという観測です。 どんな選択肢の不足のためにも、TCPは他のプロトコルを実装するためのデファクトプラットホームになりました。 あいまいな標準インターフェースにカーネルを提供して、それは、多くのマシンで動いて、よく定義された分配経路を持っています。 そうでなければ、気が確かな人々はBounded Time TCP(頼り無いバイト・ストリームプロトコル)を提案しました、Simplex TCP(一方向だけにデータをサポートする)とMulti-キャストTCP(考えることさえできないくらいものすごい)。 これらのプロトコルのすべてが、たぶん役に立つことがありますが、TCPオプションとして役に立つことがあるというわけではありません。 多くの人々が、プロトコル実装プラットホームとしてTCPを使用しても構わないと思っているという事実はプロトコルの独立しているプラットホームの破れかぶれの必要性を示します。
Finally, we point out that in our research we have found very little difference in the actual technical work involved with the three proposed methods of protocol modification. The amount of work involved in a backward compatible change is often more than that required for an evolutionary change or the creation of a new protocol. Even the distribution costs seem to be identical. The primary cost difference between the three approaches is the cost of getting the modification approved. A protocol modification, no matter how extensive or bizarre, seems to incur much less cost and risk. It is time to stop changing the protocols to fit our current way of thinking, and start changing our way of thinking to fit the protocols.
最終的に、私たちは、研究では、実際の技術的な仕事の違いがほとんどプロトコル変更のメソッドに提案される3にかかわらなかったのがわかったと指摘します。 後方のコンパチブル変化にかかわる仕事量はそれが進化論の変化か新しいプロトコルの作成に必要であるというよりもしばしば多いです。 分配コストさえ同じであるように思えます。 3つのアプローチのプライマリ原価差異は変更を承認させる費用です。 プロトコル変更はどれくらい大規模であるか奇妙であってもまして、費用と危険を被るように思えます。 私たちの思う現在のやり方に合って、プロトコルに合うように考え方を変え始めるためにプロトコルを変えるのをもう止めるべき時間です。
6. References
6. 参照
[1] Cheriton D., "VMTP: Versatile Message Transaction Protocol", RFC
1045, Stanford University, February 1988.
[1] Cheriton D.、「VMTP:」 「多能なメッセージトランザクションプロトコル」、RFC1045、スタンフォード大学、1988年2月。
[2] Hutchinson, N., Peterson, L., Abbott, M., and S. O'Malley, "RPC in
the x-Kernel: Evaluating New Design Techniques", Proceedings of the
12th Symposium on Operating System Principles, Pgs. 91-101,
[2] ハッチンソン、N.、ピーターソン、L.、アボット、M.、およびS.オマリー、「x-カーネルにおけるRPC:」 「新案のテクニックを評価します」、オペレーティングシステムプリンシプルズ、Pgsにおける第12シンポジウムの議事。 91-101,
O'Malley & Peterson [Page 18] RFC 1263 TCP Extensions Considered Harmful October 1991
1991年10月に有害であると考えられたオマリーとピーターソン[18ページ]RFC1263TCP拡張子
December 1989.
1989年12月。
[3] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88,
August 1988.
[3] SIGCOMM1988年8月88年の間のジェーコブソンと、V.と、「輻輳回避とコントロール」
[4] Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths",
RFC 1072, LBL, ISI, October 1988.
[4] ジェーコブソン、V.、およびR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」、RFC1072、LBL、ISI、1988年10月。
[5] Jacobson, V., Braden, R., and L. Zhang, "TCP Extensions for High-
Speed Paths", RFC 1185, LBL, ISI, PARC, October 1990.
[5] ジェーコブソン、V.、ブレーデン、R.、およびL.チャン、「高値のためのTCP拡張子は経路を促進します」、RFC1185、LBL、ISI、PARC、1990年10月。
[6] O'Malley, S., Abbott, M., Hutchinson, N., and L. Peterson, "A Tran-
sparent Blast Facility", Journal of Internetworking, Vol. 1, No.
2, Pgs. 57-75, December 1990.
Internetworking、Vol.1、No.2(Pgs)の[6] オマリーとS.とアボットとM.とハッチンソン、N.とL.ピーターソン、「チャンsparent Blast Facility」Journal。 57-75と、1990年12月。
[7] Welch, B., "The Sprite Remote Procedure Call System", UCB/CSD
86/302, University of California at Berkeley, June 1988.
[7] ウェルチ、B.、「小妖精遠隔手続き呼び出しシステム」、UCB/CSD86/302、カリフォルニア大学バークレイ校、1988年6月。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Authors' Addresses
8. 作者のアドレス
Larry L. Peterson University of Arizona Department of Computer Sciences Tucson, AZ 85721
コンピューターサイエンシズのツーソン、アリゾナ 85721人のラリーL.ピーターソンアリゾナ大学部
Phone: (602) 621-4231 EMail: llp@cs.arizona.edu
以下に電話をしてください。 (602) 621-4231 メールしてください: llp@cs.arizona.edu
Sean O'Malley University of Arizona Department of Computer Sciences Tucson, AZ 85721
コンピューターサイエンシズのツーソン、アリゾナ 85721人のショーンオマリーアリゾナ大学部
Phone: 602-621-8373 EMail: sean@cs.arizona.edu
以下に電話をしてください。 602-621-8373 メールしてください: sean@cs.arizona.edu
O'Malley & Peterson [Page 19]
オマリーとピーターソン[19ページ]
一覧
スポンサーリンク
