Tom here from Warrant Systems and we're going to talk about Screen Connect. So if you want to learn more about me and my company, head over to launchsystems.com. And if you want to learn about Security Screen Connect, follow along here. So our entire Screen Connect just got compromised with ransomware, 1,000 endpoints, and 50 servers. Ransom is 400,000. Any suggestions for a recovery company? Screen Connect's been in news a few times. And obviously I did the video with about Bishofox and their findings and validated by the folks over at Hunter's Labs that, yes, there was some cross-site scripting and some cross-origin problems that were fixed in Screen Connect and ConnectWise has committed themselves and sent letter. And I followed that entire video up with that entire process that, yes, they're committed to security. Screen Connect is the big kid on the block. It is very popular in the MSP space. Therefore, it is going to make waves whenever there's a company that gets compromised. This was posted in a forum. I don't know the details of this particular incident. But many of the other incidents, and I've talked to people who've done the debriefs and incident response, they have found that two factor not being enabled in password reuse were huge problems. Now password reuse, don't do that. There's my advice for that. But two factor, let's talk about it because there's some nuances to it and little details about ConnectWise Control that I realized some people may not understand. Now, this part of it only applies to the cloud instance of it. And the parts where I'm on this tab here is going to be the ones that are both the cloud instance and the self-hosted version, which we're using a self-hosted version. So I set up this evaluation. That's why it says 14 days remaining. This is not my real Screen Connect. And ScreenConnect.orgSystem.com was a dummy email just created for this particular video and everything else. The company name is real. The passwords are not. And neither is in these two factor codes. That is our phone number, though, for our company. Anyways, it's on our website, too. The first problem I kind of have is enable ConnectWise Control Cloud Account to factor authentication. I have a talk about how to do this, and they do say yes. But here's the problem. They do say to do this, but can you tell which type of two factor I have enabled right now? What if I click this? Yeah. So tyranny of the default is the term I like because many people never change things from default. The default is it emails you. So if someone, a threat actor, were to get into your email and they wanted to get into your ConnectWise Control Account, they would be able to send out an email and get those codes sent over there. Obviously, that's a huge problem. The best way to do this is to set two factor authentication code using this, and this is like Google Authenticator, T-O-T-P-based authentication. T-O-T-based is time-based, means rolling numbers. You scan this with an app on your phone, Google Authenticator being a very popular app. There's other apps like Authenticator Plus and several others out there. Basically, they scan this QR code, they generate numbers based on time that expire and are, you know, rolling numbers. I won't dive too far into that, but that would mean that the bad actor not only would need access to the username password, they also need access to the phone with these numbers that are expiring and rolling on a time basis on here. So when you set this, this is where one of the other issues I found, set two factor authentication. One, it doesn't tell me what type I'm using now, default as email. When you do set the two factor, scan this with your phone and hit save, but it does not prompt you to verify that you have the right number saved, so be careful because you can, well, easily lock yourself out of the account. Also, every time you hit configure, it does that. Now, once you've done this, I was told by several people that ConnectWise had a issue where if you were to go through and try to do a password reset on the cloud.screenconnect.com to get into the cloud account, it would bring you back a link to the email. So they would have, the threat actor would also have to have access to the email, but it would allow them to bypass the TOTP. I did validate that this is not true. I went through a Screen Connect at laurencystem.com, went through, put the password reset, did the forgot password, and it did let me change the password because it does send a link to the email, but I was still stopped because the threat actor was still needed, that rolling number that's on the phone to make that work. So good news is that if that was a flaw before, it appears to be fixed right now. So the next part we're going to talk about is what is both for on-prem and the cloud instances here, and we have proof-of-concept.screenconnect.com. Like I said, set this up as a demo, so don't bother poking away at it if you're curious. And if someone says, aren't you showing the passwords of things? Yes, I am. They're going to be deleted when this video gets finished. So someuseratlaurencystems.com, username someuser, we set a password, and then we have the authentication options. OTP, one-time password, email, Google, UB, Lintop, and Duo. I'm using the Google Authenticator one, but like I said, this is actually TOTP, those rolling numbers. The way you do that is you type GOG colon, and then we generate a number.  Once you've decided on the code that looks most secure to you, you scan it with the app on the phone for that particular user. Then that user now has access to those rolling numbers on there. Then we take this number, just this last digit, secret equals, copy it, and paste it right here. So it's GOG colon and that secret, and then you save that user. Now that particular user has two-factor, and this protects you from a couple problems. So the main one being, of course, that if they know the username, they can always click forgot password. So if they go to some user that will go to that username and send a reset link to their email. Now if that threat actor has access to said user's email, they would be able to get in unless it has some type of two-factor authentication turned on. So this is one of the reasons I'm really a big fan of it because, well, it's a little bit harder because they would have to acquire the phone that these are on. And these apps, some of them have the ability to put a password on top of an Authenticator Plus being an example of one. So that Authenticator Plus app will have to have a password on top of it again to even get in and show the rolling numbers. So that helps protect you from that. So now let's go back over here. Well, I'll just show it in action real quick to some user. Now I put in the trusted code on here. And this is what would have been stopped. So 1-5-0-0-6-3. Like I said, these numbers expire after so many seconds. And I typed it in wrong. 1-5-0-0-6-3. And now they're in. So like I said, this keeps them from being able to dive deeper into the system. Now I still wish there was a way. And I'm just going to throw it out there right now. Maybe this is a future thing they can fix. If you are self-hosting, you can do this if you're using a reverse proxy. You can filter out people's ability to hit the login page. But right now when you go to a screen connect, the login page is accessible to anyone no matter what restrictions you put. So they can always click the forget password part. And if they know your username, obviously they can become very annoying by doing that. You can see a self-hosted instance with a reverse proxy. If you're familiar with reverse proxies, they're able to filter URLs. And you can do things like only restrict, log into certain IP addresses. But what they do have is the advanced configuration editor. So I do recommend you load this. You go over here to extensions, browse the marketplace for extensions, advanced configuration editor. I've already loaded it. So the install button is missing. And that brings up these menu options here. I'll do a lot of things that you can do and customize it. Maybe I'll do a future video on customizing screen connector and talking about the product. I have an older video on it. There's a lot of options to pull up here. But what we're going to focus on is if there's an IP address you need to block because they're hammering away at things, you can put that in there. More importantly, restrict to IP addresses. You can restrict the host page and the admin page. So if you have maybe that's the same IP address or maybe you have more on here for the host page because you have more users logging in for more places. You can put all of them either in site or notation or comma separated each of the IP addresses. Maybe you have more than one site. So if you have static IP addresses, you can put those in there. Do heed the warning down here that says caution and correctly setting these IP restrictions can prevent you from logging into host admin pages. Obviously, if you can lock yourself out and then you're end up on the phone with connectivized support to get that fixed. Also, you can say require, require two factor authentication counts. So determines the minimum number of authentication factors. It must be associated with the user in order for a user to log in to the host administration page. That's another thing you can put on there as a restriction. Now, even putting these on here, if they have the username and password but they're not coming from an IP that you have authorized, they still get to do the login. So that doesn't stop them from hitting the login page or putting a restriction in it but it will stop them even if they were successfully to try to log in and they had someone's phone, for example. It will stop them from that because even if they have a successful username and password they will be on that not authorized list and it will block them in. So restricting two IP address, I think that's fairly important to throw in there. Last little thing I'll mention, security is about principles of least privilege. I made this user an admin that's probably a horrible idea. So when you're creating users, you probably don't want to have your daily user that you're using have administrator privileges. The reason for that that's really important is in the case of the cross-origin that to my knowledge was fixed. Cross-origin means another tab while I'm logged in on this tab can understand a different origin and inject something in there. And if this user's logged in as administrator, then you could then flip a setting. And that was one of the demos that they had done like, hey, you could change a setting in here, for example, turn off 2FA in there. If these users don't need admin and generally speaking for day-to-day uses they don't, you generally don't want to have them have admin privileges. And you just create a admin user that's separate that you log into when you need to change something, which from a day-to-day basis of usage isn't very often. So you're keeping the permission for a restrictive on here. And that's one more way to help mitigate any potential issues. So hopefully this helps. Hopefully this adds some layers of security. I've had people reach out that said they weren't really clear on the two factor. Yeah, hopefully this cleared that up to TP is my preferred way to do this. It's much better than things like, you know, sending SMS messages or using that. But of course they do have other options like Duo and UB Duo authentication is a great service. And UB keys are well known for security, but please just don't use email. Like I said, many of the briefs were not about something clever hack of how they got in. It was combination, sometimes a password reuse using the same passwords on emails as for other accounts. Not having two factor on email. And of course, not having two factor on screen connection. Once they do compromise email or having email as two factor or in some cases, there were instances one that I read about they didn't have any two factor at all. Just username and then weak passwords. And obviously that seemed like the pretty tragic and terrible results of that sometimes. So hopefully this helps someone and thank you. And thank you for making it to the end of the video. If you liked this video, please give it a thumbs up. If you'd like to see more content from the channel, hit the subscribe button and hit the bell icon. If you like YouTube to notify you when new videos come out. If you'd like to hire us, head over to laurancesystems.com fill out our contact page and let us know what we can help you with and what projects you'd like us to work together on. If you want to carry on the discussion, head over to forums.laurancesystems.com where we can carry on the discussion about this video, other videos or other tech topics in general. Even suggestions for new videos that are accepted right there on our forums, which are free. Also, if you'd like to help the channel in other ways, head over to our affiliate page. We have a lot of great tech offers for you. And once again, thanks for watching and see you next time.


