Welcome to the ITU studio in Geneva where we're here for the Future Network's cast symposium being held at ITU today and I'm joined in the studio by Michael Sena who is the editor of the dispatcher. Michael, welcome to the studio. Thank you very much. Now let's talk a little bit about a lot of big discussions and conversations going on here at the symposium. What have been the major themes of discussion at this year's symposium and is there perhaps a topic that stands out as this year's hottest topic? Yes well the topics are very similar to the topics that we've had for the last few years and the reason that we've continued to have topics such as AI, cybersecurity, legislation, policies is because those continue to be very important topics for everyone involved for the telecommunications, for the vehicle manufacturers, and for everyone involved in regulatory issues. Is there a particular one that's that's it comes to the fore? Well as as the moderator for the session on cybersecurity I have to say that that was a very important and continues to be a very important topic for many many reasons because I think we all understand that if we're not secure in our communications from the vehicles if we don't allow the information that's necessary to be used for further automation of our driving we're not going to use it we're not going to be we're not going to feel safe we're not going to feel secure and the fact is that we won't be. Most people think about cybersecurity when they're thinking about cybersecurity they're thinking about their computers at home or their laptops or their phones so let's talk I'd like to expand a little bit on this so let's talk about a little bit about cybersecurity what should we be thinking about in the latest cars? The main problems that we have when when it comes to cybersecurity versus in in our phones and in our PCs people who are attacking our telecommunications devices, enable devices are doing it primarily to make money I mean their thieves they want something and they'll they'll do it one way or the other either they'll they'll put something in your your computers so that you can't use it in order before that you pay them I think it's going to be difficult to attack that same problem and do it in the same way with vehicles with vehicles we have a much more difficult problem mobile phones are in our hand PCs are normally on our laptop or on a desk but with vehicles we have many more issues to address primarily from the standpoint of safety cars can be hijacked in order to earn money but something else can happen when that's that's occurring that creates an unsafe situation for the driver and people around I mean we can start driving cars without drivers into lots of people and many people can be injured so I don't think it's the same issue of being paid money it could be terrorists primarily terrorist attacks or individuals who are are acting as as terrorists not political terrorists but as as terrorists from a from another standpoint if you were a consumer if you were sitting at home you could perhaps take steps against this of course if you're driving a car it's it's a it's a different story how can consumers protect themselves mitigate themselves against these circumstances if if the vehicle has been designed in such a way that it's open to attack that someone can take control of that vehicle there's nothing you can do as a driver you have absolutely no control of what's going on internally in a vehicle that's a very different situation than you can't pull the plug out if you're driving the car even if you turn the key off the car is still moving if someone has taken control of the car you have absolutely nothing to do with it so it's a it's a very different situation that's why we're taking such long such a long time in great care before we turn over any of the driving tasks to a non-human so is it you you're any ce are they contributing to this this conversation tell us a little bit about the steps that have been taken it's immense before I began working with with the ITU which was in 2015 I produced a report on over the year updates requirements functional and operational requirements I had been working around the issues of telecommunications with with e-call b-call those sorts of things since 1997 but the whole issue of cyber security had not been part of it in the in the same way because our communications I was working with with Volvo at the time our communications were were secure one to one there was no involvement of the internet there was no it was a it was a it was a data packet going over sms and everything that we did was extremely secure but as as the years went on and we became more and more dependent on on IP on internet internet communications cyber security became much more important and then when we began to think about the whole idea of over-the-air updating it became even more important once you once you allow the vehicle to be communicated with in many different situations you have to be much more concerned with with over-the-air with cyber security and at that time the ITU is almost alone in developing the the standards I mean the the the work the wp-29 and the sg-17 these groups are doing an enormous amount of work and and now finally the the standards are published it's fantastic in your work with the automotive industry what is the challenge brought most often in discussions around intelligent transport and innovation you know it's it's it's almost like what what's you know what what did they say in the newspaper yesterday I watched the industry very very closely and five years ago there wasn't a single CEO of a company that was really seriously talking about electrification except for Elon musk and everyone thought that it was he was a crack and that there was no one you know no one it was going to be developing cars Sergio Marchione a few years ago a few years before he died said please don't buy my electric cars they cost me more money to sell them to you than than you pay me to own one so but suddenly electrification is on everybody's and everyone's thoughts and in their minds communications the if you if you mentioned communications to a CEO it's it's almost as if they're they don't really want to talk about it because because connected cars have never sold cars they've never you know it's not something that you you walk into a to a place to buy a dealer say you know I want the most connected car it's on the list it's something to think about but it's it's the cost it's the space that you get it's the you know it's what you can afford the best car you can afford for the money the size the quality and so on and then the image that you you don't you don't walk into a BMW dealer if you can't afford a BMW or somehow you can manage to pay the monthly rents on a lease so the things that we think about the things that we're working on are really not they're not top of the list for the folks who are running these companies they look at how am i going to sell the most cars what's going to what am i going to be able to put in my cars that makes them sell and now because everything is is the governments have gotten behind it good or not i'm not a big fan of electrification for many reasons not the least of which is that we we don't save that much energy and pollute less with it with electric cars but now because there's so much so many thoughts and so many regulations and we have plus and minus and so on from for insurance people are now talking about electric cars um when we get to the point of cars actually being able to do more than they can do as far as self-driving the car companies will begin to put more thought into it they're putting money into it they're actually putting a lot of money but a couple of years ago it was much more on the top of the list now it's much more on the sort of middle to bottom of the list it's not it's not the highest priority anymore because it's gotten too hard they realize that it's not going to happen tomorrow and we're not going to sell cars because of it because of regulation because well because it doesn't work yet i mean it doesn't the the self-driving cars are not self-driving and even if elan mosque thinks he's selling cars because of that he's selling cars because especially in norway because people can't afford to buy anything else they get so many rebates and so many so many kickbacks that think you know they can't afford not to buy a tesla and what about the future of mobility what are your predictions for the future of mobility and and how are regulators thinking about it how are industry players thinking about it and what should we expect as consumers um not everybody lives in san francisco not everybody lives in the middle of london i've never lived in san francisco but i did live in the middle of london um i have an apartment we have an apartment in in uh stalcom we don't live there full time but we do get an opportunity to spend time in the in the middle the real middle of the largest city in sweden um or even Scandinavia it's a very different proposition than living in a small city a small town 80 kilometers west of of uh stalcom or living in a small village in the north of of uh sweden even in our conference today there wasn't any mention of the fact that in a place like a country like the united states where 50 percent of the people live in two on two coasts and with a little dot in the middle of in chicago but the rest of the folks live on 90 percent of the land in the rest of the country those 50 percent of the people aren't riding scooters they're not riding bicycles to the supermarket they're driving cars so the the issue that car companies have today and it's the issue that transportation people have if you're dealing with transportation in the entire country how do you manage to provide the mobility to all the people in different situations not just to all the people living in the center of stalcom not to mention the fact that that stalcom people think of stalcom as urbanizing it actually isn't it's beginning it's getting better bigger people are moving into the stalcom region but they're not moving into the center center of stalcom this the same is true of most cities we have to to accommodate people being able to move from all parts and all different types of densities within a region and right now we're not addressing that to the to the extent that I feel we need to now you've taken the time to be here at this symposium it was originally going to be at the the Geneva car show but we know for the reasons of health that was cancelled here in Switzerland but I wanted to ask you what's the value of this symposium to you and to the wider intelligent transport community I tell the readers of my newsletter the dispatcher that if there's one conference that they should attend if they're if they're in the transport business if they're in the telecommunications business related to transport if there's one conference that they should attend it's this one because unlike many of the other conferences many of them are are much larger they have exhibitions they have a lot of people standing up talking about what their company is doing this is devoted to the principal issues that we're all addressing and everyone gets to hear everything at the same time there's participation if you've got a question and you can ask you can ask it during the session or you can ask it during a break or the lunch break or you sit down with all the people who were there now we have approximately 50 people in the audience today because people you know haven't been able to come not all the moderators and not all of the the panelists have been able to to travel to Geneva either or joining remotely and but joining remotely and that's that was fantastic that's absolutely great but when you come to this this event you're able to talk with anyone anytime and that's that's a major benefit and it doesn't matter who it is whether it's person coming from the commission or from a car company you with the number of people that you have all together for an entire day from nine o'clock until seven or eight o'clock this evening you have the full availability of them and that's a fantastic opportunity. Michael Senna editor of the Dispatcher thank you very much for making yourself available to us here in the ITU studio and hopefully we'll catch up with you again at some stage in the near future and and you can share some more valuable insights with us my pleasure thank you thank you


