RFC 6921 - Design Considerations for Faster-Than-Light (FTL) Communication 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6921
タイトル : RFC 6921 - Faster-Than-Light（FTL）通信の設計上の考慮事項
翻訳編集 : 自動生成

[要約] 要約：RFC 6921は、光速以上の通信（FTL通信）の設計に関する考慮事項を提供しています。目的：このRFCの目的は、FTL通信の設計における課題や制約を理解し、将来の研究や開発に役立つガイドラインを提供することです。

Independent Submission                                         R. Hinden
Request for Comments: 6921                          Check Point Software
Category: Informational                                     1 April 2013
ISSN: 2070-1721

Design Considerations for Faster-Than-Light (FTL) Communication

Faster-Than-Light（FTL）通信の設計上の考慮事項

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.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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で入手できます。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

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

1. はじめに

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ページの「光の速度よりも大きい速度」のセクションで説明されています。 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

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

すべてではありませんが、ほとんどのインターネットプロトコルは、受信者がパケットを受信する前に送信者がパケットを送信するという基本的な想定に基づいて設計されています。たとえば、伝送制御プロトコル（TCP）[RFC0793]では、図7のようなタイミング図にプロトコルアクティビティが示されています。

TCP A TCP B

1. CLOSED LISTEN

1. クローズドリッスン

2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED

2. SYN-SENT-> <SEQ = 100> <CTL = SYN>-> SYN-RECEIVED

3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

3. ESTABLISHED <-<SEQ = 300> <ACK = 101> <CTL = SYN、ACK> <-SYN-RECEIVED

4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED

4. ESTABLISHED-> <SEQ = 101> <ACK = 301> <CTL = ACK>-> ESTABLISHED

5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

5. ESTABLISHED-> <SEQ = 101> <ACK = 301> <CTL = ACK> <DATA>-> ESTABLISHED

Basic 3-Way Handshake for Connection Synchronization

接続同期のための基本的な3ウェイハンドシェイク

Figure 7 of RFC 793

RFC 793の図7

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

1. クローズドリッスン

   2.                  <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

3. SYN-SENT --> <SEQ=100><CTL=SYN>

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

1. クローズドリッスン

   2.                  <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

3. SYN-SENT --> <SEQ=100><CTL=SYN>

3. SYN-SENT-> <SEQ = 100> <CTL = SYN>

4. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> SYN-RECEIVED

4. ESTABLISHED <-<SEQ = 300> <ACK = 101> <CTL = SYN、ACK> SYN-RECEIVED

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

6. ESTABLISHED <SEQ = 101> <ACK = 301> <CTL = ACK>-> ESTABLISHED

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

これは、TCPプロトコルの発明者による3ウェイハンドシェイクがFTL通信環境で機能するという驚くべき予測を示しています。これは、3ウェイハンドシェイクの対称的な性質と、ドロップされたパケットを処理する機能によるものです。 FTL通信環境を模倣する方法として、ドロップされたパケットを使用できるはずです。実際、これはプロトコルを分析およびテストして、FTL通信環境でプロトコルがどのように機能するかを確認するための優れた手段を提供します。

2.1. 関連する問題

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通信環境は遅延許容ネットワークに似ていますが、大きな違いは、パケットが負の遅延で宛先に到着することです。レビューが必要なドキュメントには、「IPPMの片方向遅延メトリック」[RFC2679]と「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

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

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

インターネットエンジニアリングステアリンググループ（IESG）は、標準化プロセスを管理するインターネットエンジニアリングタスクフォース（IETF）の一部であり、レビュープロセスの一部としてエリアレビューを行っています。たとえば、セキュリティエリアでは、セキュリティの問題について提案されているプロトコルを確認します。 IETF議長には、全体的なレビューを行うGeneralエリアもあります。

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

5. セキュリティに関する考慮事項

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

6. 謝辞

Valuable comments and support were provided by Brian Carpenter and Rodney Van Meter.

貴重なコメントとサポートは、Brian CarpenterとRodney Van Meterから提供されました。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。

7.2. Informative References

7.2. 参考引用

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

[Ardavan] Ardavan、A.、Singleton、J.、Ardavan、H.、Fopma、J.、Hallida、D。、およびW. Hayes、「新しい放射メカニズムの実験的実証：振動、加速、超光速による放出分極電流」、eprint arXiv：physics / 0405062、2004年5月。

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

[ゴールドバーグ]ゴールドバーグ、D。、「軽いニュートリノよりも早く過去を変えることができるか？」、2011年10月、<http://io9.com/5846519/ do-faster-than-light-neutrinos-let-you-過去の変更>。

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。

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

[RFC3248]アーミテージ、G。、カーペンター、B。、カサーティ、A。、クロウクロフト、J。、ハルパーン、J。、クマール、B。、およびJ.シュニズレイン、「RFC 2598の遅延バインド代替リビジョン」、RFC 3248、2002年3月。

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

[RFC4838] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「Delay-Tolerant Networking Architecture」、RFC 4838、2007年4月。

[Tolman] Tolman, R., "The Theory of the Relativity of Motion", Berkeley: University of California Press, 1917.

[トルマン]トルマン、R。、「運動の相対性理論」、バークレー：カリフォルニア大学出版局、1917年。

Author's Address

著者のアドレス

Robert M. Hinden Check Point Software 959 Skyway Road Suite 300 San Carlos, CA 94070 USA

Robert M. Hinden Check Point Software 959 Skyway Road Suite 300 San Carlos、CA 94070 USA

   EMail: bob.hinden@gmail.com