Hi. So we're here to talk about OVEN. In the past, we've given some presentations about the architecture and sort of what we're planning. But now we're looking a little bit more real. And so we wanted to talk about how to deploy it and what our scale testing is showing. My name is Justin Pettit. I'm one of the core OpenVSwitch and OVN developers. I work at VMware. And I'm one of the OpenVSwitch developers at VMware also. I've been working on the project since it was started. And I'm Ben Faff. I'm Han from eBay, and I work on SDN Solutions. And I'm not Russell. For those of you who don't know, his wife gave birth to their second child last week. Congratulations to them. They're all doing well. My name is Ryan Mottes. I'm at IBM, and we're really interested in this stuff. So we've been actually putting it in place and doing a lot of testing with it, which we'll talk about later. So my guess is that a lot of you already have an idea of what network virtualization is. But I'm going to give a little bit of a review for anybody who might be new to it. So network virtualization, the way I like to explain it is to go back and look at the structure of a physical network in your data center or your office.  And they're connected by switches. They're connected by routers. And the physical topology of the system determines what can reach what and what it has to go through. Now, when you take those hosts and you move them onto hypervisors, usually your physical network doesn't let you reproduce that topology. So if you want to have a network that behaves as your physical network did, then you have to introduce new concepts. And ideally, you want to implement those switches and routers in a distributed way in software. And so network virtualization is how you build things to let you do that. And then beyond that, when we were at Nasirah before it was acquired by VMware, when we were talking to a lot of our customers, the big thing for them was not only that they needed those features, but they needed them to be self-service. At the time, when you looked at clouds, what you saw was that you were able to deploy your own virtual machines in terms of, say, virtual CPUs. You had self-service access to storage.  You had to get them to set up VLANs and so on. And network virtualization aims to avoid that problem by making it possible to do everything yourself without having to involve networking. So I wanted to just quickly go over what OVN is, what it's providing. Most of you are probably familiar with network virtualization, so it does the things you'd expect. You can create logical switches, logical routers, create security groups, and ACLs, L2 through L4. We support multiple different tunnel overlays, because they all have various trade-offs. So we like to give people options there. We've also provided the ability to have OVN control top-of-rack switches so that you can more easily integrate your physical workloads into your logical workloads. And so OVN works with a number of different hardware providers to do that, but that won't be the focus of this talk. But if you have any questions, you can feel free and ask me afterwards. OVN is really aimed to work on OVS, so it works on the same platforms as OVS. So we do most of our development on Linux, on KVM and Zen. We've also been looking quite a bit at how to make it work with containers. So there's some work there that's continuing to evolve as the container networking evolves as well, but we're very involved in those discussions. We also have work with DPDK and Hyper-V that's underway. So the best integration that we have right now is actually with OpenStack Neutron. But we're being very careful that things that we put into OVN are not just OpenStack specific. And so we plan to have it work with other CMSs. And we have a number of command line utilities that's actually how we use, like Ben and I, usually test it. So you can do everything that you want through the command line or through database calls that you could do through Neutron. So OVN is being developed by the same community as OpenVswitch, and it's being developed in the same way, too. So all of the development is happening out in the open. It's on the OVS mailing lists. Anyone can jump in. They can see as it evolves. All the design decisions are being discussed there as well. It's vendor-neutral, so it started with a small number of vendors who got behind and wanted to start working it. But it's grown as eBay and IBM and Red Hat have joined in. It's under a Apache license. And as I mentioned, there are a lot of vendors involved. And if you look for the Mitaka release, the Neutron plug-in, the top five reviewers are from five companies. And the four committers are from four different companies. So it's a pretty diverse affiliation associated with OVN. So our goals are to make it production quality. The OVS, I think, has a pretty good reputation in general. Not necessarily the plug-in so much, but the OVS core itself. And so we want to continue that. That's really important to us. The design is pretty straightforward, as you'll see in some of the decisions that we've made in the architecture. It scales to thousands of hypervisors. We've already tested it in the low thousands. But we expect to see that grow in the next couple of months. Our goal is to have 10,000 hypervisors supported before long. And we hope that it'll have improved performance and stability over the existing OVS plug-in that's available. And we hope that it's embraced by the Neutron community and it becomes the preferred method for most people who want to use OVS or networking in general. So why should OpenStack care? The primary job of Neutron is to provide a cloud networking API. And so we want to clean that up, make that work a little better than some of the existing solutions. We're adding this into OVS. It's actually a little bit of a separate project, but it's co-located. So we're not making anything into OVS that's oven specific, but we are expanding OVS in ways that makes this easier. And so there are other projects like Dragonflow that are also making use of some of these features. And the existing OVS plug-in is also been making some of the features that we've used to improve oven. All of these things are available and they're not oven specific. And the design that we do seems to have better performance and scale over some of the other solutions. So I'll spend a few minutes expanding on what's different about OVN compared to the existing OpenV switch plug-in and other things that are out there. So let's start out with the OVN architecture. So starting from the top of the diagram, what you see there is the cloud management system at the top. So in the case of OpenStack, that would be OpenStack Neutron and the plug-in for OVN in Neutron. So the primary way that that communicates with OVN is through a database labeled there as the Northbound Database. So that database contains the logical configuration of the system. So for example, it has tables that represent logical switches, logical routers, ports on virtual machines, ACLs, and other concepts that your network administrator is likely to be familiar with. It doesn't contain anything physical. For example, there's nothing there about hypervisors or where things are located physically in the system. So the Northbound Database has only one other client and that is a demon called the NorthD or OVN NorthD. The goal of NorthD is to take this set of concepts that are familiar to the administrator and familiar to Neutron and translate them into lower level concepts that are easier for the hypervisors to implement fairly directly. So it takes things like logical routers and then it translates them into what we call logical flows. And if you have any familiarity with OpenFlow, a logical flow is a lot like an OpenFlow flow. The major difference is that the concepts that it uses are logical ones. So for example, instead of speaking of physical ports, it speaks about logical ports. An example of a logical port might be, for example, a VIF on a VM. So it takes this lower level representation and it pushes it to a second database that we call the Southbound Database. This database has, but besides NorthD, it has every hypervisor as a client and the client there is a demon called OVN Controller.  It pushes Northbound into that Southbound Database. That's a little confusing. It pushes to the Southbound Database, for example, the set of ports that are bound on its own hypervisor. It pulls down all the logical flows and it translates those logical flows into ones that are physical flows for its hypervisor. So for example, for a logical port that is actually a VIF on that hypervisor, it would translate that into a reference to that VIF. If the logical port refers to a VIF that's on a different hypervisor, then instead it would translate that into a reference to a tunnel to that hypervisor so that if packets were destined to it, then it can send them across the tunnel. And then on the other side, Southbound OVN Controller talks to the local OpenVSwitch instance over the same channels that any OpenFlow controller would use. So it speaks OVSTB and OpenFlow to the local OpenVSwitch instance. So here's a little more information on that architecture of OVN. We use these databases, these central databases to coordinate and configure the whole system. Currently we're using OVSTB for those databases. It's possible that if we run into scale limitations there, perhaps we'll switch to a different database. The particular database is not essential to the system. And the other point is that most of the work in the system happens at the hypervisors. It's a distributed controller, not primarily a centralized one. It's a centralized database. And the architecture is one that we came up with after seeing a couple of generations of controllers at Nacera and VMware. We think that we've learned from the experience of the good parts and the bad parts of the designs there. All right, so this slide should be familiar to anybody who's done Neutron up through Montaca as far as how security groups are handled. This has been one of the pain points for OVS and the fact that, A, it's fairly painful to put this together in the control plane. B, if you're running OVS bridge, hey, you've got Linux bridges there as well. You've doubled what you've got. And if I count in a path through, I think I've got like six stacks that I have to run through to get a packet from the VM on the left to the VM on the right. And that's not an optimal way to do things. So, passing it back to Justin. So with OVN, we're using a new approach. This is something that we talked about last year, which is making use of a connection tracker so that stateful connections can actually be managed and maintained by OVS itself. And so by doing that, we don't have to go out to IP tables in order to do the stateful firewalling. And so it's much more streamlined. As I mentioned, this is something that we introduced a while ago and we've been talking with other people about how to do this as well. So there was a presentation yesterday about the existing OVS plugin that makes use of this as well and you just get much better performance. This is a slide from a presentation that we did last year in Vancouver. This is before it was integrated into any project. It was more, we were still working upstreamed in the kernel. But you can see that the throughput improves significantly by not going through those multiple stages. So the other painful point for folks doing Neutron and the reference stabilization is L3. It's agent-based, which has implications in the RabbitMQ plane. Again, you're back to using the Linux IP stack and IP tables in different namespaces for forwarding and that. And you can do overlapping IP addresses with it, but you end up with a bunch of complex stuff to actually handle what you're trying to do. And from an operational point of view, it's often difficult to figure out where things went wrong. If folks made it to the notorious MTU discussion this morning, the slides on what could possibly go wrong were just astounding. Therefore, oh, actually, therefore the picture that this turns into is that. I am not gonna read through it because it's an iChart. If you want more information, the networking guide is perfectly good. I am on the hook to put something similar to this together for the networking OVN, OVN project. So that's gonna get documented so that operators can actually set this up out of the box and get it to try it out and kick the tires. Something simpler rather than similar at home. Simpler, yeah. So yeah, something simpler. So for the OVN L3 design, this is something that I'm not aware of other open source projects doing. This is something, a similar approach that we used in the commercial product that VMware sells NSX, but that we've actually already implemented it in OVN. And so that is we're using, we're doing distributed L3 in a slightly better way or a more efficient way. Instead of going to like a network namespace and then configuring that, we actually do all of the L3 processing in OVS which is much faster. So without OVN, normally what you would do is you would attach it to a vith, send it to a network namespace and then that would have the networking configuration and then it would pop back out and then you would route it someplace else. With OVN, we actually program that as flows. And so rather than making all of those jumps, we've cached what the eventual destination is. So even if there are multiple hops, we will decrement the TTL by that number of hops and then we'll just set the correct MAC address, destination MAC address and then we'll send it on its way which is much more efficient so everything can just stay in the kernel and be a single lookup there. We've also been with one of the big things about how large you can span an L2 network has to do with broadcasts. The biggest broadcaster usually in most networks is ARP. And so we've built into oven ARP suppression so that rather than having to do that broadcast and send it to all the different nodes, we locally in OVN controller find out what the, we trap that ARP request and then generate an ARP reply and then send it back so that there is no ARP that's going out over the network and never crosses a tunnel. And the other thing is that we make no use of the neutron L3 agent. One thing that our goals for OVN is that we don't require any additional demons to be run. The only thing is OVN controller runs there and then it does everything else that you would need to provide networking. So the control plane scalability is one of the most important thing for the SDIN solution. So to achieve the target, the first thing we need is we need environment to validate scale and to verify the improvements we did. So it's unrealistic to have a big data center to just for the testing purpose. So we made this testing simulation framework just for control plane and we can simulate 2,000 hypervisors with just 20 bare metals. And we use Rally for the deployment which is familiar with in the open style community. And so this architecture, the structure is that we have central node that's hosting the central part of the OVN which can comprise by the OVN NOSD process and the OVS DB server processes which hosting the NOSBAN DB and SOSBAN DB. And this central node is connected to the farm test farm which is comprised of tens of bare metals. On each bare metal we have, we are running many, many sandboxes. So this is utilizing the OVS sandbox with very handy feature. And it's just on each sandbox, each sandbox is simulating a hypervisor actually. So on each sandbox there are three major processes running. One is the OVN controller which is a distributed part of the OVN architecture and others are OVS processes including the OVS research and the OVS DB server. So this project is actually under hosting by the OVN research on the GitHub. So you're very welcome to contribute. So I think most people are very interested in current scale achieved by OVN. So based on the testing framework we did some testing with pure OVN setup which means there's no neutron plugin involved yet but this is the current data. So for the near true part, we have two K hypervisors and 20 K VIF ports bounded on the system and there are 200 log switches. So on the right hand figure it means it's a number of ports. The port creation and binding speed along with the increase of the number of ports in the system. So the right end is which is 20 K ports and you can see the speed getting snow and on high scale the number of ports, the speed is getting snow but this is not the focus here since this is still similar in system and we're sort of over committing CPU and on each bare metal we have 40 cores but we are running 100 sandboxes. So it's sort of over committing. So in a production environment can be even better number but focus here is we can achieve the two K hypervisors without any issues and the OVN is still working pretty well and we also tried three K hypervisors but there are some issues, not issues but the speed is getting very snow and we don't want to claim that this scale we achieved but for the near true, if you're running provider networks so there's all that you need. For near three it means you need to get the notch routers involved and connecting with different logic switches. This is to be tested. So expectation for that part can be a little bit lower because of the complexity there and the work is ongoing. So the scale achieved here there was efforts and improvements already done. So this is a list of what we did based on the scalability test environment, the data provided by the environment and we did profiling and so it's very concrete result we get. So for each improvement we can get regression and we can get hotspot. One example here is a local data path optimization. So the figure here shows the improvement. It's very significant and and so what we did is just low-hine foods so far. There are even more important works ongoing in the community and more better result will be expected. So the open controller, there are two already under view. One is incremental computing is doing by Ryan and conditional monitoring is doing by Leran who is also here and showed very good results yesterday shared with us and incremental computing we also verified in this, the patch is verified in this testing environment. It's not yet merged but it's very promising and over in NOS D which is the central part the incremental computation is also very critical for the scalability and we just got very good news from Ben that the NNOC system from VMware will be open sourced and which is very helpful for the incremental computing for the logic flows. And OBS-DV is one of our hot topic but so far what we got is that even with single thread it's still be able to handle 2K hypervisors. There's ongoing work for multi-threading. I think it's Andy who is doing that job and so it's expecting a very even better result and ACL if you're familiar with the security group. So if using remote group the scalability will getting bad easily and this effort is the address set is to improve in that situation. This work is doing by Russell and the code is almost ready to be merged I think. Thank you. All right so the Neutron plugin lives in the networking OVN project. As we've said it speaks OBS-DV to configure OVN via the northbound database. The point here is a lot of there's a lot of efforts to get rid of all of the existing agents the DHCP agent the metadata agent get those into the OVN controller process so that we can keep the RabbitMQ bus from melting down when we scale up because it's a bit of a pain. One of the reasons why we at IBM are interested in this is that we have doubled down we will run this in our public cloud where this is what we're gonna do so we are currently having it in test with OpenStack we've done a 15 hypervisor deployment you can see what we've achieved we've done a 90 hypervisor deployment and you can see what we've achieved there those are the targets that we had for those deployments that isn't to say that's where they broke that was just the targets we have had for them and we met them and we're in the process of putting a 300 hypervisor and a 700 hypervisor deployment out there to test the control plane improvements because simulation is wonderful but we all know that simulation and reality can be sometimes different. One of the other advantages that we have comes in deployment because simply deployment is easy there's no additional demons host level is very simple you can do rolling upgrades as a matter of fact we'll get to that a little bit more Puppet OpenStack now supports it and TripleO there's a posting out there that's for review I don't think it's merged quite yet now as far as the rolling upgrades OVSDB scheme is versioned so when you put it in there it's carefully managed this allows rolling upgrades we've actually done this we've set up instances running data connections and pushed the big red redeploy button for the OVN control plane and the data plane and watched it work and not disturb the user connection we have not done kernel upgrades because we need to get live migration first so truth and advertising this is the same strategy that OVS itself has been using and we can certainly say that it works and let's get this to the next slide and Ben I'll turn it over to you Thanks so I'm going to talk about where we are and where we're going so tell you a little bit about what we're targeting for the upcoming release so we're working on a bunch of features that aren't quite there yet we already mentioned multi-threading of OVSDB server for performance we're also working on high availability using the RAF distributed log algorithm that should be available pretty soon we're working on support for an L3 gateway with NAT which is a feature that a lot of people are looking for I think we have IPv4 logical routing in our logical routers IPv6 I believe patches for that have been posted once or twice patches for that have been under development for a while and now that Justin is no longer spending all of his time playing manager my guess is that he'll get a chance to actually do some development he's been itching to get back to that so I think we'll see that soon we have patches that have been posted in our under review for native DHCP so that there's no need for individual DHCP demons for each logical network and in fact no need for extra demons at all metadata proxy is in the works we've had some proposals there and I think we're going to figure out what's the best strategy for that my favorite so far is to do it using a general purpose service function chaining but I don't know whether that will be the approach we end up using address sets were already mentioned those should allow for some extra efficiency when there are large groups of IP addresses or other kinds of addresses that lots of ACLs reference and finally we're working on support for routed networks you can see our logo for our milestone there the microwave release we're calling it but before that we had the toaster oven and the easy bake oven so as you can see we're moving to higher technologies all the time so here's a list of resources that you can go look at if you're interested in learning more about oven I'm not going to read all these to you so you can look at them now or you can refer to our slides that we'll post after the talk or you can come talk to us and finally if you want to want to help then one of the greatest ways to help would be to try it and test it and report bugs and in addition report successes because I know as a developer one of my frustrations is that I tend to only get bug reports nobody tells me if it works okay for them so here are the different places you can go to get involved and that's the end of our talk and we can take questions now I think I will flip it back to the previous slide because I think that's more informative so we'll take questions thanks this is a very interesting very informative I've got a couple of questions one from the NSX side to the VMware guys there is this what's going to be under the hood of the merge of the multi-hypervisor vSphere NSX product? so the OVN project is completely independent of NSX we've learned a lot from our experiences with NSX but we're not using any of the code from it I know that somebody earlier said something about open sourcing NLog which is a big component of NSX but in fact that's unrelated code it just implements the same thing okay that kind of segues into the second part which is how are you going to approach layer 4 through 7 services and do you have a strategy do you have partners for that so what do you mean by in what part of layer 4 through layer 7 do you mean? say for example load balancing okay yeah so there are patches for ACLs that are sorry no ACLs sorry for NAT that are we just got the NAT component upstreamed in the kernel for OVS the load balancing is going to leverage that as well so there are patches I think they've been sent out on load balancing if they haven't I would expect them in the next few weeks but they're actively being worked on and so we'll be making use of it there's a draft out okay yeah so there's a draft out so that's leveraging the connection tracker sort of like the ACLs are if you want to talk DPI or something then I think we're looking more at we have some ideas about how we can send traffic from the kernel up into user space for DPI engine but also we may be looking at service function chaining that sort of thing thanks since there are four of you I almost feel like this is a panel and since this session was actually marked as beginning level I feel like it's okay to ask this question do we really need so many open source networking alternatives an open stack and will we ever see them merging back together so there are fewer yeah that's a that's a that's a good question that's an excellent question the it's been one of one of my personal frustrations I I liken it unfortunately to a little bit of the history of of neutron that we are in the situation we are now the honest truth is networking means different things to different people what what you might have as networking requirements as an operator might be different from your requirements as an operator might be different from my requirements as an operator and if there's one thing that that I think we found because of the all the different solutions to try and get a one size fits all solution just makes a whole lot of people unhappy and it's not a great answer but I'd rather be in sort of the IETF model of let a thousand flowers grow and let people pick the thing they want even though for the poor guys that are doing docs and and they know who they are it makes their life heck I'd rather be doing that than then come up with a solution and have everybody go well that doesn't work and wander away well we're really complicates things is as we try to drive new features into the upper level API like I'm pushing hard to get a security group logging capability into the API and then all of a sudden all these networking alternatives underneath don't support it or they break well so so in that case what you're worried about is specifically the reference connection of the reference implementation or reference implementations since there's there's Linux bridge and OVS so let's let's not forget Linux bridge you're concerned with getting that to work something like OVN because it's in the networking OVN project it's up to the networking OVN people to make that work once it appears in the core a neutron project so it's not really your responsibility to worry about all these other things I would I would say just worry about the the reference implementations and they've all got to figure out their own their own business okay so my question is about the North Sea which does the translation between the North database and the South database base what is the design consideration of having that hosted in a central database location versus pushing that as a direct translation onto the OVN controller so the the design there it well so that that's one of those places where I really had to defer to the experience of of some some people at Nisir and VMware who built controllers before my first design for OVN my first proposal and I and Justin Justin I worked on this together our first design had had that essentially what was in that north northbound database at the height had all the hypervisors pulling from that directly and then I and then I I showed that to some of the some of the people who had worked on MVP and NSX and they said what are you doing that that isn't that that isn't going to work and they they they explain it to me and it it took a long time for me to to get convinced so I can understand why why you'd have skepticism to it Justin do you have a better technical view on that not really I mean I think that yeah I think we it's probably worth it we documented some of the reasoning I would have to to go back and look at all that we went through but but in the end there that that translation the southbound database the bits that North the rights those are those are deterministic function of what's in the northbound database so if that turns out to be a bottleneck then I think there are several ways that we could distribute or shard the work that North the does or possibly we could even distribute it down to the hypervisors I so far it it seems pretty far from being an important bottleneck in the system but I certainly understand the viewpoint that it looks like one I agree so when it comes to that level of scaling limitation will be open for having such modifications or enhancements to the current architecture right I think the the the big thing that we're planning there is to currently North the is written in a very simple way up so that whenever the northbound database changes it processes everything and then sends the differences to the southbound database the obvious thing to do there would be what we're calling incremental computation before so that if you make a a small change northbound database we do a small computation in North the and then we send those changes one thing I would say is that we didn't spend a lot of time early on in the architecture trying to optimize everything we tried to do everything in a way that was obviously correct and now we're going through and doing the evaluation to then see where the hot spots are because often times in our experience if you try and make guesses of where the problems are then you end up in the wrong spot and so everything right now is very straightforward now we're saying seeing that you know that we mean it's pretty obvious that reprocessing everything is going to be expensive but let's just make things correct and then later on we can add incremental update and then you know that's gonna be much more complicated but at least it works up until then just just let me add to that that in fact I had a bunch of guesses where we would find the first bottlenecks when we scaled it and I was wrong so I'm glad that we didn't pre-optimize those okay thank you yeah you said OAN is going to be production ready by newton but is it still going to have a future parity with the existing agent-based implementation of newton? I'm especially concerned about HR outers, DVR and things like that so independent of newton release or not we are gonna run it in OVN we're gonna run our public cloud with OVN and at the point we run it it will have feature parity with DVR, HA what's there today so it will be there by the newton release it will hopefully be there before the newton release because we plan on being out there before newton is done yeah so you guys talked a bit about a scale but I wanted to touch base more on the HA side so you said OVS-TB is gonna evolve in some sort of sequentially consistent store with draft implementation but at the same time there are a lot of other moving pieces like your North T-Process and the whole public subscribe network that you have set up between southbound DV and OVN controllers and those networks can get partitioned and you have to do a lot of state synchronization between northbound, southbound and OVN controllers is there some testing and some sort of analysis being done given any of these components can fail and networks can get partitioned that you can still maintain the invariance that you want to maintain of course testing will be important and we we have a plan to do thorough testing I think that part of what you're worried about is that it's not necessary to worry about that to the same extent you're talking about that published subscribe mechanism for example that is in fact a core component of OVS-TB it's not a separate service it's basically how all clients that I know about use OVS-TB so it's a fundamental feature if that was broken the system wouldn't work so if you get a network partition and a lot of these published subscribe connections break when they come back the full state is synchronized? so it won't be fully re-synchronized we have mechanisms to basically pick up where it left off in common cases where it's cheaper than sending the entire state okay thanks and it looks like that's the end of our time but I think that all of us are available to talk to people after the session thank you