The story of migration is largely being told in very dark, negative and very apocalyptic terms. The importance of an organisation like REF is to bring the debate to a rational level. Migration is essential feature in the lives of millions of people in the Horn of Africa. The research and evidence facility has been created to understand what motivates it, how people respond to changes in the political and economic environment, and how to provide effective protection to people made vulnerable by displacement and irregular migration in the form of evidence and policy relevant knowledge. It is a huge research area, it's very big. Combined with Somalia because they were moving from Somalia in different areas, this is where they were congregating. So you've got people moving from Sudan, moving from Somalia, you have people moving from Ethiopia, going to this area as well as South Sudan. What are some of the drivers, the main reasons that people are on the move? What are some of the experiences of movement? We're trying to look at that complexity and give some appreciation of that complexity and then I understand what sort of programming can you do that doesn't cripple movement. The most difficult part is like how to translate that knowledge generated from below in a language that policy makers also understand. We are so overwhelmed with information, for us it's a kind of guarantee of quality. We have been very impressed by the reports we received regarding the return of the population of the Somalans who have been in the refugee camps for many years and that recite and the report that was generated as a result of the recite that was done have been of use to me as a special envoy in my advocacy work.


on the girls' side. Big news coming through that the number one this season, Natrice East out of Jamaica has withdrawn from this event. She will only contest the 200 meters here and so leaves a fantastic opportunity for the rest of the field. Not that she was an overwhelming favourite, Natrice East, and I'll tell you why in a little bit. The championship record 11.27 set in 2018 by Brianna Williams who represented Jamaica and went on to win the world on the 20-double, both 100 and 200 meters. Here's the lineup for the first heat. Linda Sayer of Guadalupe, Malia Matute, French Guiana, Athalia Hingson of Guyana, the favourite. Kylie Wallace of the Bahamas, Priya Wilson of Bermuda, Chloe Jennings of Turks and Caicos and Ravianskavis of Bonaire. Athalia Hingson of Guyana, the one to watch in this first semi-final. Only the winner guaranteed of a spot in the final as the athletes get ready. 3-0-7 is Hingson of Guyana. There she is. 11-43 her personal best that was done in November last year. She is the second fastest on the 20th athlete in the history of our country. Khaleesa Smith was in the career to final in 2022, the only one who has gone faster. And maybe now with East out, Hingson is a slight favourite for gold. Sayer Matute, Hingson, Wallace Wilson, Jennings, and this definitely a big favourite for this semi-final. Athalia Hingson of Guyana. She goes in lane number four. 11-66 and 11-58 this season, so she's been in very good form. But from what we saw at 400 qualifying earlier today, we know that the Guyanese team very much on a high. And the athletes seem to be dropping personal best performances at will. Matute of French Guyana in lane three there. There is Hingson, the favourite in four. Kaili Wallace, the bohemian. No, she has an outside shot of being in the final. Freya Wilson of Bermuda, a 12-50 performer will have to be better than that today to be in the championship race later on. Chloe Jennings of Turks and Caicos and Viss Ampunier rounding out the field. Four semi-final races in the under 17 girls 100 metres. Only the winner guaranteed a spot in the final, plus the next four best on times. Stand up, stand up. She started a lot of wants. Just trying to figure out what the issue is with one of the athletes before they sent this first seat off and running. First seat of the under 17 girls 100 metres. The winner assured a spot in the final later on the 100 finals. As Gerard pointed out earlier, we'll close the show. We are 11 minutes past the scheduled start of this first seat. On your marks. And once again, Ludlow Watts gives the athletes the command and sends them to their marks. First seat of the under 17 girls 100 metres. Athalia Hingson of Guyana, the favourite in lane number four. Once again, no Natrice East of Jamaica. She's decided to go 200 only here. Off they go. Pretty quick gun and Hingson. Beautiful through the drive phase. Ticks control of the race. Wallace of the Bahamas in third position with Matuta French Guyana in second. But Hingson blows the field away in qualifying for the 100 final for under 17 girls. 11-86 on the clock. That was never in doubt. Hingson who wins the first semifinal race of the under 17 girls 100 metres. And that looked pretty good. Here's another look at it. Nice beautiful drive for Hingson. Compact through that drive phase up into sprinting motion and easing away from the rest of the field as we're joined by Terry Finist here. That's a good looking run from the Guyanese. I heard to get things kicked off this afternoon and the national record holder also a fine long jumper and she'll be pleased with her execution here this afternoon having a quick conversation at the conclusion of her opening heat. We'll get confirmation of her performance. Second fastest Guyanese junior of all time but she's still only a youth. Tremendous quality she has. Altalia Hingson of Guyanese.


