doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6921.txt b/doc/rfc/rfc6921.txt
new file mode 100644
index 0000000..82144b3
--- /dev/null
+++ b/doc/rfc/rfc6921.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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
+
+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.
+
+   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.
+
+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.
+
+
+
+
+Hinden                        Informational                     [Page 1]
+
+RFC 6921       Design Considerations for FTL Communication  1 April 2013
+
+
+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 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].
+
+   [Ardavan] 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
+
+
+
+Hinden                        Informational                     [Page 2]
+
+RFC 6921       Design Considerations for FTL Communication  1 April 2013
+
+
+      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.
+
+2.  Protocol Design Considerations for FTL Communication
+
+   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 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:
+
+       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
+
+
+
+Hinden                        Informational                     [Page 3]
+
+RFC 6921       Design Considerations for FTL Communication  1 April 2013
+
+
+   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.
+
+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.
+
+
+
+
+
+Hinden                        Informational                     [Page 4]
+
+RFC 6921       Design Considerations for FTL Communication  1 April 2013
+
+
+   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].
+
+   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.
+
+3.  FTL Communication Research
+
+   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.
+
+4.  IETF Recommendations
+
+   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.
+
+
+
+
+
+
+Hinden                        Informational                     [Page 5]
+
+RFC 6921       Design Considerations for FTL Communication  1 April 2013
+
+
+   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.
+
+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.
+
+6.  Acknowledgements
+
+   Valuable comments and support were provided by Brian Carpenter and
+   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.
+
+
+
+
+
+
+Hinden                        Informational                     [Page 6]
+
+RFC 6921       Design Considerations for FTL Communication  1 April 2013
+
+
+   [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden                        Informational                     [Page 7]
+