Cloud Native Computing Foundation ServiceMeshCon EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Introduction to Media Service Mesh - Giles Heron, Cisco Systems

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Introduction to Media Service Mesh - Giles Heron, Cisco Systems

Media Service Mesh is a new concept for enabling real-time applications in Kubernetes. Most real-time applications (such as multi-player FPS games, multi-party video-conferencing, and CCTV streaming) use UDP rather than TCP and hence are incompatible with current web-proxy based service meshes. In addition they often use out of band TCP control channel to negotiate UDP port numbers, and this is incompatible with the kube-proxy ClusterIP NAT. There is, however, a desire from the developers of these platforms to move away from monolithic applications towards the micro-services architecture, and to be able to leverage a service mesh infrastructure providing load balancing, encryption and observability. Media Service Mesh enables this.

A

Well good afternoon and welcome to the first lightning talk of the day. My name is giles heron, I'm a principal engineer at cisco systems and today I'll be giving you an introduction to media service mesh.

A

So before I describe media service mesh, I think it's worth discussing why we might need such a thing and I'm going to start with an application taxonomy.

A

So a friend of mine, who did an mba assures me that any problem can be reduced to a 2x2 matrix. So here we have a 2x2 matrix describing networks applications.

A

So in one access you have whether an app is non real time or real time and the other access you have, whether it is interactive, so typically request response, semantics or streaming so typically publish describe semantics.

A

So I think it's fair to say that service meshes today really focus on web applications and those apps are in this top left corner here now you could use a service mesh to interconnect the node to a message: bus, but you'd, probably just be transporting that traffic as tcp, so you'd be transporting the message bus rather than being the message bus. The way you might struggle with service mesh today is, on the right hand, side so real time applications and that's going to be our focus for media service mesh.

A

Those apps could be interactive, such as online games or they could be streaming apps, such as closed circuit tv. Now I called this a fuzzy application tax on me. Why did I say, fuzzy? Well, I would contend that these dividing lines between non-real time in real time and between interactive and streaming are actually quite fuzzy.

A

So, in terms of real time I might be watching football on a streaming platform. It's live football, but it's not quite real time because it's using http streaming and so if, for example, a friend of mine is watching on cable and my team scores a girl, he might text me to say wow great girl and I'm going to be annoyed because I haven't seen the goal yet, though, maybe not as annoyed as I would be if the other team scored. However, even that supposedly real-time feed he's watching, isn't quite real time.

A

So those of you who, like me, are old enough to remember analog tv, will remember when the news would come on and just before the news, you might see a clock counting up the seconds as it came up towards the hour. We don't have that anymore, because the time taken to decrypt these mpeg digital streams is slightly non-deterministic, so they they gave that up.

A

However, if you're working in the tv studio, that's producing that football stream you're going to want it to be real time, so you might have a live. Camera feed coming in from the stadium you'd be adding on at the top of the screen. Something to say you know, here's the score at the bottom. You might have a strip, that's showing news flashes or showing schools from other games. All that's going to be put together, live in real time before it's sent out and those streams are typically uncompressed multi-gigabit streams.

A

So this is very different from the web applications you have today in the other dimension. Of course, it's also fuzzy. So what would you call a multi-party video conference? Would you say it's interactive, or would you say it's just a set of unidirectional streams, I suspect truth lies somewhere in the middle.

A

So there are three goals that I would identify for media service mesh. The first is simply to extend the benefits of service mesh to real-time apps, so those benefits are going to be things like you know: very flexible load, balancing support for canary deployments, the ability to export metrics and statistics, the ability to do authentication and encryption from pods apart now. All of those things are things we'd like to hand off to the service mesh rather than handling our application.

A

We also want support for interactive and streaming applications and those have slightly different challenges. So interactive applications such as games, you very often see developers rolling their own protocols on top of udp. The challenge there is that udp itself is connectionless. It's just datagrams, there's no connection, there's no sequence numbers, so it's very hard to track connections to detect packet loss, etc.

A

What you do see, however, is some de facto standards for games. So as an example, I got this from the improbable. website, so in their spatial os protocol stack, they have two different udp-based options: there's kcp and racknet. They also in fact, support tcp and they have graphs on their website showing how much better the performance these udp options is than tcp.

A

But then, in fact, kcp is slightly better than ratnet. Now kcp is a newer protocol. In fact, when you look at it, it feels like a really good match for service mesh and that you have these three layers of reliable transport, erasure, coding and encryption.

