Okay. Hello. I'm Brett Sheffield from the LibraCast project. And I'm here to talk to you about IoT updates with IPv6 multicast. LibraCast is part of the NGI Zero program to build the next generation Internet.

If you want to know more about that, come and talk to me afterwards. There's an NGI Zero Boff this afternoon which you're all welcome to come along to. So before we begin, I want to give you a choice. We could do this talk in a unicast way or we could do it in a multicast way.

So let me give you an idea of what that might be like. So for a unicast one, we need to start with a TCP handshake and then we'll need to maintain that handshake throughout the talk. And then if you could all form a queue behind this gentleman, then I can present the talk to you one at a time.

So obviously that's ridiculous. No, stay here for a moment. So I can actually probably do two of you at once. You know, we're clever in unicast, aren't we? Or maybe, you know, you could attach to my legs. I could probably do the talk to four of you at once.

I'd need to deliver a few lines here and then repeat the same lines here and here and here. And I'm kind of doing this unicast dance. Thank you. Obviously, we're a bit clever at that in the unicast world. We can use CDNs and caching and all these sorts of hacks to make unicast work because

fundamentally unicast does not work at internet scale. So, oh, just do we want to do this in a unicast way? Show of hands? Unicast? Multicast? Okay. So I probably don't need to do the rest of the talk because you're all convinced that multicast is better than unicast already.

So fantastic. So in 2001, they wrote RFC 3170 which says IP multicast will play a prominent role on the internet in the coming years. It is a requirement, not an option if the internet is going to scale. Multicast allows application developers to add more functionality without significantly

impacting the network. So that was 2001. What year is it? So yeah, multicast is still largely ignored and much misunderstood. But it's much more efficient than unicast. It's more scalable than unicast. It solves real world problems.

It has privacy advantages over unicast, which I'll show you in a moment. And it's the missing piece in the decentralization puzzle. It also helps make this fellow a bit happier. It's a lot more efficient. We can build less data centers. Every time you waste a byte, every time you waste a CPU cycle, you are killing this

guy. So what is multicast? We'll start with the definition. You've probably seen something like this before if you've snuck into a textbook at some point. Unicast is one to one, yeah? We're good with that? And broadcast is one to all nodes.

Not too useful on the internet and doesn't exist at all in IPv6. We've replaced it with multicast, which is one to many, yeah? We're all good with that? Okay, well, that's wrong. Multicast, no form of IP multicast in use today is one to many. Unicast is one to one.

You set the destination as the sender. In the case of multicast, you send to a group. You have no idea who the recipients are. You don't know if anyone's there at all. In a multicast world, I wouldn't even know if you're in the room and extra people coming in as we have now don't change the load on me as the speaker. That's not true in a unicast world.

Unicast and broadcast are push. Multicast is pull. It's pub sub. You can't spam someone over multicast. So we've come to the philosophical question. If a tree falls in a forest and no one's listening, is any data sent?

And in a multicast world, the answer's no. It's all dropped by the first hop router or by the switch running MLD snooping or IGMP snooping if you're stuck in an IPv4 world. And that's quite important. We can do some fun things with that, as we'll come to in a moment. There's a lot of misconceptions that I find about multicast.

When I talk to people, I hear that it's multicast. Oh, that's for streaming, isn't it? Or, yeah, it would be great for streaming if everyone wants to watch it once, but there's no use for video on demand. It's unreliable because it's based on UDP. It's insecure. It can't work on the internet. Well, fortunately, that's all wrong.

Multicast is essentially about group communication. And the funny thing is, all communication is group communication. I'm talking to a group now, but even if I'm talking one to one, that's just a very small group. One to one is the special case and the only case where unicast actually makes sense.

You are here, well, round the back. There's 7.7 billion people on this planet or something and going up, well, unless this virus thing in China kicks off and it might go down a bit, but it's largely going up.

