Programming Throwdown - 137: The Origins of the Internet with John Day

Episode Date: June 27, 2022

00:01:01 Introduction00:01:28 COVID and the challenge of teaching00:04:11 John’s academic and career path00:08:14 LSI technology00:12:13 Collaborative software development in the day00:15:24 ARPANET’s early use00:20:08 Atom bomb and weather simulations00:26:55 The message-switching network 00:34:57 Pouzin00:38:00 Every register had a purpose00:45:15 The Air Force in 197200:52:10 Low memory00:59:14 Early problems with TCP01:11:51 The separation of mechanism and policy01:23:25 FarewellsResources mentioned in this episode:Professor John D. Day:Wikipedia: https://en.wikipedia.org/wiki/John_Day_(computer_scientist)Website: https://www.bu.edu/met/profile/john-day/Book: https://www.oreilly.com/library/view/patterns-in-network/9780132252423/ Pouzin Society: Website: https://pouzinsociety.org/ Twitter: https://twitter.com/pouzinsocietyIf you’ve enjoyed this episode, you can listen to more on Programming Throwdown’s website: https://www.programmingthrowdown.com/ Reach out to us via email: [e-mail] You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM  Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Hey everybody, really excited about this episode. So the internet is actually kind of an amazing thing that even I would say Patrick and I largely take for granted. I think at one point there was a networking course. I never took it, actually. But Patrick, you might have taken it. So I know very little. I know that there is all these layers. There's like an IP layer and a TCP layer, but very superficial. It just seems like dark magic and wizardry that I can just reach out and connect to just about any public server on the whole web. It's pretty remarkable. Never actually, to be honest, understood how it works all the way down.

And so really, really excited that we have John Day, who's a professor at Boston University, who's going to really dive in and explain to all of us how this actually works and how it came about and what were all the sort of design points made along the way and that whole evolution. So thank you so much for coming on the show, John. Thank you. Cool. So, you know, we always kind of start by talking to people about, you know, the pandemic. I mean, I know we're kind of hitting the tail end as far as, you know, let's say like lifestyle disruptions. I don't know what the data is on the actual pandemic itself, but so how did you kind of weather all of that?

What did you do during the lockdown? Did you still teach? How did that all go down for you? Actually, it was pretty normal. We went to teaching online. Actually, I was at a conference in Paris the last week of February. And we got in just as everything was shutting down. I came home.

I taught a week, was going to go to Phoenix to see my grandchildren. And on spring break, and we shut down right then. And I said, I think I'll stay here, which was for sure. Because I probably wouldn't have been able to get back. Yeah, right, right. But we went online. And I worked right out of where I am now. Since I don't have kids I have to muck around with.

I didn't really have much reason to go out. That makes sense. What are things like now? Are universities still online? I haven't been really much reason to go out. That makes sense. What are things like now? Are school, are universities still online? I haven't been really coming up with that. No, we went back last fall. Okay. Most everybody did.

The local schools have been meeting since fall. They've gone back as well. There's been a big debate about masks and stuff, of course. Right, right. Things are pretty much back to normal. Very cool. I'm actually going to, there's a bunch of conferences coming up. There's CVPR, ICML, and then there's NeurIPS in December.

And I'm going to SciPyCon. And so there's this huge mixture this year. There's some conferences where it's pretty much all virtual. There's some where it's pretty much all virtual. There's some where it's mostly in person. There's some that kind of say you could do either or. And so it seems like no one really knows how many people are actually going to show up. What's the whole conference scene like for you this year? Oh, right now I have nothing scheduled. Yeah. Yeah. That makes sense. Yeah. I have a feeling the conferences are going to be sparse.

I'm getting to the point where I, you know, I choose, choose them carefully. Yep. That makes sense. Totally. Awesome. So why don't you kind of, uh, walk us back a bit and kind of talk about your, uh, kind of path, you know, your career path and kind of what got you to, uh, being a professor, what made you choose to go into academia versus industry and path and kind of what got you to being a professor? What made you choose to go into academia versus industry? And kind of what's your whole background? I guess I would have said I'm very fortunate. As I always tell people, I grew up in a town of 900 in Southern Illinois, a very rural farm community. I had the largest high school graduating class they'd ever had, 42. Nice.

And then I got admitted to the University of Illinois, which was a bit of a culture shock. 35,000 students, most of them from Chicago. One of the better engineering schools in the country. So actually, one thing real quick, is University of Illinois the same as UIUC or are those two different universities? Yeah, it's UIUC. Ah, okay. Okay, cool. Yeah. And it was very lucky I fell in with a bad crowd. And there were two parts to the bad crowd. One was we were building the world's first supercomputer called ILLIAC-4, which was a 64 processor machine. And I was part of the operating system group.

And a part of that group were collaborating a lot with a very charismatic, very smart professor by the name of Heinz von Forrester, one of the four founders of cybernetics, who really put us through the wringer. He didn't tolerate sloppy thinking, and neither did we. And so it was a good match. It had a great effect on how I think. Building ILLIAC 4 had a lot of technical and political problems along the way so since we were the largest military contract on campus we were being uh demonstrated against

for trumped up reasons it was really hilarious it appears that that, okay, the Daily Illini, the student newspaper, wanted to be a leader of the radical movement. And a Vietnamese study program had been sort of snuck onto the Southern Illinois University campus. And they wanted to make the case that the same thing had happened with iliac 4 and this was terrible and it was going to be doing research you know classified research and all this bad stuff and they their proof was it was never anything about the board of trustees was never reported in the student newspaper well two of our guys one guys i work with closely went down to the local newspaper and dug through the archives and found that, well, every time there was a decision to be made, it was covered by the local papers. So in a debate on campus between the two of them and the radicals, this came up and we said, well, see, it wasn't secret at all.

It was out there in the public. The student newspaper just preferred to cover the fraternity and sorority news and not the actions of the board of trustees on LA Act 4. So did you feel like when you were having these debates and being challenged in this way, you're looking back on it. So you kind of say you're really, you know, super focused. You had this advisor who, you know, didn't tolerate fools, right? And so you were really focused on that. But then you have this huge distraction, right? So you do have to kind of tolerate the fools, right?

So how do you handle that? Well, you know, we actually used to go out and demonstrate and then come to work. I mean, come on. No, but, you know, after that, then they said, well, we don't think classified research should be done on campus. And we said, neither do we. That's why nothing in this project is classified. Ah, right. And in fact, the building it's supposed to go into is not a secure building.

So they didn't want to believe that. However, what was really interesting is one of the reasons for building this machine was to push LSI technology. This is 1970. Now, what's LSI? You have to tell me. Large-scale integrated circuits. Ah, okay. Got it.

Okay. to tell me large scale integrated circuits ah okay got it okay before we put processors on chips i mean the first chips i saw had a few gates on them wow right this was lots of gates you know doing you know functions on chips and so texas instruments had the contract to do it, but they couldn't do it for the price that they negotiated. So they put their legal legals to work and got out of the contract. So instead of having chips that were about the size of a quarter, they became circuit cards that were probably eight inches high and 18 inches long. Wow. Like a graphics card, almost like a modern day, you know, GPU or something. Instead of the machine being the size of a mainframe at that time, you know, a few cabins, the machine was 10 feet high,