A

These are all things: you'd really want to hand off to your service mesh, rather than handling them in your application.

A

On the streaming side, most people use rtp, so at least there's a standard there for layer above udp. So here we have the webrtc protocol stack and you can see rtp when in fact, srtp so secure. Rtp is a key part of that. On the left hand side you see all of the standard web stuff, so these three layers very much mapping to the three layers of routing and istio, so tcp, tls and http.

A

But this whole right hand. Side is things that can't be done today with a service mesh running on top of udp, and so particularly rtp based traffic.

A

Now rtp, in fact, generally is run in conjunction with another protocol called rtcp that provides metadata feedback for rtp rtp will run on an even port number rtcp will run on the next highest port number, so it might be port 8000 and port 8001.

A

However, those ports are very often dynamic, and so what we'll see is that rtp will run in conjunction with another protocol that might be sip or it might be rtsp. That protocol will typically run over tcp.

A

It will hand out those udp port numbers used for rtp and it will also use uris or urls, which, again, if we have a layer, 7 proxy, we can now start to have routing rules for that traffic. So we can be rooting it in a more fine-grained manner, while at the same time watching those allocations of rtp, rtcp ports and then wiring those into our data plane proxies in the sit world. People talk about pinholes a lot so having these individual forwarding rules for the rtp traffic to get it through a firewall or whatever.

A

Now the other thing on the streaming side is very often I mentioned earlier that we have published subscribe semantics. So very often what you'll see is one stream and then multiple clients consuming that stream, and so again, what we'd really like is for our media service mesh to handle that fan out so that the video server, for example, so taking an rtsp camera as an example, it can send one video feed, then the proxy can explode that out to multiple clients.

A

Finally, we want support three classes of applications, so we want to support applications that run in one cluster apps that run across multiple clusters. But of course, we also want to support internet apps that run from outside the cluster, so your client might be somebody at home, whether they're playing a game or whether they're on a video conference, and you want to tie them into a resource that runs in the cluster.

A

I wanted to give a works. Example of media service meshing operation. The example here is a cctv camera using rtsp proxies. I don't have time to show a demo of that today, but there'll be a link to that on the next slide. So the first thing that a client does, when it talks to an rtsp server, is it asks the server, what options it supports and we'll satisfy that locally from the proxy. In this case.

A

More importantly, the next message asks the service to describe the piece of media now, in this case the proxy doesn't even know where that media is far less what it comprises.

A

So it will first have to find it where it is and it will use the kubernetes control, plane and dns to do that, and now it will know that it can send towards this endpoint address here and so we'll go to the remote proxy through to the camera, and that will flow back and now. The describe message will have all the streams within that media, and so now the client will send a setup for each of those streams with a separate stream id, and what you can see is it's put its own ports on there.

A

This is because it's running over rtp in this case, so there'll be a port for rtp and a port for rtcp if it were to run over tcp there'd be no need for port numbers.

A

This example is all rtp based, but tcp can in fact be useful when we have clients connecting him from home, etc that all works on the same proxy and a proxy can mix and match between the two, but in this case with rtp.

A

What we then see is the camera's response, and now it has its own port numbers as well as the client port numbers. One thing you need to remember here, though, is that in kubernetes there's a lot of address translation going on, so those port numbers have been changed now. The nice thing here is that we can modify what we send and we can also program mappings as those pinholes in the rtp proxy.

A

Now that rtp proxy could be, as in my demo, the same piece of code as the rtsp proxy, or it could be separate as shown here, and that that's not really important, but the key thing is that those pin holes are set up. So, finally, the client can issue a play command that play command will flow through to the camera, and then the camera will start sending the media stream.

A

Now, when another client connects, in fact, we don't need to connect all the way to the campus live stream that the camera's already streaming through the proxy. So now, we'll just communicate with the proxies we'll set up the pin holes and finally, the media will get played out from the proxies.

A

I wanted to finish with a call to action, so my email address is there and please do send me feedback, whether good, bad or indifferent, there's also a link to a blog post, I'll put a link there through to the recording of the demo. So you can see that, but really and ultimately, my goal for all this is for it to become an open source project and to have a community around it. So do please contact me and please, let's all start, building media service mesh.

A

So thank you for your time and do enjoy the rest of the day.