And that's a problem. There's also all those IoT devices out there that you good folks in this dev room are creating. That's a whole lot of nodes that want to communicate and they want to communicate in groups. So I built a little IoT updater. It's up there on GitHub. It's very naughty and simple.

There's no encryption. It's just to demonstrate the point that I'm making today, which is that multicast is really useful for IoT. If you want to update your mobile phone or fridge or washing machine or whatever other IoT device that's out there being horribly insecure right now, then you probably want to send it a file and the device will do something with that file, but we can send

files over multicast far more efficiently than we can over unicast. So what we can do is we can send, basically send the file on a loop. You've got an update file. You just start sending it from the beginning, get to the end, and then loop around at

the beginning again and keep sending it. Remember that tree from earlier. If nobody's listening, no data is being sent. One node's listening, you're sending one copy. Ten nodes are listening, you're still sending one copy. A billion nodes are listening, you're still sending one copy. Unicast can't do that. So what are we sending? We're sending a checksum of the entire file so you know when you're finished.

The size of the file, which is kind of handy, you can create an mmap at the beginning and then just start filling it in. The size of the chunk of data that we're sending in this datagram, the offset from the beginning of the file, and the data itself. So if we get a chunk of data that's got an offset of zero, we chuck it in there.

If we've got an offset of four, we chuck it in there. This is UDP. We don't care what order they arrive in. We can just chuck them in any old way. So we've now got all of our data, we run our checksum, and we've updated our nodes. What happened there?

We've just sent an update to one node, a million nodes, doesn't matter. The load on the server did not change. The server is sitting behind a completely closed inbound firewall. All it needs to send is UDP. It never accepts a connection.

So it doesn't matter how many nodes are wanting that update. They just join the group and the server can be a tiny little virtual machine talking to potentially a billion IoT nodes out there. I think that's pretty cool. I made myself a strong cup of tea when I worked that one out.

There are some other tricks. I thought the problem with getting people to use multicast would be their addiction to TCP IP. Are there other ways we can achieve reliability in multicast, which is based on UDP? The answer is yes, we can. There's PGM, which is an experimental RFC.

It uses NACs and replay. So obviously if I send a packet out to you all and you send an ACK back, that's probably going to DOS me. If I'm dealing with a million nodes, that's definitely going to cause a problem. So what you do instead in a multicast world is you send packets 1, 2, 3, 5, and then

you go, oh, what happened to packet 4? So you send me a NAC, and then I just need to repeat that back to you. But you don't have to send it to me. You could just talk to your neighbor and say, I missed what he said. Can you repeat that? And you go, yeah, he said multicast's great. And, you know, I don't need to be involved in that at all.

As we saw, we can just do loop and repeat. We can do forwards error correction. That's Voyager 1. Sending a, you know, waiting for a retransmission when you're at the far edges of the solar system isn't great. Any high latency environment doesn't work well with TCP. It's one of the reasons we're getting rid of it. The new version of the web, HTTP3, is built on top of QUIC, which is UDP.

Forwards error correction lets us encode a little bit of extra data into each packet so that if we drop a packet, we don't need to get a retransmission. We can just rebuild it.

So you're probably wondering about flow control. No? Maybe. If you're sending those updates, and this is UDP, how do we deal with different rates of sending? If I'm sending flat out to this gentleman here, and you're on a slower connection over there, what do we do?

Well, we have got solutions for that. Here's one possibility, and this is something that multicast can do that unicast can't. We've got G1 there, which is a multicast group. And we're sending packets 1, 2, 3, 4, and that's great. Well, if that's too fast for you, what if we, instead of sending on one group, split

it across two? We don't care what order the packets are arriving in, do we? So we just listen on, if we want it at half the rate, we just listen to G1. If we want all of the packets as quickly as possible, we listen on G2. We can split it across four, as many as you like. If nobody's listening, no data is sent, so we can do this.

And in a IPv6 multicast world, we've got 112 bits of group address to play with. That's a lot of bits. That's enough for every atom on the planet to have its own group. So we can just play with these things. What about reliability? Well, there's a lot of different tricks, as I mentioned, FEC and so on, that you