eight feet deep and 50 feet long. Okay? The building it was to go into had no heat, just more air conditioning in the summer. Okay. You know, and the whole, but the whole other aspect of this, now, actually, this was a vector machine. So it was a, you know, know single instruction multiple data stream machine

you know parallel processing in that sort of brute force way not terribly interesting however we were given the job of putting ourselves on something called the arpanet now that was a heck of a lot more interesting. And so we were the sixth system to go live on the net. As I always tell people my original network address is 12. Not 12 dot 12. There's only one octet? Oh, the maximum number of addresses was 64. Nice. Nice. Okay.

I mean, come on, guys. So actually, so physically, how did the machines back then, you know, I mean, was it phone lines or something? Well, okay. As you probably knew, the ARPANET consisted of switches, which were Honeywell 516 minicomputers, which were about the size of a rack. Actually, they came in a militarized container that was a little over six feet high and probably about three feet by three feet. Wow. You've seen the pictures of Kleinrock's first installation on the web. And we all had one of those.

There were incredibly fast lines connecting them. 50 KB. Well, I mean, computers in those days had a hard time, you know, keeping that pipe full. Yeah. I mean, this was lightning speed. Okay. I mean, remember was lightning speed. Okay. I mean, remember, in 1971, I had a terminal at home that was 300 bits per second. Wow, 300 baud modem?

Yeah. So, Patrick, what was your... I remember I had, I think, a 2400 baud modem when I was like nine years old. Patrick, what was your first internet experience? I was high speed. I was like 28k, man. Oh, you started with 28k. Then they had the 56 and there was something about the 56 that was special. Like it had switches or something. They went to 56k dial up at one point. But no, it was 300k, 300 bits per second. And we actually were doing teleconferencing back then. I was doing collaborative software development

with people all across the country in 1971. It's a good point. I wonder why different projects now don't do collaborative coding. I think part of it is it's hard to really develop your identity. You know, back then you probably knew everybody who was on the Internet at that point because it's a closed community. Well, you get back home pretty quickly. Yeah, right, right. You know, in 1976, I moved to Houston so my wife could postdoc and I commuted to Illinois over the net.

You know, I come back up to Illinois about every six or eight weeks, check in and go back down to Houston. And we were doing a lot. I mean, there was a lot of advanced stuff going on. Of course, you know, other people were on the net, you know, UCLA and MIT and Stanford and SRI and Utah and on and on, you know, Engelbart's NLS was on the net, which was just a mind blow. So what's NLS? Doug Engelbart invented the mouse for a system called, the online system called NLS. And it was a hypertext system in 1970 with a three-button mouse and a five-finger key set. You courted commands with the key set, and it would echo the command as soon as it was disambiguated by what you had courted that was real simple you know a thumb was a and index finger b and two of them you know c and you

know nothing fancy and then everything was outlined for them because they were pushing it to do text, let alone figures or, you know, graphics. So everything was outlined for them. And you could do things like pick up a section and move it and all the subsections down. There were things called view specs where you could say, show me the first two lines of the first three levels of this document. Bing, it's on the screen. My favorite was NLS was coded in a language called L10

and a procedure call in L10 looked like a link to NLS. Oh, interesting. So you could do something like you're sitting there at your terminal and you could say, huh, what does that procedure do? Chord split screen, select the procedure, jump link.

You had the body of what you were looking at in the lower part of the screen and the procedure body in the top. Oh, that's cool. Yeah. This is 1970. Remember, in 1970, 99% of everybody is still on punch cards. Right, right. When did people actually really get on the internet? I think it was like the early 90s, right?

Yeah, right. This is, yeah, this is 20 years. Yeah, exactly. Before it was opened up to the public. We did a land use management system for the six counties at Illinois. We did a land use management system for the six counties around Chicago. We had put the first tunic system on the net in the summer of 75. And then we cut it down to fit on a one board PDP-11 in a pedestal with a plasma screen and touch. This is in 76 to create an intelligent terminal that had a keyboard, but you didn't need it. And we could do graphs for land use management and figures and draw maps down to the square mile and, you know, shade them accordingly and all sorts of stuff.

Wow. Amazing. I mean, a lot of the, you know, when I look at, you know, some of the BLAS, you know, the linear algebra systems today, a lot of them still have that code. It's either Fortran or Assembly. A lot of that code that those people wrote 20 years, 30 years ago, well, what, 50 years ago now is still there. Well, yeah, that's one of the things you have to be careful about. Actually, we wrote three operating systems from scratch before 75, but they were all done in a high-level language.

We got away from Assembler very quickly. I should have mentioned about NLS. NLS was a full hypertext system, both directions, unlike the web, which is just one way. Wait, so what do you mean by that? I didn't understand that. In the web, you have links to go forward, but you don't have links to point back into stuff. And so it's full hypertext. Oh, I see what you're saying.

Okay. And we were doing all of that. We did a spin out from the university, doing a lot of stuff for the DOD. Actually, yeah. Can you dive into that a little bit? So I know, you know, my advisor actually, fortunately, is after I graduated, but he did a spin off. So he went and worked for a company. And so what is that like as a professor? You know, how do you... Actually, we were never professors. We were always, we were academic staff. Ah, got it. Okay. So it's probably a different kind of a discussion than if you're a professor and you kind of leave. As I commented earlier, before we started all this,

to give you an idea of what this group was like, and I'll repeat, was we went out to work on ILLIAC-4 once. And it was being built in Paoli, Pennsylvania. And as we got off the plane in Chicago, the flight attendant said to me kind of breathlessly, are you guys in a band? And I said, no, we're Crypto Fascist Likies of the Military Industrial Complex, which is what the student radicals called us. I just owned it. I should mention the thing about ILLIAC 4 because that was really important. All this demonstration stuff came, the whole reason for bringing up the cost overruns that were caused by TI bugging out on the chips, okay, put the head of the project under a lot of pressure from ARPA because the machine was costing a heck of a lot, a lot more than predicted.

And so the head of the project finally said, oh, gee, you know, I can't guarantee the safety of the machine if it comes to Illinois. See, I mean, ARPA was getting reticent about giving him more money to finish the machine. So instead, ILLIAC-4 went to NASA Ames Research Center on Moffett Field. And of course, for that guy to accept it, he said, oh, well, hey, wait a minute. I can't take this unless I have the money to finish it. Well, they always like to give money to the new guy,

whereas they're reticent to give money to the old guy. Right? So the student radicals, even though there was no classified research to be done in Illinois, provided the excuse for the machine to go to Moffitt, where classified research could be done on it. Oh, okay. Okay. Kind of backfired.

