RFC 6921

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

📅 published April 2013, from ietf

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

RFC 6921 🚀 is an Independent Submission by R. Hinden from Check Point Software. It's dated 1 April 2013, its ISSN is 2070-1721, and it's in the Informational category, so it's here to inform, not to be a standard. The title block doesn't list anything it obsoletes or updates.

Abstract

Okay, bestie, the vibes are immaculate. We're getting close to the point where we can communicate faster than the speed of light. 🦋 We already know that as things approach light speed, time slows down. So logically, going faster than light means time flips and runs backwards. ⏪ The big deal for Internet protocols? Packets would show up before they're sent. 😭 That changes how we have to design protocols, and this paper lays out some of the issues and suggests where we should dig deeper. 💅

Status of This Memo

This document isn't an Internet Standards Track specification. It's just published for information. 🌸

It's a contribution to the RFC Series, made independently of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no claim about whether it's worth implementing or deploying. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741. 🙈

You can find out the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6921. 💜

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) as they're in effect on the publication date. Please read these carefully, since they spell out your rights and restrictions for 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're getting close to communicating faster than the speed of light. 🦋 It's well known that as you approach light speed, time slows down. So it's reasonable to assume that going faster than light makes time reverse. ⏪ The major consequence for Internet protocols is that packets arrive before they're sent, which will majorly change how we design them. 🔥 This paper lays out some of the issues and suggests directions for more analysis. 💖

There's a lot of chatter in the physics community about faster-than-light travel and communication. It even has a famous acronym, "FTL," which is what this document will use from here on. ✨

FTL issues have been discussed in the scientific literature for a long time. For example, they came up 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 is in [Goldberg]. 📚

[Ardavan] describes a "polarization synchrontron," which pushes radio waves faster than the speed of light. The author explains:

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

Honestly? This may be a viable approach for transmitting data FTL. 🤯

2. Protocol Design Considerations for FTL Communication 💅

Most, if not all, Internet protocols were designed on the basic assumption that the sender transmits the packet before the receiver receives it. 🕰️ Take the Transmission Control Protocol (TCP) [RFC0793]. Its protocol activity is shown in timing diagrams such as Figure 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 environment, that assumption breaks, because TCP B receives the first SYN before TCP A has sent it. 😳 For example, the first part of a TCP 3-way handshake in an FTL environment looks like this:

    TCP A                                                TCP B

1.  CLOSED                                               LISTEN

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

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

How it plays out depends on the difference between the backward time (from the future to the past) and the processing time it takes to handle a packet. ⏳ If the processing time is greater than the backward time shift, then even though the packets arrive out of order, TCP should still work thanks to the TCP symmetrical 3-way handshake mechanism. 🫶 If the processing time is smaller than the backward time shift, then it gets much harder, because many packets will be received before they're 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 equal to or larger than the backward time shift (so after an exchange of packets the backward time offset cancels out), the TCP 3-way handshake in an FTL environment looks like this:

    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's honestly iconic that the TCP 3-way handshake works in an FTL environment at all. 👑 That's down to the handshake's symmetrical design and its ability to cope with dropped packets. 🌸 It should also be possible to use dropped packets to mimic an FTL environment, which may be a great way to analyze and test protocols to see how they'd hold up. 🧪

Next up in Part 2: Related Issues, FTL Communication Research, IETF Recommendations, Security Considerations, Acknowledgements, and References. 🎀

5. Security Considerations ✨

okay bestie, this section is short but it's giving "pay attention" 🫣 It's early days for really understanding the security side of FTL communication. The biggest thing is the whole receiver gets a packet before it's sent property 🤯 That's the part everyone's going to be poking at, because it's so weird. Expect lots of exploits getting written to take advantage of it 💀

And ngl, it's kind of scary. A bunch of exploits are already being found that have zero protections available, so the malware crowd might already be using the properties of FTL communication fr fr 😭 Not me being dramatic, it's a real concern 🚨

6. Acknowledgements 🫶

Huge thanks to Brian Carpenter and Rodney Van Meter for their valuable comments and support 💜 The real MVPs 👑

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

📦 where this page comes from