Programming Throwdown - 138: Fixing the Internet with John Day

Episode Date: July 12, 2022

00:00:24 Introductions00:00:49 IP v600:04:50 OSI00:12:53 The IP v7 debate00:20:18 The definition of an address’s scope00:21:38 Why John feels DNS was a mistake00:26:40 How IP mobility works00:32:13 Bluetooth 00:41:41 Where will Internet architecture go from here00:49:49 Understanding the problem space00:59:04 The angels in the details01:00:53 Scientific thinking vs engineering thinking01:04:01 Victorian architecture01:06:11 John’s career advice01:11:18 Garbage Can Model01:14:38 How to make the most out of college today01:27:05 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/Terminologies:CIDR: https://en.wikipedia.org/wiki/Classless_Inter-Domain_RoutingOSI: https://en.wikipedia.org/wiki/OSI_modelConnectionless Network Protocol: https://en.wikipedia.org/wiki/Connectionless-mode_Network_ServiceSIP (Session Initiation Protocol): https://en.wikipedia.org/wiki/Session_Initiation_ProtocolGarbage can model: https://en.wikipedia.org/wiki/Garbage_can_modelIf 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, we are here with part two of the Origins of the Internet with John Day. Take it away, Jason. Hey, everybody. We are here with part two of the origins of the internet with John Day. And thanks so much, John, for coming back. And I still have a ton of content to go through. So I really appreciate you taking time out of your day to do a second round here. Thanks so much. My pleasure. My pleasure. Cool. I felt like we should kick it off with the sort of elephant in the room, which is IPv6, right? I remember, you know,

I've done a lot of peer-to-peer networking things in the past. And, you know, I remember seeing IPv6, I don't even know how many years ago. I mean, definitely more than a decade ago. And saying, this is amazing, because, you know, all the NAT traversal and NAT punch through and all these tricks you have to do where two computers send packets to a third computer, and it sort of like connects them to

each other. Like all of these things that, you know, aren't guaranteed to work would fade away. And I'd be able to say, here's the IP address of your refrigerator. I'd just like go and send it a packet. None of that came true. And so I think it'd be good to start with just what the heck happened? Like what is IPv6? What was it supposed to do? What really happened there? First of all, whenever anyone's talking about, I want to have my refrigerator on the internet, my response has always been no bloody way in hell yeah right yeah you know i mean i want something between me and the rest of the world yeah exactly refrigerator in the rest of the world but anyway in the late 80s early 90s for some reason which i do not understand to this day, they were handing out, well, there were two problems going on.

One, we were being very free with handing out IP addresses. And so they were able to see that we were going to come to the end of 2 to the 32 at some point. That was the minor problem. The big problem was that they had been handing out addresses in order, blocks of addresses in order, which would never have occurred to me. I mean, I'm a flatlander. I know about addresses. You know, I mean, you know, they tell you how to get there. Well, they don't tell you. They tell you where something is and you can figure out from that how to get there. You know, so in prior to 1990 or so, if you got a block of addresses, if say you're in Paris and you ask for a block of IP addresses, you've got block X.

If the next person to ask was from Sri Lanka, they got X plus one. Wait, wait, wait, really? Yes. Wait, I thought that isn't there. I thought I've seen a map, right, which has IP addresses and like some, isn't there like a regional thing there? You young guys just don't. No, no, no. So consequently, every time a block of addresses was assigned, it had to have an entry in the router table.

And the router table size was going through the roof exponentially. Ah, okay. Right? And so to me, prior to CIDR, Classless Inter-Domain Routing, IP addresses weren't really addresses. Oh, interesting. Okay. I mean, not in the sense of, you know, 1600, you know, Pennsylvania Avenue. Tells you where it is.

Yeah. Right? No, no, no. So that was scaring the heck out of them. And so the IAB convened a process to figure out what was going on. So real quick, what is the IAB? Oh, I'm sorry. The Internet Architecture Board.

Okay. Got it. It was called the ROAD process. And I forget what that acronym is. Routing, something or other. Anyway, of course, the OSI stuff is going on in parallel with this stuff. Now, we had a longstanding problem with IP addresses to begin with because they named the interface, just like the ARPANET IMPs did, right? And to solve the multi-homing problem, you need to name the route to the node. Right, right. Okay. So OSI, having been working on this earlier, had solved this problem. A network address in OSI named the node. And so what is OSI again? Open seven-layer model.

Open seven-layer model. No, no, no. Open systems interconnection. Oh, oh, got it. Okay, got it. Right, the seven-layer model. And so just for people, and I'm not going to get this right, but one of the layers is IP, one is TCP. What are the seven layers?

I used to know, but I totally forgot. Physical, data link, network, transport, session, presentation, application. Ah, okay. Got it. However, backing up a little bit, after 1983, we realized the upper three layers were a single layer. Yep, that makes sense. Okay. We also realized by the mid-'80s that the network layer was actually three pieces, three sublayers.

Okay. What it was was, in this sense, OSI didn't lose a layer. Okay. The bottom two roles of the network layer were the network. The upper part was the internet layer. Got it. Okay. Now, so anyway, the ITF has this problem with IP.

This is going to be a chance to fix the Mully-Homing problem. Also, we'll have to have bigger addresses. And we're going to have to start assigning addresses so that they aggregate, so that they're really addresses. Right. So if you see like the first few octets, you kind of know roughly where it's going to be in the world. Right, right. Relative to the big graph of the networks of the world, where it is. And of course, CIDR was the first step in that.

The second step was instead of going to IANA to get your addresses, if you were a small guy, they started giving huge blocks of addresses to tier one providers. OK, and then you went to your tier one provider to get an address. That way, you know, we knew by looking at the, at the beginning of the address that it belonged to Verizon. Okay. Got it. So, so Verizon would own, um, I think it's called class B or something like that where they own class a, a class A. They own class A. So they own like 13 dot anything else. Well, right. But now the other thing was that in the original IP addresses, as you said, there were class A, class B, class C addresses.

And this put a boundary between the network part and the host part. There were essentially 256 class A's. Then the class A's. Then the class B's were halfway. So there was 16 bits of network and 16 bits of O's. And then class C's were 24 bits and 8 bits of O's. CIDR, classless interlomain routing, allowed that to be, that boundary to be moved anywhere. So you'll hear people talk about it's a slash 16 or a slash 24, something like that.

Okay. That would define the mask that you would end with the address to get the part you were supposed to route on. Now, that was the first step. Clearly, clearly, we're going to have to have bigger addresses, so we have to have a new protocol. There was a lot of debate around it. There was this group that went to, you know, and the group decided to emphasize running out of addresses because they thought everyone could understand that. But rather than we're running out of router table size or router table size is becoming a problem. And I mean, at that point, it was like 200,000 routes in the core routers and climbing. It's now over half a million. some debate um osi had developed a protocol called clmp connectionalist network protocol

that was a variable length address that could be much larger i think it was like 40 octets or something and but was basically you know just like ip except that it named the node well can you dive into that a little bit so So if the node has multiple NICs and the IP address names the node, then I guess, let's just take a simple example. So a packet hits my home router. And I actually have this. I have a wireless and a wired connection into my desktop.

I have the wireless one turned off, probably because it doesn't play nicely for the reasons we talked about but let's say i had that on right so then the router would um because it names a node the router would have to basically decide on the fly which neck to send it well no wait okay think about this if the wire coming into the nick is point to point with another router. It doesn't need an IP address. There's no place else for it to go. It gets sent from the other router. There's only one place for it to come out.

