1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Independent Submission R. Hinden
Request for Comments: 6921 Check Point Software
Category: Informational 1 April 2013
ISSN: 2070-1721
<span class="h1">Design Considerations for Faster-Than-Light (FTL) Communication</span>
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6921">http://www.rfc-editor.org/info/rfc6921</a>.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Hinden Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6921">RFC 6921</a> Design Considerations for FTL Communication 1 April 2013</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Protocol Design Considerations for FTL Communication . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Related Issues . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. FTL Communication Research . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. IETF Recommendations . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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 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" [<a href="#ref-Tolman" title=""The Theory of the Relativity of Motion"">Tolman</a>]. A good overall description of
the effects of FTL communication can be found in [<a href="#ref-Goldberg" title=""Do faster than light neutrinos let you change the past?"">Goldberg</a>].
[<a id="ref-Ardavan">Ardavan</a>] describes a "polarization synchrontron", which pushes radio
waves faster than the speed of light. In the paper, 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
<span class="grey">Hinden Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6921">RFC 6921</a> Design Considerations for FTL Communication 1 April 2013</span>
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Protocol Design Considerations for FTL Communication</span>
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) [<a href="./rfc0793" title=""Transmission Control Protocol"">RFC0793</a>], 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 <a href="./rfc793">RFC 793</a>
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:
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
<span class="grey">Hinden Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6921">RFC 6921</a> Design Considerations for FTL Communication 1 April 2013</span>
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:
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.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Related Issues</span>
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.
<span class="grey">Hinden Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6921">RFC 6921</a> Design Considerations for FTL Communication 1 April 2013</span>
There is a large amount of work that has been done in a related area,
Delay-Tolerant Networks. For example, [<a href="./rfc4838" title=""Delay-Tolerant Networking Architecture"">RFC4838</a>] 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" [<a href="./rfc2679" title=""A One-way Delay Metric for IPPM"">RFC2679</a>] and "A Delay Bound alternative revision of
<a href="./rfc2598">RFC 2598</a>" [<a href="./rfc3248" title=""A Delay Bound alternative revision of RFC 2598"">RFC3248</a>].
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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. FTL Communication Research</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IETF Recommendations</span>
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.
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.
<span class="grey">Hinden Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6921">RFC 6921</a> Design Considerations for FTL Communication 1 April 2013</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
Valuable comments and support were provided by Brian Carpenter and
Rodney Van Meter.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC0793">RFC0793</a>] Postel, J., "Transmission Control Protocol", STD 7, <a href="./rfc793">RFC</a>
<a href="./rfc793">793</a>, September 1981.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-Ardavan">Ardavan</a>] 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.
[<a id="ref-Goldberg">Goldberg</a>] Goldberg, D., "Do faster than light neutrinos let you
change the past?", October 2011, <<a href="http://io9.com/5846519/do-faster-than-light-neutrinos-let-you-change-the-past">http://io9.com/5846519/</a>
<a href="http://io9.com/5846519/do-faster-than-light-neutrinos-let-you-change-the-past">do-faster-than-light-neutrinos-let-you-change-the-past</a>>.
[<a id="ref-RFC2679">RFC2679</a>] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", <a href="./rfc2679">RFC 2679</a>, September 1999.
<span class="grey">Hinden Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6921">RFC 6921</a> Design Considerations for FTL Communication 1 April 2013</span>
[<a id="ref-RFC3248">RFC3248</a>] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
Halpern, J., Kumar, B., and J. Schnizlein, "A Delay Bound
alternative revision of <a href="./rfc2598">RFC 2598</a>", <a href="./rfc3248">RFC 3248</a>, March 2002.
[<a id="ref-RFC4838">RFC4838</a>] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", <a href="./rfc4838">RFC 4838</a>, April 2007.
[<a id="ref-Tolman">Tolman</a>] 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
Hinden Informational [Page 7]
</pre>
|
