はじめに
- この文書は RFC6921 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
Design Considerations for Faster-Than-Light (FTL) Communication（超光速通信(FTL)のための設計上の考慮事項）
- Independent Submission
- Request for Comments: 6921
- Category: Informational
- ISSN: 2070-1721
- R. Hinden
- Check Point Software
- 1 April 2013
Abstract（要約）
We are approaching the time when we will be able to communicate faster than the speed of light.
It is well known that as we approach the speed of light, time slows down.
Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse.
The major consequence of this for Internet protocols is that packets will arrive before they are sent.
This will have a major impact on the way we design Internet protocols.
This paper outlines some of the issues and suggests some directions for additional analysis of these issues.
光の速さを超える通信が可能になる時代が近づいてきている。
光速に近づくと、時間が遅くなることはよく知られている。
論理的には、光速を超えると時間が逆転すると考えるのが妥当である。
このことがインターネットプロトコルに与える大きな影響は、パケットが送信される前に到着してしまうことだ。
このことは、インターネット・プロトコルの設計方法に大きな影響を与えるだろう。
本紙では、いくつかの問題を概説し、これらの問題をさらに分析するためのいくつかの方向性を提案する。
Status of This Memo（このメモの位置づけ）
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は、インターネット標準化過程の仕様ではなく、情報提供を目的として公開されている。
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.
これは他の RFC ストリームとは無関係に、RFCシリーズに貢献するものである。
RFC 編集者はその裁量でこの文書を公開することを選択しており、その実装や配備に対する価値については一切言及しない。
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/rfc6921.
この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6921 で得ることができる。
Copyright Notice
Copyright (c) 2013 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
2. Protocol Design Considerations for FTL Communication . . . . . 3
2.1. Related Issues . . . . . . . . . . . . . . . . . . . . . . 4
3. FTL Communication Research . . . . . . . . . . . . . . . . . . 5
4. IETF Recommendations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction（導入）
We are approaching the time when we will be able to communicate faster than the speed of light.
It is well known that as we approach the speed of light, time slows down.
Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse.
The major consequence of this for Internet protocols is that packets will arrive before they are sent.
This will have a major impact on the way we design Internet protocols.
This paper outlines some of the issues and suggests some directions for additional analysis of these issues.
光の速さを超える通信が可能になる時代が近づいてきている。
光速に近づくと、時間が遅くなることはよく知られている。
論理的には、光速を超えると時間が逆転すると考えるのが妥当である。
このことがインターネットプロトコルに与える大きな影響は、パケットが送信される前に到着してしまうことだ。
このことは、インターネット・プロトコルの設計方法に大きな影響を与えるだろう。
本紙では、いくつかの問題を概説し、これらの問題をさらに分析するためのいくつかの方向性を提案する。
There is a lot of discussion in the physics community about faster-than-light travel and communication.
In fact, it even has a well known acronym "FTL".
This acronym will be used in the remainder of this document.
物理学の世界では、光よりも速い移動・通信について様々な議論がなされている。
実際、「FTL」という有名な頭字語があるくらいである。
本書の残りの部分では、この頭字語を使用することにする。
FTL issues have been discussed in the scientific literature for a long time.
For example, it was discussed in 1917 in the section "Velocities Greater than that of Light" on page 54 of "The Theory of the Relativity of Motion" [Tolman].
A good overall description of the effects of FTL communication can be found in [Goldberg].
FTLの問題は、長い間、科学文献の中で議論されてきた。
例えば、1917年に「運動の相対性理論」の54ページの「光の速度より大きい速度」の項で議論されている [Tolman]。
FTL通信の効果については、[Goldberg] に良い全体的な記述がある。
[Ardavan] describes a "polarization synchrontron", which pushes radio waves faster than the speed of light.
In the paper, the author explains:
[Ardavan] は、光速よりも速く電波を押し出す「偏波シンクロン」について述べている。
その中で、著者はこう説明している：
...though no superluminal source of electromagnetic fields can be point-like, there are no physical principles preventing extended faster-than-light sources. The coordinated motion of aggregates of subluminally-moving charged particles can give rise to macroscopic polarization currents whose distribution patterns move superluminally. Further relevant progress occurred with the theoretical prediction that extended sources that move faster than
their own waves could be responsible for the extreme properties of both the electromagnetic emission from pulsars (rapidly spinning, magnetized neutron stars) and the acoustic emission by supersonic rotors and propellers.
『...超光速の電磁場源は点状ではありえないが、光より速い電磁場源を拡張することを妨げる物理的原理は存在しない。
亜光速で運動する荷電粒子の集合体の協調運動は、その分布パターンが超光速で運動する巨視的な偏光電流を生じさせることができる。
さらに、光よりも速く移動する拡張光源が存在するという理論的な予言がなされたことで、関連する進展があった。
パルサー（高速で回転する磁気を帯びた中性子星）からの電磁放射や、超音速のローターやプロペラによる音響放射の極端な特性は、彼ら自身の波のせいかもしれない。』
This may be a viable approach for transmitting data FTL.
これは、データをFTLで伝送するためのアプローチとして有効かもしれない。
2. Protocol Design Considerations for FTL Communication（FTL通信のためのプロトコル設計上の考慮事項）
Most, if not all, Internet protocols were designed with the basic assumption that the sender would transmit the packet before the receiver received it.
For example, in the Transmission Control Protocol (TCP) [RFC0793], protocol activity is shown in timing diagrams such as Figure 7:
すべてではないにせよ、ほとんどのインターネットプロトコルは、送信者が受信者がパケットを受信する前に送信するという基本的な前提で設計されている。
例えば、Transmission Control Protocol (TCP) [RFC0793] では、プロトコルの活動は図7のようなタイミング図に示されている。
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
Figure 7 of RFC 793
In an FTL communication environment, this assumption is no longer true, because TCP B will receive the first SYN before TCP A transmitted it.
For example, the first part of a TCP 3-way handshake in an FTL environment will look like:
FTL通信環境では、TCP A が送信する前に TCP B が最初の SYN を受信するため、この仮定は成り立たなくなる。
例えば、FTL環境での TCP 3ウェイハンドシェイクの最初の部分は次のようになる。
TCP A TCP B
1. CLOSED LISTEN
2. <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. SYN-SENT --> <SEQ=100><CTL=SYN>
The exact operation will depend on the difference between the backward time (i.e., from the future to the past) and the processing time to process a packet.
If the processing time is greater than the backward time shift, then even though the packets are received out of order, TCP should still work due to the TCP symmetrical 3-way handshake mechanism.
If the processing time is smaller than the backward time shift, then it gets much harder, as many packets will be received before they are sent.
The faster the communication is above the speed of light, the more severe the problem becomes.
正確な動作は、パケットを処理するための逆方向の時間（つまり、未来から過去への時間）と処理時間の差に依存することになる。
処理時間が逆方向の時間シフトより大きい場合、パケットを順番通りに受信しなくても、TCPの対称的な3ウェイハンドシェイクメカニズムにより、TCPはまだ動作するはずである。
もし処理時間が逆方向のタイムシフトより小さければ、多くのパケットが送信される前に受信されることになり、かなり難しくなる。
光速を超える高速通信になればなるほど、この問題は深刻になる。
Assuming the first case where the processing time is equivalent or larger than the backward time shift (i.e., after an exchange of packets the backward time offset is canceled out), the TCP 3-way handshake in an FTL environment would look like:
まず、処理時間が後方への時間ずれと同等かそれ以上である（つまり、パケット交換後に後方への時間オフセットが相殺される）場合を想定すると、FTL環境でのTCP 3ウェイハンドシェイクは次のようになる。
TCP A TCP B
1. CLOSED LISTEN
2. <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. SYN-SENT --> <SEQ=100><CTL=SYN>
4. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> SYN-RECEIVED
5. ESTABLISHED <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
6. ESTABLISHED <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
7. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> ESTABLISHED
It shows remarkable forethought by the inventors of the TCP protocol that the 3-way handshake works in an FTL communication environment.
This is due to the symmetrical nature of the 3-way handshake and its ability to deal with dropped packets.
It should be possible to use dropped packets as a way to mimic an FTL communication environment.
In fact, this may provide a good vehicle to analyze and test protocols to see how they will work in an FTL communication environment.
FTL通信環境下で3ウェイハンドシェイクが機能するのは、TCPプロトコルの発明者の驚くべき先見性を示している。
これは、3ウェイハンドシェイクが対称的であることと、パケットの取りこぼしに対応できることが理由である。
FTL通信環境を模倣する方法として、ドロップパケットを利用することは可能なはずだ。
実際、これはプロトコルを分析し、FTL通信環境でどのように動作するかをテストするための良い手段となるかもしれない。
2.1. Related Issues（関連する問題）
Additional work is needed to think about protocol design considerations when the backward time shift is much greater than the processing time.
This would create challenges where it would be necessary to have received all of the data before the connection could be established.
This is left to future researchers.
In practical terms, this scenario isn't likely to happen for a long time.
That said, FTL communication might lead to FTL travel, where we can travel into the past.
It may be necessary to start working on this yesterday.
後方（過去）への時間シフトが処理時間よりはるかに大きい場合のプロトコル設計について追加の考慮が必要である。
この場合、接続を確立する前にすべてのデータを受信しておく必要があるという問題が生じる。
これは、今後の研究者に委ねられる。
現実的には、このシナリオは長い間実現しそうにない。
とはいえ、FTL通信が実現すれば、過去に旅行できるFTLトラベルにつながるかもしれない。
昨日から取り組んでおくことが必要かもしれない。
There is a large amount of work that has been done in a related area, Delay-Tolerant Networks.
For example, [RFC4838] defines an architecture for Delay-Tolerant Networks.
An FTL communication environment is similar to Delay-Tolerant Networks with the major difference that the packets arrive at the destination with a negative delay.
Documents that will need review include "A One-way Delay Metric for IPPM" [RFC2679] and "A Delay Bound alternative revision of RFC 2598" [RFC3248].
関連する分野として、遅延耐性ネットワークがあり、多くの研究が行われている。
例えば、[RFC4838] は遅延耐性ネットワークのためのアーキテクチャを定義している。
FTL通信環境は遅延耐性ネットワークに似ているが、パケットが負の遅延で宛先に到着する点が大きく異なる。
また、"A One-way Delay Metric for IPPM" [RFC2679] や "A Delay Bound alternative revision of RFC 2598" [RFC3248] などのドキュメントを見直す必要がある。
Congestion control algorithms will also need serious review -- specifically, how to handle negative round-trip time (RTT) on TCP congestion control or the corner case where the RTT comes out at exactly zero.
Do any of the control equations include a divide-by-RTT or sqrt(RTT)?
It should also be noted that there may be the possibility for significant advancements in congestion algorithms given the properties of FTL communication.
Specifically, it maybe possible to stop network congestion before it starts.
This could be an important new approach for congestion control researchers.
輻輳制御アルゴリズムも本格的な見直しが必要になる —— 具体的には、TCPの輻輳制御における負の往復時間(RTT)の扱いや、RTTがちょうどゼロになるようなコーナーケースの扱いなどである。
制御式にRTTで割ったりsqrt(RTT)が含まれているか？
また、FTL通信の特性を考えると、輻輳アルゴリズムが大きく進化する可能性があることに留意する必要がある。
具体的には、ネットワークの輻輳を開始する前に止めることができるかもしれない。
これは、輻輳制御の研究者にとって重要な新しいアプローチとなる可能性がある。
3. FTL Communication Research（FTL通信の研究）
FTL communication has great potential for the networking research community.
It is clearly an exciting area for new research and considerable time could be spent working on it.
It is very important that we fully understand all of its aspects before we know how to achieve FTL communication.
Funding agencies should take this into account when allocating money and make sure that all new research projects look at FTL communication environments.
FTL通信は、ネットワークの研究コミュニティにとって大きな可能性を秘めている。
これは明らかに新しい研究のためのエキサイティングな領域であり、この研究にかなりの時間を費やすことができる。
FTL通信を実現する方法を知る前に、そのすべての側面を完全に理解することが非常に重要である。
資金調達機関は、資金を配分する際にこの点を考慮し、すべての新しい研究プロジェクトが FTL 通信環境に注目するようにする必要がある。
4. IETF Recommendations（IETFの勧告）
The Internet Engineering Steering Group (IESG), which is the part of Internet Engineering Task Force (IETF) that manages the standards process, has area reviews as part of its review process.
For example, the Security area reviews proposed protocols for security issues.
The IETF Chair also has a General area that does overall reviews.
Internet Engineering Task Force(IETF)の一部で標準化プロセスを管理するInternet Engineering Steering Group(IESG)には、その審査プロセスの一環としてエリアレビューがある。
例えば、セキュリティエリアでは、提案されたプロトコルにセキュリティ上の問題がないかどうかをレビューする。
また、IETF議長には、全体的なレビューを行う一般エリアがある。
The author recommends that the IETF create a new review group to evaluate all new Internet protocols to verify that FTL communication has been taken into consideration in the design of the protocol.
This would be similar to what is done to make sure that new Internet protocols are secure or are designed to run over IPv4 and IPv6.
As we look forward to FTL communication, it is critical that all Internet protocols are designed to work in this environment.
著者は、IETFが新しいインターネットプロトコルを評価し、FTL通信がプロトコルの設計に考慮されていることを検証する新しいレビューグループを作ることを推奨する。
これは、新しいインターネットプロトコルが安全であることや、IPv4やIPv6上で動作するように設計されていることを確認するために行われていることと同様であろう。
FTL通信の実現に向けて、すべてのインターネットプロトコルがこの環境下で動作するように設計されていることが重要だ。
Further, the author recommends that the IESG start a review process to do a detailed analysis of all existing Internet protocols to make sure they have been designed to work in FTL communication environments.
For protocols that do not work in this environment, the IESG should add work items to existing working group charters or charter new working groups to update these protocols so that they will work in FTL communication environments.
さらに著者は、IESGが既存の全てのインターネットプロトコルを詳細に分析し、FTL通信環境で動作するように設計されているかどうかを確認するレビュープロセスを開始することを推奨する。
この環境で動作しないプロトコルについては、IESGは既存のワーキンググループ憲章に作業項目を追加するか、または新しいワーキンググループを設立して、FTL通信環境で動作するようにこれらのプロトコルを更新する必要がある。
5. Security Considerations（セキュリティ上の考慮事項）
It is early to fully understand security issues relating to FTL communication.
The main issue is likely to be related to the characteristic of FTL communication that the receiver will receive a packet before it is sent.
Many exploits are likely to be written to take advantage of this property.
Also, given the number of exploits that are being discovered that don't have any protections available, it may be that the malware community is already taking advantage of the properties of FTL communication.
FTL通信に関連するセキュリティ問題を完全に理解するのは、まだ早い。
主な問題は、FTL通信の特徴である「送信前に受信者がパケットを受信してしまう」ことに関連すると思われる。
この特性を利用した悪用手段が多数作成される可能性がある。
また、保護機能を持たない悪用手段が多数発見されていることから、マルウェア・コミュニティが既にFTL通信の特性を利用している可能性もある。
6. Acknowledgements（謝辞）
Valuable comments and support were provided by Brian Carpenter and Rodney Van Meter.
Brian Carpenter氏、Rodney Van Meter氏の価値あるコメントとサポートを得た。
7. References
7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
7.2. Informative References
[Ardavan] Ardavan, A., Singleton, J., Ardavan, H., Fopma, J.,
Hallida, D., and W. Hayes, "Experimental demonstration of
a new radiation mechanism: emission by an oscillating,
accelerated, superluminal polarization current", eprint
arXiv:physics/0405062, May 2004.
[Goldberg] Goldberg, D., "Do faster than light neutrinos let you
change the past?", October 2011, <http://io9.com/5846519/
do-faster-than-light-neutrinos-let-you-change-the-past>.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
Halpern, J., Kumar, B., and J. Schnizlein, "A Delay Bound
alternative revision of RFC 2598", RFC 3248, March 2002.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[Tolman] Tolman, R., "The Theory of the Relativity of Motion",
Berkeley: University of California Press, 1917.
Author's Address
Robert M. Hinden
Check Point Software
959 Skyway Road
Suite 300
San Carlos, CA 94070
USA
EMail: bob.hinden@gmail.com