[Joke-RFC] RFC5984 ESP ベースの転送による IP ネットワークのスループットの向上: ESPBasedForwarding

# はじめに

* この文書は [RFC5984](https://www.rfc-editor.org/rfc/rfc5984.txt) を勉強と好奇心のため適当に訳したものです。
* 翻訳の正確さは全く保証しません。
* 誤字誤訳等の指摘はいつでも大歓迎です。

# Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding（ESP ベースの転送による IP ネットワークのスループットの向上: ESPBasedForwarding）

* Independent Submission
* Request for Comments: 5984
* Category: Experimental
* ISSN: 2070-1721

- K-M. Moller
- 1 April 2011

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

この文書はインターネット標準化過程の仕様ではなく、検討、実験的な実装、評価のために公開されるものである。

この文書は、インターネットコミュニティのための実験的なプロトコルを定義する。
この文書は、他のいかなる RFC ストリームとも無関係に、RFC シリーズに貢献するものである。
RFC エディターは自らの裁量でこの文書の公開を選択し、その実装や配備の価値について何ら表明するものではない。
RFC エディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない。

この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc5984 で得ることができる。

## Copyright Notice

```
   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

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

## 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（序論）

> 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（要求仕様言語）

> 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（背景）

> 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:
>
> "(2) No matter how hard you push and no matter what the priority, you can't increase the speed of light."

遅延を下げ、容量を増やすという現在の漸進的なアプローチは、間もなく限界に達するだろう。
この理由は以前から知られており、RFC 1925 [RFC1925] の 2 章に記載されている：

「(2) どんなに無理をしても、どんなに優先順位をつけても、光の速度をあげることはできない。」

https://qiita.com/yoshi389111/items/6db53835a7d8439d0391

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

RFC 1072 [RFC1072] では、長くて(long)太い(fat)パイプを含むネットワーク(network)を LFNと呼んでいる（エレファンと発音する）ことにヒントを得て、ゼロ遅延のインターネット経路を無限(infinitely)に太い(fat)、この経路を含むネットワーク(network)を「IFN」と呼ぶことにする（インファンと発音）。

> 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つの方法が却下された。

> *  Black Fiber
> *  Schrodinger's cat experiment

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

### 2.1.  Experiments with Black Fiber（ブラックファイバーを使った実験）

> 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.
>
> This clearly spoiled the mood of the party.

光速の限界を超えるために、ブラックファイバーを使うという試みは、当初は有望視されていた。
実験を始めて間もなく、ブラックファイバーに光の欠落が検出された。
これは、光速を超えるデータ伝送に成功した証拠だと解釈した。
ところが、シャンパンを開けた途端、次のような問題が出てきた。

1. 受信機にデータが届いていない。
2. 送信側でファイバーが接続されていない。

これでは、せっかくのパーティーの雰囲気も台無しだ。

### 2.2.  Schrodinger's Cat Experiment（シュレディンガーの猫の実験）

> 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. Schrodinger [Schrodinger35] が記述した方法を実現しようとしたものが元になっている。
オリジナルの手順では、猫を放射性物質や毒ガスの入った箱に閉じ込めている。
この実験に、netcat を利用してデータ通信機能を追加した。
研究チームは、猫の実験がうまくいくようで、同時にうまくいかないという考え方に唖然とした。
これは、ウィグナーの友人 [Wigner] によっても確認された。

https://ja.wikipedia.org/wiki/Netcat

https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B8%E3%83%B3%E3%83%BB%E3%82%A6%E3%82%A3%E3%82%B0%E3%83%8A%E3%83%BC

https://en.wikipedia.org/wiki/Wigner's_friend

> 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（ESP ベースの転送）

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

ESP (Extra Sensory Perception; 超感覚的知覚) ベースの転送の実験では、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.

ベンジャミン・リベット [Libet85] が行った準備電位 (Bereitschaftspotential) に関する実験では、インパルスから意識までのエンドユーザーの遅延は約 350 ～ 400 ms であると結論付けている。
エンドユーザーを混乱させることなく、可能な限り高いデータ転送速度を達成するためには、この遅延を考慮することが重要である。

https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%B3%E3%82%B8%E3%83%A3%E3%83%9F%E3%83%B3%E3%83%BB%E3%83%AA%E3%83%99%E3%83%83%E3%83%88

### 3.1.  Principle of Operation（動作原理）

> 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 (Precognitive Packet Generator), 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 (Deep Packet And User Inspection; 詳細なパケットとユーザー検査) によりデータストリームが解析される。
DPAUI は PPG (Precognitive Packet Generator; 予知パケット生成器) に信号を送り、PPG は IID (Infinite Improbability Drive; 無限の可能性ドライブ) によってサポートされるアップリンク IP データグラムを生成する。
生成された IP データグラムは、データグラムを転送する CFE (Clairvoyant Forwarding Engine; 透視転送エンジン) へ送られる。
最後に、「本当」のアップリンク、エンドユーザーデータグラムを受信し、ND (Null Device) へ転送する。

### 3.2.  Architectural Components（構成コンポーネント）

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

現在のESPベースの転送アーキテクチャには、以下のコンポーネントが含まれる：

> *  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 (Deep Packet And User Inspection) は、すべての個別ユーザーのデータストリームを監視する。
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 Packet Generator) の目的は、エンドユーザーが送信するトリガーとなる IP データグラムを生成することである。
このようなデータグラムを作成するために、PPG は、IID によって生成されたオフセットおよび長さパラメータに基づいてルックアップを実行する。
PPG は、以下の関数によって未来のパケットを生成する：

```
     struct mbuf * CopyDatagramFromPi(
                   insane long offset,
                   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` へのポインタを返す。
`offset` の値と `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 (Infinite Improbability Drive) の目的は、PPG と PPS をありえない確率 (およびその逆で) で支援することである。
IID はもともと ダグラス・アダムス [Adams79] によって発明された。
当初の実装は、バンブルウィニー 57 サブメソン・ブレーンの論理回路を、強ブラウン運動プロデューサー (つまり、おいしい熱い紅茶) に吊るした原子ベクトルプロッタに接続するものであった（訳注：「銀河ヒッチハイク・ガイド」参照）。

https://ja.wikipedia.org/wiki/%E3%83%80%E3%82%B0%E3%83%A9%E3%82%B9%E3%83%BB%E3%82%A2%E3%83%80%E3%83%A0%E3%82%BA

> 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 Drive に取り組んでいる) の支援を受けて、ウナギでいっぱいの無線制御ホバークラフトの上にブラウニーを取り付けることができた。
これは、多くのノイズと混乱を引き起こしただけでなく、しかし十分な量のブラウン運動も引き起こした。
研究チームは現在、完全にソフトウェアベースでのソリューションに取り組んでいる。
これがうまくいけば、ウナギで満たされたホバークラフトはすぐに別のタイプの 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.

PPG によって IP データグラムが生成された後、CFE (Clairvoyant Forwarding Engine) は正しい経路を見つけようとする。
ルートはまだ存在しないかもしれないため、ルーティングテーブルに直接アクセスすると、ルーティングエラーが発生する可能性がある。

> 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 データグラムの将来のためのガイダンスを求め、それを低コストで、背の高い人に会い、暗いサーバーラックへ送る。

https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%82%B8%E3%83%A3%E3%83%9C%E3%83%BC%E3%83%89

（訳注：ウィジャボードを使った占いで、「あなたは、背の高い、陰のある、ちょっと変わった人に会うだろう」的なことを言うことがよくあるから？　あるいは 2010 年の映画「恋のロンドン狂騒曲(You Will Meet a Tall Dark Stranger)」にそんな場面があったのだろうか？）

#### 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 (Pre-Preemptive Scheduler; 事前先取りスケジューラ) は、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 theory) に基づいており、C 言語ではライブラリ `string.h` をインクルードし、`strcpy` を使って PPS 関数ポインタを 11 次元の配列にコピーするだけで実装されている。

https://ja.wikipedia.org/wiki/%E5%BC%A6%E7%90%86%E8%AB%96

#### 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 (Null Device) に直接ルーティングされ、入口パケットカウンタがデクリメントされる。

> 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 は完璧なエントロピーの源であり、円周率の全桁を記憶できることが分かった。
研究チームは、PPG のメモリフットプリントをさらに削減することに大きな期待を寄せていたが、読み取りアクセス時間の問題に直面した。

> The ND is readily available in most operating systems.

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

## 4.  End User Considerations（エンドユーザーに関する考慮事項）

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

エンドユーザーへの配慮と差別化されたトラフィッククラス：

1.  エンドユーザーの快適なゲーム体験を促進するため、脊髄に向かうパケット (力のフィードバック情報など) は、エンドユーザーによって大脳と大脳皮質に送られるトラフィックと同期するように 350ms 遅延させる必要がある。

2.  RFC 1216 [RFC1216] の 3.3 節は、「悪い知らせはすぐに伝わる」と述べている。 これは、エンドユーザがニュースサイトを閲覧する際に、追加的な遅延を導入しなければならないことを意味する。 負の遅延は、エンドユーザにニュースサイトが示すよりもさらに悪いニュースであると疑わせるかもしれない。

3. M2M (Machine-to-Machine) 通信では、DPAUI が正しく動作しないため、パフォーマンスが低下する可能性がある。M2M 通信で本コンセプトが機能し始めたら、技術的特異点が近いことを示唆するものとして利用できる。

https://qiita.com/yoshi389111/items/57e68ac8a61cc0ad89aa

## 5.  TCP Slow-Start Considerations（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（市場に関する考慮事項）

> 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（セキュリティに関する考慮事項）

> *  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.
>
> *  ESP forwarding of traffic generated by psychics might lead to problems with recursiveness.
>
> *  Lawful Intercept of the Deep User and Intention Inspection might violate personal integrity.
>
> *  Terrorist organizations might exploit the "bad news travels fast" loophole in RFC 1216 [RFC1216].

* エンドユーザー RTT 遅延ゼロを導入すると、まずい実装をされた TCP/IP スタックでクラッシュが発生する可能性がある。 これは、帯域幅-遅延積の計算時にゼロによる除算が発生する可能性があるためである。
* サイキックによって生成されたトラフィックの ESP 転送は、再帰性の問題を引き起こすかもしれない。
* 「詳細なユーザと意図の検査」の合法的な傍受は、個人の完全性を侵害するかもしれない。
* テロ組織が RFC 1216 [RFC1216] の「悪い知らせはすぐに伝わる」の抜け穴を悪用する可能性がある。

## 8.  References

### 8.1.  Normative References

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

### 8.2.  Informative References

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

https://ja.wikipedia.org/wiki/%E9%8A%80%E6%B2%B3%E3%83%92%E3%83%83%E3%83%81%E3%83%8F%E3%82%A4%E3%82%AF%E3%83%BB%E3%82%AC%E3%82%A4%E3%83%89

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

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

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

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

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

   [Schrodinger35]  Schrodinger, E., "The Present Situation In Quantum
                    Mechanics", 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>.
```

## Author's Address

```
   Karl-Magnus Moller
   Tankesaft

   EMail: kalle@tankesaft.se
```