But the thing about Moffitt is you don't have, you're not on a college campus anymore. So now you have to try and draw folks from, I guess, Stanford would be the closest university. Well, I mean, there were lots of people wanting to do, you know, atom bomb simulations and stuff on this machine. I mean, when we turned it on, it was 13 times faster than any other machine in the world. Actually, can you dive into that? So I've heard a lot about, you know, supercomputers being used

for atom bomb simulations, but I don't actually know what that means. So when someone does an atom bomb simulation, what are they simulating? Is it the amount of destruction? What's the value there? There's a whole class of problems that are solved in a similar way. Everything from the weather to nuclear bombs as near as i can understand and in fact there's a very simple thing one does in electrical engineering solving la place's equation where you say okay i've got a potential say along one wall line or axis and

another one on the other. And the question is, what's the potential for everything in between? And what you do is you come up with a set of equations for what happens in the cell. Okay. And you have measured points. And then you interpolate by iterating over it, what that effect should be. So take the 24 hour, the weather forecast. They divide the planet, you know, the atmosphere up into big cubes. They have equations for simulating what happens in those cubes with the movement of air.

They have measurements for certain points in that space. Right. Yep. Right. So those things are real. And then they iterate over that saying, what effect should that have? Pressure, temperature, you know, wind speed, et cetera, of what's there now and where will it be? So by iterating over that thousands of times, they get a prediction of the weather. Same thing with an atom bomb simulation.

Got it. I see. So they detonate atom bombs over the ocean or like in some kind of a really controlled environment and then they can interpolate. Well, yeah, right. Or they take the, even underground, they take all the measurements and everything and then, well, actually, as you say, do one live, take all the measurements. Now you can plug it in and vary strength and everything and see what happens. Got it. It's kind of a segue, but nowadays, is that still the, the,

you know, like you still see every now and then like, Oh, you know, we have a new supercomputer. I think Nvidia built one. And then there's someone somewhere else. What are those like, what are supercom know, we have a new supercomputer. I think NVIDIA built one and then there's someone somewhere else. What are those, like, what are supercomputers used for today? Well, tons of things. I mean, notice how much better the weather forecasts are. Good point. Okay.

You know, and also the models have undoubtedly gotten a lot more sophisticated. I mean, you know, I've been a network guy for a long time now. I haven't been near any of that stuff for quite a while. Fair enough. Yeah. But, you know, just looking at it, you can see protein folding, you know. Right, right. You know, all sorts of things are being done, you know, with those sorts of problems, you know. Anyway. Yeah, that makes sense. So anyway, things went along with the ARPANET for a long time. We did, you know, all the base protocols that you would think about. And I have to say, one of the things you really want to take into account is, remember, the ARPANET was built to be a resource sharing network.

It was built to lower the cost of doing research on ARPA projects. Okay. So that they wouldn't have to buy a big honking computer for every site on the net or every site they were funding. And, and very quickly that became, you know, very much our, our, our way of working. In fact, we were the largest user of the big use 36095 at the Rutherford High Energy Lab in the UK because we were illegally moving files from CERN to Rutherford to Illinois so they could be used to build Batavia. So what's Batavia? Fermilab. Oh, interesting. Okay.

All that was going on at the same time. Ah, cool. And, you know, there was a lot of collaboration going on. Now, around that time, in fact, very soon, in fact, 1970, 71, a guy came over from France. His name was Louis Poussin. He had been on Project Mac, which had built Maltics, which is the precursor to Unix. And while he was there as a postdoc, he invented something you might have heard of called a shell. He had worked on that. And so he came back to look at the ARPA net.

He was very intrigued. And he decided to go back to Paris, into area, and build a network to do research on networks, which is not what, you know, ARPA wasn't interested in that. So they went back and started to work on it. And, of course, what they did, as anybody should, they essentially started out clean. You know, they'd talked with BBN and they talked about how the IMPs worked and all the considerations they went in. And, in fact, one of the guys who was in charge of the I imp group, building the switches, spent some time with them at ARIA working on that. But they started off clean. They said, what are the minimal set of assumptions we have to make to have a network that works?

The idea was come up with a minimal set of assumptions and then see what else was needed. Okay? Yeah, that makes see what else was needed. Okay? Yeah, that makes sense. Right, absolutely. And so what they came up with was the first thing they came up with was the datagram. You know, everybody else immediately sort of fell into, well, you know, it's like the phone system, and we've got to have these circuits,

and packets have to follow, and things have to follow these paths. And now the ARPANET was the first packet switching network. In 1960, Paul Buran had written a series of reports on packet switching. And the ARPANET was the first one to actually realize it. Now, what is packet switching? Well, before this, we had voice networks. And in 1960, Buran did this study on data networks. And the military had built something called the message switching network, where the whole message, usually it was more like a file,

was moved intact from computer to computer. Buran had the idea of, no, let's break things up into small pieces and send those around the network. And his point was that voice traffic was continuous and voice connections took a long time. They were long. Data was usually bursting. You'd send some stuff and you wait a minute and you send some stuff and you know back and forth and the connections were short short lived and so it'd be good to have a network that was just built for data and it switched small

packets so when you say switched what does that how are you using that verb? Because that's what I'm a little confused on. Well, okay. You could have every host connected to every other host, but that would take a lot of wires. Right, right. Like N squared or something, right? Like N squared, right. Exactly. So let's dedicate some machines to just doing relay.

We don't need as many wires. Not everybody is using every machine the same amount. And not only that, but we can pick up resiliency. We have more than one path to the same place. Right. them one path to the same place, right? But the general idea even then was, well, but if I open up a connection, then all the packets just follow that connection. Puzan's group, which called their network Ciclod, said, no, no, no, let's not assume that, at least not to start with. Let's assume that every packet is switched independently and that they could be any way they want. Now, I've always said that packet switching alone was not a radical idea. And actually,

it depends on, to some it was, but it depends on how old you were. If your formative years had been with telephony, then the idea of breaking packets, breaking data up into small packets and sending them through the network was a radical idea. If your formative years were just a little bit later with computers, what's the big deal? Right. You want to talk to each other. I got this stuff in a buffer, you know? Okay. I pick up the buffer and send it. So what? Right. It's the obvious thing to do. Yeah. That makes sense. So it's like a union of two disciplines, like two different disciplines are coming together.

Exactly. And so, but Pazan comes along and says, well, wait a minute. Why does every packet have to follow the same path? Let's make it stochastic. You know, let's make it better. We can better utilize the resources if we spread things out, do it stochastically. And then they step back and they said, well, wait a minute. No matter how good we do the network, the hosts are not going to trust us.

They're going to check and make sure they get everything they sent. Therefore, the network doesn't have to be perfect. Right. It just has to make a best effort. If we have a reliable protocol end-to-end between the hosts, the network doesn't have to do nothing, but it doesn't have to be perfect. That's right. I don't know if it's possible to do this nowadays in Zoom or these other video conferencing,

