RFC 5984 - Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding 日本語訳

URL : https://tools.ietf.org/html/rfc5984
タイトル : RFC 5984 - ESPベースの転送をIPネットワークにおけるスループットの増加：ESPBasedForwarding
翻訳編集 : 自動生成

Independent Submission                                       K-M. Moller
Request for Comments: 5984                                  1 April 2011
Category: Experimental
ISSN: 2070-1721

    Increasing Throughput in IP Networks with ESP-Based Forwarding:
                           ESPBasedForwarding

Abstract

抽象

This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.

この文書では、ESPベースの転送を使用することにより、IPネットワークに無限の帯域幅に到達する実験的な方法を提案しています。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5984.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5984で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
     2.1.  Experiments with Black Fiber  . . . . . . . . . . . . . . . 3
     2.2.  Schrodinger's Cat Experiment  . . . . . . . . . . . . . . . 3
   3.  ESP-Based Forwarding  . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Principle of Operation  . . . . . . . . . . . . . . . . . . 4
     3.2.  Architectural Components  . . . . . . . . . . . . . . . . . 4
       3.2.1.  DPAUI . . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.2.2.  PPG . . . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.2.3.  IID . . . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.2.4.  CFE . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       3.2.5.  PPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       3.2.6.  ND  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  End User Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  TCP Slow-Start Considerations . . . . . . . . . . . . . . . . . 7
   6.  Market Considerations . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8

1. Introduction

1. はじめに

Mechanisms for efficient packet forwarding has evolved over the past years. The demand for bandwidth is always increasing. Instead of optimizing forwarding performance and link capacity in an incremental fashion, we propose a brand new concept in packet forwarding that will provide unsurpassed end user performance regardless of link capacity, distance, and number of hops.

効率的なパケット転送のためのメカニズムは、過去数年にわたって進化してきました。帯域幅の需要は常に増加しています。代わりに、増分形式で転送パフォーマンスとリンク容量を最適化する、我々は関係なく、リンク容量、距離、ホップ数の卓越したエンドユーザのパフォーマンスを提供しますパケット転送でのブランドの新しいコンセプトを提案します。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

2. Background

2.背景

During the past years, there have been a lot of improvements made in the domain of packet forwarding. Both software and hardware optimizations combined with increased link capacities have cut down round-trip times. Despite these improvements, many users find themselves frustrated since their demand for bandwidth has increased faster than the supply.

過去数年の間に、パケット転送のドメインで行われた多くの改善がなされています。増加したリンク容量と組み合わせたソフトウェアとハードウェアの両方の最適化は、往復時間を削減しています。帯域幅のための彼らの需要が速い供給よりも増加しているため、これらの改善にもかかわらず、多くのユーザーは、自身が不満を見つけます。

The current incremental approach to lower latency and increase capacity will soon reach the end of the road. The reason for this has been known for some time and is stated in RFC 1925 [RFC1925] clause 2:

低レイテンシーと増加能力に現在の増分のアプローチは、すぐに道路の端に到達します。この理由は、いくつかの時間のために知られており、RFC 1925 [RFC1925]節2に記載されています。

"(2) No matter how hard you push and no matter what the priority, you can't increase the speed of light."

「（2）あなたはどんな優先順位プッシュしないとどのようにハードに関係なく、あなたは光の速度を上げることができません。」

Our research has finally been able to circumvent this boundary by the development of zero-latency network paths.

我々の研究は、最終的には、ゼロレイテンシーのネットワークパスの開発によって、この境界を回避することができました。

Inspired by RFC 1072 [RFC1072], where a network containing a long, fat pipe is called LFN (pronounced "elephan(t)"), we will refer to an internet path with zero-latency as "infinitely fat", and a network containing this path as "IFN" (pronounced "infan(t)").

長い脂肪パイプを含むネットワークがLFN（発音「elephan（T）」）と呼ばれているRFC 1072 [RFC1072]、触発され、我々は「無限ファット」とゼロ遅延とインターネットパスを参照し、ネットワーク"IFN" としてこの経路を含む（ "infan（T）" と発音）。

