Independent Submission                                         R. Hinden
Request for Comments: 6921                          Check Point Software
Category: Informational                                     1 April 2013
ISSN: 2070-1721
        
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

超光速(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.

我们正在接近能够以比光速更快的速度进行通信的时代。众所周知,当我们接近光速时,时间会变慢。从逻辑上讲,我们可以合理地假设,当我们的速度超过光速时,时间就会倒转。对于Internet协议来说,这种情况的主要后果是数据包将在发送之前到达。这将对我们设计互联网协议的方式产生重大影响。本文概述了其中的一些问题,并为这些问题的进一步分析提出了一些方向。

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.

版权所有(c)2013 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信托有关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  . . . . . . . . . . . . . . . . . . . . . . . . . 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. 介绍

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.

我们正在接近能够以比光速更快的速度进行通信的时代。众所周知,当我们接近光速时,时间会变慢。从逻辑上讲,我们可以合理地假设,当我们的速度超过光速时,时间就会倒转。对于Internet协议来说,这种情况的主要后果是数据包将在发送之前到达。这将对我们设计互联网协议的方式产生重大影响。本文概述了其中的一些问题,并为这些问题的进一步分析提出了一些方向。

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年在“运动相对论”[Tolman]第54页的“速度大于光的速度”一节中对其进行了讨论。在[Goldberg]中可以找到关于FTL通信效果的完整描述。

[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

TCP A TCP B

1. CLOSED LISTEN

1. 封闭式聆听

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

2. 同步发送--><SEQ=100><CTL=SYN>-->同步接收

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

3. 已建立<--<SEQ=300><ACK=101><CTL=SYN,ACK><--SYN-RECEIVED

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

4. 已建立--><SEQ=101><ACK=301><CTL=ACK>-->已建立

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

5. 已建立--><SEQ=101><ACK=301><CTL=ACK><DATA>-->已建立

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 B将在TCP A传输第一个SYN之前接收第一个SYN。例如,FTL环境中TCP三方握手的第一部分如下所示:

TCP A TCP B

TCP A TCP B

1. CLOSED LISTEN

1. 封闭式聆听

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

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

3. 同步发送--><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

确切的操作将取决于向后时间(即从未来到过去)和处理数据包的处理时间之间的差异。如果处理时间大于向后时间偏移,则即使数据包接收顺序不正确,由于TCP对称3路传输,TCP仍应工作

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.

握手机制。如果处理时间小于后向时间偏移,则会变得更加困难,因为在发送数据包之前会收到许多数据包。通信速度越快,超过光速,问题就越严重。

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三向握手将如下所示:

TCP A TCP B

TCP A TCP B

1. CLOSED LISTEN

1. 封闭式聆听

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

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

3. 同步发送--><SEQ=100><CTL=SYN>

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

4. 已建立<--<SEQ=300><ACK=101><CTL=SYN,ACK>SYN-RECEIVED

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

5. 已建立<SEQ=300><ACK=101><CTL=SYN,ACK><--SYN-RECEIVED

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

6. 已建立

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

7. 已建立--><SEQ=101><ACK=301><CTL=ACK>已建立

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通信环境中工作。这是由于三方握手的对称性及其处理丢包的能力。应该可以使用丢弃的数据包来模拟FTL通信环境。事实上,这可能提供一个很好的工具来分析和测试协议,以了解它们在FTL通信环境中如何工作。

2.1. Related Issues
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主席还有一个进行全面审查的一般领域。

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通信。这类似于为确保新的Internet协议安全或设计为在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.,“传输控制协议”,标准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>.

[Goldberg]Goldberg,D.,“超光速中微子能让你改变过去吗?”,2011年10月<http://io9.com/5846519/ 超光速中微子让你改变过去>。

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

[RFC2679]Almes,G.,Kalidini,S.,和M.Zekauskas,“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]Armitage,G.,Carpenter,B.,Casati,A.,Crowcroft,J.,Halpern,J.,Kumar,B.,和J.Schnizlein,“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,“延迟容忍网络架构”,RFC 48382007年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美国加利福尼亚州圣卡洛斯94070

   EMail: bob.hinden@gmail.com
        
   EMail: bob.hinden@gmail.com