but when we used to play video games, there used to be a way, it probably still is, where you could hit a key and see the packet loss. And so while you're playing, if you have a good connection, you might oscillate between 0% and 1%. There were definitely times where I'm sure it was problems in our own house where we were approaching like 10% packet loss. And the game still worked. So yeah. sure it was problems in our own house where we were approaching like 10 packet loss and uh you know the game still worked so so uh so yeah and in fact you could actually be better at the game

because you would kind of teleport around well you know that that's another thing where um well yeah so and in fact it was the it was the ciclod guysiclod is named after a group of Greek islands that in ancient times had decentralized organization and would come together for common defense and things like that. Oh, interesting. Ciclod was focusing on the decentralization and the switches in Ciclod were called Cigal, which is grasshopper in France, in French.

Ah, okay. Okay. And so they're the ones who came up with the basic layer structure that you heard, you've always heard, you know, physical data link network transport. And the idea was in those days, because, you know, leased lines were pretty flaky, especially in France.

So they were running a fairly reliable protocol at the bottom between, between the switches. Okay. That meant that the only thing that reason for loss in the network layer where they were relaying was due to either congestion or bit errors during relay. You know, they can protect the packets from on the wire. But once they were in the machine, it didn't happen very often, but you know, you could pick up a memory error. Right. So that's what they were looking for. So they, but you know, but it's the old 80 20 rule, right? It's easy to get more,

maybe 90 90 10 rule or whatever you want to call it. You know, it's easy to get those first 90% of the errors, but those last 10 are hard. We'll let the host deal with that. They're pretty rare anyway, so we'll just deal with those higher up. That makes sense. Actually, a bit of a segue here, but I was really curious. I want to make sure I didn't lose track of it. The machines, even today, when I send a packet to Netflix or something, it hops among all these machines.

We'll definitely dive into that. But one thing I want to know off the bat is, like, who actually programs those machines? Like, who's responsible for them today? The guy you buy your routers from. So, like, so, well, my router came from, oh, buy the router. So we have, like, a Netgear. So Netgear is actually working on the internet backbone or how does that work? Well, they work on those routers.

I mean, you know, the size of routers that are used in the actual backbone or in the periphery are all different sized, you know, Cisco, Juniper, you know, whatever routers. But like who defines the policy, I guess, is what I'm asking.

Who actually decides this packet should go here, this packet's a higher priority? There are standards for that. Okay, got it. And that we deal with at various levels for various kinds of routing. Okay, interesting. We'll get back to that. But they came up

with this whole idea of a best effort network of these basic layers that the bottom layer did some error control. In their case, it happened to be reliable, but in later cases, we were able to relax that because the media got better. And then end to end for the best, you know, transport to correct the errors that were lost by the network. What was interesting and was, okay, I should first admit something. I'm currently working with Puzan. He had his 91st birthday a few weeks ago. Oh, wow. Congrats to them. And well, actually, I had also, Louis was the guy, the big wig, the guy who was in charge of everything.

So he's only, he and I have only gotten to know each other pretty well lately, but back then all of his guys were my age. So they were all, I became really good friends with all of them. They, these guys had come up with this new way of looking at things just based on what they had seen. Right. What were the minimal assumptions that got us to do this? And then they stepped back and said, okay, that's the minimal assumptions. What else do we need? And the answer was nothing nothing it was a mind blow

you know i mean this was far simpler than what everyone else was doing yeah that is like uh some of the most amazing uh experiences that i've had professionally have been where we've been able to build something just extremely elegant. I mean, the thing that's coming to my mind is when we worked on AutoGrad, like numeric differentiation. And so you used to have to, if you're doing some kind of machine learning thing, you used to have to define all of the partial derivatives yourself. And there's a lot of functions that have no closed form. And so you're just not didn't use those functions.

You know, and then and then we came up with, you know, numerical autograd, which was which was in some stable algorithms there. And so, yeah, and then the answer became, well, you can you can differentiate through just about anything. I mean, like you might empirically have issues, but from an academic standpoint, it kind of blew the whole field wide open. And so those are some of the most powerful moments when you realize, oh, I bought, I boiled it down to these three or four components and we're actually done here. Absolutely. It is such a high when, you know, it all comes together. And actually, I should back up a long way. When we were working on ILLIAC 4, ILLIAC 4 wasn't terribly interesting, but we had access to probably the finestroughs 5500. Probably no one in the audience has ever heard one, seen one. But it was the most elegant machine I have ever worked on. There were no special cases.

If you knew how A worked and B worked, you could guess what C would do and you'd be right. That's nice. This machine was built in 1964, even before my time. And it was the first machine to use a stack for procedure entry. The lowest level machine, the lowest level language on the machine was ALGOL. There was no assembler. There were no general purpose registers. Every register had a purpose and it was used for that and that alone.

The operating system was written in an extension of ALGOL called SPAL. I mean, it was a paging descriptor machine tagged architecture. As near as I can tell, this machine in 1964 was secure. If you indexed off the end of an array, it was a fault. The stack was tagged non-executable. You couldn't overwrite it. Oh, that's nice. Okay. Arrays were descriptor-based, so you had tight control over it. The machine was incredible. One of the little ones that I always tell people about, because it shows the power of architecture. You know what a floating point number looks like, right? You have sine, exponent,

mantissa. And we always put the decimal point between the exponent and the mantissa. They put it at the right end of the word. They put the decimal point at the right end of the word? Yep. But there is no... So, okay, Patrick will probably help me out here a lot. But as far as I understand with floating point, right, you have a bit for the sign, right? You have the exponent, which is a tiny integer, right?

And then you have the mantissa. So there's not actually a decimal. I don't quite understand. You have a binary point that goes between the exponent and mantissa, right? So the whole thing is a fraction. An implicit one, yeah. Yeah. Well, there's a binary point that goes between the exponent and the mantis, right? So the whole thing is a fraction. An implicit one, yeah. Yeah. Right, right.

They put it at the right end. The reason was that on that machine, integers were unnormalized floating point numbers. They took the two separate. There was no integer to real conversion on the machine they made it they made it into one case that handled both now they had help they had a 48 oh i see okay but by just moving the point where the fraction was they changed the whole thing. So you're saying they put the exponent on the far right? Yep. And so then...

No, it was still the same thing. Sine, exponent, mantissa. Right. Instead of having it normalized so the first bit of the mantissa was a one and a fraction, the binary point was at the right end of the mantissa was a one and a fraction. The point, the binary point was at the right end of the word and the exponent was scaled appropriately. Oh, OK. I think I get it. So you're saying the. So the. Yes. An integer is an unnormalized leading leading zeros in the mantissa.

Yeah, that makes sense. But it was a nice, elegant solution. You don't have to worry about what's an integer and what's a real. Yeah, that makes sense. If you multiply and it gets too big, it floats. If you divide and there's a fraction left over, it floats. Ah, I see. But the whole machine was like that. Everything just

worked. Okay? There were no special cases. The only difference between spawning a process and a procedure call was what it returned to. Procedure call returned within the same stack.

A process returned to a different stack. Oh, that makes sense. Yep, yep. I remember when I saw, somewhat similar, when I saw a gRPC, and Patrick can kind of like echo this, but when I saw gRPC, which is this thing where you kind of define

