[Music] easy there were lots of campus ethernets because they were really easy to deploy and you could put them in a department and then you could run a wire between two departments and get a bigger network and so we've grown up networks sort of by agglomeration uh in lots of different university campuses and nsf came up with some money said oh we've got a little bit in our budget where we could get some 56 kilobit lines and tie those campuses together and they did that made the nsf met phase one but now you're tying together
10 megabit campus infrastructure with 56 kilobit wires and it was wildly popular because people that couldn't talk could suddenly talk and they're sending emails and moving huge files and everybody's really excited about this technology but um any one of those campuses could over subscribe the net by a factor of a thousand so uh we had a lot of packets piling up and getting dropped at the time i was a researcher at lawrence berkeley lab which is in the hills up above the berkeley campus and i was also teaching on the berkeley campus even back in
those days which was mid-80s we had a for every class there was a messages group you know like a little news group that was set up all the assignments would be put online and i was trying to get course materials from my office in lbl down to a machine in evans hall at berkeley and uh there was like zero throughput in the net it was uh one packet every ten minutes or so and it seemed unbelievable would be unbelievably bad and i went down and talked to mike carrolls who was heading the bsd group the
people that developed berkeley unix and he's getting reports of these problems from all over the country from in those days the easiest way to start running tcpip was to bring up berkeley unix because there was a arka-funded very nice implementation and and everybody was seeing poor performance so we talked for a long time that day and on succeeding days about well what's going wrong but is there some mistake in the protocol implementation is there some mistake in the protocol is this thing was working on smaller scale tests and then it suddenly fell apart i think
we struggled for three or four months just going through the code uh writing tools to capture packet traces and looking at the of traces and trying to to sort out what was breaking and i remember the two of us were sitting in mike's office after we've been pounding our head against the wall for for literally months and one of us i can't remember which one said you know the reason i can't figure out why it's breaking is i don't understand how it ever worked uh you know we're sending these bits out at 10 megabits they're
zipping across campus they're running into this 56 kilobit wire we expect them to go through that wire pop out on the other side go through how could that function that turned out to be the the crucial starting point that uh at that point we started saying well what is there about this protocol that makes it work how does it deal with all of those bandwidth changes how does it deal with the multiple hops so this picture that direction is time this direction's bandwidth so that's a fat pipe and that's a skinny pipe and uh the
scale of the time is you know this is a 10 megabit pipe and this is a 56 kilobit pipe so here the difference is about three to one it was really closer to a hundred to one um and so time seconds times bits per second equals bits so each of these little boxes in there is a packet it's the number of bits in a packet and if you scrunch it down in bandwidth it's got to spread out in time because the number of bits doesn't change and so uh see the burst of packets of windows
worth of packets gets launched it's going to fly through the net until it hits this fast to slow transition and then because the packets have to stretch out in time they'll have to sit there and wait as they're fed into the slower wire and you they pop out the other side they get spread out by this bottleneck by the slower wire once they're spread out they stay spread out right there's nothing to push them back together again they hit a receiver it turns every data packet into an ack so you've got a bunch of backs
that are going back towards the center and they remember what's the right spacing for that bottleneck uh so the axe get back to the sender and every act gets turned into a data packet so we can see the data packets flowing back and this is after one round trip time now the packets are coming out perfectly spaced so they go by uh a new one goes into the net in exactly the time it takes a packet to exit from the bottleneck so these acts are sort of acting as a clock that tells you tells the
sender when it's safe to inject every new packet and they're always going to be spaced by whatever is the slowest point in the net and the key thing is is how do you how quick how can you get the steady state sort of most quickly without wasting i yeah and the issue the failure we saw was this works perfectly after you've exchanged a round trip time worth of packets but when you're starting up when you're here there's no clock and so the hard part on tcp is not getting it running it's getting it started because
once you've got it running you've got a clock tells you exactly what to do so if you turn them on suddenly you get in this repetitive failure mode uh where you saturate the the buffering that was available at some gateway and then when you retransmit you do the same thing again so you're always losing packets but if you turned it on more gradually then you wouldn't overload the buffering and you'd get enough of a clock going so that you control the amount of backlog to fit the available buffer but you'd still be growing the number
of packets in flight so that you'd eventually get a you start with a kind of sporadic clock but you'd eventually fill in the details and get a per pack o'clock how did you get it to the point where it was in all the tcp implementations on the planet because they kind of have to cooperate in a way so remember it was a much simpler time when you're talking about all the tcp implementations on the planet at that time there were like four so there's the berkeley unix one there's the mit pctcp there was a bbn
one that was used in butterflies and imps and there was a multix one i took the couple of tcp kernel modules that we've been working on packaged them up in a tar i had this horrible driver hack that would let us nerf packets from the kernel and it was really a horrible driver hack it was the way you said what you wanted to snarf was by 80 being the kernel you you wrote in binary some new values these are the ports that i want to look at and the driver would capture those into a circular
buffer and you'd read kernel memory to pull that buffer out craig larris and chris tork who were working in my group at lbl and were both long-time kernel hackers we're just embarrassed at this and they put together a really nice clean driver uh thing called bpf the berkeley packet filter that would let you pull packets out of the kernel by a very efficient i o control interface and so we bundled all of that up and on the tcp mailing list which in those days was you know tcp was very experimental it was very leading edge
and pretty much everybody who was playing with it was on that mailing list to announce that this stuff was available a bunch of people ftp'd it tried it it blew up sent kernel core dumps and bug reports and fixed the bug reports and put new versions out and somebody would immediately come back and say panicked here do you want the k-core and i go oh no embarrassed put out a new version go out somebody else will come back and say panicked here and fix that and just cycled like that and after about a day we
got a version that didn't immediately panic and then started working on the uh the actual algorithms and a little bit of tuning to make sure that it actually did good all the time and didn't do any harm just completely uh a community effort and you know sort of when the community was saying this uh mostly does good and never seems to do harm that's pretty what much what mike needed to put it into the kernel so he took that the community developed modules and rolled them into the bsd release you
