Hey everyone, welcome to today's Protocol Labs Research Seminar. Today we are joined by Boston University Master Lecturer, John Day. John has been involved in research and development of computer networks since 1970, when his group at the University of Illinois was the 12th node on the ARPANET. He has developed and designed protocols for everything from the data link layer to the application layer. And today he will be presenting part two of his talks with us, this one titled, Back to the Future, Welcome to the Renaissance. He will discuss the past and bright future of the recursive internet work architecture. The YouTube link of part one of this talk is linked in the description, in the chat, sorry. And if you're watching live, I will share it in the chat for you to watch afterward. We're excited to welcome John as part of our series on revolutionary internet architectures in conjunction with our open request for proposals, RFP 11, changing the internet. So thank you so much, John, for taking the time to join us again. And I'll let you take it from here. So I'm going to talk about how, you know, how Rina came about and or actually our quest for principles. And first of all, I have to say, back in the we were very lucky at Illinois in that we were building the world's first supercomputer, which was totally uninteresting. But we had probably the finest example of computer design to use to do our work.  But I can talk about more about it later. But believe me, it was one of those systems that had no special cases and no clutches. Everything just worked. And for us, it was a life changing experience because it told us that those kinds of solutions were out there. At the same time, we were very fortunate that there was a professor on campus who claimed to be Wittgenstein's nephew and was one of the four founders of cybernetics. And he put us through the ringer and learning how to think. And we actually use that in the how we developed operating systems back in the early 70s. So let me get started here and see where this is going. I've got my my usual favorite quote here that a good architect is, you know, suffers from a topologist's vision defect, that old joke. You know, it can't tell a coffee cup from a donut. Now, as far as the origins of Rina Go, let me say right off the bat, I embarked on this not to fix anything. My goal was not to fix anything. My goal was to figure out what I knew about networking. Over the years, I had seen a number of patterns go by that looked promising, but hadn't had a chance to follow them. And, you know, there were four topics that I really felt like I needed to care, you know, to look at the separation of mechanism policy, which we'll talk a bit more about in a minute, the resolution of the the connection connectionless debate, the virtual circuit versus datagram debate, which has really torn things apart. Work through the implications of a comprehensive addressing architecture. I thought I knew what it ought to be, but we hadn't really worked through the implications. And, you know, often you get the argument that, well, you know, if we simplify here, it'll only get more complicated somewhere else. And because of the fifty five hundred, I didn't believe that. Also, I wanted to really make use of Dick Watson's result that I talked about last time, that the necessary and sufficient conditions for synchronization are put an upper bound on three times. Actually, exploring these and how we got that, how I got there is a bit interesting, but it really all came back to the beginning. It's funny how after twenty thirty years of doing this, you sort of get away from what you were thinking at the beginning. But in the early days of the ARPANET, we all believe that networking was inter-process communication. And, you know, Dave Walden wrote an RFC on it. Mike Bedlipsky wrote, said it was axiomatic in RFC 871. Bob Metcalf, you know, article on how to write an NCP, just mentioned it in passing that, well, you know, just like we all know that. And, you know, basically what we come up with is the layers of distributed application that does IPC. Rita is what you get when you try and build from these principles.  But then I had, I was browsing a bookstore, one of my favorite things to do. And I came across that the logicians had defined abstraction as invariance. And it was one of those head-slap moments, you know, like, well, of course it is. Why hadn't I thought about that? And so our rule became maximizing invariance and simplifying or minimizing the discontinuities, maximizing invariance, maximizes simplicity, minimizing the discontinuities. In other words, we prefer generate cases to special cases. Essentially says we're saying within the invariances. Construct the, and then we construct the model to not break the invariances. And when we do that, quite interestingly, we don't find devils in the details. We find angels. We pick up a topic we haven't looked at before and we find out the model already tells us how to do it. So that was a real, real interesting. The other one was do what the problem says. It's smarter than we are. And the thing is, even if you, you know, even if you sort of charge ahead and don't, sooner or later, the problem is going to get its retribution. And the longer you wait, the longer, the more it's going to cost you. You know, and the other thing we found is that good enough is only good enough in the short term. Sooner or later, it's no longer good enough. And the cost of repairing it becomes really great. Also, the more good enough to throw in the friction they create goes up exponentially. It doesn't go up linear. And the third one is always try to prove what you're doing to be wrong. We can't prove it right. Therefore, we have to continue to try and make sure we've heard what the problem said, you know, to begin with. You know, it speaks softly and we need to care. Figure that out. So the beginnings were separating maximum policy. I'd always found it odd that every operating system textbook talks about this. But it's never mentioned in networking textbooks. And it seems like it was pretty obvious that it should be because, you know, if you guys look at protocols, it's probably as much or more than I do. And, you know, we have all of these mechanisms. But and the only thing that really changes is the policies. Now, what do I mean? OK, well, you know, in operating systems, the machinery for memory management is always the same. The policy is what do we roll out to disk and what do we keep in main memory? OK, and what do we throw away? In networking, the example I always use is, you know, the machinery to do acknowledgments is always the same. The question is, when do you do it? Now, to give you an example, we always thought we'd do another version of of transport for voice because you care about order, but you don't care about gaps. You know, a small gap, nobody's going to hear it. So what? And then one day I realized, no. We don't need a new protocol. We just change the policy. We lie. There's nothing in these protocols that says you have to tell the truth.  You know, but that told me I'd had the semantics of ACK wrong all this time. ACK doesn't mean I got it. ACK means I'm not going to ask you to retransmit it. It's small, but it's significant. So that looked like it would be a powerful thing to do. It turned out it was. It was clear from this outset that layers were going to be that occurred naturally in networks, even though, you know, and everyone pretty much agrees that, you know, Dijkstra came up with the idea of layering and operating system in 1968. And of course, we started the net in 1969 and that that paper had really captured our our imaginations. And so using layers had become, you know, we're quite natural to the problem because we were doing OS stuff there. But also just because the problem actually calls for layers. Experience showed that mechanisms kept reappearing. Dijkstra said that they shouldn't, but they kept doing it. So that kind of caught us by surprise. We could see that there was a repeating structure. But what held us together and, you know, was not exactly clear. And from Ciclod's, we knew the scope was probably the most important property of layers, which I've talked through. You know, I've talked about last time. Then I got a breakthrough out of left field when I, another professor asked me a question about port IDs. And I really didn't like the answer I'd given them. And so it rolled around my head and I'm going to very quickly go through what I came up with. I can do a whole hour's lecture on this and I do it for my class. I decided that it was time to go back. That networking was IPC. So I went back and I started with two applications in a single computer communicating via IPC. And I figured I laid out how it should work. And, you know, in some detail. And then I went from there to let's have two two applications in two different computers, what went away, what I have to come back. And what you find is, well, you need a protocol to find the other application, but then you need another protocol, an error flow control protocol that makes sure the first stuff gets there intact. And so you talk about how that should go about.  And then I went to, let's have more than two applications in two computers, you know, now what do we have to do? Well, it's pretty clear that we have to be able to distinguish messages that are important for or on one flow to one application are distinguished from the other. And so what we really need is a connection I need to make that happen. And there was some discussion about how to do that. And then over some time, you know, people said, well, wait a minute, we've got these poor IDs, which are acting like file descriptors. Why don't we just use those and we'll concatenate them to make the connection ID? And that's pretty much what we do. But we have another problem. We have this makes us have multiple users of a single resource. My gosh, that's the definition of an operating system. And so we're going to need basically to have an application that manages the use of the wire. This guy. So we got that. Let me tell you in this section, we talk about how that works. And then we go to in systems directly connected. Well, you know, this is, you know, actually, in some sense, this is no big deal. We just did one of those. So let's do one for each wire. OK, so we do that. But now we have another problem. You know, the application really shouldn't have to know which you know, figure out which wire the application he wants to talk to is that, you know, so we need to have positive some kind of finder.  We know that's just not going to scale. I mean, this directly connected stuff is just going to blow up like that. So, you know, machines were getting pretty cheap. So let's let's pause and we've got some machines that are only needed for relaying. You know, so what are those look like? Well, you know, we're going to have to have one of our things we've already created for each wire and then a little application that does relaying. And that's going to require some new things in our scheme of things. And we'll talk about all of that. You know, that's also going to require that we put, you know, relays cause trouble to because you can't avoid transient congestion from time to time or rare memory errors while you're relaying. And so you're going to need an error and flow control protocol to go across the whole thing. And of course, you had in the last step, you had to add addresses to everything so you knew where the packet was going because, you know, before it was just a point to point wire. I mean, if it went in one end, the only place you could come out was the other, but here that's not the case. So we had to actually add addresses. But it's interesting that we only have to add addresses when the layer has more than, you know, two ends. Now, if we step back and look at what we've constructed, it looks like this. And you're going to say, well, Dave, you know, you just wasted 15 minutes because that's the same old model we already had. Well, no, it isn't. What I just described was that there aren't five or seven layers. There's one kind of layer and it repeats. This is a distributed computing model. OK, that's what pulled everything together. And this is the core of Rena, everything derives from that. There are five or seven layers. There's one kind of layer that repeats over different ranges of capacity, quality of service and scope. With different policies, a layer is a distributed application that does IPC. Virtual circuit and datagram is a function of the layer, not a service. Which one you use is determined by the density of traffic. The denser the traffic, the more connection like the less dense, the more connection less. One thing in that whole debate that kind of got things from Australia was that the feedback mechanisms in error and flow control protocols like TCP, the flow control and retransmission control were categorized as connection oriented and they really aren't part of the same problem at all. And then we had the separation of mechanism of policy, which we applied to these protocols. And that actually was very interesting because what you find about those mechanisms is they fall into two categories, those that have to be with the data and those that don't have to be. They can be, but they don't have to be. OK, and the two pieces are virtually separate. They really don't talk to each other. Now, the other thing we had, I have this implication of ASM-1, you may be wondering what the heck that's all about. Everybody thinks ASM-1 is a encoding scheme. It's much more. ASM-1 divides stuff up between an abstract syntax and encoding rules. It essentially makes a protocol invariant with respect to syntax. The procedures remain the same. But the syntax that's sent over the wire changes. And so when you apply all of that, what you end up with is that there's really only one data transfer protocol with different policies and encodings. The other thing that's interesting here is the data transfer protocols modify state in turn over the protocol. Application protocols modify state external for the protocol, and they just differ by having different object models. You know, this is a huge complexity collapse. And what this yields, first of all, our layers all have different scope. And we talked about that last time. And it's recognizing this scope and using it that makes the traditional ITU model or Bayesian string model untenable. You really can't talk about things like control and data planes if you're really working about scope. And of course, we also have Watson's Theorem, which I mentioned before, which we're going to apply here. And Watson's Theorem actually has some really major implications. First of all, it makes the protocol a lot more robust. There's better quality of service support. We can change quality of service during a flow by merely replacing the connection because port allocation and synchronization are distinct. We can have different quality of service for the different directions. There's no problem. It's also better security. The attacks on TCP connection establishment don't work on a protocol built to Watson's specifications. But Watson implies even more fundamental result. It defines the bounds of networking. It's networking if maximum packet lifetime can be bounded. If it can't, it's just a file transfer. This leads to a very natural structure within the IPC process and layer. And notice, again, this naturally falls out into just exactly what you'd expect or what you would want, that we have data transfer, which is our IPC transfer, which is very fast cycle time and very simple computationally decoupled through a state vector with the feedback mechanisms, retransmission and flow control decoupled through another quote, state vector or management information base from resource allocation and routing. This is exactly the kind of structure you want to see. I'll even reiterate here on the data transfer stuff. This stuff here, the data IPC transfer updates the state vector. The data transfer of the IPC control reads the state vector and generates AC and flow control. These two barely interact.  That's it. This, I've said, is a big complexity collapse. Consider, you know, we've got this structure where we just talked about, and these are the mechanisms and then plugging into those mechanisms are policies. OK, now we've found this structure repeats in the layers. But what is the way to implement this? Well, you might think that just doing something like this would be the obvious thing to do. And yeah, you could do this. This is what, you know, P4 tries to do, although it doesn't do it very well. But this does have, I mean, it has some advantages, but we can do so much better. Consider the following. Remember your automata theory? You're kidding. I mean, you think I'm kidding, right? Nope, really. Now, remember, a Turing machine is like a program. It executes one algorithm. A universal Turing machine reads a description of a Turing machine and its data and does that. Now, suppose the mechanisms are looked at as a universal Turing machine. The policies define a Turing machine. And of course, the PDU, the passage coming in is the tape. You point a policies at layer one, process the layer one header, move the tape down, point the policies for layer two, process the PCI header for layer two, and so on. No context switches, no data copies. This makes much more efficient, much simpler implementation, a huge complexity collapse. You can put the universal Turing machine in silicon. And these are code and data. Actually, we did an operating system like this in the late 70s. We know this works and also remark about one other thing here. Almost all of these results, and I can point to other places, too, the insights have come from the theory, not from the implementation. This leaves that in this kind of a system, we only need three kinds of boxes. We don't need no stinking metal boxes. A layer turns out to be a secure container, which we'll talk about in a minute. And of course, we can repeat this structure to any depth. Now, what this means is that what we're doing here, and you'll see people trying to do this in IP now, but they don't have the structure to do it, is that you're going to come across here and you're going to find out that the next hop in this routing layer here is over here. But the port you want to use to get there brings you down here and you get routed across here. OK, from above, this looks like this, that there's a hole in the metal. But that's not what's, you know, but that's just, you know, it's going down a layer.  The user of a layer only knows the destination name and its local port ID. Addresses are never visible outside the layer. Addresses belong to layers, not protocols. And also, one thing I sort of left out in this is the members of the layer, I call them IPC processes, to distinguish them from user processes, you know, are really just applications. They're just processes. So they have a process name like any other. That means that addresses are synonyms. Whose scope is limited to the layer and may be structured to facilitate its use in the layer. Because mobility is just multi-homing, where points of attachment change more frequently. Mobility requires nothing new. It just works. Well, multi-homing comes up for free here because we have a full addressing architecture. There are no home or foreign agents, no tunnels, no anchors, no new protocols are required for mobility. Use layers of different scope to ensure updates are made in time. And I'll show you how that works in a minute. Because addresses are synonyms, a network can just, we'll talk about that in a minute here. Now, all communications goes through three phases. Enrollment, allocation, data transfer. You know, this is this goes back decades, even before. I well, actually, I heard it, you know, even before we started the OSI work. Enrollment has been in the past one that we tend to ignore. Or actually, it was all manual, but it's becoming more and more automated. And basically, I've got some abstract definitions here. But basically, enrollment is how you join a layer. So how does that work? Well, suppose we have this new IPC process and you want to join this layer. How does it work? Well, as I'll keep saying, do what the model says. It's a process. It wants to join a distributed process. It needs to establish communication with a member of the layer, which he does. And then once they have established, they've got a communication via a lower layer, then they set up a connection between themselves, authenticate each other. That's the first thing any application should do with talking to any other application is authenticate each other to make sure that they are who they say they are. And if everything goes well, he's assigned an address and he's a member of the layer. That's all there is to it. And we have a couple of different enrollment procedures, so a simple one and a more involved one for things that bounce a lot. So how are connections set up? Well, it's sort of like it's done today. Application A wants to establish communication with application B, you know, using a supporting diff. So we do what the model says. You know, we do it allocate, which create, you know, which generates a create flow request. We determine that the application B isn't here. So we look at our forwarding table and we send it over to the next to where it points. Who sends it over to there, who initially says, well, look there, OK, and in this scheme, rather than just report back the way TCP does, we go there, confirm that it's there, and then we report back. This allows us to do access control at that point. We can decouple, you know, decouples for allocation, synchronization, the application never sees the address. If B had moved, it simply keeps looking using the forwarding tables to figure out using a search rules. Port IDs are not carried in protocol. A's port ID is not known to B or B's is not known to A. Access control falls out naturally, as it did from the IPC model. And it sets a structure to avoid a whole separate scheme for IP, something like IPsec. Can I jump in and ask a question? Sure. Great. I want to refer back to something you said a few minutes ago, because it's been on my mind. You said all the insights at that point have come from theory and not from implementation. Are there any are there any implementation details that popped out? Did you learn anything from implementing this or any doubles? Are there any? Actually, no, there have been no surprises of the implementation. Instead of finding devils in the details, we've found angels. And I think the reason is, is because we've constructed the model to not break the invariances. I already went over mobility. What's the big deal? It works just like boldly homing, only the M minus one port IDs come and go a little more frequently. That's all there is to it. I've got some other extra slides I can look at if we have time. Again, no special cases as I was saying before. But then we have the problem of, well, if you move and your point of attachment changes, we may have to tell a whole bunch of people. And that's going to take time. Well, we can take care of that, but there's another problem. If the host moves and his address no longer aggregates, is no location dependent with respect to where he is, we ought to be able, we ought to change of address. Now you can't do this with IP because of the way things work. But this actually turns out to be quite simple. First of all, how do we do this? Well, we assign a new synonym to the IPC process. Using the flow allocator, we notify all EFC flows that originate here of the change in source address, which we can do securely, tells the destinations of a new address. We stop advertising the old address as a route to this IPC process. We start advertising the new address via our router updates. And it just works. Slowly the old address dies out while other people are being notified via the router updates and everything just works. You want to renumber a network? Same procedure. We can renumber networks in seconds. We've done it. They had a demo like that running for over five or six years. There's a problem with the fact that things take time to update. And this is where the repeating layers can come in to save you. Basically what you can do, and I've got an extended example if we have time. Basically you can make the layers wide enough that the time to cross a layer is much greater than the time to update the layer about the existence of a new member. And so basically addresses may change frequently down here, but less frequently here and even less frequently here and may even just stay constant across the top. So this allows the whole thing to scale. And in fact the number of layers doesn't have to be constant. If I'm in an area where there's not much, I have very large areas at the bottom, very large cells. I can have fewer layers. If I'm in the middle of a city and I've got a high density of traffic and I need more layers, I have more layers. And notice that, you know, any box here only handles the same number of layers. There was an unexpected implication here. In the derivation of the IPC model, and this is another one of the things about the advantage of the theory I said. In the derivation of the IPC model, remember when we had in systems directly connected and I had to posit that finder so the application wouldn't have to figure out which type of network it was on. Well, it turns out, and it only took me two or three years to realize that it's actually maybe even longer, that the application, you know, should not see all the wires so a finder function was necessary. And we had this sort of thing. Well, if that works for wires, why wouldn't it work for networks? Right? If this is a network instead of a wire, there's one of these little guys at the end of all my layers, and we've subset it to be the ones that involve management because doing this is going to be required management. They are going to be able to see different layers that I see. Maybe they can find the application I'm looking for if it's not on any of my layers. And if that's the case, I ask around to see whether it is and if we find it and I don't have a layer in common, then we just create a layer over the top so they can talk. This has major implications. There's no global address space required. This is, you know, this is the network generator function and it caps the recursion. This was a completely, this was a completely complicated result. We had no idea it was going to be in there. So a global address space is unnecessary, but all applications could still be reached. Routing on the node reduces router table size by a factor of at least four or five. Router table size could be bounded by sizing the layer accordingly and having the number of layers you want. Flow allocation verifies the existence of the application and the other thing here, because the addresses are never seen outside the layer, all networks are private. Public networks are just more open private networks. Okay. This can have major effects. Most must be a member of a network to allocate a flow without management aware. And a layer is a secureable container. No firewalls are necessary. All members of a layer are authenticated within policy. None of the attacks on connection establishment work. No overloading of IDs. And it scales. I mean, to look at the security. Again, I put off doing looking at security for a long time. And if you remember when I flashed through the IPC model, I never mentioned security. And when I got to do thinking about it, I said, okay, well, what do we know? Well, first off, we know what I just said that the only thing that the user, the user of the layer knows is the destination application name. And his port ID is local port ID is a local ID. Okay. The layer ensures the source has access to the desk destination. That's part of it comes out of the IPC model. Once they're in communication, the applications must ensure that they are who they purport to be. So they authenticate each other. The members of the layer are all authenticated when they join. If you don't trust the layer below, which you shouldn't. SDU protection can protect from eavesdropping and integrity, et cetera. Basically. The only thing that a layer and Rita trust the layer below is to deliver something to someone. That's all. We don't care about anything else. It's protected. So the layer itself is a secure container. We did a little of our grad students for a master's thesis did a comparison of this, of this approach with the current internet approach and got to secure add security to the internet requires the left hand column in the AC model. You have the right hand column. Basically, you're just adding mechanisms for the, for the various, you know, for integrity, confidentiality, you know, et cetera, authentication. So how does it work?   These are the layers of the ISP I'm trying to draw here. And if you really think about it, this is what we do today, except we try and do it in one address space.  And then there was something that came about that I first thought of is just sort of, well, isn't this kind of cute? And I said, suppose the following. Suppose I have an ISP and he provides an electronic model for all of his users and they connect to it. And then he goes out to the half dozen, dozen, whatever it is, CDNs and data centers and forms contracts to provide their websites in his electronic mall. Okay. And that covers no 80, 85% of all the places that his customers want to go. If his customers want to go some, one of the 20 or 15%, then he simply creates one of these special layers across the top that I was describing earlier and they can talk to each other. Among other things, notice the implications for security. An attack has to come from either the customer's network, the ISP, one of the CDNs or data centers, or the special layer that I created. It can't come from anywhere else. And I have contractual relations with all of those things. I can nail track down and nail the guy who's doing it. Even if say my user gets infected somewhere else, unless the controller he's trying to communicate to is a member of one of these, these, he can't even report home. This has some really interesting implications. I call this the Wallace Garden, just to torque the net neutrality people. Also, one other thing about this, which is a slide I've left out, notice that it's up to you and your home network to join an electronic mall or an outside layer. And not only that, but you have a choice of joining. When you want to join, you can have your home network join, you can have your laptop join, or you can have your browser join. It's up to you. Okay. Now we've got talked about a little bit about congestion last time. As I said last time, the effectors of any congestion management strategy will deteriorate with increasing time to notify. So we use only congestion avoidance with ECON, limits the effects to a single layer, and can coordinate with quality of service policies. Right now we can't do that. Guarantee quality of service source to destination, implications of application layer naming, a flow can be allocated to a specific instance of destination application. Two applications using different protocols can allocate flows to the same instance of a destination application. We can't do that now. Actually, the whole reason that we have SIP is because we can't do this first one. We have known since the 80s that the most important property for effective management was commonality, commonality, commonality. So we can't do that. And not only does Rita do that, but it enables much more complex changes because we can choose the policies to be supporting rather than designing protocols that were sort of independently. And this meets or exceeds all the requirements for a future internet efforts. But it also begs the question. And it came up relatively soon after we started this. If a layer is a distributed application that does IPC, what's a distributed application? A layer is a specialization of a distributed application facility. We needed this for management as well, but we went back and did this. And so in analyzing the nature of layers, we realized that operating systems were recursive as well. When I said that layers repeated in networks, it appeared I was contradicting Dijkstra because he said that once you do a function in a layer, you don't have to repeat it. Well, actually we aren't contradicting Dijkstra. What we're saying is that once you do a function in a layer of a given scope, the function doesn't repeat in that scope. And I contend that in the given how tiny machines were in 1968, we just couldn't see the scope in operating systems. Virtualization is not actually recursion. Recursion is a little cleaner than virtualization. A process consists of the tasks, threads, the functions to manage its resources, scheduling to storage IPC. And a task is also a process. The lowest level process is usually called the kernel, the next level is the supervisor. And then the next thread management and heap management are just the OS for the process. And then you have the task to actually do the function. So basically what we're saying is that a process has a recursive structure consisting of task scheduling, memory management, inter-process communication to manage its tasks, which are then in turn processes. And so this whole thing can recurse as much as possible. And of course, an operating system, I have a whole another presentation I do called RIPVAN OS, where I came back to OSs after 30 years and everything had changed, but the implementations were still the same.  Today, that's not the case. Every peripheral has its own processor and is connected to the machine via a standard IPC mechanism. Okay. OSs seem to be moving in that direction, making, they're doing it at a glacial speed. As, you know, if you do this, then it's, you know, a minor step to go to this. And so what we end up with is that the RETA model is not just a layer for distributed, a layer is a distributed application that does IPC. In fact, the reference model is written that we describe a distributed application facility first. And then we describe a layer in a network as a specialization. That forces us to answer what is a distributed application. We're now working on a unified model for application processes, distributed applications, operating systems and networks. It's all one model. Transition? I don't believe in transition. I believe in adoption. You know, don't worry about transition. Transition will solve itself. We can operate RENA over, under, alongside, you know, the current internet. The old stuff is okay and the internet just leave it there. I mean, who cares? If you need security, much lower costs, advanced application capabilities, far less expensive mobility, use RENA. Operate RENA over, under, through, and probably start with, you know, private networks.


