0:02my name is renan and we're going to talk about moq but before we start i'm very curious how many people here have heard of moq i hit great one oh a few okay how many of you have used moq great because i see some familiar faces that are involved in the specification and all these like deep topics and i just want to say this is not a talk for you we can talk after about the deep things but this is about introducing a lot more other people to moq possibilities different use cases and how they work so let's start with introducing the problem space that moq operates in which is the real time problem space everything under a second maybe there's a fan out component but it could live streaming chats um webinars clubhouse if you remember that during the pandemic um low latency information stock takers betting uh game score distribution sharing all these things are the problem space that we're working on when we say real -time low latency applications um and the landscape is dominant of tons of protocols um i arranged some of them from higher latency to lower latency and as you can see some of them deal with media distribution

1:34and some of them deal with maybe custom protocols that you might have built because you work on the back end and the front end at the same time it could be an app it could be hardware um but there's a lot of protocols for different jobs um to be done in the in this space um there's most notably you know obviously http you can pull new information if you don't care about latency that much or if you don't care about latency distribution across different um clients you can also use something like web rtc where you care about this a lot where if you for example are building a video conferencing application your video conferencing application obviously needs to be below a certain link so that a person can speak, the other person can hear, reply, you know, how Zoom and Google Meet works.

2:30We need to use the right technology for the different problems. And there's a lot of, as I said, different technologies. I already did them again. And each of them have different problems. Obviously, TCP-based protocols like WebSockets have head-of-line blocking. Web RTC is peer -to -peer, so you need something fan -out if you're doing fan -out, like live score distribution. Lack of signaling protocols, some of them don't have standardized signaling protocols. When Web RTC was being standardized, for example, the problem that is being solved was so large, the video conferencing and the web problem, that people couldn't agree on a signaling protocol, on what a...

3:16on the internet looks like so now we have you know tons of applications like zoom we have applications like um google meets and all these different like walled gardens that have their own thing but they all use web rtc in the back end um and they don't interpret like there's no reason why you can't join from a technology perspective uh a google meets from a microsoft teams meeting and this should technically be possible you know if these were interoperable, but they're not, you know, it's a signaling problem. Some of them are not supported in browsers. If you're writing a UDP-based custom protocol, the browsers can't do just arbitrary UDP. There's a lot more other problems that, you know, depending on your use case, you need to choose the right protocol.

4:02And this is a hard job, especially when you're dealing with bad networks, bad, you know, last mile latency. and the problem space we're dealing with is typically you optimize the back end or the front end but everything in between you need to optimize for as well.

4:24MOQ is another protocol that is meant to replace many or all of these use cases that is between TCP and UDP

4:37but why are we inventing another protocol? If we have many that already work, this is a good question. And there's good answers to this. The MOQ is getting a lot of attention and a lot of work, specifically from quick people and the ITF, but also many other people are putting work into it to make sure the protocol is worth it, to make sure that the gaps that we left. WebRTC, gaps that we left, and WebSockets, gaps that we left, and other protocols from the past, even, you know, the browser protocols, the protocols from the phone world, the protocols from the TV world, broadcasting world.

5:25We're working hard in the ITFs, you know, as Coffler, but also many other organizations to make sure MOQ is worth it. It's a protocol that people can use. It's being developed, as I said, in the ITF. It's not a Cloudflug proprietary protocol.

5:45And MLQ stands for media over quick, but it's not just for media. It's for arbitrary data. If you can carry any binary data, it can carry it, and it's PubSub.

5:59How does a PubSub model work? Each publisher connects to a relay and then each subscriber connects to another relay and then a connection was made so that unlike the request response model of http for example there's a flow that's established a low latency flow that established that is established that makes data from publisher to subscriber go if you have a video conferencing application you have maybe five publishers and five subscribers and they all send data to each other the system if you have a video broadcasting live tv application you have one -to -many fanouts maybe you have one -to -one voice ai kind of situation moq model works for all where you can you know there's a publisher and a subscriber and these are generic enough and um there's no negotiation there's like web rtc that's needed between every single peer it's you know you ask for a named track and you get what that track consists of over time

7:11um there's a lot of technical benefits uh to other protocols to the previous state of the art um of moq number one that is most interesting to me is tunable latency you can go between tcp's reliable communication and udp's unreliable communication and have um something that is tunable a good example of this is for example you're right is say you're writing a podcasting application it has a video you know conferencing component to it it's a podcast application um but you also need to record this so you might have you know two subscribers to a publisher one of them could be the human participant who's in the conversation where if there's a little bit of data lost maybe a quarter of a second it's no big deal let's skip over it but um you might have another subscriber that's doing the job of a recorder that might say okay let's be more reliable we have more room to since we're recording to recover the lost content from the wire and um you know you can have different use cases at the same time running at the same time you can't do this with web rtc because web rtc uh will, you know, if you can't keep up with the data, drop the data immediately.

8:29Same with WebSockets. You can't do this because WebSockets won't allow you to have the same latency guarantees that MOQ or WebRTC could provide for video conferencing. This is why you don't have video conferencing over WebSockets. It has native fan-outs for broadcasting, obviously, and the fan-out system doesn't care about the contents. There's no header line blocking. It's over quick stream.

8:55there's connection migration again through quick there's also security again through quick you know tls 1 .3 is by default enabled for every quick session so it a lot of benefits from quick fast connection establishments another one that is kind of important in moq there's also a bunch of business benefits you can do many cool things that you aren't able to do today that now you're able to do