Okay. Now, you have multiple wires running into your router. Okay, fine. But all I need for that is a local identifier to distinguish them. I don't need addresses. A local. So what's the difference? Well, I'm not taking up IP address local. So what's the difference? Well,

I'm not taking up IP address space. But then, okay, so let's say someone sends a packet to this address. Then at some point, someone has to decide which network card to send it to, right? Yeah. And he decides. No, he doesn't decide. Okay. No. He decides which outgoing interface of his he puts it on. Right, right, right. He doesn't decide anything about your network, your NIC card. Okay, yeah, that's fair. But implicitly, it's the same thing. Well, no, it's not.

Well, so my router could send a packet over the Ethernet. Now you need an address on it because there are multiple things that will see it. Oh, I see what you're saying. Okay. Yeah, I got it. This is where having a picture would help. Yeah, I know. It makes sense. That address is called the point of attachment address.

Okay. Got it. You can have multiple points of attachment addresses, but they all go to one node address. Right. Right. Okay. And where you're trying to get to is the node. Right. Right. One of the things, and I've got a slide like this. One of the things I think people make a big mistake, you know, all those little disk router diagrams everybody draws? Yeah. Okay. Well, everybody thinks that when the wire hits the little disk thing, that that's the end. It's not because those all have to go up to the node, which decides whether

or not this is for me or not. Right. Right. Okay. I mean, I was, you know, there's always been a debate, you know, and everyone was always, you know, sort of like, well, what does the IP address or any address really name? And as I was telling one of the old sages some time ago, my definition came down to it names whatever strips the address off. Yeah, right. Okay. So the problem here is that IP addresses name interfaces.

They're point of attachment addresses. Got it. Just like ARPANET addresses were. And so the IPv6 fixes, or not fixes, but it addresses the large number. We're not there yet. So coming out of the road process, they recommend the adoption of IPv7, which is CLMP. I never even heard of that. Is that a new thing?

When did that come out? The internet, the IETF goes berserk. And I mean berserk. Okay. Well, what's the timeframe on this? Like when did, when was this happening? 1990, 1991. Okay.

And so IPv6 had already been. No, no. IPv6 has not come up yet. Oh, so seven is before six. Yeah. Okay. Got it. Okay.

And because it was this came from OSI and seven layers. Ah, okay. Okay. They go berserk. Friend of mine was the chair of the IAB at the time. He was getting 70 nasty emails an hour. An hour. Okay. Oh my God. 24 hours a day, seven days a week. Wow. Okay. How he survived, I'll never know. Okay. There was this huge hue and cry. They're not going to do anything that comes from OSI. So some people in high places backed off from this proposal. There was an IPNG process, you know, IP next generation, a huge debate. And I mean, this was a nasty,

nasty debate. I've seen worse, but not many. And finally out of it comes IPv6. Now, one of the other big deals about in the debate was the debate. There were two things. One was a variable length address versus a fixed length address. Oh, interesting. And some people didn't understand about scatter gather hardware. So they were just adamant that you couldn't do it fast with a variable length address. Turns out you can. But, you know, they won out. So we have a fixed length address. It continues to name the interface. They were not going to do anything OSI had done. They're now cutting off their nose to spite their face. So we get IPv6. Two weeks after IPv6 was approved, someone points out that IPv6 doesn't do anything for the guy who has to adopt it.

What does that mean? Do you elaborate on that? Well, okay. So I go to my upper management and I say, I'd like to spend $3 million converting our company to IPv6. And upper management says, oh, well, great. I mean, I assume this makes our network more efficient. This has been a bottom line, all this. And the guy says, well, it makes us a better network citizen.

Yeah, right, right. It's a tragedy of the commons. Well, no, I mean, in fact, it doesn't fix anything. In fact, when the IPv6 committee first convened, the only thing problem they thought they had was a bigger address. They didn't understand the router table problem. It's okay. Now, if you had fixed the multi-homing problem, okay, with CLMP, you could then do mobility with nothing new. And what is CLMP one more time? IPv7. Oh, right. Okay.

Got it. Okay. So, you know, basically the reason IPv6 has been around for so long and nobody doing anything with it was why? There's no incentive for any one person to adopt it. No reason to do it. Okay. You know, what's the big deal?

And they haven't exactly made it easy. A friend of mine did a, I mean, you know, you used to hear all of the, you know, it's better security and better quality of service and better this and better that. Or as Mike O'Dell says, you know, it's a dessert topping and a four wax. You know? It's a dessert topping and a floor wax. I remember there probably still is an IPv6 day where everyone's encouraged to use IPv6. I only participated one year. I tried to use IPv6. I think you have to ask your ISP.

I don't even remember, but I remember just giving up pretty early. Well, as I said, they thought the only problem they had was bigger addresses. They didn't understand the router table size problem. There's a friend of mine who's done a YouTube thing called the myths of IPv6. All of the stuff about better security, better this, better that, were all spin. It was all the same as v4. In fact, one of the ground rules when they passed v6 was that anything they did had to be worked with v4

in case they had to back it out. There was that much confidence in v6. Right, right. Okay. And they made silly mistakes. i don't i still i haven't figured found out i haven't bothered to look to see how they fixed it but they got rid of the protocol id field in v6 by saying it's the last option now the protocol id field tells you what protocol is encapsulated in ip and there's a registry for it at IANA with numbers, you know,

it's TCP, this is SCP, you know, whatever. But then there were options in IP as well. And it has a registry too, you know, and they have numbers. So they had assigned two different registries to the same field in the protocol. I mean, not long ago, I was watching some stuff on the v6 list, and they were trying to define the scope of various IPv6 addresses, and they couldn't do it. Now, what does the scope of an address mean? Where you can interpret it, and it means something, and it doesn't mean something else. Ah, okay. Right? I mean mean you know um luckily mac addresses are global right but um in some cases you might have a protocol where the address is only known within the layer ah got it right i mean private addresses are essentially two holes in the public IP address space. Right, yep.

They have a different scope. They're only known within the private network. Actually, this is just segwaying a little bit here. Yeah, actually, getting back to the original thing we said about the refrigerator, if let's say we all adopted IPv6, now all of a sudden you don't have network address translation and so how do you protect your refrigerator then you know i've always wondered that don't ask me man i just walked into it

no i feel like you'll still end up with if not a complete translation layer you'll still end up with something that says oh you need you know you need permission to access the refrigerator like the refrigerator must have already talked to you or something see that there's several things that have gone wrong here i mean i think we mentioned last time that you know the sockets interface is probably the worst api you could have and if you if you work it out logically from the IPC model, just, you know, as I said, start with two applications in one computer. How does it work? And just keep, you know, two applications in two computers and so on. The address should never be exposed across the layer boundary.

In the world that I would have, an address – actually, what's really interesting is the entity within the layer, whatever you want to call it, process, library, thread, you know, I don't care. If that's the entity, actually, I consider it a process. And it has an application process name just like any other. I mean, you know, just because, I mean, it's nice to give it a different name because when you're talking about applications and the thing in the layer, having the same word doesn't help much, right? You like to put a signature. So, yeah, okay, fine. Big deal. But the thing is that it has an application name of its own. The address is a synonym whose scope is only known within the layer and may be structured to facilitate its use in the layer. In other words, know where it is. Okay. But the address should never be seen outside the layer.

So, yeah, can you dive into that and help me understand? So let's say I want to go to Google, right? So I open up my browser, I type google.com, and so DNS turns that into an IP address. Whoa, whoa, whoa, back up. DNS was a mistake. DNS was a massive step backwards. So how would it work?