Welcome, thank you for coming. This is, I know, all that's between you and the very end of the conference. We're going to try and get through all sorts of stuff very quickly. Those of you who tuned into the Cloud Foundry Foundation webinar that I did with Swarna, we'll find some of the stuff in here is the same. Basically, I'm talking about how to customize things. But Bo Yang from IBM has actually done real work with this platform. So I'm Troy Topnik, product manager from SUSE. My product is Cloud Application Platform, which is a Cloud Foundry distribution. And our team was the one who brought Stratos into the foundation. So Bo, did you want to introduce yourself? My name is Bo Yang. And I'm the project manager and lead in the open source development of auto-school services for Cloud Foundry. I also work for IBM Cloud on the delivery services. OK, and so some of you are sort of Stratos converts already, but some of you might be new to it and want to just give you the basic value proposition of why you want to use Stratos. And it's because it's great. A lot of people are adopting it as their go-to interface to Cloud Foundry, even in preference to the CLI. People are using it in addition to the UIs that come with their distribution or their hosted version of Cloud Foundry. And it's proving itself really useful for a lot of people. And that's why we gave it to the Cloud Foundry incubator. So it is an official Cloud Foundry project. It came initially. The work started a long time ago. It's at HPE. Then it continued at SUSE. And SUSE is very much into an upstream first contribution model, so that came into Cloud Foundry. So if you want to work on a UI that has something to do with Cloud Foundry, doing it in Stratos means everyone in the Cloud Foundry community can benefit from it. To that end, we've made it as extensible as we can and intend to make it more easily extensible as we go forward. Because Cloud Foundry is gaining some functionality, we want to make sure that we can very quickly reflect that in the Stratos UI as it evolves as well. And we'll help you. So there's a really, really responsive team of developers that are working on this, mostly based in Bristol, UK, and a very active Slack channel and really, really, really helpful people that want to see this adopted by a lot of people and having a lot of people extending it. We can do a number of cool things with Stratos. I'll get to a little quick demo of it in a minute. The cool thing about Stratos, one of the many cool things is that it's API-driven UI. So instead of being closely coupled with an element in Cloud Foundry, it actually just communicates with the API, which means you can create additional endpoints. You can have multiple Cloud Foundry endpoints and multiple different kinds of endpoint types for different APIs to bring it into Stratos, including your own APIs. If you've got your own project that you want to bring in to your single pane of glass on your Cloud Foundry environment, you can bring that API in as well. But the demo I'm going to show in just a second is more about how you can customize Stratos. If you're running Cloud Foundry, I'm kind of surprised IBM didn't do this on the main stage the other day. If you're running Cloud Foundry and you're using Stratos, you can make it look like it comes from your company. You can make it look like it's your own. And these are the elements that you can actually customize there. Login screen, about page, and various views. And the way you do this right now, this is just for simple customization, but it's also for deeper customizations like the stuff that Bose team has worked on, is you fork the repository and then you add your custom code in this custom source directory, which sits outside of the changes that happen as Stratos is updated. So as you can keep that in sync with upstream, keep pulling in the new changes, the interface between that and the custom source structures should remain stable enough that you can get the new stuff from Stratos without merge conflicts when you're updating and probably with good backwards compatibility too. We'll see how that goes as the project evolves, but it's been a stable interface for the last several months. It's a new project, so it's changing. This custom source folder that I'm talking about, if you have it in the root directory of the project, when you build it, this is basically what I just talked about.  It'll bring in your customizations if you've built them properly and add them to Stratos. These are the main ones for doing simple customizations. You can stick your own favicon on, the logo that appears throughout the login screen and the about page. There's one specifically on the top of the nav that you can change. You just have to make sure that it is within a certain range of sizes and the background image for the login, which I can show in just a sec. You might have a different EULA for your foundation. If you're running it yourself as a service provider, you might have certain terms and conditions that you want people to see. There's a EULA page. You can extend that using a structure like this. An Angular provider. I am, I should apologize, I'm not an Angular developer myself, so I'm gonna probably defer to Bo when I hit a really hard question, because you're not an A. These extensions are done with Stratos Decorators in Angular and we're gonna show, I'm gonna breeze through these pretty quickly because we've got some good stuff to show in a second. But you can add, you can change the login screen. You can change the side nav menu. You can change, put new tabs on some of the views that you get. The application view, the cloud foundry view, that is a view on the foundation. Maybe we should change the name to foundation. The organizations page and the space view. And these other things, new actions. And this is what I'm gonna show in just a second. So to get started with the project, first thing you do is you install the Angular CLI, clone the repo, go into the repo and do an NPM install.  And then you start prepping to make your own extension. So in that custom source directory, which you'd wanna make, you create a new front end. And if you need to, a new back end. But that's beyond the scope of what we'll talk about here. Generate them with the CLI for Angular and then NPM run customize. So this is what you would do to create a new decorator to create an Angular component for the tab. So go into the front end app custom directory, generate a component, have a lot more typescript expertise than I do and go in and edit the app tab example. And I should mention that everything I show here, which I'm gonna blaze through pretty quickly because I'm gonna actually go through the directory to show this stuff. Is all available in the examples directory of the Stratos repost. So you can go in and do what I'm about to do and see how all this stuff works. So you can poke around. This is the end result. What you see once you do that build, you get an extra tab that appears and it comes up in the side of your window. So why don't we try doing this right now? I'm just gonna quickly, I'll actually get to that in a second. This is the command I will run to start the all-in-one Docker image. The reason this is the easier way to get started is that Stratos has two important components. It's got the Angular front end and it's got a go-based backend called JetStream.  You'll always find it under the Docker Hub orgs platform, SUSE platform group, slash Stratos. And the latest, you can run with this command. The important thing to see here is that the UAA endpoint and the Auto-Reg CFURL should be set to something that's real and working, whether that's a Bosch light thing locally or something running on Minicube or what I'll be running is an instance running on the public cloud. But it has to be a working UAA endpoint and a working CFAPI endpoint. You go in, NG serve, AOT false, and then the code that you're working on will become available on localhost 4200. That Docker image actually also exposes the vanilla, whatever is current upstream, the vanilla Stratos interface on port 5443. So you can switch back and forth and see what's running. And for other extension types, the approach is the same. I'm not gonna get into showing this side nav additions, but again, from this example directory, it's got all of the code examples for hello worldish kind of things. Another great place to look for examples of extensions is our downstream fork for SUSE Cloud application platform. So we actually have some things that are not in core cloud foundry. They're still all open source, but they're not generally relevant to everyone who's using this for cloud foundry. But you can go into the SUSE Stratos repository to see the difference between vanilla upstream and the extensions that we've made are also in this custom source directory to keep them separate so we can track it. Anything I say here is said better in the documentation. The team has done a great job at listing all the things you need to know to get started working on this. And why don't we take a look at the custom source directory now. So I think this is crazy. So I'm gonna run this Docker image, is that big enough? So you see here, I've pulled this earlier, I'm gonna connect to a demo cluster that I've got running up on EKS, SUSE Cloud application platform. And it says starting HTTPS server at 443, but we know that was actually mapped somewhere else to, this is gonna be tricky. Oops, bear with me a second here. I'll make it bigger in a sec. So this is vanilla Stratos. This is the latest build from upstream. I can see the applications that I've got running on my demo system that I'm using for the summit. We've got the various application views. And this is where you can add some tabs. And we can see generally what it looks like. This is the upstream version. The SUSE version has SUSE branding. I'm logged in as an admin, so I can see administrative functions that I wouldn't be able to see as a regular user. I can modify user permissions. All the things basically that you can generally do with the CLI, you can do with this because you're using the API. Now I'm going to go to the right repo, make the font bigger. And I'm going to do, I don't have, there's this example directory. And that has an example custom source directory. So all of those examples that were mentioned earlier are listed here under the app directory. So you can go through those and look. What I'm going to do here is just move that into the root directory. So now I have that in custom source. What did I say the commands were? NPM, run, customize. And that just pulls in the customizations. And then we should be able to do ng serve aot equals false. And this is going to reuse the back end that I have running in the Docker image. And it's going to use that for communicating as the API communication point with the UA and CF API endpoints. And once this is done, we should see this running on localhost 4,200. 4,200 and we'll see, not running yet. Okay, compiled successfully. I think I'm having, this looks completely different. I don't know why. If anyone was at my talk in Basel, I had even worse UI issues, projector issues. So we'll go back to the login screen where we should see that some, we've rebranded it ACME. So this is your company. We could log in and see that we've changed the logos all around, not all of the logos clearly, but we'll see on the application view that we have got this example. It's basically a hello world sort of thing and one here as well. So if you want to see how these are put together, go through that example directory. You can build it the same way. And this is the flow for when you're doing development in Stratos. So these are the basic building blocks of how we work in Stratos. And the team has done a great job of putting some examples together that can show you how it's done.  I'm really glad that Bo's team picked us up and decided that Stratos was gonna be the way they were going to build or rebuild, I should say, a UI for a bottle scaler. So firstly, I'm going to introduce what is an app outskillers project. Actually, this project we started two years ago as a collaborative builder. So I guess everybody knows what outskilling is doing, right? So basically what we provide is kind of a capability so that you can adjust your number of instance of your collaborative application based on the policy you define. So we support two type of policies. One is recording the dynamic scaling. So basically you can scale application automatically based on the performance metrics like CPU memory support response time. And the other type of scaling we call it schedule scaling. So you specify the time slot. You can specify no matter it's a recurring or just a specific time slot. Then when the time comes, then we automatically scale your application to the instance number that you defined. So it's actually last month we graduated this project to be a core Cloud Foundry Foundation project from incubating so it's not an incubator anymore. There are several deployment in production and also starting from the version 2.1 IBM Cloud in IBM Cloud Foundry Enterprise environment it's already included this outskilling service. From a user perspective, we also provide a command line interface as a CFCI plugin so that you can manage your policy. You can see what's going on with your performance application performance metrics. You can retrieve the scaling histories when your application is actually scaled and what's the number of instance, some sort of this thing. So besides the CLI actually, we also have a project in the Cloud Foundry community to build the web GUI, right? This is the one that we built previously. So it's a separate project and it's a standalone UI so you can deploy using Bosch separately and we actually doing the logging stuff through the UAA, through the SSO. So when you have a Cloud Foundry web GUI, something like a Stratos, basically you go to this URL and there will be a SSO so you don't need to sign on again. So at least the project ripple here so you can go there to find that. So some of the screenshots, so it looks like it's nice. So what's the reason why we actually rewrite? And because the mid-reason that actually Stratos is now becoming the defective web GUI for Cloud Foundry. And by extending the Stratos, we got quite a few benefits. The first thing is that actually you don't need to deploy a separate UI, you don't need to go to another URL to manage the application also in policy, right? You just go to Stratos and manage all. So it's a pretty unified experience and while the local and field will be consistent given you customize your Stratos with a different and a local field and for the auto-scaler service, actually it will use the Stratos local field. So it's pretty similar integration, the similar local field with a better user experience. And also we can simplify the development and deployment. Actually Stratos already provide a very good foundation for you to build the UIs. So we don't need to build a sort of code and what we can focus is just the UI side and some of the extension on the backend to invoke our auto-scaler service API. So we have less work, right? And for the deployment, we can leverage Stratos development model no matter. You can use different options to deploy this piece of work like you can deploy the Cloud Foundry app or deploy through Kubernetes help chart or Docker compose or even single Docker image, right? So it's pretty flexible. Well, the only concern is that how we can involve this UI separately. Now today, as Troy described, actually you have to fork the project and add what you want to do. It's still you need to do at the code level. But if you, because now the extension goes to the customer source directory and there is a symboling to the core source directory of Stratos. So when you do the extension, when you, if there is some change on the upstream master branch of Stratos, you rebate from that. So there will be no code conflicts. So you don't need to deal with the conflict. So it looks like it's not a big deal. You still have a kind of flexibility for that. I guess there will be a further work on how to make it more. We've got to slide a little later for that. So before I go to some of the details, how we extend Stratos, I want to show what it looked like when you have the other scaler, a web GUI in the Stratos, right? So now I can, you know, from the Stratos, I can deploy an application and run the build pack and it's up and running. And then you can go to the application dashboard. What you can see is like here, we have, you know, additional tab we call the other screw here. This is our extension, right? Then when you click the other screw tab, it will bring you to the conversion page. So because it's the first time, you haven't attached any policies, so that shows that policy undefined. Then you can then define the policy from the very beginning. You set up the minimal and the maximum surface instance and also the amount of scaling policy. In this case, I want to scale based on throughput. So I define the scaling policy. This means that if the average throughput is less than 10 for 60 seconds, I remove one instance and cool down one minute, this means that after I scale down and I will wait at least one minute before the next skin action kicking in. I also define another policy for scale out, right? So then you can specify the, you know, schedules for this type of scaling. In this case, I specify, you know, recurring scaling basically mean that I will scale at least, you know, to five instance during every, during, you know, 10 a.m. to 6 p.m. every Monday, Tuesday, and Friday. And you can also add specific dates for schedule scaling policy. Okay. Then you save the policy. The school, all school service will retrieve the policy and start to collect the, you know, your performance metrics and then trigger the scaling action. So then you'll go to the, you know, metrics page. You will see the throughput because you define the demand scaling based on throughput. Let's give some load to the application and then you can see the throughput goes up and it's up to the upper threshold. So after some time, there will be a scaling action showing that your application instance scale from one instance to two, and it will continue to scale out if you still load the application. Then I stopped the benchmark client. So there was no request going to your application. Then your application will scale in to the initial instance that is one instance. If you check the scaling history, the scaling events then basically shows that firstly it grows from one to two and two to three and then they shrink from three immediately to one instance. So this is the vertical demonstration. Let's see. Where is the? I know, right? Okay. Where did it go? No, how did we lose that? Just close. Did you close that? I don't think this is, I think we can work with this. Yeah. Sorry about this, folks. Why don't we do questions now? So the next is, I will go a little bit of details on how we extend that, how we implement this. Give me a second. Then that's already, is the wrong one? It's the wrong one. Weird. Yeah. There we go. Okay. So the students actually have a front end. It's anglo-based and the back end is written in Go language. So you can extend both the front end and the back end. So actually try, folks on how to extend from the front end. So actually there will be, for the back end that we call it jet stream. It's basically a proxy. So it received a HTTP request from the front end and doing some processing forward to the back end CF endpoint. Let's first say how we are extending the back end first. So the jet stream proxy have the plugin interface. So if you want to extend the back end, you just implement the plugin interface. So there will be different things you can extend. You can add another middleware to handle your HTTP requests. You can add another endpoint. You can also customize your routing for your HTTP requests from the front end. In all the skillet case, actually, we don't need the former one. What we did is actually we extended the routing kind of things, basically. We got the HTTP request from the front end. We just composed the right API endpoint for all the service at the back end. And we proxy that to the back end. It's pretty easy. And after you extend this plugin, implement this plugin interface, what you need is just add this plugin to the list so that it can be initialized. So the next is extend the front end. So what we did is go through the same way that Troy described, create the customer source directory and use the Angular command lines to generate the module and customer module and component. And then using the NPM run customized to actually link the customer source directory to the threadhose core source directory. And then what we do is decorate the component so that Troy knows that it's actually extension of the application tab, right? The here in the scene is we have kind of requirements to detect whether the auto-scaler is available because the threadhose manages multiple clover wrap environments. So some of the clover wrap environments may not have auto-scaler service. So we need a way to detect whether it's available. And if it's not, then we will not show the tab. What we did is we add the action and this is a health check. And for this actions, we have the NDRX effect to retrieve the health information from the backend to detect the availability. If it is successful, then we push the tab list to the tab to the list so that it will show up. If it is not, then we just skip. So that is then the next, how we are going to render the page for auto-scaler. I'm going to show a very simple case how we render the policy. So here, what we do is firstly, we create action for the auto-scaler policy service so that we can fetch the auto-scaler policy from the backend. And then we register an effect to list on this action. So this effect is actually fetch the policy and store that to the state tree so that the front-end can get the policies from using this entity key to this group here. Then next, what we do is actually, we define an observable variable for the auto-scaler policy service. And in the DOM tree, when the DOM tree is rendered in the browser and this observable variable is actually, sorry, is requested. Then it will trigger the app auto-scaler policy service, the action, to retrieve the policy. And then the front-end, we can get that policy from the state tree and then render the whole page. So these are the basic ideas, how we are extending that, how we render the policies in the application, the auto-scaler tab. So there are many others, right? We follow the same way to extend. So you can get more details of the code. Actually, we push the code, not our own repository, we push the code to the auto-scaler branch of Stratos. So if you want the details, just go there to see, to see all the code. Yeah. So I'll wrap it up really quick. I know we're a little bit over time. Sorry about that. We are working on a way to make it so that extensions can be published in separate repositories so that we have a proper plugin mechanism so that we don't have to do this thing with the custom source. It works pretty well right now, but long-term plan, we want people to be able to maintain extensions for Stratos completely separately. And we just want to do that because it's going to make it easier for users to add and subtract components and easier for maintainers to keep their code separate. We want to improve the back-end plugin mechanism. We want to improve and extend the documentation. Neil, the project lead, wrote that line item. I think his docs are pretty great, but he's always looking for continuous improvement on those. And also making it easy, just like when you create a component with the Angular CLI, to make something that will make a Stratos-specific, to generate a skeleton for a Stratos-specific extension. And then one of these things, the availability check that Bo was talking about, looking to see if there was an autoscaler to talk to, there's probably something internal with that. So I got to check with Neil if maybe there is something like that. If there isn't, we'll make sure it gets added. So thank you very much for coming.