Before the invention of this new forwarding principle, several experimental methods were tried. We have chosen to share our failed attempts in order help others avoid the same mistakes that we encountered. The following two methods have been dismissed:

この新しい転送原理の発明前に、いくつかの実験の方法が試みられました。私たちは、ヘルプ他の人たちが遭遇した同じ過ちを避けるために、私たちの失敗を共有することを選択しました。次の2つの方法が却下されています：

o Black Fiber o Schrodinger's cat experiment

シュレーディンガーの猫の実験〇〇ブラックファイバー

2.1. Experiments with Black Fiber

2.1. ブラックファイバーを用いた実験

Attempting to push the speed-of-light limitation by means of using black fiber looked promising at first. Shortly after initiating the experiment, lack of light was detected in the black fiber. This was interpreted as proof of successful data transmission faster than the speed of light. After popping the champagne, the following problems were detected:

黒色繊維を用いることによって高速の光制限をプッシュしようとすると、最初は有望に見えました。まもなく実験を開始した後、光の欠如は黒い繊維で検出されました。これは、より速い光の速度よりも成功したデータ伝送の証拠として解釈されました。シャンパンをポップした後、以下の問題が検出されました：

1. No data reached the receiver. 2. The fiber was not connected at the transmitting side.

1.ませデータは受信機に到達していません。 2.繊維は、送信側に接続されていませんでした。

This clearly spoiled the mood of the party.

これは明らかに党の気分を台無しに。

2.2. Schrodinger's Cat Experiment

2.2. シュレーディンガーの猫の実験

The Schrodinger's netcat experiment was based on an attempt to implement the method described by E. Schrodinger [Schrodinger35]. The original procedure includes locking up cats in boxes with radioactive materials and poisonous gas. Data communication capabilities were added to the experiment, by using netcat. The research team was dumbfounded by the notion that the cat experiment seemed to work and not work at the same time. This was also confirmed by a friend of Wigner's [Wigner].

シュレーディンガーのnetcat実験E.シュレディンガー[Schrodinger35]によって記載された方法を実施するための試みに基づいていました。元の手順では、放射性物質や有毒ガスとボックスに猫をロック含みます。データ通信機能は、netcatをを使用することにより、実験に追加されました。研究チームは、猫の実験が動作し、同時に動作しないように見えた概念で唖然とされました。これは、ウィグナーの[ウィグナー]の友人によって確認されました。

A detailed analysis of the experiment indicated that the probability vectors collapsed whenever traffic was sent to the box. The conclusion was that this approach would only work without traffic, thus eliminating all practical applications.

実験の詳細な分析は、トラフィックがボックスに送信されたときはいつでも、確率ベクトルが崩壊することを示しました。結論は、このアプローチが唯一のため、すべての実用的なアプリケーションを排除し、トラフィックなしに働くだろうということでした。

3. ESP-Based Forwarding

3. ESPベースの転送

Experiments with ESP-based (Extra Sensory Perception) forwarding has proved to successfully remove the limitation in RFC 1925 [RFC1925].

ESPベース（超感覚的知覚）を用いた実験転送が正常にRFC 1925 [RFC1925]に制限を除去することが証明されています。

The foundation for the ESP-based forwarding scheme is to reduce latency by means of precognitive datagram detection and generation. By applying this technology, latency will not only reach zero, but might even become negative.

ESPベースの転送方式の基盤は、予知データグラムの検出および生成によって待ち時間を低減することです。この技術を適用することにより、待ち時間がゼロになるだけでなく、それでもマイナスになる可能性があります。

Experiments performed by Benjamin Libet [Libet85] regarding the readiness potential (Bereitschaftspotential) concludes that the end user latency from impulse to the conscious mind is approximately 350 - 400 ms. In order to reach the highest possible data transport without confusing the end user, it is important to take this latency into consideration.