Well, well, well. What do we have here?  No? Yes? Well, either way, welcome. It can be difficult to discuss or even simply contemplate your sexual desires and fantasies. You may feel stressed or anxious thinking some of your sexual fantasies or thoughts are taboo or unusual, but odds are some of them may be more common than you think. And we're gonna dive deep into the most common sexual fantasies. Discussing them, that is, from a psychological standpoint. Why do people have sexual fantasies? What's the reason? You may remember that there's a few reasons if you watched the first part in our most common sexual fantasy series. In part one, we discussed the results of a survey of over 4,000 Americans in a Psychology Today article by psychologist Justin Lemiller. The most reported reasons for participants in the survey were simply to experience sexual arousal. While 69.8% of Americans reported they had sexual fantasies because they were curious about different sensations and sexual experiences. Following that, participants reported having these fantasies to meet unfulfilled sexual needs, escape reality for a while, or to express or fulfill a socially taboo sexual desire. See, lots of people have seemingly taboo sexual fantasies, which is why it's important to discuss this topic. According to an article from Insider, evidence suggests that those who have sexual fantasies experience less anxiety and a greater sense of self-esteem. So what are these seemingly taboo thoughts? Well, here are three more of the most common sexual fantasies. Homo eroticism and gender bending. According to Insider, gender bending is when a person challenges societal expectations of their gender. Anyone regardless of sexual orientation can participate in gender bending. For example, someone participating in a drag show might be participating in gender bending. Some may get the term gender bending confused with transgenderism, but they're different. According to Insider, transgenderism is when someone has a gender identity or gender expression that differs from their assigned sex at birth. But what about homo eroticism? A 2019 paper published in Social Forces suggested that 3.6% to 4.1% of men and 7.6% to 9.5% of women reported having a level of romantic or sexual attraction to the same sex.    It's quite common for heterosexual people to have this fantasy as well. An article from Insider explains that sexual desire is not an either or situation, nor does it define your sexual identity. For example, a heterosexual cisgender woman who is in a sexually fulfilling relationship with a cisgender man can still have fantasies about other women.  She explains to Insider that people might identify as straight, but they can have a little titillation about, you know, imagining or even engaging in same-sex sexual acts.  Occasionally, having that homosexual fantasy, I don't think it necessarily means anything about their identity in and of itself. Romance.  In the Miller's same survey, he found that 87% of gay and bisexual men and women, 88% of straight women, and 91% of straight men, fantasize about their current romantic partner. It's common for many people to fantasize about romantic sex. What that means is different for each person.  Tantric sex is often a slower sexual experience that focuses on connection and the feeling of the experience overall, not focusing on orgasm as the main goal. Healthline explains that when you practice tantra, you and your partner learn to be physically aware and spiritually present, feeding each other energy that continues to grow well after you've finished having sex. Healthline also adds that tantra also allows you both to explore and expand all aspects of your personalities so that you begin to truly know the other person inside and out. Variety and novelty sex. One bit of adventure. Some people may want to spice things up in the bedroom or out of it.  Okay, well maybe some of those will have to stay fantasies, but maybe just not in the bedroom this time. Do keep in mind, in the United States, public sex is illegal, so some locations may just very well be in your fantasies.  According to sex educator Cassandra Carrado with O-School, the feeling of facing the unknown and trying something for the first time can give you a thrilling adrenaline kick, and for some people arousal is connected to that feeling of adrenaline. So will you be mixing things up in or out of the bedroom? There's quite a lot of sexual fantasies out there, and these are just some of the most common ones. The most important thing to remember is that these sexual fantasies are often normal, and it's alright to fantasize and explore your sexual desires and interests. If you have a partner, it may also be a great idea to communicate your sexual fantasies to them. Why? It may just improve your sex life and relationship, according to a survey conducted by psychologist Ari Tuckman.  Tuckman adds that these couples are doing a lot of things well, which makes it easy to feel safe with the vulnerable intimacy involved in sharing their most secret desires. Do you think you'll share your secrets in the bedroom with your partner, or will your personal fantasies remain just that personal? Enjoyably so! We hope you enjoyed this video, and if you did, don't forget to click the like button and share it with a friend or partner. Subscribe to Psych2Go and hit the notification bell icon for more content like this. As always, thanks for watching!


