Cloud Native Computing Foundation EnvoyCon 2020 - Virtual, 12 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Creating request buffering filters for edge devices - Seiichi Koizumi, Tomoya Amachi

Description

Creating request buffering filters for edge devices - Seiichi Koizumi, Tomoya Amachi

We are developing a proxy for edge devices that work on an unstable network. Using custom envoy-filters.This session will speak how to manage request data when changed network interfaces and network statuses.

Our proxy use cases on the following lines:

1: Run applications that do not suppose in an unstable network onto vehicles. Even if the network is unstable, misaki-proxy buffers the request in a queue. So that the application does not need to add retransmission processing.

2: Upload large files only when vehicles are connected to a WiFi network. 3G/4G network is more expensive than WiFi. Therefore, only with WiFi can you be able to request large amounts of data. You can set the type of network you want to use for each destination domain.

A

Hi everyone thank you for attending our presentation, I'm sejj kozumi product manager at denser corporation today, we would like to talk about the creating request, buffering filters for its devices.

A

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 omboy.

A

As background vehicles will be like smartphone, big application is keep creating a new values for vehicle, so we are developing misaki platform, which brings cloud native ecosystem to the vehicle application.

A

However, there are some technical restrictions, such as a narrow, mobile connection, no lt signals and heterogeneous network connection, so to remove a barrier between vehicle and cloud network control using onboard is quite important.

A

Now we will move to the technical details. That part will be represented by.

B

Tomoya, thank you sadie hi, my name is tomoya amati and I'm from uduis. So next I will explain why do we use envoy next slide?

B

Envoy is a good solution for cross-cutting concerns. Regarding networking, we want to run variable application on x devices. We don't know, what's the law all of them, however, we know they need to upload data to cloud external servers.

B

So what are our network concerns? Let's introduce our concerns on edge next slide.

B

Our first concern is network costs.

B

The mobile network is highly available, but expensive and wi-fi networks are basically cheap, but a 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.

B

However, for current area map data, we want to download as fast as possible.

B

So we want to use the mobile network and data value changes depending on the situation.

B

We want to change data and network combinations dynamically next. Our second concern is unstable networks.

B

X 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 without envoy. Each application would need to implement backgrounds, backup solution to these problems.

B

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 fox in japan, so our icon is fox.

B

Mizaki proxy consists of two binaries, the first misaki envoy that is based on envoy. The second is the misaki proxy manager they communicate with the file system.

B

I will introduce each of them, but basically they all send requests from the ads through misaki envoy and the misaki proxy manager supports minsaki envoy next. First, I will introduce misaki envoy misaki envoy contains two custom void filters and forked. By onward little example, we use two custom filters. The first is http filters that control http request.

B

The second is network filters that control tls and other requests.

B

We can change configuration per host using type filter, config.

B

Mrk invite provided buffers request during buffer duration. If there is no network connection or the network type does not meet requirements.

B

The next right, for example, this configuration file has network types set to wi-fi.

B

So if h is connecting to a mobile network, the misaki environment, holding the request up to network type changes to wifi after buffer duration, if the network is still unavailable, save the request data to the file system buffer duration set as one minute in this configuration file.

B

The data will be released by minsaki proxy manager when the network available again, if we use tls, we can save request data, so we just drop it. Tls connection is run on our future tasks.

B

Next, second, I will introduce misaki proxy manager.

B

It contains a lot of features in one binary and the features are mainly divided into startup scripts and runtime processes, startup scripts message, proxy manager, edit ip tables and all requests forward to mr key on voice port.

B

It also disables the default dns reservoir because we want to run an original dns reservoir that reserves a domain name. Even if network unavailable, runtime processes contains following features check, network status and network type update over configuration, dynamically learn an original dns reserver right now, I'll resign request and save response data. When network is available, request data saved by misaki envoy that exceeds buffer duration misaki over 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.

B

The ih application requests data when offline after a while the network recovers during buffer duration.

B

Before I start to explain how components work, I will introduce what happens when requesting from application next slide.

B

Preference data is sent to the tag server. The client needs to resolve the domain name.

B

Basically, the dns deserver on the ad sends a request to the cloud dns server to resolve it, and next so, when online or in a much network type, misaki proxy's, dns reserver returns a dummy, ip and buffers request.

B

The process does not need to access an external server. It is all done on the edge device if the network is available during the perforation envoy will resolve the domain name and send the request to the tag server.

B

Next conclusion: first, we have developed a proxy for vehicle s devices. Second, our approach shows vehicular restrictions and it helps application developers to develop edge, apps and finally feature tasks. We are trying to enhance multiple message proxy as a service mesh.

B

Thank you for listening. I hope you enjoyed the presentation. If you have a question, please ask us on twitter.