400 MS - [Libet85]準備電位（Bereitschaftspotential）に関するベンジャミン・リベットによって行われた実験は、インパルスから意識へのエンドユーザーの待ち時間が約350であると結論付けます。エンドユーザーを混乱させずに可能な限り最高のデータ転送を達成するために、それを考慮にこの遅延を取ることが重要です。

3.1. Principle of Operation

3.1. 動作原理

Traffic between the end user and the server reaches the ESP-enabled router. Inside the ESP-based router, the data stream is first analyzed by the DPAUI (Deep Packet And User Inspection). The DPAUI sends a signal to the PPG (Deep Packet And User Inspection), which generates uplink IP datagrams supported by the IID (Infinite Improbability Drive). The generated IP datagram is sent to the CFE (Clairvoyant Forwarding Engine) that forwards the datagram. Finally, the "real" uplink, the end user datagram is received and forwarded to the ND (Null Device).

エンドユーザとサーバ間のトラフィックは、ESP対応ルータに到達しました。 ESPベースのルータ内部では、データストリームがまずDPAUI（ディープパケットインスペクションおよびユーザー）によって分析されます。 DPAUIは、IID（無限ない確率ドライブ）でサポートされているアップリンクIPデータグラムを生成するPPG（ディープパケット及びユーザー検査）に信号を送ります。生成されたIPデータグラムは、データグラムを転送しCFE（千里眼フォワーディングエンジン）に送信されます。最後に、「本当の」アップリンクは、エンドユーザデータグラムが受信され、ND（ヌルデバイス）に転送されます。

3.2. Architectural Components

3.2. 建築コンポーネント

The current ESP-based forwarding architecture includes the following components:

現在ESPベースの転送アーキテクチャは、次のコンポーネントが含まれます。

o DPAUI o PPG o IID o CFE o PPS o ND

DPAUI PPG IID CFE PPS ND

3.2.1. DPAUI

The DPAUI (Deep Packet And User Inspection) monitors the data streams for all individual users. The DPAUI is implemented by means of implementing a learning agent that analyzes each individual user. The output from the DPAUI is a signal that indicates that an IP datagram will be sent by the end user within a couple of seconds.

DPAUI（ディープパケットおよびユーザインスペクション）は、すべての個々のユーザのためのデータストリームを監視します。 DPAUIは、個々のユーザーを分析学習エージェントを実装によって実現されます。 DPAUIからの出力は、IPデータグラムは、数秒以内にエンドユーザーが送信されることを示す信号です。

3.2.2. PPG

The purpose of the PPG (Precognitive Packet Generator) is to generate the IP datagram that the end user will trigger to be sent. In order to craft such a datagram, the PPG will perform a lookup based on the offset and length parameters generated by the IID. The PPG will generate the future packet by means of the function:

PPG（precognitiveのパケット・ジェネレータ）の目的は、エンドユーザーが送信するトリガするIPデータグラムを生成することです。そのようなデータグラムを作るために、PPGはIIDによって生成されたオフセットおよび長さのパラメータに基づいてルックアップを実行します。 PPGは、機能により、将来のパケットを生成します。

struct mbuf * CopyDatagramFromPi( insane long offset, unsigned int len);

構造体のmbuf * CopyDatagramFromPi（非常識長いオフセット、unsigned int型のlen）;

The CopyDatagramFromPi() function will return a pointer to an mbuf containing the IP datagram. The offset value and len matches a corresponding offset and length in the decimal set for pi that contains the bit pattern for the future datagram. This method of operation will reduce the complex matter of precognitive packet generation to a simple lookup.

CopyDatagramFromPi（）関数は、IPデータグラムを含むMBUFへのポインタを戻します。オフセット値とlenは、対応するオフセットおよび長さ、将来のデータグラムのビットパターンを含むPIの小数点セットに一致します。この操作方法は、単純な検索に予知パケット生成の複雑な問題を軽減します。

Concerns have been raised that the full decimal set of pi requires an infinite amount of memory. This might have a negative effect on the manufacturing cost of the router. These concerns were successfully managed by using a perfectly circular buffer. This reduced the previous stated memory requirements at least by half.