Good morning guys, welcome to my summer morning routine This is just what I have been doing in the past few weeks or months. I actually really really love this morning routine I think it's my favorite one that I have done and kept up with It's not too intense and it just like puts me in a good mood in the morning Something I really really have been trying to do those staying off social media in the morning Which has been good when I actually do it. My face also gets like really puffy now So like when I wake up it is so Puffy, but I start up my morning by a nice long walk with the dogs I have to jump hot cats and it's just like a really good mood sometimes else in the music so when I wake up I just immediately put on like workout clothes because That makes me like actually work out in the morning too I Do it typically after I burst my teeth is I just put in an oil and then I massage my face out I don't know why I'm waiting on the name. It's really early. These two products are really been helping me I have the chill house Literally don't know why I can't remember the name of this so I do me and then I have the ordinary Squalene so this is just like a hydrating gel and it is so Good like $10 like we're doing there is so inexpensive. This is by far the playlist I think I've ever been like actually Like look at the difference already when I did two swipes because I hate my kids in my face with the dogs and I'm gonna have to tell anyways my life is over here not all but I slept on it so it so that's what happening So I immediately get dressed in what I'm going to wear to work out This really helps me in the morning and it gets me up also, of course, I dig my Instagram story photo You know, it's just it's fine. It's fine. Then I had on downstairs I am extremely affected by my environment, so I immediately open up all the blinds. I turn the lights on I normally play some music and I just make the house a good vibe for the morning Something else I've really been trying to do is starting my day off with an entire hydro flask before I drink like Coffee or whatever else. I definitely feel so much better whenever I'm drinking that much water Now time I just woke the dogs up. Are you guys excited? Are you ready?  Come here boy. Come here. Good morning Good morning kids. Let's get cocoa. Coco, come on Good girl. Good girl And then you're so cute.  So I think that might be what I do We're back in the walk. I Feed them immediately and then this is only one in front of you. Oh, I'm Yeah, and so it's just you know glam life of being a mom with her special food and her special men It's as truly acting as though. He's never seen food or water before Literally the most dramatic I've ever seen I have to feed them separately. So it's one look at his own food and I won't take your diamonds. You were such a good boy.  Okay? Currently back on my lemon water grind. It's the best way to start your morning. I'm actually dead Coco Just keeps putting herself away She's so funny. They're being created right now. Well Fitz is getting created and then Coco has to be obviously go along for the journey So what a good boy you are what a good boy you are normally Normally he has more stuff in his crate, but it's being washed right now. So Okay, so this is the part of the morning where I The part of the morning where I do my morning reading. I am a much better person when I do this I was like anywhere from like 10 minutes to like an hour and a half if I have the time And I go through every morning and we draw the circle for today for a challenge I know I've shown this everywhere, but it's literally the best evil ever It's just like a few quick pages of reading literally just like three and then all like journal read some more They kind of just depends on the day. I have you guys are more interested in like faith content for me You guys can join at the living room.  They can't believe it. This is so weird for me So this is my favorite part of the day like if I could do this 24-7 I think I would also back with my hot lemon water in the morning this seriously guys 10 out of 10 10 After I diva I'll normally clean up a little bit and also take the dogs out again and then play with them a ton They're being crate trained. So they're on a very strict schedule and then I will go work out So now I'm gonna do a little Melissa would help flow no part of me wants to work out So I'm gonna do just like a quick honestly like a 20-minute flow because that's the only thing I can get myself to do right now My workout. I'm actually going upstairs Quickly shower and then start getting ready for the day getting myself to do that workout was very difficult not gonna lie I've definitely not been like working out like crazy as of lately. I've been really kind of off my game and just doing like Maybe a 30-minute workout from home. I think I'm getting a treadmill tonight though So hopefully that happens now is about the time that I go and I get ready for my day So I think I'm actually gonna like wear a kid outfit today Summer sunscreen and then bronzer blush highlight pretty much Say no to mascara everyone I just hate putting on mascara and I actually kind of like this look I'm it being a little bit more just like natural and doing and whatever with no mascara But I am changing my earrings into my bigger Jennifer Fisher hoops and then my Dyson Aerox is actually my other bathroom So I'm not gonna do my hair in there and then call it a day I feel like I'm wasting this outfit because it's such a good outfit also question of the video How am I supposed to do this? Seriously? What time do you guys wake up in the summer and? Where are you watching this video from also? Are you in school because I'm really curious? I'm already an online student, but I'm just really curious to see I mean only one semester left Whoo, but I'm just curious to hear like what your schools are doing and stuff with coven Cute. I'm a cute jewelry. Okay. This is like my new favorite outfit too Okay, so I did the absolute bare minimum like I didn't actually get myself a plot I just kind of wanted to just go through it really quickly Definitely not great, but it's like slightly better than it was, you know, so my outfit for today It's this cute revolves that I just got I'm obsessed with it And I feel like I'm wasting it because this is one of those outfits that you lay Remember Liz McGuire and after repeating on a meme. So anyways, it's so cute. It's from song style I'll link it down below. I'm obsessed. It's like too long on me I have my slippers on guys. We're working from home. Okay But it is just literally the most comfortable thing. It feels like you're wearing pajamas, but it's so cute So that is what I'm wearing today. So now that I am ready for the day. It is currently at 9.15 I'm feeling really great.  I'll show you guys when I make for breakfast what I've been making my coffee It's normally just black.   Is so beautiful I'm just going to sit here.  Hope you guys enjoyed today's video, and I will see you soon. Bye


