 OK. So today's your mystery bonus lecture. What are we going to talk about? So I thought we'd go back and talk about virtualization again today a little bit. And this paper is about smartphones, which I like. But the technique that we're going to describe today is something that's a little bit different. So this is a third form of virtualization. We talked about full hardware virtualization. We talked about where we were going to actually try to faithfully execute an entire OS kernel directly on hardware inside a virtual machine. We talked about pair virtualization. We were going to trade off some small modifications to the kernel in order for much improved performance by modifying the kernel to interact with a hypervisor, which controls the VM state and makes it more efficient to do certain operations that might otherwise pierce the VM. Today we're going to talk about something called container virtualization. So this is kind of hot right now. Does anyone know why? You guys might have used container virtualization recently or heard about a company that's using container virtualization. Yeah? Portability? Yeah, but there's one word where if you say this word, people will get it. What's that? Docker. Nope. Docker. Who's heard of docker? OK, so docker is the Darling in Silicon Valley right now. What docker is doing, essentially, is exploiting an old technique that allows you to do what's called container virtualization. So this is also known as OS virtualization. So this is interesting. Has anyone ever set up a docker instance before? Have anyone ever used docker for anything? Does anyone know what docker is for? Since they're, you guys haven't gone to their web page, checked it out. So you actually use something that's hosted on docker. The discourse forum that we set up for you guys to use this semester runs inside a docker container. So what does that mean? It means that when I want to set that up, I get this docker container, which is kind of one single thing, and I run a command that starts that docker container. And then that container runs happily inside my existing operating system. Now, to run a site like Discourse, there's a bunch of things that have to run. Like what are some of the applications that would be required to support a forum like Discourse? And clearly, I need a web server. I need a database. That's where the information is stored. What else? What's that? Yeah, there's something else, though. I mean that Discourse and most other, you need more than a web server. You need something else. So that's why actually we're not using the back and forth. But that could be done by the web server. I mean when you run code in a web server today, you usually just don't run a web server that serves static content. What else do you need? Yeah. What's that? Yeah, yeah. So you need something to interpret the web script in language. So Discourse is written in Ruby, so it uses something called Passenger, which I've never heard about, that I guess runs Ruby on Rails. What else? What else might you want running in there? Discourse, has Discourse ever contacted you? Has it sent you something? How did it do that? Magic. Email. So there might be an email server in there. There might be a, I know, I think Discourse uses Redis, which is like a queue, sort of a caching in a queue management system. So this is sort of the reality of modern day computing, which is if you want to set up something, like before, if you wanted to install Discourse, you'd have to install all of these software packages. So you'd have to find a machine. You'd have to download Nginx. You'd have to download Passenger. You'd have to download these things, set them all up, try to configure them properly so they all run together. And when you were done, you would have this machine. And what container virtualization laws do, now to some degree, what else could Docker have done? What would be another way for Docker to package, sorry, Discourse, to package all of this software together? What would be, based on the things that we've talked about in class, what would be another way that they could have done this? What's that? What's that? How do they distribute it? Well, but they could have distributed how. I mean, it's one of the, there was just a use case for one of the things we've talked about previously in this semester. I have a whole bunch of software that I want to bundle up and package together into one, into one. Multiplication. Well, Son and Ed, this is multiple applications. That's what's so hard about it, right? Yeah. Yeah, like a virtual appliance or a virtual machine. I could bundle this all up and you could run it inside, like you create a virtual machine for it and you could load it into a virtual box virtual machine or something else. So that's another way of doing this. Container virtualization has some advantages. It's a little bit easier to set up. It exploits features that are already built into Linux. And so that's what we're gonna talk about today. So this is virtualization of a very different kind. It's pretty interesting. This particular paper that we're gonna discuss in the context of applies it to a very specific problem. Okay, so just a few brief announcements. I don't know what's wrong this year. Is it the lack of piazza? Is that what's killing you guys? Like, I don't understand. Just do the course evaluations. Do you want questions from the final exam or not? Okay, I guess not because you're at 54%. So I want you to do the evaluation. You want to do the evaluation. Why can't we get together on this? Yeah. That's okay. I mean, everyone should be reading the discourse forum. I can send a mass email, but I don't know. Is that gonna work? Every time I do that, people are like, stop sending me so much email. I get like one email a week from the department. I can't figure out what to do. Read it, delete it, whatever you want. Okay. As opposed to the emails, which you read carefully. End to end. All right, I'll make sure Donna sends it out as a really ugly forward. Because I know that's what you guys like. Okay, please, yeah. I mean, find someone who's not here in class and make friends with them quickly in the next few days and then convince them to do the evaluation. I mean, that's another strategy. On Wednesday, we're not gonna have class. Please go to see the talk by Bob Horowitz, Eric Horowitz. Shit, I think I got his name wrong. Anyway, whatever, someone Horowitz, famous person that overlaps with class. So please go see that. How many of you will have tickets for that? Okay, good, a couple of you. The rest of you, maybe there's still tickets off. I don't know, I'm going, I think it'll be cool. And then we're not gonna do a Friday 8am recitation because Ali was there last week and no one else was. And Friday morning at 8am is a very lonely place to be if there's no one to talk operating systems with. So we're just not doing it this week. On Friday in class, we'll do exam review. Okay. So, you guys didn't read the papers. I'll just tell you what kind of paper this is. So this is, people applying an old idea to a new problem. And there's some hard work they have to do and we'll talk about what that is. But the old idea here is OS virtualization. So OS virtualization in some form or another has been around for a long time. Can I virtualize that fan and make it shut off? Yeah, that sounds bad. Say goodbye, that's it. We can order you a new laptop right live in class. All right, so OS virtualization, right? Then this is, and again, this is different. And it's kind of cool, it's a different take on virtualization for what we talked about already. The new application here are smartphones. And to some degree, some of the complications they had to go through are unique to the smartphone environment have to do with smartphone use of devices. So we'll come back and talk about that. But a lot of these ideas are sort of have been swirling around. And they put them all together and got this to work on smartphone platform. All right, so OS or container virtualization on Linux, which is the operating system that runs underneath the Android platform, allows them to do the following. It allows them to create what are called multiple virtual phones. And I'll have a YouTube video, which if I'm desperate for time, I'll show at the end. But essentially the interface to this becomes you have your single phone and by swiping in some weird way, you can now switch between multiple virtual phones. So you can have like four virtual phones running on top of this one single physical phone. Why would you want to do this? Well, first of all, I mean, here's what a virtual phone is. Each virtual phone runs Android. So they're all Android phones. They can make phone calls. They can run unmodified Android applications. They can use data collections. They can do pretty much anything that a normal phone would do. They interact with the touchscreen, except each virtual phone is completely and totally isolated from other virtual phones on the device. Essentially, it's like it's, this is kind of the equivalent of a virtual machine. It's like those other virtual phones don't even exist. I can't see what's running. I can't tamper with them. I can't access any of the private state that they might have, okay? So here's a sort of a picture of this architecture. They, so here's one virtual phone and that virtual phone describes this entire name space. And again, if there's an app running inside that virtual phone, it has no contact whatsoever with apps running on the virtual phones. They also have this special root name space, user space that they set up that handles certain interaction with hardware devices. We'll come back to that in a sec, okay? Yeah? Nope, nope. You can't do that, right? I mean, that would leak information between the virtual phones, right? So the idea here is that apps on one virtual phone are totally isolated from the other apps. Now, to some degree, for example, if you were using a message-oriented app and you had both phones registered under the same name and they were synchronized in that way, sure. But the two phones, the two message-oriented apps would be, they would think that they were different. So the only way that they would find out was maybe they would get a message over the network that said, oh, you know, like if you guys do this on Hangouts and stuff like that, it synchronizes all of your devices, whatever. So that's what it would look like. It would look like two separate devices. Does that make sense? I'll look at you, we're using two separate phones. So, and this is, now the interesting thing about this is they don't do this using the virtualization techniques that we've already talked about. But first of all, what are use cases for this? Why would I do this? This seems sort of weird. How many people carry around two devices, two phones? Why? They use one for debugging. Okay, so that's a use case, right? This is a very much like I'm a CS developer and so not representative of the general population use case. But yeah, like sometimes people will use a phone for debugging. If my app crashes on that phone, it's okay. Developers are using this phone to beta test or alpha test, various things. Okay, so that's an interesting use case. What else? Yeah. Yeah, so the math, I hope. Now I'm sure there's some people out here that just like to have lots of phones because it's fun or interesting or something. Maybe you can use one with each hand, I don't know. But I suspect a lot of people, at least a little while ago, who had multiple phones had two because they had one that was for work. Why would work want you to have a whole separate phone? I wouldn't make sense for certain companies to give you a whole device. Why would they want that? Yeah. It's secure, okay, why is it secure? The answer is correct, but what's secure about it? What is it secure from? Okay, that's true, right? That's true, right? But I would argue if you're gonna fat finger your address book, you could also pick up the wrong phone if you're gonna send some, I don't know, what you're going to send. Yeah, so it might cut down on the number of mistakes, but from the perspective of an employer, like what would they be worried about? Yeah, Matt. So that's a good point. I might want to mentally separate out things. So when I get a call on my work phone, it's a work call. When I was growing up, my mom worked from home and she had a dedicated work phone. And when that phone rang, she screamed at everybody to shut up, you know, because I've got a work call. So that was like the protocol was everyone had to be silent when that phone rang because she was working from home and she wanted it to feel like a professional setting. So okay, you might want that, what else though? Why would employers want this? Yeah. Okay, yeah, you might want to, so I might not feel like it's appropriate to, you know, for my employer to be paying for my personal calls or for my personal, my employer not to be paying for my, like what if I don't want all the extra usage that I accrue on my personal device? I want that to be built to my employer because it's work related, okay? What other security things, right? So these are all good reasons. What about security issues? What are security concerns? What do people tend to do with their personal phone? Yeah, okay, so the work phone might have constraints about how it's used. I mean, in general, the work phone allows the employer to really control that environment. So for example, I might not be allowed to install software on the work phone. It's totally locked down. That prevents me from installing some sort of malicious app that might steal information from the apps that run on the work phone, right? Like this is, you know, Android's a new platform. iOS is new platform. I'm sure there's cases where there's been information leaked between apps. And if I want to attack a company, I might try to get onto somebody's phone. So, okay, so fast forward to now, what do, so I think there was a period of time where companies seemed very enthusiastic about buying phones and buying service for their employees. Now they don't do that anymore. What do they do instead? There's this phrase in the business world now. B-Y-O-D, what does that mean? Yeah. Bring your own device. So now they want to use your phone. You know, they've had enough of this, you know, I'm penned paid for someone else's phone service. So now they want to run this directly on your phone. So this technique might be a cool way of doing it. You know, imagine I have two virtual phones on my phone. I have a personal one and a work one. And you know, I can have, you know, it provides a lot of isolation between the two and to some degree it provides some of the mental isolation that I want to where when I'm on the work phone I have a certain background set up. The employer might completely control that software environment to make sure that nothing bad happens, okay? So there's some, you know, use cases for this, right? Security, and then to some degree encapsulation. The work and, you know, my work, my employer might want to completely control that environment. So they control all the software running and they think it's secure, who knows. So why not use the existing virtualization solution? So here is their argument, right? This is back in 2011. You know, we can debate whether or not this is still true. So while VMs are useful for desktop and server computers applying these hardware virtual techniques to smartphones has two drawbacks. Smartphones are more resource constrained and running an entire additional operating system, OS and user space environment in a VM imposes high overhead and limits the number of instances that can run. Slow, so some responsiveness is less acceptable on a smartphone than on a desktop computer since smartphones are often used for just a few minutes or even seconds at a time. Does this make sense? When I run two virtual machines, let's say I run two Ubuntu virtual machines on the same server, I've got two complete copies of the operating system loaded. And there is an enormous amount of duplicated code and other things in those two virtual machines. So bringing the virtualization level all the way down to hardware means that it includes a lot of other crap, like the operating system, all the device drivers. And if I can build a virtualization solution on top of the operating system interface, which is what I'm gonna do here, I can have one OS and that can potentially use fewer resources. I don't know about the lots of VMs thing. I don't think people are gonna have like 30 virtual phones. That seems weird, right? But whatever, okay. The second reason is that there are these devices that applications want to use. And these, so these existing approaches don't provide good ways of sharing these devices effectively between multiple virtual machines. And this is something that they spend a lot of time on in the paper. Because if I want to run two instances of a pedometer app, maybe my employer makes me run one because they want me to be fit and then I want to run another because I want to make sure my employer is not lying about how fit I am. I want to make sure those both have access to the accelerometer independently from each other. Okay. Does this make sense? Any questions about this? So this is the goal. The goal is to be able to create these virtual phones without doing full hardware virtualization or pair virtualization. No, so what's required for this to work? So when we talked about virtualization, we already noted that for hardware virtualization, I have to have identical, the identical ABI. I need to be using the same binary interface. So I can't do hardware virtualization for an ARM target on top of X86. For container virtualization, what's required? And go back to this slide. What do the two virtual phones have to agree on? What do they share? They're both running on top of what? I know it's like turn, right? Yeah, they're running on top of Linux and the identical Linux kernel version. So here I brought the interface level up, but now what happens is the two containers or two virtual phones have to be sort of built and ready to use the identical version of Linux. The shared API here is not the hardware API. It's actually the operating system, system call interface. Now here's what's interesting. So at this level, what do we have to virtualize? So for hardware virtualization, the goal was that we would virtualize the hardware interface. And what that meant was certain operations that were performed inside the VM were invisible outside of the VM. Operations that would normally modify hardware state, part of the virtual machine, the requirements of being a virtual machine was making sure those didn't actually change the hardware state for applications running outside of the VM or in other VMs. So in this case, so in this case, the OS interface is shared. So what is virtualized? It's kind of interesting. So again, all you can think of these as the virtual phones here as separate applications almost. Everything, all the apps that run inside these virtual phones are making calls through the same OS interface. That's the standard system call interface that you guys are familiar with. What do I have to virtualize in order to isolate apps in multiple virtual phones? Yeah, not quite. Okay, I mean I need to virtualize aspects of the user program interaction. So let me put it this way. Give me an example of an operation at the system call interface that could potentially pierce the virtual phone. Give me an example of something that one app and one virtual phone could do using the system call interface that would normally be visible to other apps but cannot be visible to other apps in the other virtual phone. What's one example of that? Normally in an operating system there's lots of things that apps can do that are visible by other applications. In this case, we need to start cutting down on those things. So what's one example, right? You can do it with the phone call. Okay, so we definitely need to make sure that incoming phone calls to the device end up in the right place. This turns out to be uglier than some of the other aspects of this. We'll come back to this later. This has to do with limitations of the underlying hardware that even these guys can't work around. Give me an example of something I can do with the OS interface that should not be visible. Yeah. Yeah, how about open with the create file? Like create a file. If I create a file in one virtual phone, that file and its contents cannot be visible in the other virtual phone. So that's kind of interesting. Where, who should be able to see those files contents? Yeah, other apps potentially inside that same virtual phone assuming they have the right permissions, blah, blah, blah, blah. Okay, so that's interesting. So there's something interesting going on at the file system namespace. What else? There are some other things. What other aspects of the overall system behavior might I normally be able to observe that I cannot now observe? And if you've ever used Docker, you've observed this. Because when you outside of the Docker container, there's certain things that you don't see. What's another example of something like this? Another example of something I can do with the system call layer that I need to make sure that it's not visible in the other virtual phone. Well, you guys know about a dozen system calls. You just guess at random, yeah. Well, okay, but that's normal, right? So remember, that's a normal feature for isolating memory between apps. Normally, app memory is private, so that's okay. Now, you're right if two apps want to share memory through something like, you know, by setting up a shared memory region, I have to make sure that they're isolated from each other, which points to another interesting place where I need to make sure that there's some division here. What's that? Fork. If a process in one of the virtual phones forks, that process and its child cannot be visible in the other virtual phone. So there's another namespace here, which is the process namespace. If I do like PS in virtual phone one, I should not see any of the processes running in virtual phone two. Same thing the other way, okay? So we got a couple of these. And what we're really doing here, which is really interesting, is we're virtualizing the OS namespace. So all these names and meaningful numbers that applications use to access system resources, we need to make sure that those are tagged with the virtual phone that they originate from and don't mix with the other virtual phone. Does that make sense? We'll talk about some examples here, right? So the file system namespace. This is super important because this normally leaks a lot of information between apps. Now, I sort of protect this information locally inside each virtual phone using the standard permission mechanism and things like this, but across virtual phones, there's just nothing. If a process in one virtual phone creates a file or modifies a file, the namespace has to be completely distinct. So I can have two files with the same name in the different virtual phones that have completely different contents. That's required to make sure that these are totally distinct. The process namespace, same thing here. So really here we're talking about the stuff that I would be able to get through PS, the PROC file system, all those numbers. The process communication between processes and the ability of processes to contact each other to establish IPC has to be stopped at the boundary between the virtual phones. Same thing with the network namespace. The two virtual phones have to be able to have different IP addresses, different services running on the same port. So I should be able to have two web servers, for some reason, if I was running a web server on my phone, but certainly you would do this inside Docker, a web server running inside the container and a web server running outside the container. And those web servers have to kind of, I need to be able to have a way to set up different IP addresses and port mappings for those two virtual phones, as if they were separate devices or separate machines. And then the device namespace. So this is where things get pretty tricky on phones in particular. So Linux does something interesting with devices, which is that it exposes devices like files. Has anyone ever poked around in dev and your system? So there's this directory called dev. Inside dev are devices that Linux is exposing as files. Those devices have file-like interfaces and things like file systems use those devices to actually communicate with real hardware devices that are exposed in that particular way. So like disks are a great example. When you mount a drive or a part of a drive in Linux, you have to give the path to the device that represents that. And so this is another place that I, we need to be very careful with OS virtualization because if there is unintentional sharing at the device level, I can do things that can get around some of the other things that I'm doing above like the file system namespace and access parts of the system and I'm not supposed to. All right. So here, these are basically these four techniques put in the words of the paper. We use four techniques to isolate VPs from one another and the root namespace. So, oh I forgot something, user credentials. Same thing with users. I need to be able to create identical users in each virtual phone and assign them with different permissions, assign them to different groups. The user namespaces have to be totally distinct from each other and that's important so that I can do permissions and lots of other things. So user namespaces is number one, kernel level device namespaces, so that's dev slash and I need to make sure that that information is isolated between virtual phones. Mount namespaces, so this is once I actually get a file system mounted. I need to be able to have the same, I need to be able to have two virtual phones, both have to be able to have a root mount point and those root mount points have to be totally distinct from each other. So they have to not only use different parts of the disk but they have to have namespaces that are completely, completely separate. And then they do something interesting here to help secure the device namespace and I don't know, hopefully you guys have never done this because this is like a level of Linux hackery that means that something is going terribly wrong in your life but you can create device nodes manually inside Linux and configure them by sort of by hand and they prevent, in order to secure the virtual phone, they prevent you from doing this because this is a capability that if the virtual phone had it, it could use this to access parts of the disk, for example, that it's not supposed to be able to see. Parts of the disk that might be serving as the root mount point for a different virtual phone. Questions up to this point, does this make sense? So I'm providing the same file system API. The file system API is identical. Sorry, the kernel API is identical. What I'm doing is I'm making sure the names diverge. So a name in one virtual phone is distinct from a name in the other virtual phone and there's several different namespaces I have to deal with here. So three out of these four problems had already been really solved and rolled out in other previous solutions and that's really all of the other namespace stuff except for the devices. So the device namespace was not handled particularly well and this is what they wanted to get right because, so for example, what would be a simple if not very good way to, so what do I do, how do I provide two different separate root mount points to different virtual phones on top of a single disk? How does that work? You guys know how this works, you might have done this before without even thinking about it, how do I do it? Yeah, it's actually, it's almost like creating two different partitions, okay? Now I might use a namespace mapping to make them look like the same device or something to the virtual phones but that doesn't really matter. The point is that there's some disk blocks that are allocated to virtual phone one and there's some disk blocks that are allocated to virtual phone two and the file system sort of separates out the names to make sure that I can share the file system that way. Why can't I do this with a device? Like for example, take the accelerometer. Why can't I apply the same technique or what would be one bad, sad, not very good way to quote unquote virtualize the accelerometer on a system like this? That's one kind of wrong way to do it that wouldn't meet some of their design goals. But would be a way to do it. Ron, you want to take a guess? That's, well that's not quite gonna do the trick because what's going to happen? So my suggestion is, why don't we just let one virtual phone use the device at a time? For example, when the virtual phone is in the foreground the apps that run in that virtual phone get to use the accelerometer and they can do things like configure the accelerometer. Part of what's tricky about these devices is that usually they're configurable. So for example, I might have a game that wants to use the tilt controller. It sets up the accelerometer to sample at a very high rate so it can monitor how you're tilting the phone. So here's my proposal. When a virtual phone comes into the foreground I just let the apps on the virtual phone use the devices, configure them how they want to and when I switch to another virtual phone I just stop the apps on the first virtual phone from using the device and I let the second virtual phone use the device. Why is this not a great solution? Yeah, it won't be too bad. I mean, you're right, there's a little bit of a configuration overhead but remember, we're assuming people don't switch virtual phones that often from the, into the foreground. You know, I mean, this is not, this is not like a context switch, it doesn't happen that often. It's something that you're doing. So okay, it's like I'm gonna use my work phone for a little while, send a few work emails and I switch back on my personal phone and we use that for a little while, send a few, yeah. Yeah, so like, the famous pedometer application. How do you think, or I don't know if you guys went to Hari's talk last week they're driving an application that uses accelerometer data in the background. So it's reliant, the devices, sorry, I'm really plungtied today, the apps running on that virtual phone even in the background are relying on continued access to those devices. So if you suddenly make the accelerometer go away, they're not gonna be very happy. They're gonna miss steps. If the GPS isn't working, they may not know where you are. Same thing with things and they talk a little bit late about network virtualization but it's also true of network devices. I wanna be able to accept a packet, route it to the right virtual phone even if that phone is running in the background because it might be doing something like delivering a notification or something like that. Or for example, I might have an app on the virtual phone that's running in the background that's doing something like syncing data to a server or something like that. It's doing background traffic that's useful. So I wanna make sure that that's not the case. So that's what's a little tricky here. And they apply, it's interesting here. They apply two techniques to this problem and we'll point out why in a second. So they say, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, integrating novel kernel level and user level device virtualization methods to prevent a complete virtual smartphone loss environment. Kernel level and XS provide transparency performance. User level mechanisms provide portability and transparency when the user space environment provides interfaces that can be leveraged for virtualization. For proprietary devices with completely closed software stacks, user level virtualization is necessary. So what do they mean by this? So the interface that we're virtualizing across is the OS system call interface. By kernel level, they're talking about below it. By user level, they're talking about above it. So they're making changes essentially to both Linux which sits below the system call interface and provides it and to what else? What other component, when they talk about user level virtualization, what are they modifying? On an Android phone, what sits basically right on top of the OS interface? Provides a lot of access to these devices, yeah. It's the Android platform. So Android provides this big library of tools for accessing devices and things like this and so they modify that too. So they're modifying both on top of the virtualized interface and below it. What does this remind you of? Yeah, this is sort of like para virtualization. Now they talk about, in certain cases, the changes they're gonna make to Android are done for convenience. It makes it easier. But there's one case that we'll come back to later. There's a couple of cases where they, when they're working with proprietary devices where those changes are required. There's actually no way to provide the features they want to by just changing the kernel. So we'll come back and talk about why that is in a second. Okay, so yeah, I have to make changes both to OS kernel and to the Android runtime. So here's why they have to do the user level virtualization. So there are, sadly on these devices, there are these big blobs of proprietary code. And a lot of those frequently are bound up with what's called the RIL, the radio interface layer. So when you get an Android smartphone, even when we get them on phone lab and build them ourselves, they come with these binary blobs that are used to drive things like the LTE chip set. We do not have access on phone lab to the source code for the drivers for the Sprint's LTE network. We just get a blob of binary code that we hope does the right thing. This is true for most smartphone platforms. I'm not sure of one that I know where you actually have a non-proprietary radio stack, although that's sad. So it says details of the vendor library invitation, its communication with the baseband, our well-guarded secrets. The baseband is the radio. Baseband is the thing that makes wiggly waves in space so that you can receive your cat pictures. Since the stack is a complete bad box, it would be difficult if not impossible to intercept or replicate or virtualize any aspect of the system in the kernel without direct hardware vendor support. So essentially, I don't understand the communication protocol here between the binary blob that sits in user space and the underlying device that it's communicating with. And so it's very hard to virtualize. So instead, here's what they do. So this is the normal Android radio interface layer. So there is this piece of code right here that is supposed to be radio-independent that's provided by Android. Then there's this vendor blob that I don't have access to. And the radio, this R-I-I-D communicates with the vendor R-I-L in order to drive the radio and kind of do the right thing. What we do here is we stick, this is kind of an interesting case of using a level of indirection. So we insert, what they do is they write their own radio interface layer that then communicates over a socket with a component that runs in the root namespace. And that now intercepts communication and communicates with the vendor R-I-L. So the vendor R-I-L has to, so what's important here is that this interface right here, the interface at the top of the vendor radio interface layer, that is known. So when vendors write these, they have to make sure that they conform to a specific interface. What's unknown is this. I have no idea how the vendor's radio interface layer actually implements the commands that I send in. I say like, associate with this network and it goes to the driver and magic happens. So I don't really understand how that works, but I do understand how to talk to it. And by doing this, by sticking in this new radio interface layer that they wrote, they can now do things, they can now handle the communication and the swapping between virtual phones correctly. Does this make sense? It kind of makes sense to me too, not entirely. But this is how I get away with virtualizing the radio interface layer. Yeah, Ron. Okay, hold on, hold on, we'll get back to that. So yeah, so this comes to a limitation of this overall system. Now, this is kind of sad, because you get like about two thirds of the way through the paper. Up until this point, you're like, this is awesome. I can have like four different phones with four different phone numbers. No. So unfortunately, information about the phone's identity on the network is actually, you guys may or may not know this. It's actually encoded in what's called the subscriber identity module, which is a physical card. It's called a SIM. If you guys ever replaced your SIM, you go to Europe, you buy a new one, whatever, it helps you get on the network. Okay, so, and I have no idea what that word is, but whatever. So yeah, so essentially subscriber identity model, SIM, subscriber identity modules, encode one phone number on the network. And this is not something that their system can work around. So what do they do instead? They run VoIP. It's kind of hacky. I mean, why not? Once you start to run your voice traffic over IP, I can do whatever I want. This is how things like Google Voice work. I can, the phone number that's used is provided by the VoIP provider, and then they're essentially exchanging just normal data traffic with my phone, and I can do this. So this is how they get around the limitations of these SIM cards. So actually, it's interesting. So three or four years later, has anyone heard of Google Fi? Yeah, so what's Google Fi? Who didn't explain it to me? Yeah, does anyone know what's interesting about it? What's cool about Google Fi? What's interesting about it? What's different about it? Yeah. Nope. No, that's Google Fiber. Yeah. That's true. But there's something, there's something really interesting. You guys don't know. What's so interesting about Google Fi? It uses two providers. So Google Fi phones use both Sprint and T-Mobile. It's like the two crap, I should be careful, I have a long standing relationship with Sprint. It is not the two best carriers in the United States, but that one. But so they use both. And the phones will actually roam from one carrier's network to another. So how do they do that? I just told you that the SIM encodes this one identity that cannot be changed. And so when I stick a SIM in the car, in the phone, I'm on a particular carrier's network and it's over. So what do they do? How does this work? Anyone know? It's very interesting. What's an obvious thing to try? What's that? No, no, no, it has nothing to do with WiFi. This has to do with the fact that they are using two overlapping sort of phone and LTE networks. Yeah, Steve, you have a guess? There's a simple solution. You guys might have seen these phones out there, yeah. Yeah, just throw hardware at the problem, right? Get a phone that has dual SIM cards. That is not what they do, okay? You could do that. So they actually created, it's really fascinating, they created this whole programmable SIM card that they use in the Google Fi devices that allows them to reprogram what is supposed to be this sort of like fixed piece of hardware, which is pretty neat. They don't switch networks that often, but they do find that carrier diversity helps because what might be true is when you're on campus, Sprint's network is the best. When you go home, you're closer to a T-Mobile tower and so you get a little bit of a better connection. They said then, I think on average, the phones switch two or three times a day between different networks, but they do use both. Did you have a question, Steve? Did you have to direct a mask between each phone number and the SIM cards, I think? No, because at that point, like you have to remember, when you use VoIP, once the connection gets to your phone, the phone number information's totally lost, right? All the phone sees is like a data stream, right? So for example, using Skype or something like that, by the time that gets to your phone, it's just a data connection, right? I mean, Skype might send some metadata along so you know what number is ringing, but Skype has sort of done the work of interfacing with the phone number system and converted everything to data somewhere else and what you're basically doing is you're just establishing a network connection to their servers. Does that make sense? Yeah, cool. All right, so anyway, unfortunately, at least in 2011, you can't work around the multiple SIM problem, but this is what they do, okay? Any questions about this? We finished a little bit early. I didn't know how fast we'd go, but yeah, Steve. Are you working? No, no. I mean, once Google does something like Project Phi, you know it's kind of a solved problem. I mean, Project Phi is awesome, by the way. If you guys haven't signed up, well, you should sign up for phone lab first, but you can go sign up for Project Phi later. It's a very cool project, yeah. Rising the old landline, it seems like we're still stuck to that modality and that thought set as if these were still all connected to the physical line program. So that's- Is there any move to roll out that modality in a completely different way, instead of identifying us by, you know, another that's attached to this advice, identifying us in a more vertical way so that we can get the phone call without a notice? Yeah, I mean, I think that's happening, right? I mean, you know, you're talking about carriers with a great deal of, you know, so for, does anyone have Verizon Home Internet Service? I'm sorry, I used to. Verizon does this really funny thing when you sign up. What is it? They make you pay an extra five bucks a month for what? You can't just get Verizon DSL, it's impossible, or it used to be, at least. Make you pay $5 a month so you can have what? A home phone number, right? Does anyone, I have a theory about this, which may or may not be true, I might get hate mail from Verizon, right? Do you know why that is? I'm pretty sure their home phone number is like the primary key in their database. And so I think if you don't have one, they're just all confused, because when you call them, the first thing they ask is, what's your home phone number? And I'm like, I have no idea, I don't know what it is, right? I know that I'm paying $5 a month for it, and that annoys me, but I have no idea what it is, right? But yeah, but these companies, like that's sort of the mindset that came out, right? Now, what's really interesting is that very recently, this is something that, you know, we'll talk more about in my class next semester on the internet. I mean, we've gone through this very long transition from circuit-based networks to packet switch networks. And you guys probably have a hard time realizing how radical packet switching was when it was proposed back in the 50s and 60s. So there were these famous stories. This guy came up with the idea of packet switching, and he went to like AT&T, and he was like, this is gonna revolutionize how you communicate. And they were like, it will never work. And actually, they apparently held a whole day, like special symposium for him where they brought in all these engineers, and all they did was give talk after talk after talk all day long about how packet switching would never work, right? It was never going to work. And then at the end of the day, they asked him, they said, are you convinced? He said, no, and of course he was right. So internally, your voice communications get converted to data very quickly, right? It might be like a connection to the tower, but it doesn't take very long when you're in a subscriber network before your voice calls are chopped up into little data packets and sent across that packet switch network that the phone company said would never work. What's interesting is that's actually reached all the way to the network edge. So new versions of LTE don't actually use packets for voice all the way to the device. So essentially what LTE carriers are doing with LTE is pretty much running Skype over their own proprietary networks. Like that's where we are today, right? It took us 50 years to get there. But so, I mean, things will change, right? I don't know how long it'll be before I can just call an email address. That would be awesome. You could pretty much do that already, right? But it would be nice to be able to just, you know, punch into my phone and not to, you know, completely, let's get rid of numbers. People don't like numbers, right? People like names and addresses and things like that, so. All right, no class on Wednesday. I'll see you guys Friday for exam review. Good luck finishing up assignment three.