Because I'm having a hard time hypothesizing. The API that we had, I think I mentioned this last time, the API we had when we put the first unix system on the net made it look like files. Oh, so I would go to slash Google and Google would own that path somehow. You would have a, actually, there's a lot of implicit stuff in when you're saying Google.

Actually, what you're saying is connect me to HTTP at Google.com, right? Okay. Actually, the application name for that might be http slash google slash com. Ah, I see. Yeah. Right? I mean, just like, you know, when we did the first one, we said, you know, the example I gave was, you know, you'd say, you know, open UCSD slash telnet, right?

Yeah, right. Okay. So the thing is, all DNS does, all DNS is DNS is a macro for an IP address. You know, the browser makes it implicit because it's a browser that you want to connect to port 80 rather than port 23. Right. Yep. Yep. Okay. So there's a lot going on there. And, you know, all this has just been heaped on, you know, as I said, you know, if we had done an API that looked like files. So, first of all, no applications would have had to be modified to use the net.

Oh, that's interesting. Let's think about this. So, so if an application wanted to... Oh, I see what you're saying. So if an application wanted to receive traffic from another application over IPC or from the net, it would be the same code. Yeah, that makes sense. Yep, yep. Yeah, of course.

What else would you do? Yeah, that's a good point. You know, it is kind of strange. Why would you do? Yeah, that's a good point. It is kind of strange. Oh, because we are doing sockets. Yeah, sockets do kind of work that way.

You can open a file or you can open a network socket. But yeah. No, if, you know, and so if we'd had that and had application names

of the form I was saying, then we could have gotten rid of well-known ports. We would have application names. Right, right. Right. And no one would have been the wiser. It would have just happened.

Yeah, that makes sense. You know, nobody would have, you know, wouldn't have have just happened. Yeah, that makes sense. Nobody would have... It's a really good point. Just to put an example on this, we set up a Minecraft server. I have young kids and they play Minecraft. We set up a Minecraft server

and my kid had to know Minecraft runs on port 27,000 something and then I had to go, OK, Minecraft runs on port, you know, 27000 something. And then I had to go into my router and I'm not a networking guy. I mean, I'm a total Luddite here. I had to go on my on my router and find the port and forward it. But but to your point, it'd be so much better if I could just say, you know, slash Minecraft, just forward slash Minecraft. Well, you know, and the other thing is, you know, when you connect to a well-known port, you get a new clean instance of that application.

How do I connect to a specific instance of an application? Yeah, there's no way. There's no way. How do I connect to a specific instance of an application with two different protocols? Yeah, no way to do that either. Right. But if you had application names and you had the full addressing architecture,

it's no problem. Well, how would you multiplex that? You know, like let's say, you know, for example, you go to slash Google, like Google is going to have thousands of instances of that application. Ah, but isn't Google then a distributed application

that is doing its own load sharing? Is Google its own? Yes. Right. Google has a load balancer and all of that. They're handling all of that. I connect to, you know,

maybe I have an Anycast, it's an Anycast. Maybe the Google application name is Anycast that connects me to the nearest one. And they say, ah, the least loaded guy who's going to provide you the best service is this one over here and we'll

hand it to him. Oh, that's true. Just because you're using paths, it doesn't mean you don't have redirects. You get redirected to the real application. But it all becomes their application's job to do right right that makes sense perfectly normal so but you know but because of ip you know well because they never developed the application layer the ip address ip was a disaster to start with um you probably don't know how ip mobility works but it's's a disaster. I've never heard that before. Yeah. You have to explain IP mobility. Is that cell phone internet at a high level?

Yeah. Well, there's all sorts of protocols for this. I mean, you know, proposals for this. And the way IP mobile. OK, remember, in the IP world, the only thing you have a hold of is the IP address. It's the only identifier you've got. Why in the Mac right mac address yeah but mac addresses are local i mean you can't reach a mac address like you can't say connect

me to this mac address at least not that i know of no and and there's a whole other set of problems there but anyway because that's the only thing you have a hold of now you have and and the address is telling you where it is now right because it's lighter now you want to move so how do i know where you are okay yeah interesting all right so my router tables tell me worldwide you know where these guys are so the way IP mobility works is if I go someplace, I connect to one of their routers and I say, hey, my home router is over there across the country. Create a tunnel from my home router to here for me, because this IP address is going to be on your interface X. Wait, so what is the use case here? I'm sorry, what?

What's the use case here? Mobility. It's like when you say mobility, I interpret that as cell phones. Is that correct? Am I getting that right? Well, we're talking about moving laptops around too. Okay, so if I, well, help me understand this because, you know, if I take my laptop and I go to a hotel or something, I'm going to get a new IP address, right?

Oh, you're talking about like if I have like multiple like Wi-Fi with the same SSID and I'm roaming? Let's say you were moving around. Let's say with your phone you're moving around, okay? If you want to keep the same TCP connection, you don't get a new address. Oh, I see what you're saying. So you're saying, let's say we're, let's say we're streaming audio and we're in the car. And so we're hopping from cell tower to cell tower. You know, we're, we're moving physically, but we need to have the same address. Well, you do and you don't. Okay. Right now, IP is floating on top of the cell phone system, using it, okay, as if it were one big network.

Of course, the thing has been, how do we do it with IP and replace all that cell phone stuff down below? The problem is that you've got, all you've got is the IP address. And they've made a few improvements, but it's still a real mess. Basically, because that's the only thing you have to hang on to. You have to come up with a tunnel from your home agent or router to the foreign guy that you're currently talking to. So that when you send out packets with your IP address and they go across the network to a server and he turns around and sends using your source address, sends it back to you. It's going to go to your home router who's going to put it in a tunnel, send it to the foreign router and hand it to you. OK, got it.

OK, this gets crazy. OK, if you're moving now from cell tower to cell tower, we're tearing down tunnels and bringing it back up. This is getting really cumbersome. Right. Right. Okay. If you have a full addressing architecture with application names, then you just, you know, things change down below and nobody has to, you know, you don't need any tunnels. If you move too far, and this is the neat part, if you move too far and you want to change your address so it aggregates, you assign, taking the definitions I used earlier, you assign a new synonym to the process with the address of where you are in the network now.

You tell via the management connection, but you're changing source addresses for all connections that originate here. You start advertising the new address. You stop advertising the old address. And it just works. Right, right. That makes sense. Right? stop advertising the old address and it just works. Right. Right. That makes sense. Right. And it, you know, and it happens just, you know, seamlessly. And, you know, in fact, you don't even need any new protocols, you know?

And this, this is grossly simpler than what 5G is doing. What is 5G doing? Look, I can't even begin to explain that. Okay. I've seen 5G diagrams that have seven layers below the network layer. Oh, okay. All right. I mean, it's just, you know, you want to glaze over real fast. Go read about 5G.

Okay. I was, I mean, not to get us too sidetracked, but basically, I know folks who got 5G home internet, and that's actually pretty powerful. I was really surprised. I was very skeptical, but it works extremely well. From what I understand, the physical layer stuff is pretty good. The network layer stuff is... But, you know, I mean, you can hide a lot these days. I mean, look at Bluetooth. Oh, my God. Yeah. Bluetooth works really well, right?

Yeah. I mean, I seem to always have issues with it, but maybe it's just me. No, no, no. It's not just you. I mean, I have the problem I have now, which is like the one car and a train of problems is I have Bluetooth headphones that and I don't know how this works, but they're paired to my laptop and my. And so there's some kind of cleverness that tries to, you know, figure out which one to actually get the audio. For some reason, you know, my laptop will be shut in my backpack, in my car, the trunk of my car. I'll be in the passenger side.