a client and a server in this third uh this this idl and then it generates code in like a zillion different languages and then you can say okay call this function in i don't know python and then and then you do have to put the location of the machine and then in c plus plus you just say look i'm waiting you know i'm waiting for this function to get called and here is the answer. And it all just kind of was like, now I'm calling functions and getting answers. That was just this really beautiful, kind of elegant thing. And so when you see something like that, it kind of warms your heart.

So anyway, so we were going along with all this stuff and, you know, Ciclod was adopted. But the ARPANET had made a couple of mistakes. Not big ones, but little ones. Well, actually, they were sort of little. Very early on, we realized that what we were, you know, operating systems were our guide. You know, we essentially, you know, operating systems were our guide. You know, we essentially, you know, we're emulating an operating system on the net, on the ARPANET.

And to give you an example, I mean, you will read in textbooks that Telnet is a remote login protocol. And you may have thought about it that way. Yeah, I mean, it takes an IP address and then gives you a shell on that computer. No, it's not. Telnet is a terminal driver protocol. It is the terminal driver for a network virtual terminal. Okay. So there's no difference between a terminal directly connected to the machine and one coming in over the net. Yeah, I see what you're saying. Yeah. Right. Okay. Most people will tell you, in fact, I've seen it in textbooks. Oh, it's a remote login protocol. No, not.

Okay. And so our whole thing was, let's have the services we have on an operating system on the net. So we had Telnet and FTP in that. Now, we also understood that addressing sort of had to follow what operating systems did. And we'd have to have application names and network addresses and all that stuff. In fact, John Shock at Xerox PARC had a very elegant way of putting it that application names tell you what you want to talk to. Network addresses tell you where they are. And routes are how to get there. Okay.

So the plan at the beginning was you would go to like, just use an example, you know, google.com colon Google, and that would access the Google application. I mean, maybe not colon, but that would, let's back up. We're not that far along yet. Okay. One mistake we made and we discovered it pretty early was that when I said my address was 12, in the early days, the ARPANET switches, the amps, could only handle one host. And your host number was your amp port number. And that was common back then.

Terminal numbers were often the same as the ports off the switches or concentrators they were connected to. Your telephone number, the last four digits of your telephone number were the name of the wire coming from the central office. This was common. Winter of 1972, my boss came in to work one day and said, hey, take your Air Force bases, join the net, and they're taking us at our word and they want two connections to the network. And I said, oh yeah, great shit. That's not going to work. You know, and it was pretty obvious why, because if, if you connected it to two different imps, it had two host addresses and to the network that looked like two hosts. The network didn't know those hosts went to the same place. Right.

Well, a second after I said, oh, crap, it's not going to work. I said, oh, I'm an OS guy. I've seen this problem before. I know how to fix this. We have to route to the node, not the address. Right, right. Right. We have to route all the way to the node, not the address. Right, right. Right? We have to go out all the way to the end.

The internet never fixed it. An IP address still names the interface. I'm going to jump in here and interrupt our interview today to talk about our sponsor, Zencastr. Zencastr is an all-in-one podcast production suite that gives you studio-quality audio and video without needing all that technical know-how. It records each guest locally and uploads the crystal-clear audio and video right into the suite, so you have high-quality raw materials to work with. Jason and I have been using Zencastr for programming Throwdown

for a while now, and it's a huge upgrade over the way we used to do things. It's so much easier and more seamless to have everybody join a Zencastr room and get individual audio streams for each participant, which allows editing and mastering to go much more quickly. It just also feels like a better experience for all involved. I'm so happy that we have this new solution instead of the way we used to do things back when we first started. If you would like to try Zencastr to make your own podcast, you can get a free trial by going to zen.ai slash programming throwdown. That's zen.ai slash programmingthrowdown. Back to the podcast. Wait, let me think about this.

Hang on. So an IP address. So I thought that you need the IP address and the port. Oh, no, no, no. Let's not get ahead of ourselves. Oh, no, you're right. So the interface, like the NIC, can serve multiple ports. So you're saying the IP address points to the NIC card.

And so, yeah, so if you have like a wired connection and Wi-Fi. You have multiple NICs, you have multiple IP addresses. Right, right. That makes sense. Yep. So if you have multiple IP addresses, what's the problem with that? Like, what's the problem with you thinking that that client has two hosts and just, you know, depending on which one reaches you, you just reach back? If I have sent a packet to address A and it goes down, the network doesn't know how to route it to B at the same time. Oh, got it.

Got it, got it, got it. Okay, yeah, totally makes sense, yeah. Now, the next thing we did was, well, we all knew we had to have application names and all that. But, you know, after they got the network installed, man, it was like, hey, we got to have a demo. We got to show people this thing's useful. Right?

I mean, you go, you know, we spent a lot of money doing this. So we said, okay, we don't have time to do a directory. Okay. All right. We've all got the same applications. As a stopgap, we'll put Telnet on socket one, FTP on socket three, and RJE on socket five. We have well-known ports. Two or three years later, we rewrote the Telnet spec and put it on socket 23 for testing.

It's still there. Yeah. Yeah, for people who don't know, when you Telnet to a host, you don't have to specify the port. I mean, it's true for almost anything, right? If you go to a website, you don't have to specify the port i mean it's true for almost anything right if you go to a website you don't have to specify the port you know there's defaults no you do have to specify the port uh well if you go like let's say just in your browser and you type google.com you don't talk you don't do it but the browser does yeah but the the browser has a default like by default it'll connect to what is it 80 i think, I think, right? Yeah, port 80, right. And so you can go on Wikipedia and see a list

of the most common port number for each application. And Telnet is 23 because they put it on for testing and it's still there. So if you may open whenever you open a Telnet connection in the TTY window of your laptop, it's connecting to Socket 23. Right. Yep. In fact, then later, and this is really terrible.

In 1975, when we put the first Unix system on the net, we hacked file IO to do it. So what you would type is open UCSD slash Teldat. And we give you a Telnet connection. Yep. Yep. That's right. There are no domain names in 75. However, a few years later, when they were getting Unix ready in the BSD version of Unix, even though they had a meeting and they

tried to convince him, Bill Joy insisted on doing sockets, which is a terrible API, about the worst you can expect, because now every application had to be modified to use the net. Right. And it exposes the internal workings of the layer. Treating them as files was a whole lot better. In fact, I've heard that Microsoft's adoption of IPv6 was delayed two years while they had to change all of the programs that access the net because Socket's now dealt with larger addresses. Yeah, I believe it. Yeah, I think it kind of went the other direction where now you can actually use the Socket

API to write and read to files. So the Socket API ended up kind of being like something that now you can use for everything. But it's not as clean as a file API. No, no, not as clean as all. So, I mean, we had it right to begin with. In fact, if we had done, and also well-known ports, you guys are too young to have ever seen this, but well-known ports are equivalent to what early operating systems did when they had jump points in low memory for the applications. Okay.