can use, but multicast can do silly things like this. I'm not saying it's a good idea, but replay the data with a slight delay. You missed a packet, quickly join that group, grab it a little bit later, it's like pushing the red button on your TV for a replay. DNS, we don't need it in multicast.

What's the purpose of DNS? Okay, well, it takes a human readable address and turns it into a machine readable address. So we basically just need to agree on where, say, example.com is.

So at the moment we did that with centralized systems, but with an IPv6 address, we've got 8 bits at the beginning that are all 1 to say this is multicast, then some flags, and then a scope variable, e means global, and then the rest of it, 112 bits, is the

group address. That's a lot of bits, which means we can do silly things like this. Take a SHA-3 hash of example.com, or any hash you like, squeeze out 112 bits, which is basically collision proof, enough for our purposes, and we've just resolved example.com. We can all agree where that is, which group that is, without consulting any centralized

service. Pardon? That one, no it's not. The 1 is flags, the e is global scope. So that brings me to my project, which is LibraCast, which is aiming to decentralize

the internet with multicast. I'm trying to do that by getting multicast in the hands of developers. I was going to do the dance, but I haven't got the time. So I've built a multicast library, which you can find on GitHub. I'm expanding that into a messaging library. We're building a transitional tunneling technology on top of that, which should be available

mid-year. Very similar to the M-Bone, if you're familiar with that, and your cast gate, if anyone in Brussels was involved in that local project. This gentleman over here is helping me build an improved routing protocol, because currently multicast is dependent on unicast, and I'd like to change that.

I'm building some multicast-enabled applications, which you'll find out about more soon. And I'm working with FOSS projects to enable multicast everywhere I can. I'm trying to ensure that new standards like WebRTC and QUIC, which are based on UDP, aren't broken for multicast.

Currently WebRTC, I got very excited, it's UDP, but it mandates encryption, and it mandates a one-to-one Diffie-Hellman key exchange, which kind of breaks it for multicast. We can use group keys, we can use capability tokens, we can do fun things. If we write the standards correctly. QUIC is UDP, and the BBC research team in the UK are currently drafting an RFC to enable

that for multicast, so I'm very excited. This is just a sample of what the API looks like in C, hash include librecast.h, and yeah, if you've worked with zero MQ, it's confusingly and deliberately similar.

You create a context, create a socket, create a channel, bind a channel, bind as many channels as you like to that socket, and then you can send and receive multicast packets to your heart's content. All of which helps keep this fellow a lot happier, because it's a lot more efficient.

So folks, think of the polar bears, and think multicast. Thank you, Brett. We have time for one question. Gentlemen, over here.

Hi. So you mentioned that during an update, you can cyclically transmit the file to update some large blob or something, some data, and then nodes interested in reception of that update might switch into the group, listen, receive update, and basically the server doesn't

care whether somebody has received that update or not. So does it mean that it's transmitting continuously all the time? What about the traffic cost? You will kill lots of polar bears with that. Well, if nobody's listening, no data is sent.

If at least one node is listening, then you are sending that stream of data. So it's always at least as efficient as unicast, but when you have multiple nodes, it becomes a lot more efficient. By default, you don't know necessarily who's listening. There are things we can do to know who is actually receiving that update and so

on, but by default, it is far more private, because there is no destination address on a multicast packet. That's a huge win for privacy, and that's something I think we all care about. But when to stop? How does the server know when to stop? Well, if you're updating IoT nodes, then you want to provide the updates constantly,

so you never stop until that update is no longer relevant, and you don't just have to use it for IoT nodes. You can build an entire web server using this technique and run the entire static web over multicast. You send all of the files all of the time, and you have pretty much infinite scalability.

The only thing you need to scale up to is how many files you want to be able to support, and we have to do that with unicast anyway. I think I need to wrap up now. Thank you all for coming. All right. Thank you, Brett. Thanks, guys.