Yeah, I'll be in the passenger side of the car. My laptop totally shut. And then my headphones will hand off from my phone, which is, you know, three inches away or a foot away't know, a foot away, to my laptop, which shouldn't even be on. And so it's like one of many issues I've had. Well, let me guess. They're both Macs, right? The laptop's a Mac. The phone's an Android.

Oh, okay. Well, all right. I have a similar problem with a pair of Bluetooth headphones I have up here so I can watch tv while my wife is asleep and it pairs to my laptop i still haven't figured out how to get it to talk to my laptop and not talk to the tv it says it's pairing to both of them but it clearly isn't yep yep it's clear there's some there's some problem there they just fix that. No, Bluetooth is a mess of special cases. It's gotten better since it first came out,

but it was one of the worst protocol designs I've ever seen. So spiraling up a little bit, actually, can we do anything in sort of user space to improve this? Like, can you build, like, do you have to sort of, is there anything we can build on top of what we already have to make this any better? Well, there are two really bad problems. Okay, one is this addressing problem. Okay, the other one is the congestion problem. The congestion control scheme we have in TCP is pretty terrible, mainly because it works by causing congestion.

Yep. Yep. So that one probably is hard to fix for us. And also because they detect congestion by drop packets, it's predatory. If you try and do anything below it that happens to drop a packet, you're going to get feedback mechanisms warring with each other. Okay. And so there's no nice fix. And basically, the thing is, this is another case where at the time, we had a better solution. We have a solution that was based on explicit notification that started notification when the average queue length in the router was greater than or equal to one.

In other words, very early. Nip it in the bud so you can back off and not lose packets. Right? Because, I mean, with what we have now, the fact that you have to detect lost packets means the queues are full and they've been throwing stuff away. Right. Yep. So those are retransmissions.

And the longer it takes to recognize that, the more retransmissions you're generating. Yeah, that makes sense. 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, then 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 programming throwdown. Back to the podcast. What about the other issue? I feel like the addressing issue,

I feel like that's solvable with another layer on top that, you know, almost like a, like, SCTP or one of these things where you say, here's a list of, you know, interfaces. I know I'll point to the same node, and I'm just going to like SCTP or one of these things where you say, here's a list of interfaces. I know I'll point to the same node. I'm just going to use SCTP to just get me there. Remember, multi-homing is a problem of delivery, not sending. Wait, what's the difference there? Well, the thing with multi-homing is

if one interface goes down, I know what the other one is to use. But it's also a quality of service, right? It's sort of picking the best one. Yeah, but that's a whole different thing. Got it. Okay. I mean, first of all, congestion is doing you more harm on quality of service than the addressing is. Oh, definitely. I feel like the congestion is probably hard to fix. Yeah. No, I mean, first of all,

nobody thought about putting congestion in the transport layer until the internet ran into the problem. They were all going to put it in the network layer where they could come, they could coordinate it with quality of service. But now you've got these functions in the network layer trying to make the traffic smooth and you've got TCP pulsing it. Right. I mean, you're working against each other. And part of that's because they lost the Internet layer. You know, if you had the two bottom layers. The way we, you know, in fact, in fact, the NWIG, the International Network Working Group had had the right answer in 1975, but the Internet lost the Internet layer. Yeah, I mean, to your point, you know, I mean, even to this day, I really have a far from lucid understanding of IP.

I'm definitely, you know, I understand, like, my understanding is you can do TCP, you can do UDP if you're willing to tolerate some packet loss. And I know that they sit on top of IP academically, but I don't have an understanding of what that actually means. I think a lot of engineers are in that boat. Well, yeah, it's not really key. There's a lot of stuff that gets really complicated in there. IP should probably never have been separated from TCP. You know, there's just one patch after another. And, you know, every time you do a patch, there's friction and the friction doesn't add up linearly. Right. Yeah. Yeah. Right. You know, and so, you know,

I mean, for example, they, everything worked with, with TCP early on. Oh, well, as much as it could until, and they split IP and then IP fragmentation has never worked. And so, you know, then you have a, then you have a fix for that. The trouble is that doesn't work because it's turned out to be a denial of service attack. And just on and on and on. You could probably reduce the complexity of the net and increase the security by at least two orders of magnitude by fixing what's down below. Right. You know, and there's all sorts of things you wouldn what's down below.

There's all sorts of things you wouldn't have to have. For example, you wouldn't need SIP. SIP is like a voice thing, right? It's been a while since I heard that. Well, that's what everybody thinks it has to do with. The fact of the matter is, it's how voice or IP solves the problem of connecting to a specific instance of an application. Ah, okay. Got it. Right?

They were all their own. What does SIP stand for? Session Initiation Protocol. Ah, okay. Got it. Okay. It's how you resolve a phone number to an IP address in a port. Got it.

Okay. Okay. But, you know, if you had application names. Yeah, you wouldn't have to do that. Wouldn't have to do that. So I wanted to, like, I want us to take just a little pause here. I want to jump into, you know, what we could do to make things better. But I'm really curious if you could humor me on this.

Like, where do you make things better but i want to i'm really curious if you could uh humor me on this like where do you think things will go i think that that because i really don't know i feel like we're just stuck where you know ipv6 is i haven't even heard much about it lately and so i just like where do you think if you were to look into a crystal ball where do you think the internet architecture is going to go, if anywhere? The problem we have is thinking outside the box, okay? And going back to basics. Starting in 2000, and to some extent it's still going on, there's been a future internet effort. It hasn't come up with anything. Mainly, the reason is that the argument has been, well, there are new requirements on the network. Therefore, we need to do different things. It turns out that if you fix the flaws that were introduced, you not only don't need new things, you get things you didn't have before. But as I've

had several, you know, full professors tell me, well, this is really hard because, I mean, the only thing I've ever seen is TCP. Okay. They, you know, but, you know, that shouldn't be a barrier. I mean, one of the things I've been, I think I'm, I've had a couple of long email discussions with some of the early people on addressing, you know, people who were there at the beginning, especially some of the Xerox PARC people. And the one thing that struck me was that they were all trying to fix the problems they had in front of them. No one was stepping back and saying, what's the big picture here? And things that I thought were indications that they were turned out that was wrong. Got it. Yeah. You know, but,

you know, as opposed to the Ciclod guys, which I mentioned last time, who said, we're going to assume, you know, what are the minimal assumptions? Right. And then let's put that together and see what we have. And much to their shock, it was all they needed. Okay. To some extent, this whole thing about protocols, I went through, you know, and again, okay, so maybe it started earlier, but it shouldn't have. I've always, you know, there's a thing they teach in operating systems. Every OS book I've ever looked at talks about the separation of mechanism and policy.

Yep. All right. It always seemed to me we ought to apply that to networks. Right. Yep. I mean, it ought to fit like a glove, man.

Right. And so actually I did it, but I didn't do it by just, you know, coming up with them back in the early days we had, we were trying to specify protocols pretty well. And we had a pros outline form that we had for writing protocols there. And we actually took it to the point where we developed what we call RoboPros.

We realized that if you did what your rhetoric or English teacher taught you to do of, you know, don't say the same thing, you know, don't say things the same way twice, vary the language and all this stuff, was exactly what you didn't want to do in a specification. Nah. Because if you did, someone would say, well, he said it differently. So he must have meant something different. Right, right. Okay.