Underneath here is another piece of Mazda hardware for the sim world. If you didn't think the R5 and everything was enough, they've come out with something even more awesome to add to that collection. Another sim wheel, their new FSR wheel. So this wheel is something I'm super excited about. So we're going to take that as you can see their new FSI formula wheel behind you is no one from Mazda racing. So it is an incredible looking formula style wheel with a nice display and everything like that. So we're going to take a look and we're going to actually open this up and we're going to take a look at the actual wheel. I'm super excited to take a look at this wheel. When I got this in I was, oh my God, I need to play with this because I've wanted a formula style wheel and for like GT racing and F1 and all that stuff. So we do have stickers like we do in most of our wheel sets so that we can change it all up. And of course, right here we have the wheel and of course the signature Mazda bags. I'm going to get this wheel out of here and that's really stuck in there. They don't want this thing moving around. That's for sure. If I can get it popped out, they really do not want that wheel going anywhere. So we're going to set the wheel aside so you can see the box is like really strong fabric. And of course we have the quick dampeners and things like that. So we're going to set this aside and we're going to take a look at this beautiful piece of Mazda hardware. The FSR wheel is something like I said, when I saw it, I could not wait to get it. So we're going to take a look at it first looks at this wheel. Oh man is this thing pretty. The carbon fiber with the leather, the screen and everything like that. Of course we have the actual quick release and we have some magnetic carbon fiber shifters and of course the clutch pedals and looks like we got a plug in for a display. This one has the same T style connection that the wheel from the R5 had. So that is something incredibly cool. This wheel is just insane looking. This wheel I can't even get over the fact of how cool this wheel looks right now.  And based off the picture, it looks like these actually light up and they do appear like they could be lighting up once we get it on the rig we'll be able to see. We have that really big display with the Mazda on the carbon fiber. We do have the shift lights like we do on all the other wheels, which is something I just touched that screen. Oops. And then we do have some thumb dials. Yep. Thumb dials that rotate all the click into same with the one on the other side for the diff. Yep. And that clicks. And then we have all these rotary dials. We have map with not just lines, they actually have, as you can see in trying to get the glare off numbers. So you can fully set this up for mapping with actual numbers. We have trash control. We have ERS, we have ABS, we have turbo and we just have all these metal these are metal dials too. This wheel is beautiful. We have some thumb sticks, which also go in. This wheel is incredibly beautiful and a very amazing piece of work. You know, got nice stitching and everything like that. This wheel, if you want a formula wheel, this is definitely, I can't get over how pretty the carbon fiber and this screen, once we get this plugged into the rig and that screen goes on, you can see the energy like tag hanging there. So once we get this on and get the screen going, this thing is going to be incredible looking. This is by far the prettiest wheel I've seen. And they came out with the GS wheel originally, which didn't have the screen and this wheel now has this screen.  Very nice quality, thick carbon fiber, a little bit of polymer down there, of course. But I just can't get over how amazing this thing feels. It's like the perfect size and all these rotary dials and everything are just like physical clicks and all these buttons. If you can change the color of these buttons, that's going to be insane.  So we can actually see what this thing looks like. I'm super excited to get this going. So let's go get this thing on the rig and we're going to see what this actual, you know, FSR wheel looks like when I plugged in. So once again, another amazing piece of hardware. Can't think Mazda Racing enough for sending this out, as well as the R5 system and everything like that. Big thank you to Mazda Racing, me and partner with me and the channel. So let's get this thing on the rig and yeah, see how this thing lights up. All right. So we have the Mazda FSR wheel all set up. We're going to plug it in through our rig onto the R5 wheelbase and we got some tracking of lights, the Mazda symbol and of course now we have full display and buttons and everything. This wheel, all this thing is so nice feeling and it feels even better on the chassis and on the rig. So we're going to switch over to the desktop cam and see what we got going on here. So we do have this and what kind of options do we have. So we have a lot of different options with this FSR wheel. We have shift lights. We have brightness of shift lights. I believe that's brightness of display maybe. Oh no, that's just shift lights. So here's dashboard settings, brightness, miles per hour, Fahrenheit. We have all different kinds of dashboards set up that we can change to. That is so nice. All these different dashboards that we can put on and use, they've got a lot of presets. So we're going to go back to, I personally like, personally like this one right now. So we're going to set this one up right now, kilometers an hour. What is this? Options. Oh, so there's button, different combinations. All right, let's see. Press, bull, sometimes, simultaneously, button, color, wait a minute.  And we can just make them whatever we want. Color combinations. Oh, there it is. That is awesome. Okay. Not going to lie, that is, that is pretty sweet. Now if I push these, this is going to save it. Oh, it does. So now if we take the wheel off, we plug it back in. Does it save those? Or is that something we have to do every single time? No, it saves it. That is awesome. So what do we got here? Let's see. Right clutch pedal and toggle. Oh, you can just toggle straight through the displays. Oh, okay, that's even better. So this wheel just keeps getting better and better. That is so sick. Okay. Yeah, that is, that's beyond, that is beyond awesome. So we should probably hop into a game. We're going to go into a game and see how this thing feels in a game. So we're going to get that switched up and we're going to get into a game and we're going to go full send. What better game than in F1 2022? So we're going to go full send and just see what we can do. I don't think I have much that up. So definitely need to fine tune some wheel settings. But first, testing with this wheel. This feels so amazing. That display, okay, we almost broke loose. That display, super cool.  Oh, I have not played an F1 game in a minute. Definitely need to get some settings, but the factory F1 formula settings do feel super nice. And I'm going to lie, I'm super stoked to have this wheel in my arsenal of Mazda equipment because this wheel would also be great with the RSV2, the mechanical paddle shifter feeling super nice.  I'm having a blast with this wheel. Can't think Mazda racing enough. Well, I knew that was going to happen. Mazda racing enough for sending out this FSR wheel. Definitely going to be doing a lot more F1 as well as GT racing because this wheel can be used in GT racing as well. Turn that card out a little bit. That's a little loud. This wheel can be used in GT racing for like GT3. We totally missed that. And things like that. So we're going to be doing some racing and stuff, but I just can't get over how awesome this wheel looks and feels. If you guys want to pick up your own Mazda racing equipment, all the links will be in the description box below. You can go through the reference code for Evil Rabbit when you go, if you want to go purchase yourself an R5 system or maybe this FSR wheel or some of their other RS wheels, CS wheels or the DS wheel. This wheel with the display is just such a beautiful piece of equipment. And I can't wait to use this more. So make sure you guys follow me on all social media, all that you're found in the description box below. I thought I could make that. I'm Evil Rabbit. I'll see you guys on the track.