Hi, I'm so glad people came. I wasn't sure if anyone would actually care about this, so I'm glad you did. I actually went to college in Portland. Did anyone else are reading in here? I know Gabrielle is. We got it. Yeah, all right. So, so cool. So it's awesome to be back here. And I teach digital humanities at UCLA and I wasn't sure coming in if people would actually know what that is or not. Does anyone, like, who knows what that is? Maybe, sort of. Okay, cool. Well, the fact is, like, if you don't know what it is, you're in good company. A lot of people don't know what it is and there's even a website called, like, whatisdigitalhumanities.com, I think, and every time you refresh it, you get a different definition. It's very frustrating. I like to say it's the use of digital tools to explore humanities questions. And I always say explore and not answer because, as you probably know, the humanities isn't really about definitive answers to questions. Like, you can't just be like, there's one interpretation of Jane Eyre or one interpretation of, like, medieval art. You're always kind of gesturing toward interpretation rather than coming to distinct conclusions. And because of that, we have some particular needs and difficulties in our field. That I was hoping might be interesting to you. I was hoping they might be interesting enough to even get you to, like, think about working on some projects or tools or talking to us about getting involved because, as you'll see in a minute, we have some needs. So why study data in the humanities classroom? As you know, we probably have some humanities majors in here. The humanities, you know, is about interpretation, close reading, you know, we love paradox and changing the terms of the debate. That's kind of our thing. And that's not necessarily something one associates with data, except that, as you know, like, the entire cultural record is slowly or quickly becoming digitized. And it's become important, I think, to help students and other people who think about the humanities to not cede all of that digitized cultural record to people who are not trained in the humanities. So we've been, oops, excuse me, we've been at UCLA really working hard on helping students to think about data as a representation of one view of reality. So developing some fluency and literacy with data, but also understanding it in context, and that's certainly not the only way to think about the world. Right now, we have about 70 students in our DH minor, and we're growing pretty fast. We've only been around for about five years. And I think DH programs are popping up all over the world. I mean, certainly in the United States, I think they probably number in the hundreds, at least. So it's really a growing field. At UCLA, we're on the quarter system, which is 10 weeks. So in our intro class, which I usually teach, we have 10 weeks to get students up to speed very, very quickly. And our students are really lovely, but they tend not to come in with a ton of data literacy or indeed technical literacy. The typical DH minor is an undergrad non-STEM major. Their experience with technology is usually limited to like Microsoft Office, you know, Word, PowerPoint, and maybe Excel. Maybe Photoshop or the Adobe Creative Suite. And we have 10 weeks in the quarter system to get from like an absolute zero to data literacy, while also trying to incorporate a lot of theoretical reading and discussion about like what the humanities are, what data is, et cetera, et cetera. So to try to get them there, you know, we want to teach them how to work with data in a basic way, but we also want them to be able to put a data set into context with a lot of critical reading and research, because otherwise, you know, a data set visualized on its own doesn't really mean anything. So it's like if you're working with data about comic book characters, which is one data set we've used in the past, and you're trying to visualize genders of comic book characters, we want you reading all the critical secondary literature on like gender and comic books and narrative art in addition to doing that database and statistical work. And so the assignment that we use in my DH 101 class is to, everyone kind of adopts a data set, like in sitcoms, you know, people will have to adopt a bag of flour and treat it as their baby for a few weeks, and it's kind of like that, but with a data set for groups of students, it's kind of their baby for the quarter, and they have to get from zero to being able to visualize it, map it, write a narrative about it, and then put the whole thing on a website.  And I've noticed, I wanted to share with you some features of the kinds of data sets that my students can work with versus the ones they can't work with. These might be surprising to you because you're used to working with people who have some data literacy, but I've noticed some very specific things about data my students can work with. So first of all, they need some context to the data set, they need some background about where it came from, how it was recorded, so not just stuff about what kinds of characters are in a field, but actually where did that field come from. They need some kind of model, like it was really helpful for them when they were doing visualization of a data set about comic book characters to see 538s work on those characters. My students can't work with APIs. I know we all love APIs and things like that, but they're not out of place yet where they can do that. I mean, I can do it at the beginning of the quarter and get the data for them and prepare it, but the less I have to do it in advance, the better. If I don't have to learn someone's API, then I'm a lot happier. So in keeping with the title of this conference, they love CSVs, they can't work with XML or JSON or turtle or anything like that. They need to be able to double click the thing and open it in Excel, because they want to see the structure of the data set, and they want to be able to drop it into something like Tableau and just immediately visualize it. And the ideal size for my group is like 2,000 records, because it's too big for them to individually change every record, but not so big it'll crash Excel. So these are hard-learned lessons that I've picked up over the years of teaching beginners, and I was hoping maybe people would find this compelling enough to think about creating training data sets when they're building out larger APIs and link data and stuff. That is awesome and wonderful, but also maybe think about smaller training data sets for students who are getting started, because the good news is they become very fluent very quickly, they learn so fast it's scary, and they'll learn your API and they'll learn about Sparkle queries and they'll learn about all that stuff, but they need to practice with something a little bit more manageable. I don't know how interesting this is to you. This is the suite of tools that we tend to use in my class. Maybe these are familiar. Databasic is a wonderful teaching tool for students. You can drop a CSV in and it'll tell you what each of the fields are. Open Refine for cleaning, Cardo for mapping, although I'm mad about their new interface. RAW is like a really nice data visualization package, Tableau, Side Escape, Fusion Tables, WordPress, P5.js, which I just wanted to flag as something that we're more and more interested in using for each student. Does anyone know P5? Do you want to explain what it is? That's the processing port to Java Scripts. Lots of creativity is used as an easy way to do visual design. Students come in learning P5 already. What's great about P5 is that as opposed to D3, which I also love and use a lot, P5 takes as your primitive, not a bar chart or a scatter plot, but a circle or a square. If you're interested in doing some experimental visualization, you can have a circle bounce against a square every time a female comes up in your gender. I'll explain why that's interesting to us in a minute. Maybe not immediately compelling. I wanted to give you a quick look at some of the work my students do after a quarter. Oh, I can't because it's down. Perhaps I'll share this out on my Twitter feed in a moment, but I did want to say they get pretty far. You'd be surprised. In 10 weeks, they get pretty far. This was using a dataset about all the performances from the New York Philharmonic, which I think Dan Fowler shared with me initially. They were able to show the influence of German composers in the early years of the New York Phil, which was pretty good work for a bunch of undergrads. I wanted to talk about this tool wish list that we have in the humanities that has to do with our specific way of looking at the world. I don't think I can play this for you because my Wi-Fi connection is down, but maybe you've seen this map of slave ships that was in slate. It was drawn from the voyages database of the travels of vessels carrying enslaved people. It's a really, really powerful visualization. You can see the ships traveling over time. You can slide back and forth. I wanted to emphasize it not because it's an inherently powerful visualization, which it is, but it also shows something that a lot of people in the humanities are trying to do all the time and really having a hard time with, which is showing time, space, and movement all at the same time. Everybody thinks there's some tool you can just drop a data set in where you have a scrubber and you can move it back and forth and see how people migrated or see how an object traveled. It's the most common request I get and one of the hardest to fulfill. For some reason, I don't know. It's interesting to think about why that's so important to humanists. It's hard for us to do it without custom programming. I think that humanists think about uncertainty in a way that's a little different from statisticians in the sense that the techniques I've seen in statistics for visualizing uncertainty depend on quantifying either a margin of error or a degree of uncertainty. But for us, uncertainty is more about epistemological uncertainty or ontological uncertainty. This is a pretty standard network visualization of some data we gathered about the early race film industry. It's fine. It's all the people involved in the industry and they're connected via the films they worked on together. But I think what was really interesting to us in this project was trying to figure out what a race film was because any individual criterion for a race film like directed by a black director or contains an all black cast, any individual criterion will fail because the race film industry was a community of practice. It wasn't like a binary category that a film could sit in. We were really interested in showing some of these films were really race films and some of them were kind of not race films. And we didn't really have a good technique in our repertoire for showing that kind of strangeness and fuzziness in our data. So we love thinking about fuzziness and strangeness and how to depict that. We're also always interested in multi-perspectivality. I wanted to show this map because in a way it's pretty straightforward. It's a map of Harlem in the 1920s and you can pull down a menu and map these different events. But what's striking about this map to people who spend time with it is that you realize looking at the categories that this isn't Harlem for people who lived there in the 20s. This is Harlem for the police who were surveilling Harlem like assault, domestic assault on police, automobile crash. Right now, so right now there's one map of Harlem but wouldn't it be cool if you could flip it so then it was from someone else's perspective? This is the police view of Harlem. Well, what did Harlem look like to someone who actually lived there? It's cool to think about. We don't really have a way of doing it. So Lauren, McCarthy and I, the one who developed the JavaScript port for P5 have just convened a series of workshops where we're kind of working through some of these issues. It's called Scopelab. It's a feminist data workshop that really thinks about uncertainty and contingency really seriously. So we're working on it. We're hoping maybe you'll think about working on it too. Talk to me about working on it. And I think that's it. Thank you. So I think I made it through. I'll go back to the previous slide so I can get that address. Yeah. I have a point. I see that you use cytoscape. These were a particular reason. Because when I tried to use it, I was very frustrated. So I'm surprised with the adoption. It kind of has, yeah, in DH. What do you use? For graphs. I use R most of the time. Yeah. And it's frustrating because I don't know. Yeah. The root of networks and traditional networks is always very cool. Yeah. That's a really good question. So we do tend to use cytoscape. I know Thomas and I both use cytoscape like when we're doing network graphs. Only because Gaffey stopped working more or less. And so we switched to cytoscape which is fine. We sometimes use Palladio which is another kind of web-based interface for doing network graphs. What I found about network graphs in the humanities is that humanists sometimes are interested in traditional measures of networks like various kinds of centrality and stuff. But more often they're just wanting to see connections. So it would be nice if there was like a beginner level network graph tool that could handle a lot of different nodes. But didn't have all the bells and whistles that like cytoscape or Gaffey has. Yeah. I say using like a lot of tools. I've thought about this problem quite a bit. Oh cool. I was wondering if you tried to put an on focus. Just because of the idea of like teaching people who don't know much about code one single environment. Because I love the web on the JavaScript program as well. But you have a lot of levels of abstraction and complexity to deal with web technologies. That's curious. I think from zero of the digital industry with so many things to learn. It's really true. Like what you say that we're kind of immediately moving them away from actually dealing with like whatever the data is at its most basic level. By asking them to like visualize it immediately. And I do know people who take that approach where they don't you know they start very granular with like what is data. Like what's the difference between a document and like an individual record. I find this. I don't know if this is true or not. I guess my my suspicion is that my students want to see things right away. Like they want to know what they're dealing with right away so that quicker we can get to visualization. The more comfortable they are. But I also see some very compelling reasons to get them programming with Python quickly. Yeah every year I'm like I'm going to teach this class differently. Next year for sure. Yeah please. That is that is so true. I mean that's kind of one of the most satisfying things to me is seeing the students having those conversations. And actually I find that happens most often when they're cleaning the data. So that's why I love teaching them open refine because they have to make these decisions about OK well you know like we have too many fields here which ones are we going to get rid of. And like oh well if we get rid of like you know this element then we won't be able to track it. Or like if OK if we clean up this language and standardize the vocabulary we're losing this nuance. And so they really see it very directly when they're trying to like aggregate terms and open refine. And sometimes they get it and sometimes they just don't want any part of it. They're like you know I don't want that you know like there's a field it's called statistics it's fine. Like don't make me you know talk about theory in the humanities at all. Yeah. Good idea. You're really walking through part of what you think is kind of problematic about the API access in the context of the concept. Maybe the scope of the data set. But I'm curious if you can comment on any sort of contextual information around the data set like features of the description of the data in terms of quality of provenance enhancements that have been made to the data that are that you've seen or that you think might be helpful or. Yeah. I mean actually it's kind of not what you might expect. Like I know data people are always very interested in tracking provenance and tracking like changes made to the data set over time. And they're not kind of there yet. They're not thinking about data in that way yet. What they find most helpful is actually talking to the person who if they're if paper records exist like taking the paper records and entering them into some kind of structured form because they don't understand how data gets from like out in the world to like structured data they can work with. So they really like to like see you know for example take the New York Phil collection they like to see the document that like described these performances and then how someone transposed those messy categories onto a spreadsheet or whatever. Yes I'm glad you asked that because it's such a good point. I subscribe to that newsletter too and love it. I find that like students I mean my humanities students like it's not that you couldn't make a humanities argument out of like municipal water records but they're not at a place where they can see that yet. So they need like traditional cultural artifacts like the you know like the Philharmonic's performance or like you know costume design over the years. Things like that where they can have an easier time seeing how to make an argument that speaks to the humanities about it and finding those data sets is just awful. Like if anyone here has tried to do it they can back me up. There's just like a grapevine where we all tell each other about these things like Dan told me about the New York Phil thing. You know 538 will sometimes put out an interesting data set. So those of us who do this kind of work have been talking for years about like aggregating it somewhere. Well one could imagine a different data set pretty easily although I don't know that it exists like understanding the neighborhood. I guess and one could also imagine just like switching to a different data set via this menu. I think what would be more kind of interesting and challenging would be seeing features on the map actually change as they reflect the way in which people perceive them. Like this Cartesian map really reflects like an authoritative view of the way space works. Whereas if someone's actually navigating their neighborhood wouldn't it be cool if you could like different features would change in size and shape as they took on a different importance to a person who lived there. Like maybe the church would be really big. I know it's not statistically accurate but sometimes to the humanities like that's not as important. Yeah I think we need to wrap up.


Getting Jared Vanderbilt, Malik Beasley, D'Angelo Russell, Mo Bamba at the trade deadline. You see what the Lakers path that they charted was. We're going to try to be more like that 2020 team that won the championship and a little bit less like that star driven team that they had the last couple of years with Russell Westbrook. Rob Polinka goes in and in that front office, they go get all these role players. And Jared Vanderbilt was big time last night guarding Luca Dante. You see a Lakers team now that's starting to find its groove and Anthony Davis bigger than anything. The way he's played down the stretch, his jump shot looks right again. He's playing at a very, very high level and that's a good sign for the Lakers.