So we, we had it down to, you know, when you are in the X state and you get one of these, you do this. Yeah. Sort of pros. So I came up with an outline form for adding a new mechanism to a protocol. And then I religiously followed my outline, no matter how simple the mechanism was. Again, and I had no clue what was going to come out of this. Could have turned out to be a waste of time. But what fell out was I realized when I stepped back and looked at it,

well, okay, the first one that was sort of an ankling that things were coming was I had done an outline for acknowledgments, right? I mean, the machinery is the same question as when you're going to acknowledge. And then I was going to do flow control. It was another mechanism, right? And we had that sliding window thing going on, right? So one night, I started doing these like one at a time. And, you know, in the evening, I forgot the kids to bed.

And, you know, so I started doing it in down acknowledgement. And I noticed that I was only manipulating the left window edge. Well, that's kind of odd. I thought I'd at least have to refer to the right window edge. Well, I was going to do flow control tomorrow night, but I'm curious. So I did flow control, and I only referred to the right window edge. And then I said, of course, you idiot. The linkage is in the policy, right?

Well, duh. Yeah, right? Well, duh. Yeah, right. It makes sense. You know, light dawns on, you know, thick skull. And I went into this friend of mine, you know, doing this as long as I have, the next day at work and said, told him this insight. And he goes, well, you mentioned it. You know, it's obvious, but no, I hadn't thought about it either. But then I, the other thing that fell out of that was I realized that the mechanisms fell into two categories. Those that absolutely had to be with the data,

the error check, sequence numbers, you know, things like that. And the thing is, it didn't have to be. They could be, but they didn't have to be. And those were the feedback mechanisms. Right. That makes sense. Yep. Right. And what I realized was the other thing, which was a real shock, was that the, I call those the ones that had to be with the data, tightly bound, they had to be with the data. It only wrote the state vector,

recorded what sequence number it had gotten and everything. The other side only read it. And the two pieces never talked to each other. Actually, the only time that they did was when the flow control window closed and the feedback side told the other side, don't send anything. That was it. Otherwise, they never talked. Now, and so when you're when you're designing these, I mean, I wasn't designing anything.

Right. I was looking at the structure, you know, and I was doing a process, but I wasn't, you know, in much the same way with the IPC model, I was not skipping steps. You know, this designing a protocol that looked like TCP or TP4 or SATP or any of those things, you know, we'd done dozens of them, but we never done, A, the exercise of separating mechanism and policy. And, you know, we hadn't done a careful job of analyzing what the structure of the problem was. And I don't see researchers doing that at all. Actually, I've seen one other good example, which was Roz Jane's work on congestion.

You know, everybody's looking to find an answer, not understand the problem space. Right, right. Okay. So, yeah, how do researchers do research on something like this? They have to build their own network, right, where they can invent new protocols. Like, they can't use routers off the shelf or any of that because that's all designed for the existing protocols right they well first of all they end up well okay this also has to do with how you get funding okay all right okay all right and who's gonna what will they fund and what do they understand well this is this is clearly, you know, the Renaissance period where the kings and the princes will fund brilliant people to do anything.

No, it's definitely not big business coming in and dictating what people research. Sort of like a hint of sarcasm there. No, no, no. It really is. And also, you end up, you know, also people tend to build, they concentrate on a particular problem. Okay. And they'll sort of have an idea of what might work. And they go after that. And they build the rest of the context around it. Now, when I was doing the OSI work, I was the rapporteur for the reference

model with the architecture. So I got pulled into all the discussions up and down the layers. And I saw some patterns go by that I thought would be simplifying. And of course, the excuse I always got was, oh yeah, Dave, but if we simplify here, it's just going to get more complex somewhere else. OK, I don't know if I it seems there's got to be like a logical fallacy to cover that. I don't believe it. Yeah. Well, and the reason I don't believe it is that we were very fortunate. Back when we were building the first supercomputer, we had to use as our computer probably the finest piece of computer system design ever done, the Burroughs 5500.

You'll have to tell me what that is because I have no idea. Right. Oh, this is way before your time. In fact, this is even sort of before my time. This machine came on the market in 1964. Okay. This machine, the way I've always described it is if you knew how A worked and B worked,

you could guess how C would work and you'd be right. Ah, nice. There were no special cases. Everything just worked. Okay. It was the first machine to use a stack. Okay. Wait, so what do you mean?

Like a call stack? So it's, so it's a, wait, really? Oh, I guess in the sixties. Yeah. It's possible. Yeah. Yeah. I never really thought about that.

IBM still does it. I don't think. Or else they simulate it. This was a zero. Think about it. This was a zero address stack machine with no general purpose registers. It had a tagged architecture. The stack was tagged non-executable. It was descriptor based. So if you indexed off the end of an array, it was a fault.

Every register had a purpose. It was used for that purpose and that purpose alone. This is sounding a lot like the virtual machines that you see, like the Java virtual machine and stuff like that. And it was pretty clear that the machine operators' operations had been developed to fit what they needed. Oh, because the lowest level language on the machine was ALGOL, okay? Like Pascal. Right, right. Okay? The ALGOL compiler was written in itself. The operating system was written in an extension of ALGOL called ESPAL.

And like I said, everything just worked. One of my favorites, I couldn't believe this, my class last Tuesday. You know what a floating point number looks like? Oh, I think we talked about this on the past show. Are they like reversed? Right, right, right. Yeah, yeah. That was extremely clever.

Why haven't other people adopted that? Ah, because it takes a longer word. Oh, okay. Got it. Probably. I don't know. But the thing was, this thing was really elegant. That taught us that elegant solutions existed.

Right, right. Okay. This is one thing, just stepping back a little bit, making things more abstract, like, this is one thing that's really underappreciated in our field is, you know, I feel like there's people who fall into two camps and both camp kind of missed the mark on this one camp says you know we're going to be really pedantic and really strict and um you know and so and so then you know that kind of slows the development on the other end of the spectrum it's just kind of total chaos and it's uh you know let's get this product out the door and there's no rules and everything's just crazy and but there is like a third orthogonal axis there, which is, you know, how much you are willing to vary sort of the elegance of something and the time spent on that. And I think that, you know, it's really important for people to take a moment and say, OK, we've built something.

What did we learn from this? That's really fundamental? And can we build it over again with that a priori or a posteriori knowledge? Well, I have a theory on this. Let's hear it. Yeah. In the other sciences like physics and chemistry and stuff, nature holds our feet pretty close to the fire. If you try and build a molecule or do something with physics that violates the rules, it tells you real quick. In computing, we have two problems. One, the theory we have is very far disconnected from the reality.

What do you mean by that? Turing machines and automata theory don't tell me much about how to build a computer. Ah, okay, got it. Right, right. Right? You know, on the other hand, we also have the problem that we build what we measure. So is the... Oh, interesting. Well, yeah. Is the thing we're seeing a fundamental principle that we can't get around,

or is it a consequence of how we build it? Those are the two things we have. This is why you often, I believe this is why you often, I believe this is why you often have the first one as a throwaway, because you can only take the design so far as to what the trade-offs are going to be before you dive into the implementation and make some mistakes. Yeah, yeah. So you can see, now you can begin to see what the trade-offs are, and you get a better idea of what the nature of the problem is. Yeah. I mean, a great example of this is Intel's processor architecture, right? So it's like,

how did they know how big the pipeline should be? How many floating point coprocessors they need? I mean, all of this is empirical. They probably survey their big customers. They probably collect some data. And then they say, okay, we need to, there's more people doing floating point now. There's people mining Bitcoin now. We need to change the processor architecture. And so it's very feedback driven.