Good morning everyone. Good morning. Thank you. Thank you so much for for coming to our talk. This is this is our first KubeCon and we're really excited to be here. My name is Pratima Banerjee. I'm here with my colleague, Ken Hoan. We're both research engineers from a small business called Real-Time Innovations, which is based out of Sunnyvale, California. And we're here today to speak on the topic of bringing real-time performance to the Edge Cloud. More specifically, we're here to introduce the Data Distribution Service or DDS in Real-Time Published Subscribe or RTPS standards to the to the KubeCon audience here. So I'm going to start the talk with an overview of DDS and RTPS and the standards and the benefits that they bring to the Edge Cloud environment. And then, Ken Hoan is going to conclude by showing some DDS performance benchmarks that really highlight the power that these open standards can bring. So before we get started, just just a little bit of background about us. So Real-Time Innovations or RTI was founded back in 1991 by a group of researchers from the robotics lab at Stanford University. So they were interested in building software that could provide the kind of fast, reliable communications that are needed by robots that operate in ad hoc teams. So for communicating things like sensor data, control messages, events and status, and their work really became the foundation for what later became the DDS and RTPS standards. So to continue on that thread, today RTI provides communication softwares for domains such as autonomous systems, including commercial automotive, health care, so including things like telemedicine and patient monitoring, industrial automation, so things like smart manufacturing and industrial robotics, energy with smart grids, renewable energy, and in defense and aerospace. So a few of these are highlighted on the slide here. But in addition to these product solutions, we've also been involved in a lot of standards associated with these domains. So things like AutoSAR and ABCC and the automotive space, things like ICE and OpenFMB and like the medical space. And then in the robotics space, for those of you who might be familiar with ROS2 or the robot operating system, DDS is actually the underlying communications protocol used by the ROS2 operating system. So the interesting thing is that all of these different domains have a certain set of challenges in common. And they all have requirements for communications that span edge systems, where you need very, very, you need to require very, very strict timing to enable device to device communications. And you might include embedded systems in those areas. They also have a need to communicate at the edge cloud systems, which have slightly less strict timing requirements, but they're still very, very sensitive to latency. And finally, they have a need to provide connectivity up to cloud environments that can support a little bit more latency tolerant use cases. So our approach to addressing these challenges is rooted in the data distribution service or DDS and real-time published subscriber, our RTPS family of standards. So these are open standards for secure, interoperable, real-time data-centric communications. They enable platform independent, transport agnostic, and loosely coupled peer-to-peer interactions. And they provide controls and patterns so that we can achieve really ultra low latency at the edge and the edge cloud. So I'm going to get into each of these points in a little bit more detail in the slides that are coming up. But from an overview perspective, these are really kind of the key benefits that DDS and RTPS bring to the edge and the edge cloud. So just a quick note here. So DDS and RTPS aren't really standalone standards. They're actually, you can think of them really more as a family of standards. So they are governed by the Object Management Group or the OMG. And the family of standards around DDS and RTPS are actually provided comprehensive framework for real-time data communication and interoperability. So they're kind of the core. So on the slide here, you can kind of see the core standards for DDS and RTPS for the API and the wire protocol. But then also around that, you can see that there are language bindings for specific programming languages. There are standards for security that get layered on top of the DDS communication protocols. There are type definition format standards in IDL, XML, and JSON. And then, finally, there are specifications for lighter weight versions of DDS for resource constrained environments. And that's the DDS XRC standard that actually just recently came out. So one of the things that we wanted to explore with this talk is to understand where there might be synergies between these standards that have been developed in the OMG and also so that we can kind of leverage opportunities for maybe understanding where the synergies might be between these standards at the OMG and then the open standards that are developed as a part of the KubeCon and the cloud-native community. So what is DDS and what is it all about? So the core of the DDS standard is the data-centric published subscribe model. And we can kind of think of this as a shared global data space. So applications interact with one another by directly accessing that shared state and the interactions with the communications protocol revolve around interacting with the data itself rather than focusing on the endpoints or the communication channels. So in a way, you know, you can think of it that the applications are actually behaving as though all the data that they need to operate is actually available to them locally, even though the data producers and consumers are really part of a really large distributed network. And another way of thinking about it is that the interface to the state distribution system is actually the data structures themselves. So and just one thing to note here, persistence, data persistence and data storage are actually orthogonal to this whole state distribution mechanism so that there's actually services that you can actually link in to the DDS data bus to actually store the data off to persistent storage as you can kind of see represented on the slide here. And another key point to make about DDS is that it only uses peer-to-peer communications. So this allows for direct communications between the data producers and the data consumers without relying on a centralized server or a broker and it reduces bottlenecks and enhances system reliability so that your system cannot be affected by the loss of one or more brokers that are in charge of managing the data. So DDS is loosely coupled, which means that components can interact independently without prior knowledge of each other and this kind of architecture promotes flexibility and adaptability so that DDS is optimally useful for complex distributed systems. So I also want to note here that the RTPS standard actually includes the wire protocol for DDS, which is called the common data representation or CDR serialization format and that specifies how data is transmitted between the producers and the consumers. And so the end result here is that we can achieve the key benefit of interoperability between producers and consumers that are located on like vastly different platforms and transports. So you can have people running on really a plethora of different architectures and still able to exchange data using this common wire protocol mechanism. So the final key feature that we wanted to highlight here is that DDS offers a very granular quality of service configurability and that configuration can be done per individual data flow. So per, you know, individual data flows from within specific producers and consumers and for specific data types that make up that shared data space. So this allows users to tailor communication parameters like reliability, latency, resource usage for individual data streams. So by customizing the QoS for each data flow, DDS can optimize the resource allocation and network efficiency. So for example, you know, you can send critical data with a really high reliability setting and optimized for very, very low latencies while, you know, less critical data, you can you can set those configuration parameters a little bit more loosely so that, you know, you might not need that same stringent level of reliability or those same latency guarantees. And this kind of flexibility ensures the DDS can adapt to a variety of different requirements for real time systems, which, you know, which can vary widely depending on what domain you happen to be deploying to. So one way of thinking about the kinds of QoS that you can configure in DDS is in terms of the CAP Theorem. So you can optimize for message delivery, you can optimize for consistency and or, you know, availability too. So you can kind of tune your configuration parameters to kind of optimize, you know, based on the types of guarantees offered in each of these areas. And again, it's important to note that they're, you know, I mean, this is kind of the real world. So there are going to be trade offs, right? And, you know, you're always going to have to make trade offs between the different types of guarantees that you want to enforce. But the nice thing about DDS is it offers a lot of very fine grained tunables so that you can really ensure that you're getting the exact type of performance guarantees that you need. All right, so to summarize, DDS offers a powerful framework for the Edge Cloud with a range of benefits. So the first one is customized reliability. So DDS can accommodate situations as specific trade offs. So as we were just saying, we can allow for very fine grained tuning of reliability, resource utilization, and determinism based on specific requirements. It allows you to set up mechanisms for efficient data transfer. So you can set things up like sender side filtering to limit the amount of data that's actually getting put on the wire. DDS also enables eventual consistency. But in this environment, eventual consistency actually takes place within the timing requirements needed for real time systems. So when we're talking about achieving eventual consistency across all subscribers for a given set of data, we're talking about a consistency that's achieved within microseconds. So that's really the kind of timescale that we're talking about, the eventual consistency guarantees being achieved in. And then finally, data model evolution. So the DDS type system supports the definition and evolution of data models over time while maintaining interoperability. So we saw earlier that there was a type extensibility standard. So as a part of that standard, the DDS type system can actually be evolved within a deployed environment so that new applications can evolve to using new types without really disrupting any legacy applications that need to be maintained. So it was kind of our expectation that not too many people in this audience would be familiar with DDS. We were pleasantly surprised a little while ago to find that there might be at least a few people who are a bit familiar. But to kind of help maybe drive home some of the points that we were talking about, we just wanted to offer a comparison exemplar between DDS and Apache Kafka, which some of you might be a little bit more familiar with. So at a high level, if we're kind of doing this side-by-side, DDS is designed for real-time applications providing determinism. And it provides this fine-grained quality of service configurability and contrast. Kafka is optimized for high throughput streaming data and log-based data streams. And it's commonly used for a lot of analytics applications and it's used for a lot of data integration. So the Kafka architecture is cluster-based and it requires producers and consumers to interact with a central broker. DDS is broker-less, so all the interactions are peer-to-peer as we were just discussing. DDS supports both the published subscribe and the request reply model, and Kafka is primarily published subscribe. Kafka runs over TCP. DDS is actually transport independent, and it can run over UDP. And most recently, there's actually a spec in place for time-sensitive networking, which is a real-time networking protocol. So for latency-critical applications, you can actually run over these other protocols as well. And finally, Kafka is agnostic to the type system, whereas part of the definition of DDS actually includes the type system as a part of the protocol. And that type system is what's used to define the global data space that we were talking about earlier. So just to give a little bit of context and to show a couple of real-world use cases for how DDS is used, we're going to go through a couple of usage scenarios for DDS. So the first is what we're going to be looking at, an autonomous driving type of application. So in this scenario, the DDS layer data bus is used for the vehicle control system. And so we can see the structure has a few distinct layers here. So the first layer, kind of in the green box there, is the sensor and sensor fusion layer. So at that lowest level, the various sensors, sensors like the lidar, the radar, the cameras, et cetera, are actually collecting the real-time data about the vehicle's surroundings and doing things like object detection, looking at road conditions, traffic information, stuff like that. So there's kind of the sensing layer of the data bus. Then there's the controls layer, which is kind of that middle layer, which is that first orange arrow there. And that acts as the brain of the vehicle. So at that layer, there's aggregation that's going on that is enabling decision-making components like situation awareness and vehicle control. So you kind of have that at the middle layer. So you can kind of think that as the edge cloud type layer in this scenario. And then finally, there's the connectivity layer. So it's that top cloud layer up on the upper right-hand side. And that layer implements connectivity and reach back to off-vehicle data sources for functions like traffic management maps, things like that. So a key point to note here, though, is this green arrow along the left-hand side. And that's that there's a single-shared data model. And again, kind of going back to that shared global data space. So there's a single-shared data model that spans all of the different layers here. So that you don't need to do any data or protocol translations as you're going up through the different layers. So from the edge layer up to the edge cloud layer up to the top layer in the cloud, you really have a consistent set of data structures, which makes the architecture blend seamlessly together. So the second use case, and it follows kind of very similar pattern to the to the first one, is from the medical industrial internet of things or IIOT domain. So here again, you kind of see the same layer data bus architecture. And you see at the very lowest level, you have the devices within a given hospital room. So you have the given sensors and monitoring equipment within the, you know, within a given hospital room. And then that gets aggregated up to the higher level hospital system. So it might be like a hospital ward or like a nurse's station. So that's kind of your edge cloud layer there. And then finally at the top layer, you have your cloud or data center layer where there's a higher level of data aggregation happening.  And once again, we see that there's the single-unified data model that's actually spanning all those layers. So you don't need to waste time in processing doing a lot of data translations, data mappings, or protocol translations. So at this point, I am actually going to hand off to Kyung Ho to talk more about DDS performance. Yeah. Thank you, Pratima. Yeah. So from this slide, I'd like to introduce some of the DDS performance numbers that we measured in the edge and cloud environments. And I believe these numbers are going to provide some of the insights into expected performance that you can achieve when deploying DDS applications in such environments. So we actually offer a performance testing tool called the PERF test for users to assess DDS performance within their own environments. And this tool evaluates two critical performance metrics, throughput and latency. And we actually use this tool for our performance experiments to measure the latency numbers. And one challenge we encounter when we measure the, you know, performance in a distributed environment is the clock time variance across the different machines. And this variability can significantly impact latency numbers, especially latency numbers in a micro, you know, microsecond range, so that to address this issue, this tool actually calculates a round-trip latency and then divided that in half to derive the one-way latency, which actually providing a more accurate representation of latency experience in the network. So we conducted performance measurements with Kubernetes to gain insights into how containerization and virtual networks impact real-time applications. Our approach was deploying PERF test application in a Kubernetes cluster. And before jumping into the performance numbers, I just want to give you some idea of how DDS operates and how we measure DDS performance in this environment. So DDS by default operates on publish and subscribe messaging pattern. And to measure the performance, we deploy publisher pod and subscriber pod and measured a message from a publisher to subscribe to get the latency number. And as Pritima mentioned, it is important to note that DDS is fully decentralized peer-to-peer architecture so that there's no brokers in between between publisher and subscribers. And so that we don't need to deploy additional component for communications between the subscriber and publisher and subscriber. They directly communicating each other. And DDS utilizes multicast for its built-in discovery. But most of Kubernetes CNIs do not support multicast so that to resolve this issue, we need to deploy a component called the Cloud Discovery Service, which is going to provide a discovery for publisher and subscriber applications to discover each other and communicating each other. But after discovery phase is done, they're communicating directly each other peer-to-peer. But to access this Cloud Discovery Service, we needed to create a cluster IP service for perf test applications to access Cloud Discovery Service. And then the last one that I want to talk about is that we use node label for the experiments because we want to we don't want to deploy publish and subscribe applications on the same node because we want to measure the performance over network so that we assign different node labels to deploy it in the different machines. So from here, I would like to talk about the performance measurements in three different environments. First, performance at the edge with bare metal servers. And then second is performance numbers in the edge with Kubernetes. And the last one is Cloud with the Kubernetes. So let's first let's begin by looking at the performance number from the edge with bare metal servers, which actually specifically located in the RTI office in California. For all experiments, we measured median latency while changing two different parameters. The first one is sample size, ranging from a small 64 bytes to the large, like a 63 kilobytes sample. And then different quality of service settings, reliable and best effort. So DDS by default is operating over UDP. It does not provide reliability of the message transmission, but DDS implemented reliable protocols on top so that for users to decide if they want to reliably send a message they can do, otherwise they can do a best effort. And as the data shows, DDS delivers incredibly low latency with small message sizes. You know, we're seeing latency as low as like 20 microseconds. And even the large message sizes, like it's around like 180 microseconds for both best effort and reliable. Continuing our performance evaluation journey, we shifted our focus into the same edge server, but using Kubernetes with Calico as the CNI. And we used the default setting of Calico here. And the results provided insights into the impact of container orchestration at the edge. And incorporating Kubernetes with Calico CNI, we observed a slight increase in median latency when compared to the bare metal servers in the previous slide. For small message, latency is around like 30 microseconds. And for large message sizes, it is extended to around like 300 microseconds. Let's now take a look at a plot that draws a comparison between the performance of bare metal servers and Kubernetes. And this comparison reveals that how Kubernetes, particularly like virtual networks, introduce different degrees of overhead depending on the message size. And Kubernetes with virtual networks introduces a modest overhead, especially for small messages where the difference in latency is around like 10 microseconds compared to the bare metal servers. And this indicates that it is well suited for small messages like a command and control type of message, which typically falls into a small size. And however, it is important to note that as message size grows, the absolute latency difference becomes more noticeable. For larger messages, there is indeed measurable overhead with Kubernetes. Even so, this overhead remains below 300 microseconds. This means that even for large messages, I think Kubernetes remains a viable option, providing acceptable performance. Lastly, let's look at cloud environments, specifically that we used AWS Elastic Kubernetes Service, EKS. And in this scenario, we anticipated certain changes as cloud environments often introduced more overhead because it has shared resources and also additional virtualization layers. So for small messages, we observe a latency of approximately 230 microseconds. And while for larger messages, the latency increased to around 700 to 800 microseconds. Now, let's take a look at the comparison of performance between the edge and the cloud environments, both using Kubernetes in this case. As the graph shows, the performance difference is quite significant. However, the variation is in line with what we expected, given the inherent difference between the edge and the cloud. It is important to note that we conducted this test on T2 small instances. That means definitely there is room for improvements with larger and dedicated instances. So here, the key thing we want to talk about is that we provide a performance tool, as I mentioned, that helps you to gauge the expected performance in your own environments. And this tool serve as a very useful resource for understanding how DDS will perform in your specific setting. Taking a closer look at this graph, you'll notice that the best effort latency tends to be higher than reliable latency, interestingly. As I mentioned, in a reliable setting, you need to do additional kind of work just to make sure your message is delivering reliably just by sending a heartbeat or ECNAC messages. But interesting for large messages like 16K and 163K messages best effort latency is high because we actually use the DDS fragmentation feature here. We actually selectively apply this DDS fragmentation for a reliable setting. And then the message size is larger than the MTU size, which is around 9,000 in AWS. So the reason why I apply this is that we could see some of the high latency when the message size is higher than MTU size in AWS so that we apply this feature so that DDS is fragmenting the messages instead relying on the IP fragmentations under the hood. So we could see that incorporation of DDS fragmentation generating a substantial performance improvements here. So this is actually all we have today. And I want to wrap up these presentations with these two questions that would guide us to our next step. As we presented today, DDS standard support data-centric and peer-to-peer communications offering incredibly low latency for real-time use cases. And it is a well-established connectivity communication technology for the edge. While it has found its place in the edge, we would like to explore potential needs and benefits of extending its capabilities into the cloud environments. As an example, we can look into cloud-native extensions for DDS and these extensions could enable DDS to seamlessly integrate into cloud-native architectures for applications, require low latency and real-time communication requirements. And so here we are really looking forward to hearing from you about any kind of cloud use cases that require low latency and real-time communications. Thank you for joining us today and we look forward to the insightful discussions and collaborations ahead. And if you have any questions or feedback, please use this QR code to leave them. Thank you. Yeah, I think we can take questions now. Thanks for the talk. So I'm Tom Wain with Sony. By the way, I am the member of the TSC for a robot operating system. And I got a question about, as you mentioned, about CNI implementation, most likely it doesn't support multi-casts because it generates the different problems and necessary packets to using a multi-cast. Are you guys working on with some CNI implementation to enable multi-cast? So you're asking we are aware of any CNIs supporting multi-cast? No, are you guys working on specific CNI implementation to enable multi-cast? As far as I know that we've not used to be, but it's EOL now for the open source project for the CNI that works with multi-cast. Yeah, so we don't work on our own CNI implementation, but we recommend some of the CNI that do support multi-casts like QNation, BifNet or others. So if they want to use multi-casts for discovery and also for user data, if they want to, that's what we do now. But I don't, we didn't really kind of plan that we kind of develop kind of our own kind of CNI to support multi-cast. Okay, thank you. Yeah, thanks. Hi.  Like what, the diagrams of, you know, like you have a relay where one data bus plugs into another one, what sort of latency are we looking at between those two points? I think that kind of, you know, it is, it is situation specific. And I think some of the benchmarks that we've done and those were between the offices in California going up to, you know, like Amazon environments were on the order of, I mean, still below a millisecond, but on the order of like a few hundred microseconds. So it's those levels of latency. So still within the microsecond range, but not in like the tens of microseconds maybe. Yeah, yeah. Awesome. Thanks. Hello. Miguel Martinez, Jonder. First time hearing about the specification, I'm interested to know, if you know about adopting CAN bus as part of the protocol that DDS supports. Maybe it's a question for the specification itself, but I'm not sure if you know about CAN bus. I think like, you know, some of our like users in the automotive, you know, space, they're using CAN bus and they're adopting DDS as well, so that instead of like adopting CAN bus as part of DDS, you know, maybe we can kind of look into kind of gateway so that if you want to convert in kind of CAN bus data into DDS space and vice versa, that might be a kind of way to go. If you already have systems running over CAN bus, but in addition, you want to do more kind of additional, more complicated things like autonomous, you know, driving logic and you can develop DDS and then you can have that kind of gateway to get the data from the CAN bus and vice versa. Yeah. Thank you. Well, maybe I didn't get the comment. My understanding is we need to do a layer between CAN bus and DDS specification, right, so we can adapt it. Yeah, and also we are part of the AutoSAR community so that I can just provide you, you know, kind of specific things that we are doing in RTI regarding automotive and CAN bus. Yeah. Thank you. Yep. Hi, I'm A from HPE. We have some customers in the automotive domain where the subject of latency does come up. Now, looking at your performance charts for the larger packets, it showed that on Kubernetes, the latency was about double the bare metal scenario. Have you considered introducing a way to artificially add latency so people can tell at what point they need to start getting worried about latency? Like, you know, it could be that 300 milliseconds latency versus 150 is critical for the application or it could not be an issue at all. So how do people know when to, you know, what order of magnitude of latency starts being a problem for them? Oh, so I think that's kind of situation dependent. So there are metrics that can be recorded. So there are statistics that are actually part of the protocol. So you can actually gather those latency statistics so that, you know, all that information, like all of the statistics around not only latency, but also around like lost messages, you know, if there are like, you know, like ACNAC types of statistics, all that is actually provided by the protocol that can be recorded that people can actually put like thresholds on to indicate whether or not there's a critical condition or like a warning level that needs to be addressed. So yeah, those things are all kind of part of the statistics API that's included in DDS. Sounds good. I think we can stop here. Yeah. Yeah, thank you. Thank you, everyone. Thank you.


