5th HLF – Lecture: An Interplanetary Internet
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 49 | |
| Author | ||
| License | No Open Access License: German copyright law applies. This film may be used for your own use but it may not be distributed via the internet or passed on to external parties. | |
| Identifiers | 10.5446/40146 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
2
00:00
Internet forumImplementationInternetworkingPresentation of a groupTuring testCommunications protocolSoftwareMeeting/Interview
00:34
Internet forumEvent horizonOperator (mathematics)Water vaporInternetworkingLecture/Conference
01:17
Context awarenessSoftwareÜbertragungsfunktionInternetworkingLecture/Conference
01:45
Execution unitUniformer RaumPointer (computer programming)Physical systemTelecommunicationARPANETMereologySatelliteNetwork topologyDistanceInternetworkingOperator (mathematics)Domain nameNeuroinformatikBusiness modelGraph coloringGame controllerDifferent (Kate Ryan album)SoftwareWeightSpacetimeSource codeMobile WebBit rateError messageWeb 2.0Order (biology)Connected spaceCommunications protocolMultiplication signCubic graphTask (computing)Lecture/Conference
04:08
Projective planeSeries (mathematics)SpacetimeComplex (psychology)Connected spaceRoboticsMobile WebSoftwareLink (knot theory)Network topologyWeightOrder (biology)Uniform resource locatorTelecommunicationSurfaceInternetworkingNumberConnectivity (graph theory)Physical systemCASE <Informatik>Scaling (geometry)MetreLecture/Conference
06:05
Game controllerNumbering schemeMessage passingSource codeGroup actionPropagatorDataflowMultiplication signOrbitLecture/Conference
06:54
Message passingQuicksortCoefficient of determinationRoundness (object)Multiplication signOrbitDataflowType theoryDomain nameDomain nameGame controllerString (computer science)Web applicationAddress spaceOrder (biology)Communications protocolConnected spaceSuite (music)Physical systemSatelliteIP addressTelecommunicationSurfaceNeuroinformatikMetreNumeral (linguistics)GoogolSoftwareIntegrated development environmentWeb 2.0Lecture/Conference
09:19
Communications protocolInformationSemiconductor memoryRoutingFiber bundleIP addressFigurate numberWeightOrbitCelestial sphereConnected spaceSystem callBitIntegrated development environmentData storage deviceLink (knot theory)ARPANETDomain nameImage resolutionInternetworkingData structureMultiplication signPhysical systemRevision controlSet (mathematics)Router (computing)Process (computing)SoftwareMetropolitan area networkMereologyLevel (video gaming)NumberSatelliteSoftware developerLecture/ConferenceMeeting/Interview
12:10
Multiplication signInternetworkingSatelliteMechanism designDifferent (Kate Ryan album)Graph (mathematics)LengthCommunications protocolLink (knot theory)Fiber bundleLecture/Conference
12:34
InternetworkingFiber bundleCommunications protocolUDP <Protokoll>Netzwerkverwaltung10 (number)Multiplication signPredictabilityPhysical systemData storage deviceOnline helpDependent and independent variablesIntegrated development environmentLecture/ConferenceMeeting/Interview
13:51
Dependent and independent variablesResponse time (technology)NetzwerkverwaltungCryptographySoftwareCommunications protocolOrbitAuthenticationGame controllerOrder (biology)Information securityInformationKey (cryptography)Fiber bundlePhysical systemInjektivitätControl flowQuicksortDistribution (mathematics)Public-key cryptographyWeightLecture/Conference
15:06
QuicksortRight angleLecture/ConferenceMeeting/Interview
15:36
PlanningSoftwareBit rateSpacetimeLine (geometry)SurfaceOpen setLecture/Conference
16:11
Revision controlOrbitCommunications protocolFiber bundleSoftwarePrototypeSpacetimeSurface2 (number)Data storage deviceQuicksortFrequencyMultiplication signPhysical systemComputational fluid dynamicsInternetradioOverhead (computing)Lecture/ConferenceMeeting/Interview
18:26
OrbitCommunications protocolFiber bundleSurfaceConfiguration spaceSatellitePrototypePole (complex analysis)Point (geometry)Computational fluid dynamicsLecture/Conference
19:17
Form (programming)Communications protocolSoftware testingFlow separationFiber bundle2 (number)IterationLecture/ConferenceMeeting/Interview
19:46
Communications protocolTelecommunicationFiber bundleInternetworkingHorizonSatelliteRoboticsGame controllerOrder (biology)Communications systemSoftware testingSource codeVariety (linguistics)Form (programming)Cartesian coordinate systemInteractive televisionPhysical systemCASE <Informatik>PlanningCoprocessorRouter (computing)ImplementationData transmissionSound effectFlagVariable (mathematics)Standard deviationSpacetimeInformation technology consultingIntegrated development environmentIndependence (probability theory)MultiplicationSemiconductor memoryProjective planeEmailGroup actionARPANETResponse time (technology)Metropolitan area networkTask (computing)Forcing (mathematics)Multiplication signBit rate2 (number)Revision controlParametrische ErregungConfidence intervalSoftwareBounded variationLink (knot theory)Real-time operating systemTerm (mathematics)Dependent and independent variablesData storage deviceLecture/Conference
25:34
Power (physics)TelecommunicationPoint (geometry)OrbitTerm (mathematics)SoftwareMultiplication signPhysical systemRow (database)NeuroinformatikLecture/Conference
26:29
Multiplication signPhysical systemOrder (biology)Pulse (signal processing)LaserOcean currentWhiteboardQuicksortAutonomic computingCivil engineeringPower (physics)MereologyTrajectoryException handlingDistanceMode-locking2 (number)Lecture/Conference
28:45
GravitationSpecial unitary groupPlanningOrder (biology)PhysicistField (computer science)SpacetimeSoftware testingTransmissionskoeffizientSoftwareShape (magazine)Sound effectExecution unitProjective planeElectric generatorFood energyLecture/Conference
30:06
Internet forumExtension (kinesiology)MereologyInternetworkingDebuggerLecture/ConferenceMeeting/Interview
Transcript: English(auto-generated)
00:00
Our next speaker will be Vint Cerf, who received the Turing Award in 2004, together with Robert Kahn, for, I quote, pioneering work in internet working, including the design and implementation of the internet's basic protocols, TCPIP, and for inspired leadership in networking.
00:23
And this latter aspect of the quotation, I think, will shine through today's presentation, because he will talk about the interplanetary internet. Vint, please. Well, first of all, thank you very much for allowing me to participate in this event.
00:48
I have to say, following Michael is so hard, because he's just so profound. And I just have a simple lecture to tell you about, and that's how do we extend the operation
01:01
of the current internet to cover the rest of the solar system. So my purpose here is to give you a sense for, is that the vodka or the water? If it's the water, I'm not interested. I never touch the stuff. The purpose here is to give
01:23
you a sense for how you have to change your thinking when the context in which you design the network is done. And so as we move from our terrestrial environment to the interplanetary one, our thinking about how to make a network function really had to change.
01:45
So let me just remind you that the internet design was done based on three different kinds of networks. There was the ARPANET. Oh, they have a pointer here, don't they? The ARPANET was this thing here, which is based on dedicated telephone circuits connecting
02:07
packet switches together. But when Bob Kahn and I were doing the work, the Defense Department wanted to use computers in command and control. So they wanted to make sure that they could put computers in mobile vehicles. So we had a mobile packet radio net in the San Francisco
02:24
Bay area with cubic foot-sized radios. And then we had a satellite network over the Atlantic in order to link the western part of Europe to the eastern part of the U.S. But that emulated ships at sea, ship-to-ship and ship-to-shore communication. These three packet
02:42
switch networks had very different regimes, different packet sizes, different error rates, different delays because satellite was synchronous. It was a half second up and down, a quarter of a second up and down, and another quarter of a second back. The packet radio network topology kept changing so the connectivity would vary. So the networks, even though they were all packet switched, were quite different. And our task, way back in the
03:05
early 70s, was to figure out how to design a protocol that made this whole system look uniform. Well, of course, if you fast forward, this is what the internet looks like. It's a big, giant, colorful network. Every little color here is a different network.
03:21
The system is fully distributed. The operators have different business models. They use different technologies. But the thing they have all in common is that they all use TCPIP as a way of moving data from source to destination. We have a common internet addressing space. We have the domain name system, which you use all the time in connection with Tim
03:42
Berners-Lee's World Wide Web. So here you have this giant, distributed system. But one thing that we can say about it is that most of the delays are relatively short because we're talking terrestrial distances. Even when we're talking about synchronous satellite hops and things like that, we're only talking about a few hundred milliseconds.
04:01
So that's what the terrestrial internet is like, and it seems to work relatively well. Now, in 1997, we landed a new rover on Mars. Remember that 1976 was the successful landing of two Viking spacecraft, and then there were a whole series of failures. And then
04:24
in 1997, the Pathfinder project landed a small rover on Mars. And so here you see several of the different spacecraft. The Sojourner was the little mobile component, and of course the lander was in a fixed location. My colleagues and I met in 1998
04:44
at the Jet Propulsion Laboratory after the successful Sojourner experiment. And we started asking ourselves, how could we do communication to support space exploration that was better than a point-to-point radio link? Because in this particular case, the 97 case, the signals coming from Mars were being transmitted directly from the surface
05:05
of Mars all the way back to the deep space network here on planet Earth. The deep space net has a big 70-meter dishes. They are in Canberra, Australia, in Madrid, Spain, and Goldstone, California. So they are very large-scale dishes in order to receive
05:20
very weak signals and to transmit very powerful signals back to small antennas that would have to receive them. But this is a point-to-point link. And we thought, gee, we have this internet thing. And it is capable of relaying packets through very complex topologies, complex connectivity. If we could have something like that in the
05:44
interplanetary system, we might be able to mount much more complex missions with a lot more numbers of devices communicating with each other. So if we could build an interplanetary internet, we could support manned and robotic space exploration better than just with point-to-point radio links. So let's see if I can get the next one.
06:05
So when we began our work in 1998, we thought, well, TCPIP works on Earth, so it ought to work on Mars. And actually, it probably would. But then we started thinking about what happens between the planets. And the first thing we discovered is that the speed of light is too slow. Between Earth and Mars, when we're closest together,
06:24
it's 35 million miles. It's three and a half minutes of transit time, propagation delay. And of course, another three and a half to come back. And when Earth and Mars are farthest apart in their orbits, they're 235 million miles apart. That's 20 minutes one way, 40 minutes round trip time. The original TCP flow control scheme was really
06:44
simple. Basically, if the receiver was running out of room to receive any data, it would send a message back to the source saying, I'm running out of room, stop sending. And if you receive that message within a few hundred milliseconds of running out of room, then it sort of works okay. But what happens if it takes 20 minutes before you hear
07:03
that the other guy has run out of room and you're pumping the data like crazy and it's falling on the floor and the packets are blowing away or the dog eats them or something. So the problem here is that round trip time delays are vastly bigger, and that's just Earth to Mars. I mean, when we start talking about going to the outer planets,
07:20
we're talking about hours of round trip time. So that's a problem. The flow control didn't work very well. There was another little problem, too. It was called planetary motion. Planets are rotating, and we don't know how to stop that. And so the problem is that if you have something sitting on the surface of Mars and you're talking to it directly from Earth, even with the big 70 meter dishes,
07:44
as Mars rotates, eventually you can't talk anymore until it comes back around again. The same problem with satellites that are in orbit around Mars. So what do we have? We have a variable delay and disrupted communications environment, which is much harder to deal with than the sort of thing that we have here on Earth.
08:04
Here's another example of our inability to simply adopt the TCP IP protocol suite. Whenever you use the World Wide Web, and you type www.google.com, or maybe you type www.bing.com or something like that,
08:24
what happens is that string, that's a domain name, that string has to be looked up in the domain name system, and what comes back is an internet address. So we're talking about layers here, protocol. So the domain name system basically hands you back, hands your computer back,
08:43
an IP numerical address to say where your packets are supposed to go in order to make a TCP connection on top of which you run the HTTP protocols, on top of which you run web-based applications. So the problem is that if we're doing this in an interplanetary environment, imagine you're on Mars and you want to connect to Google on Earth.
09:04
So you type www.google.com on Mars, and you send the domain name system lookup packet to Earth. It's going to take anywhere from seven to 40 minutes to get the answer back before you can then make the TCP connection all the way back to Earth.
09:21
And in that amount of time, it's possible that the thing that you're talking to on Earth has moved and it has a new IP address, and so you get the wrong answer back. So we ended up concluding that in fact the TCP IP protocols were not going to work very well in this delay and disrupted environment. So we said, okay, it's a new regime.
09:42
We'll call these DTN protocols, delay and disruption tolerant protocols. And we developed a brand new kind of networking based on that idea. The specific protocol we developed we called the bundle protocol. And we just picked that name because bundle and packet were kind of similar, only we wanted to distinguish the DTN versions from the terrestrial Internet protocol.
10:05
So bundle protocol is what got developed. The first thing that we realized is that because of the domain name resolution problem is that we had better break up the process of figuring out how to route the packet into two pieces.
10:21
So part number one, which planet are you going to? And so the first part of the routing is figure out which planet you're going to. And then after you get there, then you can ask the question, okay, I got to the right planet, now where do I go? And so it's a delayed binding solution. So first we figure out what planet we go to and we route through the planet system.
10:43
Then when we get to the right planet, we route on the planet to the destination that we're going to. So it's a two-part naming structure and a two-part binding structure. The second thing that we realized, way back in the day when Bob and I were doing the original Internet design,
11:01
memory was really expensive. And so if you were going through the store and forward network and you got to a router that didn't know how to get to the next hop, it would throw the traffic away. And that's what TCP does. And actually at the IP layer of the protocol, the lower level,
11:21
if you land at a node in the Internet and the node doesn't know where to send it because there's no route anywhere, it throws it away. The reason it did that is back then memory was expensive. And so we couldn't just store traffic in the net into each of the routers. But we're talking about 1998, memory got cheaper. And so we said, okay, look, if we've gotten halfway to Jupiter
11:43
and we're at the node at Mars, let's hang on to the data until the link between Mars and Jupiter comes up and then we'll forward the traffic because we went to a lot of work to get it to Mars. So we actually store information in the bundle protocol in the network itself and we wait until a link becomes available.
12:03
And if you think a little bit about celestial motion and the like, you know that some of the connectivity is predictable simply because we know what the orbits are of the planets and the various satellites. So we can actually build ahead of time what we'll call a contact graph so we know when it's going to be possible to communicate on the various links
12:23
based on orbital mechanics. And so when we're storing the traffic, we know when it's going to be likely that we can open up a channel to push the data further on. So that's another difference between the internet and the bundle protocols. The other problem that came up was network management.
12:42
In the internet world, there is a thing we call ping. Ping is basically just a user data protocol packet which allows you to send a packet to the destination saying, hello, are you still there? Can I actually get there? And then you get an answer back. Typically it takes tens to maybe hundreds at worst of milliseconds
13:03
to get an answer back if there's anybody there to respond in the internet environment. And so that's a big help when you're doing network management because one of the most important things is the destination is still there and if you can find out quickly, then if it doesn't respond, you know you have to go do something else.
13:21
In the interplanetary system, given that the store and forward is uncertain as to its delay and it's also uncertain as to its success, ping is not your friend here anymore because you can't rely on it to come back in any reasonable amount of time or any predictable amount of time. So the whole design of the network management system
13:42
had to be rethought in the interplanetary system given the fact that you really don't have a well-defined round-trip time that you can rely on after which you can decide that things have timed out and there's something broken. So network management has had to be rethought, mostly in the, you can send commands but you don't know for sure
14:03
when you're going to get a response back. So you have to be prepared for this uncertain response time. We also were very worried because we were doing this work for NASA and we were worried that we had spent lots and lots of money to put some of these spacecraft on Mars or Jupiter or in orbit around Saturn
14:22
and we didn't want a headline that said 15-year-old takes over Mars net. And so we thought we had better build in some strong authentication and some strong cryptography for confidentiality so that somebody couldn't go in, break into the system, inject bad information into it, take control over one of the distant networks.
14:44
So this system was built with a lot of strong authentication and security into it and thanks to people like Whit Diffie and Marty Hellman, we had public key cryptography available to do the key distribution in order to support those kinds of concepts. So there's much more security built into the bundle protocol
15:02
than had been built into the TCP IP protocols. So that's sort of the kinds of considerations that came up. Then we were doing this in a purely speculative way. This is 1998 to 2004. What happens in 2004? Two rovers land on Mars successfully, the Spirit and Opportunity.
15:23
And I don't know if you remember how they were delivered. They were delivered in big balloons, right? You just drop them, they go boing, boing, boing, boing, and then the balloon opens up. I have to tell you, if I had been at NASA and somebody came in and said, I'm going to deliver your $6 billion thing in a balloon that's going to bounce on Mars and open up, I would have thrown them out.
15:43
But in fact, it worked. So now we've got these two rovers on Mars. The plan was that the two rovers would behave the same way as the Pathfinder. Data would be transmitted from the surface of Mars all the way back to Earth in a direct line to the deep space network. So they turn on the radios and they overheat.
16:01
And I don't know why it was that this wasn't noticed before they actually sent them to Mars, but they said, uh-oh, now we have a problem. Now the data rate from Earth to Mars for the rovers, the Spirit and Opportunity rovers was 28 and a half kilobits a second, just a blazing speed. And the scientists are all grumpy about that to begin with.
16:21
Then we tell them, sorry, we're going to have to reduce the duty cycle for the radios because we don't want them to damage themselves or damage the other instruments. Now they're really grumpy because they want to get more data back. Well, one of the engineers at JPL says, well, wait a minute. You know, the rovers, the Spirit and Opportunity have an X-band radio on board. He said, yeah, that's not the one that goes back to Earth.
16:42
This is one that could be used to signal to the orbiters. What about the orbiters? Why are they there? Well, we send orbiters to Mars first to map the surface of Mars to figure out where the rover should go. So this engineer says, well, you know, there's an X-band radio on the orbiters. Why don't we reprogram the rovers and the orbiters
17:03
so that we can take the data from the rovers, transmit the data up to an orbiter when it comes overhead, and have the orbiter hang onto the data until it gets to the right place in its orbit to transmit the data back to the deep space network. That's called store and forward. That's also called packet switching.
17:21
So we notice that the radio going from Mars to the orbiter is much closer than going all the way to Earth, so we get 128 kilobits a second. And because the orbiter is outside of the atmosphere and it has bigger solar panels, we have more energy, and so we can transmit data back to Earth at 128 kilobits a second.
17:42
So now we get four times as much speed by going store and forward, and we don't have the overheated radio problem. So all the data that came back from Mars and still comes back from Mars is coming by way of the store and forward protocol. Now, it wasn't the protocols that we developed during that 1998 to 2004 period.
18:01
We actually used a prototype that was called CCSDS File Transfer Protocol, which was a sort of an early version of the bundle protocol before we elaborated it. But that protocol was available and it had been tested, and so we used the CFDP to build the interplanetary system,
18:24
which is currently being used, between Earth and Mars. And so for the last 13 years, that's how all the data has been coming back. When we landed Phoenix on the surface of Mars at the North Pole,
18:41
there wasn't any configuration for that particular mission that allowed a direct-to-Earth path, so we took advantage of the fact that the orbiters were available and we did all the relaying from the North Pole of Mars just to the orbiting satellites and then back to Earth using the CFDP protocols. And the same thing is true for the Mars Science Laboratory,
19:01
which is over here, and the future missions as well. So at this point, we're using this prototype. Protocol has been thoroughly tested and shown to work. But in the meantime, we've been continuing to work on the refinement of the bundle protocols. So in 2008, 2009, and 2011, we took advantage of NASA's permission
19:24
to use the epoxy spacecraft, which had visited two comets, to test our bundle protocol. So this thing was about 81 light seconds away and we uploaded the bundle protocols in their then-refined form
19:40
and we did tests for several iterations with Earth-based stations and epoxy. Then we uploaded the bundle protocols to the International Space Station and allowed the astronauts to use the protocols for communication that wasn't considered operational communication,
20:03
so they weren't ready to trust us with anything that was too important. But email going back and forth between the astronauts and their friends and other kinds of application data was transported back and forth between Earth and the International Space Station using the now standardized bundle protocols.
20:23
Between 2012 and 2016, the European Space Agency has been doing this metron test. We're doing real-time testing of the control of robots from the International Space Station using the bundle protocol. Now this is important because, in a sense, the bundle protocol was designed
20:42
around this worry about variable delay, uncertain response time, and the like. And yet, if it turns out that the underlying communication is fast enough and low enough latency, we can use the same protocol to do real-time control. And so the metron experiment allowed us to show that the astronauts could control
21:02
and drive a spacecraft. Here, actually, it was in Germany. The first one was a little Lego thing, and then the next one that they did was a little more elaborate. But you could do real-time control because the round-trip times were low. So that means the same protocol, the bundle protocol, works for both the real-time communication cases to allow interaction
21:24
and also the delayed kinds of interaction. You don't want to try to steer a rover from Earth when it's on Mars because you won't find out until 20 minutes later that you just rode over a cliff and that's not too good. You know, dear sir, you just destroyed a $6 billion spacecraft.
21:41
Congratulations, and here's the bill. So now we know that we have a protocol that works over both of these real-time and not real-time regimes. But now data rates are an issue. And so the next question is, how do we get increased data rates? At best we would get maybe megabits per second in these deep space links,
22:05
and the question is, could we use optical communication at much higher data rates? So now another test was done with an orbiting spacecraft around the moon from Earth. So we transmitted to the LADEE spacecraft at 600 megabits a second
22:22
using the bundle protocols. So now we have yet another example of the bundle protocol spanning now speed variations from 20 kilobits a second up to 600 megabits a second in this lunar test. So that gave us some confidence that the protocols that we've now standardized are capable of spanning a very broad parametric regime for communication.
22:46
We also have done some other tests with the Japanese space agency JAXA on interoperability of multiple implementations, independent implementations of the bundle protocols. Then we moved the work from the research environment
23:01
of the Internet Research Task Force to the Internet Engineering Task Force where standardization in the DTN working group is underway. And that means that these protocols could be made available for commercial application. They are in fact available already in source code form on GitHub
23:20
and have been downloaded and made use of in a variety of civilian applications. The Consultative Committee on Space Data Systems, which is a U.N. agency and standardizes protocols, has actually standardized both the bundle protocol and also an underlying transmission protocol that we call the Licklider transport protocol
23:43
because J.C.R. Licklider was the man who thought up the ARPANET project in the first place. And in 1962 he sent a memo around to some of his colleagues saying, I want to tell you about the intergalactic network. And so we found that letter and we thought, well, we're not quite at intergalactic yet,
24:00
but interplanetary isn't too bad, so let's honor the memory of Licklider by naming this transmission protocol after him. And then finally, another test that was done in the north in the Arctic. Lulee University implemented the DTN protocols in order to track the Sami reindeers that were floating around or walking around in the north
24:23
and also to provide the Sami community with a communication capability because it's so far north that you can't really use satellites. The antenna would have to be flat on the ground on the horizon and you still can't get to the satellites because you're so far north,
24:40
but they were using store and forward communications with the radios on the reindeer as a way of doing delayed and disrupted tolerant communication. There's also, at Braunschweig, there's also an implementation that was done on the Ubiquity router and also for the Raspberry Pi processors
25:03
using the free versions of the protocol that are available at GitHub. So just to finish up what the plans are, we're also going to be using the TDRSS system, which is a near-Earth communication system for near-Earth space exploration.
25:21
We're going to be implementing the DTN bundle protocols for that system as well. And during the 2020s, we have offered these protocols to all of the space agencies that are planning their missions ahead of time. So here's what we hope will happen in the long term. We're not saying we should go build an interplanetary network and then wait for the aliens to show up or something.
25:43
The whole point here is mission by mission. We can launch these scientific spacecraft, but when the spacecraft have finished their primary scientific mission, then it's possible to convert them into nodes of an interplanetary backbone. And so the idea is to take advantage of the fact
26:02
that we're going to be sending these spacecraft out anyway. And as long as they have power, communications, and computing capability, they can be used or repurposed in that fashion, which is exactly what we did with the orbiters around Mars so many years ago. So over the course of the decades, especially you folks in the back rows,
26:22
we'll actually be able to watch this interplanetary system grow over time. Now the story doesn't quite end there. It turns out that some of us have aspirations to get to the nearest star, and we'd like to be able to send a spacecraft there in 100 elapsed years.
26:42
In order to do that, we're going to have to work on propulsion because the current propulsion systems that are available would take 65,000 years to get to Alpha Centauri, and that's sort of a long time. That's about six times longer than our civilization has existed. So we need to find some kind of propulsion system
27:00
that will get us up to somewhere between 10 and 20 percent the speed of light. Then there's the navigation problem. You know, when we send spacecraft in our solar system, and we get part of the way through the path to the destination, there's typically some mid-course correction that you do. You send commands to the spacecraft and you tell it to alter its trajectory
27:24
in order to assure that it gets to the right place at the right time at the end. And that's all done with reasonable delays. We're talking about minutes to hours of delay to make these mid-course commands. But imagine you have a spacecraft that's a light year away on its way to Alpha Centauri.
27:41
It's going to take a year to send a signal there and another year to find out what happened. So that's not very interactive. So navigation is going to have to be done on board autonomously. Fortunately, the stars are not moving too fast and there are some that we can use as navigational beacons. And so the possibility of autonomous navigation to get from here to Alpha Centauri is entirely feasible.
28:05
And so that's how that problem is likely to be solved. Then there's this other problem. How the hell do you generate a signal that you can detect from four light years away in a spacecraft that you can afford to build and get there? So that's my problem. And some of the ideas that are kicking around involve things like
28:22
collimated lasers, maybe femtosecond lasers, you know, pulse lasers. So if you had 100 watts of power available and you could compress it down to 10 to the minus 15 seconds, that's a pretty good-sized pulse that you might be able to detect back here at Earth. Except for one other problem. Over a four light year distance, even a collimated laser is going to have some beam spread.
28:43
So by the time you get four light years away, the beam is kind of wide. The signal is very low. And now you know why I need an interplanetary backbone network because I think we have to build a synthetic aperture receiver that will take the signal from Alpha Centauri and reintegrate that signal back
29:01
in order to find out what did this spacecraft find. But there is one other possibility. One of the physicists reminded us that gravity has an effect on light because it affects the shape of space. And so it's possible that we could use the gravity field of the sun to focus a signal coming from Alpha Centauri.
29:22
Now you have to go 550 astronomical units away from the sun in order to get to the focal plane of the sun's gravity field. But that would be a great test for a new engine that gets us out, you know, that could get us up to 10 or 20 percent the speed of light. So the idea now would be to build a spacecraft, get it out to 550 AU
29:42
and let that be the receiver for the signals coming from Alpha Centauri. Now the other way around is a little harder because we don't have anything at Alpha Centauri that we can rely on other than the spacecraft that we delivered there in the first place. So we may need to use the synthetic aperture transmitters in order to generate enough energy in order to talk with the spacecraft there.
30:03
So I won't live to see the end of this particular project, but it's a lot of fun to be part of it at the front end. And I can now, to echo what Michael said, if you get to start something and be part of it, even if you can't see the end of it, it's really cool.
30:21
And that's what I feel about the internet and its interplanetary extension. Thank you very much.