Yeah. In fact, even in those early days, Burroughs was analyzing user code for sequences that they were going to put into hardware. Oh, interesting. Yeah. Yeah. I remember there's a, is it the Vax? But there was a, there was a machine that was doing something similar and they did like even sorting and hardware, you know, things that people wanted. Right. Yeah. Yeah. I mean, I've always contended that the argument between RISC and CISC was not so much between complex and reduced, but that the hardware guys were not building the operators that the compiler needed. Yeah, that makes sense.

Okay. That you design the compiler first, and then you figure out what hardware operators you wanted it to have. Right? Then you figure out what hardware operators you want it to have, right? And, I mean, I remember when the 68000s were coming out, that Motorola would produce a new version of 68000. It was like, guys, these are neat, complex instructions, but without a compiler, I'm not going to use it. Right, right. I want the compiler to do the bookkeeping for me, for God's sakes.

Yeah, that makes sense. You know, and also this thing of, well, here's this really neat instruction, but in order to use it, I've got to move all this stuff around so I can use it. By that time, I should have just done it myself. Right. Yeah. You know, so, you know, those are always the tradeoffs. Now, I think we've made a breakthrough in that. And this is going to sound really weird, but I came across a book about a 19th century

logician, doesn't matter. And in the back of it, this is why browsing on Amazon isn't worthwhile. You know, I mean, you can't look at the back. There was this whole subchapter that the logicians had decided abstraction was invariance. And it was a head slap moment. What had I been saying when I said separate mechanism and policy? I had been pulling out the invariance. When I say I can't tell, you know, I suffer from the topologist's vision defect.

I can't tell a coffee cup from a donut. Pulling out the invariances. What I realized that the exercise I had been going through with networking was letting, you know, not forcing everything into one mold, which is the mistake many people make. But I was pulling out the invariant stuff and letting the part that had to vary, vary. Yeah, makes sense. Right. And also, what I also realized was I was then constructing the model not the way I wanted to, but the way the problem told me to, and not break the invariances. I mean, I can have invariances at different levels, right? You start out with some very general invariances and you start making them in different areas. You make different decisions about, you know, narrowing them down. And what we found, strangely enough, was there was no, we didn't, we never encountered a devil

in the details. In fact, just the opposite. We'd pick up a new topic that we hadn't looked at yet and find out that the model we were working with had already solved it for us. Oh, that's nice. Right? That, you know, there were angels in the details. Right. So, so how do we get this? So, you know, we talked about this a little bit in prep, but, you know, how do we get, you know, we talked a bit about where things are going and the answer is, is, uh, you know, a lot more research in a TCP and, you know, kind of incremental changes. How do we actually, you we actually blow this up?

Can we get a couple of company intranets onto something new? How would this work in practice? Well, there seems to be a rise in private networking. Right, yep. And I think that's the place to start. Yep, that makes sense. Right.

So just to recap, and actually tell me if I'm wrong about this because I'm not 100% certain, but for example, my laptop, I have a work laptop. It's right here. It's not turned on now. But but but when it's on, you know, we have a VPN. And so what that means is is, you know, my computer is is tunneling through my home Internet and all of that and it while you're in this tunnel it's sort of isolated and then at some point it gets the other end of the tunnel which is some network that is you know somehow like within the work system and so it's just as if i was in the office from a networking perspective and so with a private network and so i understand like if I go to google.com on my work laptop, it's actually, and please correct me if I'm wrong, it's like somehow going into work from a networking perspective and then connecting to Google from there. And so given that it's private

anyways, you know, it might be possible for us to do more clever things there. Well, and you know, the other thing is, you know, a lot of the reward structure is aimed in the wrong direction. People are rewarded for making things different. And in fact, in my book, I drew the distinction where I was trying to figure out what the difference between science and engineering was. And actually, both of them do experiments, right? I mean, that's not a – How I understand it is with science, you typically start with a hypothesis and then you're trying to validate it. With engineering, you start with a sort of an architecture of what you want to build.

Well, what I came to was in science, you're interested in the commonalities, in variances, the similarities between things, leveraging that similarity. In engineering, you want to exploit the hell out of the differences. Yeah, that makes sense. That makes sense. Yeah, I mean, that kind of goes along. Like with science, you start with a hypothesis

which is going to be hopefully some really short, maybe even a one-liner. Yeah. And so to get that level of abstraction, you have to do exactly what you were saying. For engineering, it's like, you know, the goal is this huge architectural diagram. And so you're trying to, you know,

kind of get every piece, you know, squeeze the water out of the rock on every piece of there. Well, but again, that comes back to finding out what the variances are. I mean, you know, the conclusion we've come to is that there aren't five or seven layers. There's one layer that repeats. You can use that for a lot of different things. You know, your VPN is just another layer, you know,

and on occasion you may join other layers with it, you know. But, you know, and as I said, when we did that, all sorts of things fell out that we had no, you know, it all came out of that IPC model thing I described earlier, you know, which was very general and very, you know, rudimentary, you know, very elementary. But on the other hand, it turned out that the layer was a securable container, that we basically didn't need firewalls, that all members of the layer were authenticated. One that fell out that we didn't expect at all was that you don't need a global address space, but you can still reach every application. That makes sense. Yeah.

And so that enhances security a lot. Yeah, similar to, if I could draw the analogy for folks in the audience, it's similar to how you have folders and folders have security. So, you know, if I try and go to someone else's home directory, it won't let me. And then therefore, like, by default, it won't let me see any file in any subdirectories. You know, it's handled in a recursive way like that. Right. You know, and so, you know, but again, by coming up with the invariances and we've got a little bit of term inflation. I mean, I don't want to I mean, I don't want to step on too many toes, but. We have a lot of real inflation, too.

So you're in good company. But a lot of people who have the title architect are really more chief engineers. That's really their role. Okay. I mean, I had this discussion with somebody. One of the things I always point out is that they're, you know, what is an architecture? It's a style of construction. There's a difference between Victorian architecture and a building built to

Victorian architecture. Wait, can you, let me resonate on that. So a building built to Victorian, so the building is an instance of the architecture. Right. And it has certain characteristics that make it be Victorian. Right, right but victorian architecture itself is sort of this abstraction is the abstraction you never totally reach it you know it's uh yeah okay that makes sense and then basically to some extent the other thing this is something i realized oh back in the 70s is first of all pattern recognizers are rare every humans in general are good pattern recognizers but there are some people general are good pattern recognizers, but there are some people who are just really good at it.

You know, they see patterns that others don't pick up on, you know, and they're rare. They're the guys who have to come up with the theory. And, you know, it became apparent to me back then that we were either going to have to come up with tools so the few people who could write really good code could write all the code that had to be written or it was going to be bedlam, right? Or we had to put stuff out there

so that people who were not good could do it and get it right. Right, right. One or the other. Well, we haven't done either one. Yeah. Right? And, you know, this whole breakthrough with invariance,

I mean, we've talked about abstraction in computer science forever, you know, this whole breakthrough with invariance, I mean, we've talked about abstraction in computer science forever, you know. And actually, one of the things that scares me is people tell me that the RINA stuff that we talk about is, quote, too abstract. It's like, guys, this is computer science. This is what we're supposed to be good at. Right, right. And believe me, RINA isn't category theory or algebraic topology. You know, on the scale of abstraction, it's not all that abstract. Yeah, yeah. Yeah. So one thing here is, is, you know, there's, this is, this is piquing the interest of like, you know, tons of folks

