 Hi everyone. Thank you for attending our presentation. I'm Seiji Koizumi, Product Manager at Densho Corporation. Today, we would like to talk about creating request-buffering filters for each device. First, we would like to give you some background about the activities. Then, we will expand our technical challenges under how to solve it by using Envoy. As background, vehicles will be like smartphones. Vehicle applications keep creating new values for vehicles, so we are developing a Misaki platform which brings cloud-native ecosystem to the vehicle application. However, there are some technical restrictions, such as a narrow mobile connection, no LTE signals, and heterogeneous network connection. So, to remove a barrier between vehicle and cloud, network control using Envoy is quite important. Now, we will move to the technical details. That part will be presented by Tomoya. Thank you Seiji. Hi, my name is Tomoya Amachi and I'm from Woodways. So, next, I will explain why do we use Envoy. Next slide. Envoy is a good solution for cross-cutting concerns regarding networking. We want to run variable applications on edge devices. We don't know what's the role of them. However, we know they need to upload data to cloud external servers. So, what are our network concerns? Let's introduce our concerns on edge. Next slide. Our first concern is network costs. The mobile network is highly available but expensive and Wi-Fi networks are basically cheap but are limited area coverage. Developers want to change network types depending on the application. For example, in machine learning data processing, we want to use Wi-Fi because of the large volume of data. However, for current area map data, we want to download as fast as possible. So, we want to use the mobile network. And data value changes depending on the situation. We want to change data and network combinations dynamically. Next, our second concern is unstable networks. Edge devices are not always connected to the network. For example, some tunnels do not have network connections and some places do not have mobile service coverage. With that envoy, edge application would need to implement background backup solution to these problems. Next, I will introduce how we use envoy. Our project is called Misaki proxy. Misaki means divine messenger in Japanese. And a divine messenger is a fork in Japan, so our icon is fork. Misaki proxy consists of two binaries. The first Misaki envoy that is based on envoy. The second is a Misaki proxy manager. They communicate with the file system. I will introduce each of them, but basically, they all send requests from the edge through Misaki envoy. And the Misaki proxy manager supports Misaki envoy. Next, first, I will introduce Misaki envoy. Misaki envoy contains two custom envoy filters and forked by envoy filter example. We use two custom filters. The first is HTTP filters that control HTTP requests. The second is network filters that control TLS and other requests. We can change configuration per host using typed per filter config. Misaki envoy provided a buffer request during buffer duration. If there is no network connection, well, the network type doesn't meet requirements. Next slide. For example, this configuration file has network type set to Wi-Fi. So if the edge is connecting to a mobile network, the Misaki envoy buffering the request. Up to network type changes to Wi-Fi. After buffer duration, if the network is still unavailable, save the request data to the file system. Buffer duration set at one minute in this configuration file. The data will be released by Misaki proxy manager when the network available again. If we use TLS, we can save request data, so we just drop it. TLS connection is one of our future tasks. Next, second, I will introduce Misaki proxy manager. It contains a lot of features in one binary and the features are mainly divided into startup scripts and runtime processes. Startup scripts, Misaki proxy manager, edit IP tables, and all requests forward to Misaki Envoys port. It also disables the default DNS resolver because we want to run an original DNS resolver that resolves a domain name, even if network unavailable. Runtime processes contains following features, check network status and network type, update envoy configuration dynamically, run an original DNS resolver. Finally, a recent request and save response data when network is available. Request data saved by Misaki Envoys. That exceeds buffer duration. Misaki Envoys returns the saved response when the application requests the same headers and body. Next, today, I will introduce how these components work. Here is an example case study. The IH application requests data when offline. After a while, the network recovers during buffer duration. Before I start to explain how components work, I will introduce what happens when requesting from application. Next slide. Before the data is sent to the target server, the client needs to resolve the domain name. Basically, the DNS resolver on the edge sends a request to the cloud DNS server to resolve it. Next. When offline or in a match network type, Misaki Proxy's DNS resolver returns a dummy IP and buffers the request. The process doesn't need to access an external server. It is all done on the edge device. If the network is available during the buffer duration, Envoys will re-resolve the domain name and send the request to the target server. Next. Conclusion. First, we have developed a proxy for vehicle edge devices. Second, our approach solves vehicle restriction, and it helps application developers to develop edge apps. Finally, feature tasks. We are trying to enhance multiple Misaki Proxy as a service mesh. Thank you for listening. I hope you enjoyed the presentation. If you have a question, please ask us on Twitter.