懸念はパイの完全な小数のセットは、メモリの無限の量を必要とすることが提起されています。これは、ルータの製造コストにマイナスの影響を与える可能性があります。これらの懸念が正常に完全な円形のバッファを使用することによって管理されていました。これは、少なくとも半分で以前に述べたメモリ要件を削減しました。

3.2.3. IID

The purpose of the IID (Infinite Improbability Drive) is to assist the PPG and PPS with improbable probabilities (and the other way around). The IID was originally invented by Douglas Adams [Adams79]. The original implementation was based on hooking up the logic circuits of a Bambleweeny 57 sub-meson Brain to an atomic vector plotter suspended in a strong Brownian motion producer (i.e., a nice hot cup of tea).

IID（インフィニットない確率ドライブ）の目的は、ありえない確率（およびその逆）とPPGとPPSを支援することです。 IIDは当初、ダグラス・アダムス[Adams79]によって発明されました。元の実装は、強力なブラウン運動プロデューサ（茶即ち、素敵なホットカップ）に懸濁原子ベクトルプロッタにBambleweeny 57サブ中間子脳の論理回路をフックに基づいていました。

The research team struggled with the implementation of the strong Brownian motion producer. As a matter of fact, the majority of the research budget was wasted before it was fully conceived that a warm cup of tea and router equipment rarely mix.

研究チームは、強力なブラウン運動のプロデューサーの実装に苦労しました。お茶やルータ機器の温かいカップはめったに混ぜないことを十分に考えられていた前に、実際のところ、研究予算の大部分が無駄になりました。

Aided by the gastronomical department (working on Bistromathic Drive), the research team managed to attach a brownie on top of a radio controlled hovercraft full of eels. This not only caused a lot of noise and disarray, but also a sufficient amount of Brownian motion. The research team is still working on an entirely software-based solution. Hopefully, the eel-filled hovercraft will soon be replaced with a different type of python script.

（Bistromathicドライブに取り組んで）美食部門に助けられ、研究チームは、ウナギの完全なラジコンホバークラフトの上にブラウニーを添付することができました。これはノイズと混乱の多くが、また、ブラウン運動の十分な量を発生させないだけ。研究チームは、まだ完全にソフトウェアベースのソリューションに取り組んでいます。うまくいけば、ウナギに満ちたホバークラフトはすぐにPythonスクリプトの異なるタイプに置き換えられます。

3.2.4. CFE

After the IP datagram has been produced by the PPG, the CFE (Clairvoyant Forwarding Engine) will attempt to find the right route. Since the route might not exist yet, direct access to a routing table might result in routing errors.

IPデータグラムは、PPGで生成された後、CFE（千里眼フォワーディングエンジン）は、右のルートを見つけるしようとします。ルートがまだ存在していないかもしれないので、ルーティングテーブルへの直接アクセスは、ルーティングエラーが発生する可能性があります。

The implementation of the CFE is very straightforward: any off-the-shelf routing stack with a routing table and a routing daemon can be used. A standard Ouija board is simply put on top of the routing table. For each datagram, the CFE initiates an Ouija board session that will establish a connection with the routing deamons. The CFE will seek guidance for the future of the IP datagram and then send it along for a low cost, to meet a tall, dark server rack.

CFEの実装が非常に簡単である：ルーティングテーブルおよびルーティングデーモンを有する任意の既製ルーティング・スタックを使用することができます。標準ウイジャ盤は単にルーティングテーブルの上に置かれています。各データグラムについて、CFEは、ルーティングのデーモンとの接続を確立しますウイジャボードセッションを開始します。 CFEは、IPデータグラムの将来のためのガイダンスを求め、その後、背の高い、暗いサーバラックを満たすために、低コストのためにそれを一緒にお送りいたします。

3.2.5. PPS