out there. And I'm sure a lot of people are, you know, maybe they're in undergrad, maybe they're in high school, right? And so they're saying, this is awesome. I want to work on the future of the internet. What do you recommend to those people? Like what sort of career advice would you give them? Or, you know, what would be sort of a path for them if this is something that really charges them up? I wish I knew. All right. I really wish I knew. see this stuff firsthand. You know, I, you know, you need, you know, and you're probably, if you're going to actually do it, you probably have to read widely and, and think about it a lot on your own.

Try and get with good people, you know? But the thing is, and that was another thing where we were really lucky, you know, we had a group of very smart people of which I was the least and, and they put me through the ringer. And we had a professor who was not related to computer science at all. He was one of the founders of cybernetics who didn't tolerate sloppy thinking. And he really put us through the ringer. And what we learned from our sessions with him, we applied to ourselves, you know, and really debated this stuff. You know, again, I think it comes back to stepping back and taking the big picture,

you know. Yeah, you may be working on a specific thing for work right now, okay, but how do you think it fits with all the other solutions? Where are the generalities, okay? What makes sense? If it doesn't fit, it's, you know, I think, I mean, right now we're working with three basic rules of the road. Maximize invariance and minimize discontinuities.

That's a highfalutin way of saying no special cases. And if you think about it, a special case is breaking the invariance. That's why it's a special case. Do what the problem says. It's smarter than we are, you know, study the problem. And in fact, one of my favorite quotes by Kettering is a problem well-defined is a problem half solved. Yeah, definitely. You know, so, you know, all that stuff that people say, oh, we don't have time to do that. We don't have time not to do that, you know. And, you know, I've always been a big believer that good design was made better code than line-by-line optimization.

You know, the real collapses in complexity come when you go, oh, wait a minute. If we look at it this way, it's much simpler. Yeah. You know, you know, those are the things and it's a talent, you know, I mean, I'll never be a violinist, a virtual violinist or a painter or any, you know, anything else, or even maybe, you know, you know, turn out, you know, a thousand lines of code a day. In fact, one of the guys I work with today was my office mate in the 70s. He and I have been together for 50 years. Right. He's a dynamite implementer.

Right. And we bounce off each other. You know, he sees things I don't. I see things he doesn't. You know, and, you know, but, you know, it, it, but you, you know, I think reading widely is, is really key. That is a really good call out. You know, when I was a undergrad, I really didn't read a lot. Um, you know, we would get these assignments. Well, yeah, that's, that's true too. But, but, uh, I feel like, like, you know, later on when I went back and read the papers on all these topics, you even go back and read papers from the 60s and the 70s and you read about sort of you could see the sort of genesis of the methods and you could see the historical patterns and then you could place yourself in history and say, okay, here is

what needs to happen next in this narrative that's spanning a whole bunch of people, a whole bunch of years. But it's like, okay, now this is the next chapter that has to be written. It's very hard to do that if you don't read a lot. Right. I'll throw you a real curve. My first semester in graduate school in CS, when I went back after I got a master's in AA, the only course I took was the social ecology of the Amazon basin. Okay. All right. One of the best courses I've ever had.

I have no interest in the Amazon basin in any major way. Okay. But when I read the description of the course, I said, this is going to be good. So why? What stood out? The professor had assembled guest lecturers and looked at every aspect of what was going on in the Amazon. OK, we had lecturers from geology, geography, biology, ecology, economics, politics, Spanish

and Portuguese literature, the IMF, the World Bank, okay, on and on and on. In that course from the project, he pointed me at a guy in the business school who turned me on to a theory of organizations called the garbage can model, which is all about business, how organizations behave under high degrees of uncertainty. OK, that has been a guiding thing for me ever since, because I don't know any organizations that are operating under high degrees of uncertainty. Yeah, I mean, all the time, you know. In fact, one of the things I point out in my lecture on, say, network management is that managing the network is a low uncertainty problem and it better stay that way. Right. Because if the network's down or the electric grid is down, you know, there's bad things happening. Right. Right. So it's got to be insulated.

And, you know, and the model actually brings out all sorts of good advice. Like don't put high uncertainty projects in low uncertainty divisions. How many times have you seen that done? Right. And vice versa. My favorite is for high uncertainty projects, hire people with low degrees of self-confidence. Why? High uncertainty. Yeah. Like that. How, why is that? You don't want somebody who thinks he knows the answer. Ah, okay. Got it. You want somebody who's always going to be doubting that they've actually looked at everything.

Ah, interesting. Okay. And the advice to the president is never, under any circumstances, make a decision. If you're the president. Now, yeah, it's funny, right? If you're the details. As you move up, your decisions have to be more and more abstract. By the time you get to the president, what you're doing is setting direction and setting environment. It's the only thing you can do safely. Right, right. Yep. Okay. This is something that I experienced and a lot of other people experienced where we go through this phase where we move into leadership and we still want to hold on to all the code that we wrote.

You know, and we were an engineer at the same company. And so we started seeing these changes go by and, you know, you start wanting to jump in and make all these contributions. And then at some point, I realized that, you know, with the amount of time that I had left over to do these things after I was doing my real job, I just was not making good decisions as opposed to somebody who's there 40 hours a week minimum. And also, don't you feel like you're walking on ice? I don't know what that metaphor means, but maybe. You worry that they're doing what you would have done? Oh, interesting. Yeah, yeah, right, right.

I mean, are they seeing the things that you would have seen? Right, right. All of that. Oh, gosh, yeah, absolutely. Yeah, so we have a few minutes left. So I wanted to give time to you to give advice to the folks out there. We have a lot the folks out there? We have a lot of kids out there.

And what is the best advice you can give to folks, high school, college, maybe even young professionals, old professionals, what's your best advice that you can give to all of us? Unfortunately, the best advice I give runs counter to the way universities are pushing us today. Okay, all right. I start every one of my courses with the statement that this is a course in learning how to think. We're going to use networking or operating systems as the case study, but this is a course in learning how to think.

And I start with a quote from John Henry Newman from 1856 that says, the purpose of the university is to create a habit of mind that lasts a lifetime. You're in a university. It's like a walking encyclopedia. Use it. If you get a break. And that, to some extent, I think we had more freedom to do that when I was in school. Today, school is so expensive and everything. You know, you don't take things on a lark. Interesting. Yeah. You know, it's, you know, it's all about getting a job. This is the time to really get a, you know, at least an exposure to as wide a group, as wide a bunch of stuff as you can.

You know, you know, one of the best, you know, another one of the best courses I had as an undergrad was a you can, you know. One of the best, you know, another one of the best courses I had as an undergrad was a drama course, reading plays, you know. I ended up with a really brilliant TA who went on to write screenplays in Hollywood and actually founded a local version of Second City and a theater, you know, and was doing some great stuff. But I mean, but the thing is, you know, the biological theater, you know, and was doing some great stuff. But I mean, but the thing is, you know, the biological sciences, you know, all of that stuff.

I mean, even just on sort of a cursory level, get as wide an education as you can. And like I said, it's not just computer science. I mean, one of the things that worries me about computer science these days, and it has for decades now, is when you take a degree in computer science you don't take college physics um yeah that's right you know it's not clear you even take calculus yeah i think well so yeah so basically if i remember correctly i kind of geeked out i took extra courses but yeah i think you're right you you have to take uh right so the way calculus works in universities you take calc one two and three i think for cs but then but then those aren't real calc classes you want to get into a calc or you actually prove all the theorems and that's optional and also just you know i mean i remember when i

