IoT Updates with IPv6 Multicast
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Sheffield, Brett
Could we update a billion IoT nodes from just one tiny virtual server? Could a server that is behind a completely closed inbound firewall, using no caching, no CDNs and which never accepts any inbound traffic communicate at massive scale?
 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 NGI0 program to build the next generation internet. If you want to know more about that, come and talk to me afterwards. There's an NGI0 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. We're clever in unicast, aren't we? Or maybe 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 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? 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 3117 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 is the missing piece, oh sorry, 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? 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. 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 is 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 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 update. It's up there on GitHub. It's very noddy 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, 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 M map 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. 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 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. 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 TCPIP. 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 AC back, that's probably going to do me. If I'm dealing with a million nodes, that's definitely going to cause a problem. 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, great. I don't need to be involved in that at all. As we saw, we can just do loop and repeat. We can do forward 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, HTTP 3, is built on top of QUIC, which is UDP. Forward 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, you know? 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 an 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? It's a good one. OK. 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 was centralized systems. But with an IPv6 address, we've got eight bits at the beginning that are all one to say this is multicast, then some flags, and then a scope variable, e means global. And then the rest of that, 112 bits, is the group address. That's a lot of bits, which means we can do silly things like this. Take a char3 hash of example.com or any hash you like. Squeeze out 112 bits, 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. And? Pardon? That's a thing local. That one? No, it's not. The one 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 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, the 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 FOS projects to enable multicast everywhere I can. I'm trying to ensure that new standards like WebRTC and QIC, 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. QIC is UDP. 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 Libracast.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 as 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. So you mentioned that during an update, you can cyclically transmit the file to update, some large blob or something, some data, and then notes 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 coast? You will kill lots of polar bears. If nobody's listening, no data send, 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 are 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. Thank you all for that. Thank you.
 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 NGI0 program to build the next generation internet.  If you want to know more about that, come and talk to me afterwards.  There's an NGI0 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.  We're clever in unicast, aren't we?  Or maybe 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 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?  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 3117 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 is the missing piece, oh sorry, 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?  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.  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 is 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 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 update.  It's up there on GitHub.  It's very noddy 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, 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 M map 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.  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 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.  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 TCPIP.  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 AC back, that's probably  going to do me.  If I'm dealing with a million nodes, that's definitely going to cause a problem.  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, great.  I don't need to be involved in that at all.  As we saw, we can just do loop and repeat.  We can do forward 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, HTTP 3, is built on top of QUIC, which is UDP.  Forward 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, you know?  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 an 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?  It's a good one.  OK.  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 was centralized systems.  But with an IPv6 address, we've got eight bits at the beginning that are all one to  say this is multicast, then some flags, and then a scope variable, e means global.  And then the rest of that, 112 bits, is the group address.  That's a lot of bits, which means we can do silly things like this.  Take a char3 hash of example.com or any hash you like.  Squeeze out 112 bits, 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.  And?  Pardon?  That's a thing local.  That one?  No, it's not.  The one 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 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, the 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 FOS projects to enable multicast everywhere I can.  I'm trying to ensure that new standards like WebRTC and QIC, 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.  QIC is UDP.  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 Libracast.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 as 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.  So you mentioned that during an update, you can cyclically transmit the file to update,  some large blob or something, some data, and then notes 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 coast?  You will kill lots of polar bears.  If nobody's listening, no data send, 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 are 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.  Thank you all for that.  Thank you.
iotmulticast_0_143.png iotmulticast_144_4943.png iotmulticast_4944_6047.png iotmulticast_6048_6227.png iotmulticast_6228_6863.png iotmulticast_6864_7739.png iotmulticast_7740_8099.png iotmulticast_8100_8567.png iotmulticast_8568_11483.png iotmulticast_11484_12503.png iotmulticast_12504_12695.png iotmulticast_12696_12887.png iotmulticast_12888_12959.png iotmulticast_12960_13031.png iotmulticast_13032_15599.png iotmulticast_15600_17447.png iotmulticast_17448_18119.png iotmulticast_18120_20699.png iotmulticast_20700_22319.png iotmulticast_22320_23147.png iotmulticast_23148_24323.png iotmulticast_24324_24947.png iotmulticast_24948_25067.png iotmulticast_25068_25163.png iotmulticast_25164_25415.png iotmulticast_25416_26075.png iotmulticast_26076_26191.png