Hey everyone, welcome to Hegan Iruthel. So it's time for your pre-download and it's available already if you are in Singapore, Malaysia and Canada. But if you do not belong in these countries, you may try. Okay, I'm just gonna tell you this outright. You may try to download the Google Play Store in those countries. And you can try to download the game from there. Okay, it's not impossible to play this game for soft launch. It's just that you'll have to, you know, do some research on how to download the game for the soft launch. So for Singapore, Malaysia and Canada, you can download the game. It was already allowed earlier. So this was up at 11 GMT plus 8. And we have here on display Armand. So again, guys, the meaning of pre-download is you can download the game today, but you can actually still, you have to play it on February 23rd. It's just a pre-download, meaning at least on the 23rd. You won't have any problem downloading it anymore. You'll be playing it automatically once the servers are live. Okay, so I'm just gonna be going through a couple of characters. Just to have, just to remind you guys of who the notable characters are, who you're gonna be re-rolling for. I'm gonna do a extensive re-roll guide anyway when the soft launch comes in. But again, at least I'll refresh your memory on who are most notable, who you don't want to get based on my experiences in the CBT. Take note that the tier list that I'm gonna be presenting is not updated. I've researched through a lot of tier lists and I haven't seen an updated one. When they added new characters, Arman is not even added there and she even is a good character. So let's move on to that tier list and see whether some of the characters there are familiar to you and some might be new to you. Okay, so we will start with, this is actually by PocketGamer. So far I think it's more of a short description of what they have. All of the characters or all of the heroes are the same with the other tier lists, not the updated one for the last CBT. But I'll do my best to at least jog your memory in terms of who is good and if I agree with their tier list. So more or less this is for tier C. So Asa, Celia and Ume, they're in the bottom of the tier. I don't think you'll be re-rolling for them. So let's move on to tier B. These ones are worth getting but not for the re-roll, especially for Roko. Roko is a good healer to have. So I used Roko during the CBT. Siakum is also one that is actually nice to have. But again, they're not on the top tiers. Okay, moving on to tier A. So I think this is up to tier S. So for tier A, these are your secondaries if you don't have characters in tier A. So the ones that I think are good here that I have used is Fenny. She has actually a good, she is ranged by the way. Good damage, good AOE damage as well. Queen is a assassin, not so good. I think she's in the middle in terms of damage. There's going to be a better assassin from her but she is actually good to have. Who else did I use here? Euphoria, I did. But Issa, Issa, not so much. Probably Issa is going to be, she's a caster. So debuffs. Euphoria is going to be a hoplite. So shield. And Fen, as I've said, AOE attacks deals a lot of burst damage. So for here, the best ones to get for tier A is going to be Fen and Queen. And moving on to your tier S, these are the must haves. But for the five here that I mentioned, Chlora is easy to get. She is lower rarity, not the top rarity, not S. I'm not sure if rank A, she's not the top rarity. So it's easier to get Chlora, so Screamer easier to get as well. The ones that I think you should focus on is these three. Gildan is the best tank or defender that the game has. This is Gildan. Illuya will be the best assassin that you can get. So if you want a very high damage assassin, then Illuya deals a lot of burst damage. Deals massive damage, Illuya. And Cerslith is not an assassin, but she is, I think, a warrior type. So very good DPS as well. So for the first CBT, my main DPS was Cerslith for the last CBT. It was Illuya. So both of them are used. If you plan to re-roll guys, Cerslith and Illuya is actually the way to go. So Gildan, if you fancy a defender, then go for Gildan. But again, primary re-roll target will be Cerslith and Illuya. I can't vouch for the new characters. I really haven't seen much. I used Arman. I had terrible luck in pulling for the new characters added on the last CBT. But so far for this tier list. And anyway guys, I'm gonna be updating... I'm gonna be putting out an updated tier list as soon as characters are available and I am able to test them out. I'll be putting out a more detailed tier list. But at first glance, you won't regret it if you get Illuya or Cerslith. This is it. If you're going after a re-roll or just looking for a good DPS character. So that is it guys. This is just a reminder, probably another additional information. Just in case you are waiting for more information on characters on how to start. I'll be putting out a lot of videos on day one, especially on team build. Which you really need because once you get your first good character then you want to figure out who you want to put around them. The team build, the basic, the beginner team build. And also the next one would be fast progression. How to progress fast through this game even if you're free to play. Okay guys, so thank you very much for staying this far.  This is The Warden and I'm out of here.