The PPS (Pre-Preemptive Scheduler) is synchronized by means of an NTP connection to the IID based NTP server. This ensures that the ESP process will execute ten seconds ahead of local time (layman's term: "into the future"). This value should ensure operation even with very long Round Trip Times and should also include the readiness potential of the end user.

PPS（プレプリエンプティブスケジューラ）はIIDベースのNTPサーバへのNTP接続によって同期されます。（「未来へ」素人の用語）これは、ESPプロセスが先に現地時間の10秒を実行するようになります。この値は、非常に長い往復時間での動作を保証しなければならないし、また、エンドユーザーの準備の可能性を含める必要があります。

The pre-preemptive scheduler not only provides a separate user space, but a separate dimension for the code to execute in. The dimension alignment is based on string theory and has been implemented in the language C, simply by including the library string.h and then using strcpy to copy the PPS function pointer into an eleven-dimensional array.

プレプリエンプティブスケジューラ別のユーザ空間を提供するが、で実行するコードのための別個の寸法のみならず。次元アライメントは、文字列の理論に基づいており、単純にライブラリstring.hのを含めることにより、言語Cで実装されていると次いで、11次元配列にPPS関数ポインタをコピーするstrcpyのを使用。

3.2.6. ND

After a little time, less than the 'end user to server' Round-trip time (RTT), the real end user datagram will reach the ingress side of the ESP-based router, since the datagram has already been sent, routed and returned. The datagram is directly routed to the ND (Null Device) and the ingress packet counter is decremented.

データグラムがすでに送信されルーティングされ、戻ってきたので、「エンドユーザーのサーバーへのラウンド・トリップ時間（RTT）未満少し時間が、後に、実際のエンドユーザーデータグラムは、ESPベースのルータの入力側に到達します。データグラムは直接ND（ヌルデバイス）にルーティングされ、入力パケットカウンタがデクリメントされます。

Experimentation showed that the ND is a perfect source of entropy and is able to store all digits of pi. The research team had great hopes of reducing the memory footprint for the PPG even further, but ran into problems with read access times.

実験は、NDは、エントロピーの完全なソースであり、PIの全桁を格納することができることを示しました。研究チームはさらにPPGのためのメモリフットプリントを削減する大きな期待を持っていましたが、読み出しアクセス時間の問題に走りました。

The ND is readily available in most operating systems.

NDは、ほとんどのオペレーティングシステムで容易に利用可能です。

4. End User Considerations

4.エンドユーザーの考慮事項

End user considerations and differentiated traffic classes:

エンドユーザーの考慮事項と差別トラフィッククラス：

1. In order to facilitate a pleasant end user gaming experience, packets destined for the spinal cord (i.e., force feedback information, etc.) must be delayed by 350 ms in order to synchronize with the traffic that is routed by the end user to the cerebrum and cortex.

1.快適なエンドユーザのゲーム体験を容易にするために、脊髄を宛先とするパケット（すなわち、等、フィードバック情報を強制的）にエンドユーザによってルーティングされるトラフィックと同期するために、350ミリ秒だけ遅延されなければなりません大脳および皮質。

2. RFC 1216 [RFC1216], Section 3.3 states that "bad news travels fast". This means that additional delay must be introduced when the end user is browsing on news sites. Negative latency might make the end user suspect that the news is even worse than indicated by the news sites.

「悪いニュースは速く伝わる」という2 RFC 1216 [RFC1216]、セクション3.3の状態。これは、エンドユーザーがニュースサイトで閲覧しているときに、追加の遅延が導入されなければならないことを意味します。負の待ち時間は、ニュースがニュースサイトで示されているよりもさらに悪くなるエンドユーザーの容疑者を作るかもしれません。

3. Machine-to-Machine (M2M) communication might experience reduced performance due to difficulties for the DPAUI to work correctly. When the concept starts working for M2M communication, this can be used as an indication that a technological singularity might be near.

DPAUIが正しく動作するために3マシン・ツー・マシン（M2M）通信が原因困難に性能低下が発生する可能性があります。コンセプトは、M2M通信のために働いて起動すると、これは技術的特異点は近いかもしれないことを指標として用いることができます。

5. TCP Slow-Start Considerations

5. TCPスロースタートの考慮事項

The lack of RTT of IFNs might cause some problems with TCP slow-start. More precisely, it will most likely not be slow at all. This might be handled by implementing a congestion avoidance mechanism, but will need further study.

IFNのRTTの欠如は、TCPスロースタートでいくつかの問題が発生する可能性があります。より正確には、それはほとんどすべてで遅くなることはありません。これは、輻輳回避メカニズムを実装することによって処理されるかもしれませんが、さらなる研究が必要になります。

6. Market Considerations

6.市場の考慮事項

Unfortunately, we foresee that this product will never be ready for the market. This is especially true for the Pre-preemptive Scheduler, which by nature, will always be slightly ahead of its time.

残念ながら、我々は、この製品は市場の準備ができないことを予見します。これは性質上、常に少し先にその時間のだろう事前プリエンプティブスケジューラ、特に顕著です。

7. Security Considerations

7.セキュリティの考慮事項

o Introducing an end user RTT delay of zero might cause crashes in badly implemented TCP/IP stacks. This is because division by zero might occur when calculating bandwidth-delay product.

ゼロのエンドユーザーRTT遅延を導入Oひどく実装TCP / IPスタックでクラッシュが発生する可能性があります。帯域遅延積を計算する際、ゼロによる除算が発生する可能性があるためです。

o ESP forwarding of traffic generated by psychics might lead to problems with recursiveness.

O占い師によって生成されたトラフィックのESP転送が再帰での問題につながる可能性があります。

o Lawful Intercept of the Deep User and Intention Inspection might violate personal integrity.

Oディープユーザーと意図検査の合法的傍受は個人的な整合性に違反する可能性があります。

o Terrorist organizations might exploit the "bad news travels fast" loophole in RFC 1216 [RFC1216].

Oテロ組織は、RFC 1216で「悪いニュースは速く伝わる」抜け穴[RFC1216]を利用するかもしれません。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

8.2. Informative References

8.2. 参考文献

[Adams79] Adams, D., "Hitchhiker's guide to the galaxy.", 1979.

[Adams79]アダムス、D.、 "銀河ヒッチハイクガイド。"、1979年。

[Libet85] Libet, B., "Unconscious cerebral initiative and the role of conscious will in voluntary action.", 1985.

[Libet85] Libet、B.、「無意識の脳イニシアティブ自主行動における意識的な意志の役割。」、1985年。

[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.

[RFC1072]ジェーコブソン、V.およびR.ブレーデン、 "長時間の遅延経路のためのTCP拡張"、RFC 1072、1988年10月。

[RFC1216] Richard, P. and Kynikos, "Gigabit network economics and paradigm shifts", RFC 1216, April 1991.

[RFC1216]リチャード、P.とKynikos、 "ギガビットネットワーク経済学とパラダイムシフト"、RFC 1216、1991年4月。

[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.

[RFC1925] Callon、R.、 "十二・ネットワーキング真実"、RFC 1925、1996年4月。

[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.

[RFC1928]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。

[Schrodinger35] Schrodinger, E., "The Present Situation In Quantum Mechanics", 1935, <http://www.tu-harburg.de/rzt/rzt/it/QM/cat.html>.

【Schrodinger35】シュレディンガー、E.、 "量子力学において現状"、1935年、<http://www.tu-harburg.de/rzt/rzt/it/QM/cat.html>。

[Wigner] Wikipedia, "Wikipedia: Wigner's friend.", <http://en.wikipedia.org/wiki/Wigner's_friend>.

[ウィグナー]ウィキペディア、 "ウィキペディア：ウィグナーの友人"、<http://en.wikipedia.org/wiki/Wigner's_friend>。

Author's Address

著者のアドレス

Karl-Magnus Moller Tankesaft

カール・マグナスモラーマインドジュース

EMail: kalle@tankesaft.se

メールアドレス：kalle@tankesaft.se