So, let's talk about failure criteria right now. Let's consider a uniaxial tensile specimen, and I know you already looked at that in developing a more circle when we looked at, if I section it in different directions, we will get different stresses. But let's look at a uniaxial tensile specimen in terms of how it fails, okay? So if we mount this uniaxial tensile specimen in a testing machine, so it's cylindrical specimen gripped at the two ends, and we load it under displacement control and plot force versus elongation, what we'll see is initially the force displacement behavior will be linear, we expect that, a linear elastic material. However, at some point it's going to plastically deform, and this isn't force versus strain or stress versus strain, it's force versus elongation, so be aware of that, but in a lot of materials we tend to see a strain hardening effect, so once it starts to plastically deform, we can still increase in the amount of force that that structure can carry. We call this strain hardening. At some point you're going to reach a maximum, necking will start to occur, so we will localize the deformation cross-section of that cylinder will reduce and the force begins to drop off, and that will eventually lead to complete failure of the specimen. Now if we take a close look at the actual failure mode there, and I have a few specimens zoomed up on that, we see that it's not failing in that plane of maximum principal stress. We already showed that at Mohr's circle for uniaxial tensile test means that the uniaxial applied stress is your maximum principal stress. We see that there is an angle, and you can actually measure it, and it is approximately plus or minus 45 degrees, so here's a nice cup, a sheer cup that is formed that is on a 45 degree, sometimes you get 45 through most of the specimen, so it's some combination of planes in the positive and negative 45 degree orientation. What is going on here is if we recall the Mohr's circle for uniaxial loaded, so we already looked at this before, your stress is P divided by A, so that's our maximum principal stress, stress in the y direction is zero, and so we get the following Mohr's circle with a radius of P divided by 2A, which happens to also be our maximum sheer stress, so it's just the Mohr's circle for that stress element. If we look at what's happening on that 45 degree plane, this is the point, this is the surface corresponding to the cross section through the cylinder, because that's where our uniaxial tensile stress is, and if we rotate an angle of 45 in physical space, we'll give us 90 degrees, sorry, 2 theta on the Mohr's circle, so this theta refers to the theta in physical space, obviously that's 90 degrees on the Mohr's circle, we see that at negative 45 or positive 45, we're at the maximum sheer stresses, so we get the maximum sheer stress, which in a uniaxial test, this isn't a general formula, this is just the formula for the uniaxial test, is sigma 1 divided by 2. We know that in a uniaxial test, we derive a stress allowable called the yield stress, so we look at what stress does yielding occur, that is a normal stress, so that occurs when sigma 1, because that's our stress in the x direction, is equal to our yield stress, so if we combine these two, we can say, well, sheer stress seems to be dominating that failure mode, our failure is occurring on a plus minus 45 degree plane, so failure is likely a result of sheer stress reaching a limit, so this is our engineering yield stress, we just do a test, calculate a stress, but it's not really related to the failure mode, the failure mode is related to sheer, so we can combine these and come up, this is the classical Tresca yield criterion that says, a material will fail when the maximum sheer stress in any orientation reaches the yield stress divided by 2. This is a failure criteria for ductile materials, what we see in here is we were taking, the yield stress is an engineering value, we do a test, we get that normal stress value, but then we look at how does the structure fail and try and better align those parameters, so in a ductile material, if you go back to your materials course, what is yielding? Yielding is dislocation movement, and dislocations move along consistent slip planes through sheer, so that deformation and failure mechanism is dominated by sheer stress, so it makes sense physically that sheer is driving that failure. If you have a brittle material, however, if I take a composite, well composites may be a bad example because it's got multiple components, take a ceramic, if I made a cylindrical specimen out of ceramic, pulled it in tension, it would break right in that perpendicular plane, there would be no plus minus 45, because sheer has absolutely nothing to do with the failure mode. Brittle materials fail just due to exceeding the pulling force between atoms, so it's when the normal stress reaches a certain maximum value, so that suggests another failure criteria, it's in the book but you don't have to memorize it or remember it, but you have a different failure criterion for that different class of material. Now, looking at this failure criterion, we can kind of come up with an interesting confusion that is often come across by students, and that is what happens if you have a biaxial loaded specimen. So when we had a uniaxial loaded specimen, we saw our Mohr's circle looks like this, our maximum sheer stress is just sigma x divided by 2, and so our yielding will occur when the sheer stress reaches the yield stress divided by 2. But how is the Mohr's circle going to look like in a biaxial loaded specimen? Well, if I look at this stress state, what can I say about it already? What property does it have? There's no sheer, so it's still the principal stresses. So it will look similar to this except sigma x still remains the same, I haven't put numbers but let's assume it's the same value, sigma y is half of sigma x over 2, so this principal stress is going to translate to the location of the center. So the Mohr's circle is going to shrink. If you think about the Tresca yield criterion, it's saying, well, when the radius of that Mohr's circle is half the yield stress divided by 2, we have failure. So this seems to indicate that if you biaxial load a structure, it's become stronger, which isn't very intuitive. This is where, although we do Mohr's circles in two dimensions, this is where you have to sometimes consider three dimensions. So if I think about this instead of as a square but as a cube with the z direction coming in and out of the screen, what is my stress in that direction? It's zero. We have no stress acting in and out of the page and there's also no sheer stress acting there. So I actually have a third principal stress that is equal to zero. And in any plane stress problem, that will always occur. We're looking at rotation within the plane, find the orientation of the axes where I have no shear. Always in that third dimension, I will have a principal stress of zero because of that plane stress state. Now in fully 3D problems, it gets a little bit more complex, that might have a value and again I said the Mohr's circle translates into a Mohr's sphere and it's difficult to visualize so we won't look at that. But that three dimensional aspect comes into play. So if we consider that as a cube rather than as just a simple square, we know that sigma z is equal to zero, that's our plane stress assumption and the shear stress is acting on this face are also zero. So that is the definition of a principal stress and we will obtain our third principal stress is equal to zero in plane stress problems. So what happens then is if we're considering the problem as three dimensional, we have three different planes that you can create a Mohr's circle for. This sort of should be yellow but the predictor is not so good. This face here is the yx plane which we've already calculated the Mohr's circle for. That was the sigma x and sigma y which happened to be sigma x over 2 and that gave us this small Mohr's circle. So that we already did. But you could then change your perspective to a different plane. So if we consider the z y plane, so now we're looking at this face, sigma y is there but sigma z is equal to zero. So it's an element that looks like this and it's also because we have no shear stresses in this case, our principal stress plane. So we have a maximum principal stress at sigma y which is this point here and in the other direction is zero. So we're going to get a second Mohr's circle that represents the y z plane. Now the more interesting one in this case is if you look at the x z plane, now we have our uniaxial load sigma x in the z direction we have nothing. This is indeed that original, before we look at the biaxial load, the original Mohr's circle. So principal stress of sigma 1, principal stress of 0 and we get a third Mohr's circle that has that maximum shear stress. But now our 45 degree rotation is not within the y x plane, it's within the x z plane. So it still fails at that 45 degree angle, it's just rotating in three dimensional space. So what we see from here, this is the exact, if we looked at just the uniaxial loaded case, this large Mohr's circle is the same one. So biaxial loading it didn't change the point at which it fails, our maximum shear stress will still be the same. But it changes the three dimensional orientation of that failure plane. So you have to be careful in looking at Mohr's circle if you're looking at this plane which is our original plane, we had this smaller Mohr's circle, but there was this larger one hidden because of our principal stress of 0. So how you identify that will depend on how you can visualize it. Some people like formulas as a crutch, so I always say effectively you have three possible maximum shear stress, you have to check which one is largest. It's always the difference of all the principal stresses and sigma 3 is always 0 for a plane stress problem which is what will limit ourselves to in this course. So if we go back to this, what if sigma y is equal to 0? As I said, this Mohr's circle that we produce is smaller, but we have these other two hidden Mohr's circles that intersect with our principal stress of 0 and the other two principal stresses. So when we look at that hidden principle, that hidden Mohr's circle, we still see that our maximum shear stress is sigma x divided by 2 so we would get failure at the same applied stress. So in fact the biaxial load doesn't change the stress in the x direction at which failure will occur, it just changes the orientation of the failure plane. This was the three shear stresses. What we can actually do is plot how this would look in the principal stress coordinate system and what I mean by that is if I make a plot showing values of sigma 1 and sigma 2, sigma 3 is always equal to 0 because this is for plane stress, we can create what is known as a failure surface. Failure surface is just a nice plot that you make. If you're inside the surface, then you're below your limit for failure. If you're outside of it, your structure has failed. So if we look at this criterion, tau max is sigma yield over 2. If I'm in the positive, sigma 1, sigma 2 quadrant, so both sigma 1 and sigma 2 are positive. If both of them are positive, I absolutely have this hidden Mohr's circle. So if I have that hidden Mohr's circle, it doesn't matter what the value of sigma 1 and sigma 2 are. I'm always going to have this maximum stress that is sigma 1, maximum shear stress that is sigma 1 divided by 2. Therefore I will have limits with either sigma 1 exceeding the yield or sigma 2 exceeding the yield. If either one of those exceeds yield, then I would fail. Similarly, if I look at the negative quadrant, I get the mirror image of this. So both my principal stresses are negative and if they're both negative, I will always have this hidden circle defined by the maximum principal stress divided by 2. So my limits will be when the maximum principal stress, whether it be sigma 2 or sigma 1, reaches yield. The other two quadrants are a little bit different. If we look at when sigma 1 is positive and sigma 2 is negative, the Mohr's circle we plot is the one where we have the maximum shear stress. The other two Mohr's circles are smaller. They're contained within that original Mohr's circle. Therefore my maximum shear stress will be sigma 1 minus sigma 2 divided by 2. Don't divide by 0, that breaks mathematics. So when that is equal to yield stress over 2, so we basically get that the absolute value of sigma 1 minus sigma 2 is equal to the yield stress. So that will give us a straight line defining failure. And similarly, we get the mirror image of it. They're both 1's positive, 1's negative. So the absolute value of 1 minus the other when that's equal to the yield stress, we have failure. So this produces this failure surface and really what you need to do is just consider whatever your principal stress 1 and 2 is, 3 is always 0 for plane stress problems. If I'm within the blue area of this, I'm fine. It's just a graphical representation of this formula. But I like to show it on because it shows the regions where these hidden Mohr's circles occur. So the hidden Mohr's circles will occur, or there's always hidden Mohr's circles, but the hidden one is always maximum if your two calculated principal stresses are non-zero and have the same sign. So in this quadrant and this quadrant. So that changes how you calculate the limit. So there is that Von Mises yield criterion for ductile materials. It's in the textbook if you're interested to look at it. There are brittle failure criterion for brittle materials that relate more to the normal stress. For composites, one of the most common ones is a side woo, or the side woo hill, or the side hill. There's many different variations on it. But there are many, many, many more, especially when you get into composite materials. There are hundreds of failure criteria trying to describe the complex failure in composites. So as I said, in this course, we are going to limit ourselves to the Tresca yield criterion. That's the only failure criterion I'll ask you in the exam. Just a word of a warning. When the old exams get posted up, in previous years we did also cover Von Mises stress. So you might see a question that references the Von Mises stress criterion. Just ignore that, okay?