Early operating systems didn't run that many applications. And so they had actually allocated low memory locations in the machine, physical memory locations, for the addresses of the applications. And when you typed a command, it did an indirect jump through that location. Okay. Now, what is a low? I've seen this from back when I had a 486. There's low memory and high memory. But I have to admit, I don't know what it means.

So what actually is low memory? Actually, the ones with the lower numbers. Right. But semantically, yeah. Well, and the OS is down numbers. Right, but semantically, yeah. Well, and the OS is down there. Ah, okay. It's similar to how some of the ports are used by the kernel, like up to, what is it, 1024 or something, right?

Right, exactly. It's the same thing. Got it, okay. So if we had done the file API, we could have transitioned application names, got rid of well-known ports, and no one would have noticed. Right, right. That makes sense.

Okay. I mean, so it'd be similar to paths. You know, like you go to google.com slash careers or something. It's almost like that's an application. I think it's a web app i guess well except that google.com a lot of there's a lot of crazy stuff going on underneath right right that illusion whereas if we had done application names you wouldn't have any of that crazy stuff yeah that makes sense also all you can do on the internet

today is a rudimentary client server. Okay? You cannot connect to a specific instance of a program. When you connect to google.com, you get a new copy. Yep. Yep. Right? Or telnet.com.

Or telnet. When you connect to telnet or anything else. You get a new copy. Okay. You can't then connect to that specific instance. Right. Yep. Nor is there a way to connect to a specific instance with two different protocols. Yep. That makes sense. So we don't have in the internet today, we don't have application names.

We don't have node addresses. The IP address is technically naming the same thing the MAC address is. And this is the root of most problems. There's no solution to the multi-homing problem, which is the Tinker Air Force Base thing I talked about. Mobility, actually, if you have a full addressing architecture, you don't need any new protocols for due mobility. That makes sense. Yeah. One of the things I read up on a while back was, I think it's called SMTP, but it's basically like a Dirichlet distribution kind of applied over a set of endpoints to try and deal with homing. So it's sort of like,

you know, you use a stun server or something and say, okay, this is my public address. Here's my internal address. I don't know which one you should reach me on. And then SMTP will just like try all of them and get confident about one. Yeah, SMTP is a variation on, well, it's the mail protocol. Oh, no, sorry. I'm thinking of something else. Maybe I'm thinking of there is one for VoIP. Oh, that's what it is. SCTP. Yes. SCTP. Yeah, they fixed multi-homing by changing the definition. Yeah. Well, CTP. Yeah, they fix multi-homing by changing the definition. Yeah. Well, I think they just stochastically fire at all of them, right?

It's great for sending. It's not so much for receiving. Well, they have to do the same thing to you, right? So they have to be running a CTP and hitting you on all these different addresses. If you fix it right, then it just works. Yeah. Let me add a little bit of context here because this is actually something I know a decent amount about.

So right now, you might go and contact google.com and that might go through so many different machines. And it might get to the point where if you were to go to google.com again, you would end up at a different machine. And that creates problems because you need some kind of state usually. so what happens is all these machines they all tell google hey if you want to talk to this person who just reached you so you can return them you

know the logo or something you know here's a path that will get you back to where you started and and if you follow this path you're good. But if you don't have those link backs and you just try and talk to this person, you're not going to get them. And so, yeah. Now you know why there are cookies. Yeah, cookies are, yeah, cookies is basically like a little key value store

that you send to the server every time, yeah. Right, right, right. Yeah, but if I remember correctly, there's like a routing table. And so all the machines know where a packet came from. And in that one specific instance, you're allowed to go all the way back to that machine without knowing where it came from.

There's a lot of machination going on that doesn't need to be there. Yeah, right, right. Okay. And to some extent, I mean, well, to get back to what we were sort of talking about, how should I go about this?

Of the four protocols we could have picked, or the four or five at the time, TCP was the worst. So why was that? If you analyze those protocols carefully, the two big things in TCP that are different is that there's only one header format. There's only one packet type.

Everything is the same way. That makes for a very large header. Okay. Second of all, the sequence numbers number the bytes, not the packets. Really? Yes. Wait, what's the distinction there? So like, if you know the size of a packet, then you kind of know what sequence numbers actually. When TCP was proposed, there was no IP. Okay. And they knew they would have to fragment at gateways between networks. Right.

There's two ways of doing fragmentation. I can either have a sequence number and an offset that says, here's the sequence number of this packet and all of its fragments. There's the zeroth one. And then whatever the length is of the first fragment, that's the offset for the next one, and so on. Or I can do it in bytes, and then the byte number becomes the sequence number. Right. Yeah. Okay. This has a couple of problems. Okay. First of all, your sequence number space is going to turn over a lot faster. Okay. In fact, even when TCP was proposed around 74, 75, people were going, hey, man, on a satellite channel, you could roll over the sequence number space.

You don't want to have two packets with the same sequence number in the net at the same time. You know, that's just a bummer for everybody. The other problem is that TCP does not require you to retransmit on the same byte boundaries. Oh, no. Okay, that is a problem. So now you're getting that's like well now you're getting like uh fragments that are missing and then you have to go back and say okay i got enough packets for this tiny sliver retransmission that overlaps yeah if someone sends you three packets um you could end up with uh what

two you know five retransmissions or something like that. Well, or you can end up with retransmissions that overlap. Yep, yep. And now you've got to pick out what you don't have and what you do have. Now, there's one way around this, which is, oh, I do a circle queue, and I have a contiguous block of memory for this connection, so that all I have to do is overwrite it. Right, right. Okay?

That's simple. If I've got it in a linked list, this is a bear. Yep, yep. Okay? There's just one problem with doing the circle queue. We've known since 1968 that statically allocating buffers to connections is grossly inefficient, like three or four orders of magnitude. Yep, that makes sense. Because, yeah, you have this block, and the block by itself doesn't really tell

you anything, and so you have to be scanning through it. Well, no, no makes sense. Because, yeah, you have this block and the block by itself doesn't really tell you anything. And actually, what's funny is it took until 2004 for them to discover the same thing about routers. But in 1968, Peter Denning did it for terminals okay and he started with 50 users and 750 bytes of buffer space and he did a queuing model and he showed that with pool the probability of running out of buffers was 0.006 but if you static, it was 0.9. Oh, wow. If you went to 1,000 bytes, the pooled case dropped to 10 to the minus 6, and the static case dropped to three quarters. Okay. Okay? You have to go to 4,500 bytes to get the same performance you had at 750. Right, right.

That makes sense. Yeah. Okay. So while a continuous memory, you know, continuous block of data per TCP connection would work and be simple, it's not what you want to do. Especially as the bandwidth delay product gets larger and larger. So then you're stuck, you know, kind of iterating through all these linked lists to find out what you're missing. Right. And then they separate IP from TCP. Yeah. So what does that mean? I've heard that, but I don't quite have a mental model of what that means.

