The magic of this is there is no interim long term storage inside the network.
All the long term storage is outside, and now we're going to talk about that.
So one of the things that makes IP so fast is that it is not demanded to be
perfect, it is not demanded to, to deliver data in order, and it's not
demanded to, it, it's, there's no requirement that it doesn't lose data.
Its fast and barely ever loses data and when it does there is a layer to recover
and that's we are going to talk about next.
So the internet protocol is this multi-hop packets can take multiple
paths, they can make use of all kinds of crazy links.
But now, we're going to move up one, right?
We're going to move up to the TCP layer. So the TCP layer is both simple and
complex. The purpose of the TCP layer is to
compensate for the possible errors in the IP layer as well as make best use of
available resources. So if the network, if the overall network
from the overall network from here to here is extremely fast we want to send
data really fast right. If on the other hand the overall network
from here to here is really slow we want to send data slowly and be efficient
cause remember part of the goal of the. TCP IP networking is to share effectively
and so we need to be aware of whether our network is fast or slow.
And those are the kind of problems we solve with a TSP layer.
How fast is the underlying network, how reliable is it and if something goes
wrong what do we do to deal with that. So the key idea in TCP/IP is that when we
send some data, we break it into packets and then we send each one.
And then we keep them until they get an acknowledgement from the other side and
then and only then do we throw them away. And at some point, if a packet gets lost
It can be sent again, and again, and again until it finally is acknowledged in
the destination system. And so that's basically what TCP does, is
it figures out which packets have or have not made it across the Internet layer.
So here's an example scenario. So we got a message that's broken up into
five packets. We've got sort of the first hundred
characters, the, the, you know, first characters, the second, and third packet.
Now, what TCP does, is it speculatively sends a few packets.
Says okay, let's get ahead. Cause if you sent one and waited Then you
might not make best use of the network, so you kind of guess and dump a few
packets out there. And so you send, let's say we send three
packets, cue them up for sending. And as fast as we can send them out the
back of our network, we start spooling them out the back of their network.
And somehow, two of them make it across the internet, to the destination, but
somehow that poor second packet, just like every time I'm doing a lecture, the
poor second packet never gets it. You don't want to be the second packet in
one of my lectures, 'cause you're going to get it.
But somehow, the second packet has gotten vaporized.
Now, time passes. And[COUGH], the receiver gets this s-,
s-, this sensation that maybe, maybe, maybe something's missing.
And so it sends and acknowledgement back, and it says, I'm going to send a note
back that says, look, I'm ready for 200. I do have 100, and I'm, I'm ready for
200. Matter of fact I might even through away
300 cause it's been so long. So I want you to start me over at 200.
[COUGH] But sender all of a sudden knows that 100 has been sent.
And so it knows that is can throw this one away now right it's been
acknowledged. So there's an acknowledgement stream
going back and forth, so now the sender sends 200 and 300 and then they make it a
cost, the receiver says I have got 200. Thus the 300 and then they send 400
speculatively. 300 makes it, 400 makes it and receiver
says. I got 400, which means now it can cross
off 300 and 400, right? Check those off and throw them away, and
then send 500 cross, and at some point check those off.
It's got 500, and now the sender can sort of like empty, check everything off.
Everything's been sent, and it's been acknowledged, and we know.
And so that's kind of an oversimplified view of the kind of bookkeeping It's
going on, on both sides of a TCP connection.
And so this, right here is in a sense the genius of the internet.
The storage requirements in the middle, the routers, this is the IP basically the
network of networks, they, we didn't design these to require a lot of storage.
We wanted them to be fast, we wanted them to be agile, we wanted to be dynamic, we
wanted to be clever, but we also gave the right to fail.
So we didn't demand storage. We didn't say, hey, hold on to packets,
you know, all over the place. Just, store up piles of packets, piles of
packets and pile up in these, we don't ask that.
No router has to keep the packets. As a matter of fact, routers are supposed
to throw packets away to communicate back and forth between the system that maybe
things aren't working so well and, don't use me to get to California.
On the other hand, with hundreds, maybe, you know, hundreds of thousands or
millions of routers but billions of computers on the outside.
So we need a way to make this reliable. So we need to have memory to store the
packets while they're in flight so we can retransmit but we store the packets in
the computers that are outside. And there are billions of these
computers, there are billions of them. Every computer that you can carry around,
every laptop. come here.
Every time we add another computer to the network, we add storage for packets that
are being sent. So when your computer or, or phone is
sending across the network, it is responsible for retaining its own copies.
It does not expect the inner part of the network to do so.
And that is absolutely brilliant, so it's what really makes this work.
And so that's kind of a great oversimplification of what's going on.
And it turns out that there is still a lot of engineering to make that happen.
So I'd like to introduce you to a, to another of the innovators in the, that we
meet in this class his name is Van Jacobson, and I met up with him at Xerox
Park he did the work we're going to talk about while he was at Berkley, and[COUGH]
In the late 1980's there was this prediction that the internet was going to
die. And it seems obvious that it was, it's a
good idea now, but back then there was a bunch of folks that felt like academics
weren't smart enough to make a network. And
And they were like IBM and digital equipment that thought they, the vendors,
should make the network, and we should just pay them to use their network.
And as the NSF net was coming up, and more and more computers were being
connected in the background, the backbone was so slow it started to fail.
And it looked like the predictions of all of the computer vendors that said
academics couldn't build a robust scaleable network were going to be true.
And so Van Jacobson tells the story very differently but the way I saw the story
happening and unfolding in 1987 is Van Jacobson saved us.
the network was crashing, and we all installed Van Jacobson patches and the
network got better. And in my recollection this was the last
time it appeared that the entire internet was going to crash.
So we named it the Van Jacobson protocol. And he doesn't like to call it the Van
Jacobson protocol because he's a shy and unassuming guy.
But I, I think he saved us. And so this interview is him describing
sort of that moment back in the late 80's where he invented the slow start
algorithm that really is part and parcel of every T C P implementation that you
have on every computer that you use as a matter of fact it's being used to float
control on this lecture right this second as we speak.
So here's Van Jacobson.