took freshman physics you know and suddenly the equation for you you know, where, you know, something's going to fall made sense. You, it was derivatives guys. Yep. Yep. You know, it was all about derivatives, you know, and you know, things just didn't, you know, I think, you know, also I think having a double E degree, I was much more into systems and their dynamics. Right. Right. Whereas I think computer scientists this is what i

sort of see in my students is that they're used to everything being linear right yep they're not used to concurrency yeah you don't have to take diff eq uh differential equations or really any of that in cs yep i made the mistake of taking it this summer. Oh, God. Actually, my wife and I were talking about this yesterday. We both took courses in the summer that we just wanted to get over and done with. Neither of us liked history, which now I actually really appreciate history. But as an 18-year-old, I didn't really appreciate history. And so both of us knocked out uh history in the summer uh we took four hours i think four hours a day five days a week of history but we were done in like three months

i can't imagine doing diffy q in the summer i took diffy q in the summer that's unbelievable i mean i don't think i would have uh survived that it was we call it the summer of the lost sign yeah i can't imagine right i mean because you know it the summer of the lost sign. Yeah, I can't imagine. Right? I mean, because, you know, it was one of those where you dropped a sign somewhere in the answer. You know, the thing just blew up in your face, right? Yep, yep. And of course, in those days

we didn't have Math Lab and, you know. Right, right. Well, you know, and I was debating about that today. You really touched on that. I just, I think we mentioned this last time. I just read a book called Faraday Maxwell and the Elect well, first of all, he's the one who translated Maxwell's equations into vector calculus. And he's the one, as a double E, why I had to take a semester course in transmission lines. Oh, interesting. And this guy was really incredible.

He was, he had had scarlet fever as a child and was deaf or mostly deaf in england telegraph machine operators the telegraph was visual not auditory so he became a telegraph operator okay and taught himself all this stuff and figured out how to find bugs in transmission lines with loading and impedance oh interesting all that stuff right and? And I'm like, wow, now I understand why I had to take a course in transmission lines. Yeah, that makes sense. And then I sort of was, would I

have at 19 or 20 been more interested in it if you told me the history? Like you, I sort of honestly said, probably not. Yep, yep. That's true. It took getting older to really appreciate how they got it figured out. Yeah, totally. Yeah. It's interesting why that, I have to think more about why that phenomena is what it is.

But I know a lot of people go through that phase where they start to appreciate history more and more over time um but so i wanted to give you some time also to plug anything you were mentioning a little bit earlier that you have a book uh so what's the what's the name of the book book is called patterns and network architecture patterns and network architecture a return to fundamentals cool it's old in terms of what we know now but i don't think there's anything wrong in it which is scary it's a good sign you know i mean we've confirmed most all of it so far as i know but we've extended it quite a bit and i i need to get to work on a follow-on that brings it up to date but yeah so so there is that out there. And if people want to reach you, what are other ways?

Oh, I have a very complicated email. Okay. day at bu.edu. Ah, nice. Oh, that's, yeah, you have actually, we're tied for the shortest email. For a while, I had an email that was the same number of characters. The other one I use, which is the one I probably respond with, is jeanjour at comcast.net. Ah, nice.

John Day in French. Nice. Oh, okay. I was trying to guess what it was. Okay, cool. In Gmail, I'm German. So what made you, you just kind of felt like let's do different languages? My name translates in all languages.

Yeah, I guess that's true. Yeah. Very cool. Hey, this was an absolute pleasure. I think I learned a ton. The audience learned a ton. People are going to walk away from this with looking at the Internet in a whole new way. And I hope a lot of folks go out and pick out your book.

We'll link to that in the show notes so that folks can get easy access to that. It's available on Kindle. It's out of print in hard copy. Yeah, I mean, nowadays we definitely promote Kindle. If you want to read it on Kindle, you know highly recommend jumping on amazon getting audible subscription you can do that through the uh programming throwdown link that helps us out as well and uh i think they have it now i i recently got an email where i think there's some kind of synergy between audible and kindle maybe there's a discount like a kickback program or something

there but well there's a lot here to dive into and a lot of good thinking. It needs to go on. Yeah, definitely. I mean, if you are, you know, if this is something that super, you know, appeals to you, definitely, you know, take your, you know, architecture course at University Network Architecture. Learn more about it. You know, meet with a lot of those smart people who are going to push you and challenge you, like John mentioned. And yeah, I mean, um yeah i mean there's there's there's you know the internet is not going away that is for sure so the internet is here to stay it's the i believe the internet is like the uh uh you know collective consciousness of humanity

and so i don't think it's going anywhere so i i'll tell you i we a whole nother topic but you know i mean all of the stuff that goes on with social media and disinformation and fake news and all this just scares the hell of a Jesus out of me. Yeah, you know, a lot of people don't realize sort of like the communal nature of the Internet. I mean, we haven't had the whole world, you know, influencing each other, you know, in real time before. So this is a whole evolution in humanity but but it's also you look there's there's something about the isolation that allows you to say things or think things you wouldn't if you were in person oh the physical isolation yeah right right you know i mean the well the decoupling, maybe is a better way of putting it.

Right, right. You know, the way some of this stuff gets going. And also, I think that, you know, in terms of our world, socially, there were always the strange ones. But they were insulated from each other. Right. And it didn't get out of hand. And now, you know, the most bizarre things get out of hand. Well, yeah, I'm pretty sure that there's state actors involved in a lot of this. So that's a big part of it.

The Internet was much more independent. You know, I feel like now every state actor is saying, oh, how can we get it on this, right? Well, there is that, too. But there's also just the fact that, you know, what people will believe is just amazing. You know, the BS sensor is just not that well-tuned. Yeah, I think we go through cycles in civilization. That's what I'm hoping. Yeah, I think that.

Yeah, I think that, you know, we go through cycles where people I think ultimately I think people are really more afraid. People are more afraid than they've ever been right now. Yeah. I mean, you you could read that historically there was a similar thing with the early days of newspapers, the early days of radio, etc. But I don't know. Maybe it's just us, but this one feels different. Yeah, I mean, I think I see a lot of similarities from the 2020s and the 1920s. But yeah, it's wild.

I mean, the only thing we were missing was hyperinflation so uh but anyways well leaving on a good note i think that um um i think that that you know we've had an amazing conversation here um a ton of really good material as i said internet's not going away so if this content interests you, dive deep into networking, network architecture. You're going to learn a lot. As someone who's built, I've built a variety of different networking apps that have various degrees of popularity.

I think that there is, as John said, a huge commonality between networking and application development and understanding you know kind of all of that is going to be extremely beneficial um in a society where as the networking uh the internet is not going anywhere so so definitely uh take the time in university to learn about this stuff one of the other points that i always make in my class is that every other aspect of computer science you can go into is a specialization.

Networking is the only one that uses all of them. Yeah, that makes sense. Yeah, I mean, you need databases for routing tables. You need everything. Analytics, you need software engineering, you need operating systems, you need it all. Distribution fitting to do all the routing and everything. Yeah, very cool. Well cool well john thank you so

much for coming absolute pleasure i'm really glad that we had the time to do a two-parter because we had so much amazing content and um we'd love to to get feedback from the audience and uh you know if you have questions definitely send them over to john and see you can cc us on the show programming throwdown at gmail and uh again thank you so much for for coming on the show my pleasure take care music by eric barn dollar programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're free to share copy distribute transmit the work to remix adapt the work but you must provide an attribution uh to uh patrick and i and uh share alike in kind