Like, what is the distinction? There were two different protocols. There was one protocol, and they made it into two. And so what does IP do, and what does TCP do? Well, IP, okay, TCP has port numbers and no addresses, okay? IP has addresses, fragmentation, and a type of service field. And a couple other things, but they don't matter anymore. Wait, so IP doesn't have port number? No.

I see. But I see the TCP has a port number and then like an endpoint or something that gets from IP? No, no, no. This is one of the confusions that these guys don't really understand addresses okay when they allocated the address box they divided it up into a network part and a host part okay now someone along the line excuse me somebody got the idea that this is addressed two different things it doesn't It addresses this one thing. In fact, I recently had a discussion

with one of the guys in the net who's been around as long as I have. And I finally told him, because there was always a debate about, well, what is the IP address name actually? Is it a process? Is it a library? A NIC card?

Whatever. And I said, I finally came to the conclusion what the IP address names is whatever strips off the IP header. Ah, yeah, that makes sense. Right? Now, if you look at the address, okay, now, this is another thing that just blew my mind oh wait hang on i just want to reiterate this because now i think it's starting to click so the idea is you know ip gets you from

computer from node to node and now you're at that node so at this point the address of the node doesn't matter anymore you're already there and so what really matters is what is the port you know so that i can talk no No, no, no. Actually, I have a presentation I do for my class where we start with IPC, inter-process communication, between two applications and two computers. Or actually, one computer. We start with one computer.

We understand how that works. Then we go to two applications and two computers. Then we go to more than two applications and two computers. Then we go to more than two applications and two computers. Okay. At that point, you have to be able to distinguish what packets belong to which connections. Okay. Now, in the early days, very early days, some people said, oh, well, the one side will start numbering from one end of the word and the other one will start numbering from the other end of the word. We hope they don't meet in the middle.

Right, right. Yeah, well, OK, but not great. And then somebody else said, hey, we have these port IDs that are essentially the file descriptor between the guy using this connection and the connection. Let's just concatenate them and use them as a connection ID. Okay, let me just explain something to the audience out there. So I think I get what you're saying. So when you actually make a connection to Google or anywhere,

I'm using Google as an example here, but you can replace Google with anything. When you go and make a connection to something, you actually assign a port. Your machine actually assigns a port for that connection. A lot of people don't know this. And so the way this works under the hood is your computer has reserved, I think it's 32, 768 up to 65, 536 like that or 535. That space of numbers is reserved for outgoing ports. So, for example, if you ran a server. They're reserved for incoming ones too if you want to use them.

They're just not open for well-known ports. Right. just not open for well-known ports right so like if you uh we actually i had this at work the other day where there was a service that wanted to run on my machine on port uh i think it was like 41,000 and most of the time it was fine and one time i restarted and said oh my the service can't run because that port is being used and i thought well that's really that's really strange we have two copies of this server running so i'm digging around i'm like okay finally i run lsof to can't run because that port is being used. And I thought, well, that's really strange. We have two copies of this server running. So I'm digging around. I'm like, okay, finally, I run LSOF to find out who's on this port. And it's just an outgoing connection, like some connection that's

going to AppleCare or something, just pick that port because it's anything above that 32K number is fair for anyone to use. And so, so yeah so for any connection between two computers the source which is going to have some really high port number is connecting to the destination which hopefully i mean didn't happen in this case but hopefully has a lower port number so that you don't end up with a conflict and so to your point if you stick the two if you if you concatenate the two port numbers now you have something that's unique for that. Like once again, once you've stopped thinking about IP.

It's unique within the context of the two IP addresses. Right, right. Okay. Yeah, that's good. Now you would think that if you were going to split this protocol off, that now if you had a choice between doing it in a way that everything works or doing it in a way that's broken, which one would you choose? The working way, I think, sounds pretty great.

Well, actually, they didn't. They chose the way that broke. So what did they choose? Because you lost me there. Well, IP fragmentation doesn't work. And it never has. What is IP fragmentation? Well, remember we said that when you go between networks, you may have a different MTU number and maximum transmission unit.

And, you know, you have to fragment the packets. Right, right. Right. Well, IP fragmentation has never worked. Oh, I see. Okay, so you're saying, you know, okay, so just to recap, so you send a packet out, and every packet has a

size. Yep, and so then it gets to a machine, and that machine has an MTU, which I think is maximum. It's another network that has a maximum transmission unit of, say, 200 bytes. Right. And so it has to get broken up.

Right. And so you're saying breaking it up at the IP level doesn't work. So I think, well, how does it even happen in practice because you don't have the sequence number at the IP level? Well, actually, what you have, that's one thing I left out. One of the things you have in the IP header is a packet number, 16 bits. Oh, okay. And an offset. Okay.

So now you have two sequence numbers in TCP. Yeah, there's the rub. Yeah, right. Right? Because IP doesn't do retransmission. Right. So if you miss half of an IP packet, you either have to say this whole TCP packet is hosed or you have to try and do something really clever. Well, no.

I mean, that's what happens is, you know, you send it. One of the fragments gets lost. You store it. And now you have to wait five seconds to age it in case the packet's late. TCP is going to retransmit before that. Yep. Yep. Which is going to give it a new sequence number, which gives a new packet number,

which goes through the network and maybe loses one. Right. Right. And this just gets out of control. Two copies of the same packet partially assembled, but the destination doesn't know that. Yep. Okay? So it doesn't work. Now we have a solution

called PathMTU Discovery. You send a ping with a certain size of data, and you set the don't fragment bit and if it comes back and says, sorry, I couldn't deliver, it's too big, then you do it again with a smaller one

until you find one that works. Yeah, I mean, similar to our SCTP story where to your earlier point, you don't have an elegant system anymore. And so now you go down this rabbit hole of empirics where you just try and blast things. And basically, you're building like a particle filter of appropriate MTU size. To jump ahead a little bit, one of the exercises I did, Bill Wolf in the 70s wrote a paper on operating systems in which he talked about the separation of mechanism and policy. And the point was that the mechanism was often the same.

The only thing that changed was policy. So, for example, the machinery for taking one process off the machine, putting in a queue and starting another one was the same. The question was, which one do you run next? That was the policy. Is it round robin? Is it first come, first serve? What is it? Right.

Same thing with memory management. OK. Well, I always thought it was really odd that this is taught in every operating system textbook I've ever read, but never mentioned in networks where, you know, the machinery for doing acknowledgements is always the same. The question is, when do you do it? The thing about extending credit for flow control is always the same. The question is how much? Right? So it seemed to be really applicable. So, you know, and I got this, I had this real insight one day. We always thought we'd do another version of transport for voice because you care about order, but you don't care about gaps, which we were saying about your gaming thing.

Right? If it's a small gap, who cares? Nobody's going to notice it. Yep. And then I realized that we didn't need a new version of transport. We just changed the act policy. You lie. You say you got it.

There's nothing in these protocols that says you have to tell the truth. So, well, I thought, so now this is where you'll have to educate me on this, because now there's not only TCP, there's UDP. And so with UDP, yeah, you don't have to acknowledge, right? Let me think. So actually, that also told me something else, that we'd had the semantics of acknowledgement wrong all these years. Acknowledgement doesn't mean I got it. Acknowledgement means I'm not going to ask you to retransmit it. It's subtle, but it's major. Oh, and this gets back to your