Let's continue with Manoj Khumini who is going to tell us about afrationality of RIS algebra. I would like to thank the organizers for this opportunity and so this is about some conditions for RIS algebras to be afrational and so this is motivated by some earlier work of Hiri and Hara, Watanabe and Yoshida and the newer results that I will discuss and at least sketch a little bit where obtained with Mitra Kohli it's I mean that's a slightly older work and even newer work with Nirmal Kohli. So I'll mention the method. Let's begin afrite. So this is the context. We have a Niterian local ring we will just assume that they are normal domains for more I mean we could of course raise these questions over anything but results will be in this context okay and this is of a prime characteristic and we consider a filtration R which is just which we just call I0 then I1 of M primary ideals and by this script R we will write the RIS algebra and the question the thing is find sufficient and or necessary conditions for this reasoning to be so we'll make a restriction immediately which is that which is which will be implicit in the discussion throughout we will just assume that the RIS algebra is our priority so we will assume I mean when we try to find conditions we will we'll have a prior assumption that this is both Kohli and Makore and normal okay so in fact therefore we are not discussing an arbitrary filtration we are this filtration I is therefore is the integral close I n is the integral closure of I1 I1 to the end therefore and therefore we will just change but therefore we should keep this I mean we keep this in mind so we'll write I as the first ideal and we will also assume that I has a reduction yeah these are in primary ideals has a reduction J generated by system of parameters these are not very restricted I mean once you make this assumption these are not realistic and just one more thing maybe I'll just put it here we will we'll also occasionally need to look at the extended RIS algebra for this filtration which is just where for negative indices I n is okay so what is the motivation for this question so there are characteristic zero results results of here and so let me state one there are many results in that that paper of here let me just take one that's sort of representative and sort of will motivate our results assume that R is a regular local ring the basing is a regular local ring and then if this is a rational single the RIS algebra is a rational singularity implies that the canonical module of home of the RIS algebra in degree n is the multiplier ideal sorry this is you do not know how to write that J or whatever symbol is okay this is the this is a this is a result in this there are other results but okay so okay so this is the multiplier ideal and as a corollary of this same same hypothesis thing and let us further denote by D the dimension of R okay and so the notation so there's I here which is the first ideal and then J is a system of parameter J is a reduction generated by a system of parameters then this this ideal the is Jn colon I to the D minus 1 bar so this is a this is a I mean this is really not a consequence of of this part it is really the consequence of this so maybe I should quickly sketch the argument because that is the part that is sort of motivated somehow this thinking about this problem okay so let me just quickly sketch this has nothing I mean essentially this is just a calculation of omega r in degree n it doesn't have to do with just with multiplier ideals so let a denote the extended RIS algebra for the reduction this is Gordon Stein r is Gordon Stein so this is Gordon Stein and omega a is as a graded module it is minus d plus 1 a shifted by minus d plus 1 and in fact in fact R this RIS algebra R R the extended RIS algebra R prime is the normalization of it when it's required the chalk doesn't break but and then we can calculate omega r bar as a graded module by this omega a and omega a is a a shifted by this and therefore this is a conductor and this is that's where this expression comes it is the conductor in graded in certain pieces that's where this expression comes okay so this is yeah so actually I was thinking at some point that such formulas might be useful in computing multiplier ideals computing meaning in my colleague to but now I'm not entirely sure of that thing it's not clear to me which is easier so okay so I sort of abandoned that part of the thought but there is this because one would think that there are existing algorithms to compute integral closure and colons let us say relatively easy to compute so we could do this and compute this one but I do not have any sort of intuition about the extreme cases in which where this works okay so I okay so now we have some characteristic P motivation okay so I mean substantial part of the characteristic P motivation comes from two three papers of Hara, Vatanabi and Yoshida okay so this is a paper which discussed a rationality of these algebras and then the the famous paper Hara and Yoshida defining test ideals and there is another paper of Vatanabi and Yoshida which does some other I mean I forget the the full content of this thing but it has similar looking colons and things that involve test ideals so let me quickly motivate I mean let me just quickly say some of these things okay so first so this is the paper which is described a rationality and more importantly it also has a good collection of interesting questions and problems and conjectures so it was a nice paper to start so let me just in this context in this context of this theorem and the corollary there let me quote a result from Hara and Yoshida this is a test ideals paper okay so if you assume R is Gorenstein oh sorry I didn't actually explicitly say anyway for example I used here that this is this is finite over A but so I am assuming the rings are all rings that we consider are excellent I didn't oh so I so all these rings that we are discussing are excellent our Gorenstein and a rational then sorry if the Ries algebra is is a rational this the same formula there which is in in degree n is the test ideal of this is yeah sorry this is yeah both of these quantity this is for all n positive n because this is anyway zero in in non-positive degrees and this is the test ideal okay so so there therefore there is a formula similar to that which involves involves powers of J and integral closure of ID minus one which will compute a test ideal as a colon but again as I said I was at this point I'm not sure I'm trying to compute test ideals that way is more efficient than anything any other known algorithm okay so this is so that's one result and yeah so and this is this paper of at Nabe and Yoshida also has similar formulas involving integral closure test ideals and and the reduction so there is okay so this is the sort of motivation for for to start thinking about these problems so let me now get into some new results that are already published so results and I'll also touch upon further new results okay so maybe I should at this point okay so I said this but all rings that week all rings schemes we don't need a lot of schemes but we need proj of our are excellent in this so that is and let me just quickly define a rationality although I stated things have without actually saying what it is so we'll assume since these are all excellent and we'll also further assume that they are homomorphic images of Cohen Macauley rings so we'll just take this restrictive definition but which is equivalent to the general definition is a rational there exist an ideal generated by system of parameters a system of parameters that is tightly closed and for a new theory and ring a new theory and ring slash scheme is a rational if it is so close points maximal ideals I mean we are all the things that we discuss their aspect localization so it's enough to check at maximum ideals and the main thing that we use to prove these results is the tight closure of zero in the top local homology module so this is a theorem of Karen Smith suppose that this is called Macauley then a fractional if and only if the tight closure of zero in the top local homology module of zero where D here is the dimension throughout for the base ring are I will write D for its dimension and so we are to slightly we rewrite this in a graded situation and so what we will do to prove is that so similarly to prove that the reese algebra is a fractional we will show that it is Cohen Macauley or sometimes we part of the hypothesis and to the the tight closure of zero in the top local homology module of the reese algebra is zero okay so let me not write the subscript it is the homogeneous maximal here we are right at once because I just introducing more notation when I write like this for the reese algebra I always mean with respect to the homogeneous maximal this it's a local ring so there's a unique one so this is essentially studying this is the all these new results that I'm going to present and so there was a question in that paper of paper of Hara Watnabi and Yoshida which asked what is the relation between a rationality of sorry sort of question it was actually conjecture that put one direction what is the what is the relation between their rationality of the of the reese algebra and the rationality of the extended reese algebra okay so that is so that is theorem okay so let me state the theorem and one direction was already known the following are equivalent the extended reese algebra is a rational okay so this is the x the basering is a rational basering and so the idea behind this okay so I should clear two implies one had already been proved by Hara Watnabi and Yoshida and they had asked for their conjecture that the other statement is true and so one implies two was proved by Mitra and myself and also this argument is different from me so this argument will give a different proof of the other direction also and what is I mean what is the what's the underlying idea if you take zero so if you take this top local cohomology module of the reese algebra this is so at some point you would reduce to some Cohen Macaulay some lemmas to prove that yeah either under under either of these hypothesis some Cohen Macaulayness will be there so so let me just write like this it is actually the negative part of the top local cohomology module of the extended reese algebra these are different maximal ideals but let me just be sloppy in my notation in degree j this is this is not a very difficult and I mean a new observation was that the tight closure of zero in this module tight closure of zero in this module here is has the same behavior which is the negative part of the tight closure of zero of this one and using this one can and and also what's it where does this come in in this hypothesis that in degree zero of the extended reese algebra this lives only in negative degrees but extended reese algebra top local cohomology lives in all degrees and in degree zero this is the homology of I mean these are not okay so that's where now you just one one looks at what happens to the tight closure of zero that theorem will follow yeah so that is the so now I would like to state another result this again came from the paper of the question came from the paper of Harawath Nabi and Yoshida see if the reese algebra is a fractional then so would its proge which is the blow-up of the so maybe I so let me call x the proge of the reese algebra and there is a map to speck are and this is the blow-up map of spec blow-up of spec are along spec are more I so that's this that's this map so if this is a fractional if the reese algebra is a fractional x would also be a fractional and so they were theorems of in the paper in characteristic zero of herey and in Harawath Nabi Yoshida in characteristic P where they ask questions or prove theorems related to the fact related I mean of the similar sort the sort of hypothesis it says some hypothesis on our and x is a fractional would that imply that the reese algebra is a fractional there were some so the next result that I want to list is related to that so I think there is a okay at least for me there is a motivation for this question which is I think the first example where of a non-affrational reasoning was by Anurag Singh and the example that he constructs the proge is not a fractional so the non-affrational points of the proge therefore also show up in the spec and therefore no it is okay so therefore I for somebody I was curious and they're actually there are many quite a few results which say that if x is a fractional and nice hypothesis on our should force the reese algebra to be a fractional so let me state the next theorem which I will quickly go through because it's it's a so let's assume that this is a let this be a three-dimensional rational singularity in characteristics P okay so by this at least the way we have defined this to mean that there exist a resolution of singularities with the usual vanishing property okay I quickly say where the three-dimension is coming is going to come in okay and again as usual we are taking in primary ideals assume that x is a fractional for all n sufficiently large the verinice subring of the reese algebra not that I mean we do not know the reese algebra as such is a fractional or not but if you look at the verinice subring of the nth power okay so this is a this is just skip every degree other than those are divisible by n and such results again at least in discussing whether reese algebras are corn macaulay or not there are older results of Craig and Hakaba and various people if you under suitable hypothesis on the nose the reese algebra may not be corn macaulay but a verinice subring are corn macaulay so this is maybe it's a result it's okay maybe in the interest of time I so maybe I'll just say okay so the point is that so the way the hypothesis here it means at least for us we took that as a definition of rational singularity as that there exist a resolution of singularities which which for which the usual vanishing of homology applies for a resolution singularities of our but so but where does three dimension three come into play that is because we would like we use the result of Kausar which said that in dimension three you can do so then we make we can make that resolution singularities factor through this x this morphism and then it is just a and then some some argument to prove that if you do like this it'll become corn macaulay then that here like this to say that if you further replace the n by larger ones we can get this also and that is the that's the idea of the proof okay so dimension three is to say that the resolution of singularity would factor through this x which I do not may exist in other cases but I I don't know much okay so I that's where we used yeah and also I think the sum of the spectral sequence arguments are quicker and we'll we'll finish our fast if it's in dimension three they may become too big if they're higher dimension okay so I okay so now further newer results which are not so these things are these this is still sort of in preparation okay so this is so I'll so there are the newer results are somewhat more technical to state and they were there in Nirmal's post I don't know the posters are still there so the full technical details are there I will just give one result which also looks similar to this so I think similar hypothesis RM three dimensional Gorenstein complete f finite Gorenstein because you have to do some duality in the middle okay so just calling my call I may not be calling my call I may be enough but we haven't really and if you instead of working with the with this yeah so that maybe we have to look at not test ideals but sub modules of omega in that case but so that we have not done complete is for some technical reasons finite are all for some using other results which are sort of they require that in the hypothesis yeah assume that the resalgebra for the maximal ideal is coin McCaulay and that the proge of the resalgebra of the maximal ideal is a rational then the resalgebra itself is so we have this only for the maximal ideal and yeah and we have I mean syntactically we have this extra hypothesis that you have to assume prior a priori that this is going my colleague is not required here but of course then you have to pass to a larger thing to get okay so this is the okay and yeah I yeah so the remaining results are technical any questions yes can you say something about the proof if it's not to that oh it is I can we'll upload the thing in a week or so hopefully so then yeah sorry the other questions we don't I mean I do not know if it's true or but we don't have a proof so it looked like earlier in your talk you were looking at the filtration by the integral closures of the powers of the ideal yeah under this hypothesis powers of M would be integrally closed but I mean in the early in the result that you're in thank you this I need okay thank you any other last round for questions okay let's take tomorrow's again