9:27So getting into the more technical nitty-gritty, what do I need to know? What is the main data models? What's the API that I play with? What is MOQ? MOQ is a layer on top of quick. So in quick, you have the quick streams. You can set reliable, unreliable, et cetera, and it's a data stream. MOQ makes four new concepts available to you. And again, this is a ITF standard so everyone else who talks MOQ understands these things and understands what the roles these things play. There's a track which is a named stream of data that goes and this could be video, this could be audio, this could be data stream, whatever it is. It's binary stream and you can subscribe to a track. In a track there's a group and this is something that is independently decodable.

10:17For example, in video, it could be a keyframe interval where no data, if you just jumped in between, makes sense unless you have the beginning on the whole chunk together. Or it could be like maybe a chat blob where a certain part of the chat message doesn't make sense if you don't have the entire thing. So it's independently managed group. A subgroup is a quick stream. These you can prioritize. I'll give you an example in a second about how you can play with subgroups. And an object is an immutable payload. Everyone, you know, and this is what powers the scaling of it. There's caching that the MOQ relays can do around an object.

11:04So when you do your MOQ applications, you basically place what you decide in your application. If it's a media application, if it's a chat application, whatever it is. where your data goes and where it falls into this, and MLQ takes care of the reliability properties.

11:21Cloudflare runs MLQ today in all these locations. Every Cloudflare location is a MLQ relay. What is a relay?

11:32Relays are for scaling MLQ, so you might have communication between two different servers and two different machines, and you can do that over MLQ. But the benefit of MLQ... comes from the fact that you can have something between like a CDN that can scale. So what you do is a publisher and a subscriber each connect to connect to their nearest relay and then one of them publishes, one of them subscribes and Cloudflare within the Cloudflare network makes the connection between these two so that the data flows reliably between each other. And the good thing is that once say for example you make a connection from Sydney to London, that connection can be reused so that there doesn't need to be another connection happening for the scalability properties to work.

12:21Because object IDs are immutable, Klafly can reuse the object IDs and cache them, as it were, and have these data flows do efficient fanout.

12:39Internally, in our implementation of our Relay, we use Herbal Objects to keep track of which server owns which data flow, which client.

12:52Tunable Latency is an example of Tunable Latency where, using subgroups, you can have different versions. For example, 360, 720, 1080p, and depending on the congestion, they can be fastly dropped or brought back up. They're... easily within the same connection you're not doing another http request you're not doing another

13:12connection establishment there's no other thing it's in the same connection that exists it can be dropped by the server and then brought back up and then dropped by down again depending on the fluctuation of the internet another example is voice ai a cool thing you can do in voice ai is you know say you have a user speech to text model the server does maybe inference and then text-to-speech model, you have different reliability profiles, but in the same connection, you can have high reliability. Your voice needs to be very clear to AI for it to understand everything you're trying to say. But then the AI talks way faster to you because the tokens can flow way faster to you because AI, you know, then you can hear. So what you can do is you can, for example, make the first half a second of the data flowing back to you less reliable because you need to listen to that.

14:02immediately but you can have the rest of the you know 30 second message 28 seconds of the 30 second message have um retransmission properties so that your the message that comes in can be recovered while you listen to the first part of the message um this is not something that can be done by any other protocol and it is you know interesting creative use case of you know the tunable even you can tune it during a message being sent tunable reliability affordances that MOQ gives.

14:37You can do PubSub for data, you know, match scores. You can align it however you want, depending on what you want to see. There are certain things that are today, if you want to use the MOQ, are not a good fit. For example, if you're doing pure cacheable file downloads, MOQ is not a good fit yet. There is a way to request... response different objects in moq it's called fetch you can use it to fetch history for example in your stream but this is not a crazy new thing that moq enables it's like something that you can do with http and it's not differentiated that much um if you're using web rtc's built -in echo cancellation no suppression features uh bandwidth estimation features that you don't want to have control into at all um you can use those with you can use WebRTC for that and also if you do DRM there's no good browser -based DRM story like encrypted media extensions for MOQ but these are all problems that are being solved you know with the ITF and other groups right now browser support there is browser support on every major browser including Safari iOS um you can use it today um moq is possible everywhere uh right now uh we maintain mockrs which is our um all you know which also powers our server side implementation for

16:11our relay written in rust um there's many libraries uh that we also support um and you can play with

16:24MOQ is not yet a IETF RFC yet, so there's different drafts that are ongoing. Currently, the current draft is, I think, draft 2022. Koffler supports draft 18, and we're kind of upgrading our support as we go.

16:45But you can play with it, and soon, hopefully, it's going to be an RFC. If you control your front end and the back end, there's no reason, you know, to play with MLQ right now. Don't be listening. MLQ is serious business. There are cases where QUIC or UDP is not supported in certain networks. There's a solution to this. There's a standardized mapping of QUIC into TCP, TLS, WebSockets, H2, etc. called QMux. That is the way to deal with older clients, clients that don't support these networking primitives like Quake or Networks and all these issues. Quake is trying to be compatible with everything. Emoki is trying to be compatible with everything.

17:32So in cases where it's not supported, there's an option.

17:37You can build with Half-Less Relay. There's docs about them.

17:42And getting started is easy. Point your agent to the Emoki. alliance getting started page um and speaking of moq alliance there's a lot of companies working with moq as i said this is another cloudflare technology um you know cisco intel amazon all these people are going to support moq or i've already done something with it um there was an moq specific conference in san francisco two weeks ago the videos of that will be out soon including has used of MOQ on Instagram. If you go live on Instagram today, you will be able to use MOQ today because their live streaming pipeline on MOQ from the app to the server.

18:28No, their live streaming pipeline on the app to the server is currently implemented with MOQ.

18:36Protocol development is at ATF. You can contribute. And this is a secret email. to all the engineers working on MOQ at Cofflair if you want to get more information.