sequence number thing, right? Because if you get sequence number one and three, then you could go back and say, hey, I got two, even though you didn't get it. I can say I got three. I got three. That acknowledges everything before that. Well, well, okay. So if you want to be reliable, you would say, I got one, I got three, I didn't get two, please resend it. If you don't want to be reliable, you say, I got one, I got three, I'm missing two. If it's all based on bytes, you know, you get one and then you get 350. And then it really becomes weird. Like how many packets did I actually miss? You don't know. But, you know, but it works a little differently, but you got the basic idea, right? So I went through and did separation of mechanism of policy for all of the mechanisms and protocols

like TCP. And when I put it together, it was really interesting because the mechanisms cleaved naturally into two different groups. Those that had to be with the data, sequence numbers, where else could they be? Right. And those that could be but didn't have to be, Acknowledgements and flow control. Now, notice that the first set in policy is imposed by the sender. And the second set are feedback mechanisms where policy is imposed by the receiver. And the two pieces barely talk to each other. The part that has to be with the data records what sequence number comes in, and the feedback stuff reads that and decides what to do in terms of acknowledgements and flow control. And the only time it interacts with the other part is to say, hey, wait a minute,

the flow control window's closed, you can't send anything. That's it. There's no interaction. If you cleave the protocol that way, then the whole problem of IP fragmentation not working goes away. In other words, if you join UDP and IP together, and if you want reliability, you throw in the feedback mechanisms, there's no problem. Yeah, so there are like reliable UDP protocols in user space. There's not a kernel protocol. No, that's an illusion.

So reliable UDP, I think the way it works. You mean there are protocols built on top of UDP that are reliable? Exactly, yeah. Yeah, okay, all right. That I'll buy. Yeah. Right. And so, and so, uh, actually this is like, uh, and I want us to spend a little bit of time. That's like saying I could build a reliable protocol on top of IP. Right. Right.

So like, what is the, you know, um, what is the advantage of, um, doing things at the kernel level, like making a new protocol versus building a reliable UDP? One of the things that was developed in the 80s that the Internet dearly loves to hate was an encoding scheme called ASN1. And they thought it was just an encoding scheme. But actually, it was different. It was what ASN1, ASN stands for abstract syntax notation. It was an abstract syntax notation and encoding rules. Think of the abstract, I mean, it's a mouthful, but think of the abstract syntax as what you would write in a program. Coding rules is what the code generators would do. Okay. So I could have, you know, so for

example, there's one set of encoding rules that's very verbose and you can have the fields in any order and all sorts of stuff, but it's fairly, you know, bandwidth inefficient. There are other encoding rules that are very bandwidth efficient to the point that if you compress it, it gets, you know, it gets bigger instead of smaller. What it's really telling you is that I can make protocols invariant with respect to syntax. Okay. So for example, in a transport protocol, I've got these silly fields and they're either used for two, one of two reasons, hashing into a table to look up an address or a port number, or doing a simple arithmetic modulus, the width of the field, on sequence numbers. The procedure is the same, right?

So what you really come down to is there's really only one data transfer protocol. And also, I'll throw in a ringer, which I've gotten a lot of controversy and pushback from our guys on. I think UDP should be thrown out. There should be no flows in a network that are not flow control. Oh, interesting. It's a denial of service vector. If I've got flow control, I can shut it down. Yeah, there's the, like your router will do quality of service and these kind of things, but it's not quite flow control. It's like a, you know, trying to solve the same problem. Well, it tries, but it's got the transport layer working against it, which is another problem.

I mean, you know, because TCP congestion control is about the worst you could ever last for. Okay. First of all, it works by causing congestion. Right. Yeah. You know. Yeah, it works by saying no. And as soon as you say no, everyone wants to give it back to you.

One of the really worst things is because it detects congestion by lost packets. It's predatory. Yeah. You can't do anything in the layer below and drop a packet because TCP will react and you'll have feedback loops working against each other. Okay.

In 1988, there was work done by Roz Jane, then at DEC, who showed that, one, you should use ECON, explicit congestion notification. And two, notification should begin when the average queue length is greater than or equal to one. Very early, which gives you time to react so that there's no loss. Yep, that makes sense. Okay. And, you know, the thing is about what we've got in TCP now, and it really irks me that every time there's a proposal for something new,

BBR, it's like, oh, everyone's just in love with BBR. It's still implicit notification. As far as I'm concerned, you haven't moved off the dime. It's not an improvement at all. Yeah. I've often said that TCP is the greatest thesis generator ever developed. Okay. Because there's no solution. I mean, also the effectiveness of any congestion scheme decreases with increasing time to notify. By putting it in TCP, you've maximized time to notify. The reason it's a great thesis generator is there is no solution to congestion in the transport layer. Before the 80s, everyone was looking at putting in the network layer. Okay?

Now, you can do things. You can try various tweaks and different ways of handling, you know, you can do RED and, you know, all these things and you can get enough data to, to do a thesis. The trouble with most, all of these proposals for improving is that they're great. If you're the only one doing them, when everybody else starts doing it, it's really not much better than what you had. Yeah, that makes sense. It's like all of these best response stock kind of things. It's like, okay, I have this new algorithm to trade stocks, but it only works because not everyone is using it.

Not everybody's doing it. You get enough data to get a PhD thesis, and there's always another tweak somebody else can do. Yep. Right. I actually, I was doing a roundtable one time years ago and I made that comment and some guy in the audience went, hey, that's how I got mine. That's awesome. So we're going to put a bookmark in it what i think we should definitely do um you know we're going to make this a two-parter for folks out there so this isn't the the end of the

story by any means um but you know what we should do um in the next episode is we should talk about you know i'm really curious like what you know uh steps can we take? I mean, both on in terms of, you know, the academic steps and also like, how do we get people out of this sort of quagmire we've gotten ourselves into? We definitely should talk about that. And we can revisit or we can visit, you know, some of these things like DNS and how all these things came about. I'm really curious to know more about this. But so we're going to call it for this episode.

And then when you catch the next one in a couple of weeks, we're going to dive into all of those topics. But in the meantime, John, I wanted to thank you so much for coming into this first part here and explaining so much of the technical depth to us. This has been really fascinating. I've learned a ton. Patrick and I have learned a ton from this first part already. And thank you so much for sharing

this with us. Okay. All right. Well, it was great fun. Cool. And yeah, we're really looking forward to chatting again. And for everyone out there, thanks so much for subscribing to us on Patreon. There is a super fast RSS link. If you're a subscriber, appreciate everyone doing that. And thanks for supporting us on Audible and all the various podcasting platforms. And we will see everyone in a couple of weeks. music by eric barn dollar programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're're free to share, copy, distribute, transmit the work, to remix, adapt the work,

but you must provide attribution to Patrick and I and sharealike in kind.