Network Basics in 10 Minutes: Reliability, Speed, and Everything Between

Hi, my name is Tsahi Levent-Levi. I'm the owner of Blogik.me and WebRTC Courses, and I'm here to break down real-time communications so you don't have to. This time I want to discuss a bit about networking basics. This is something that I did in my kids' school for the 10th grade of those learning computer science to know a bit about modern communications and technologies. So if you think about where we started, it was something like this. Humans started communicating with each other, and when they needed to do it from a distance, they needed to use something else. They didn't have computers and they didn't have networks, so what they did was use things like fire signals. They used signals from the smoke coming out of fires to signal towards a distance. Then came the telegraph and other solutions. Today communications are a lot more complicated. There are a lot different, a lot more nodes within the network, and we can communicate with virtually anyone else on the planet or any other device on the planet. What are the building blocks that we have for communications? What it does it mean to send something to someone? So the first thing that we need is a destination. Who it is that we want to send the message to. We also need to know the source. Sometimes— not all the time— sometimes we don't really want to know the source, so we try to hide the source from the destination, but that's a different topic. The other thing that we need is the message itself. What is it that we're trying to send the other side? What is it that we're trying to convey? That can be text, an image, a video, audio, or anything else practically. That's the message that we're going to send. The third one, which is also very important, is actually the requirements. What are the requirements that are associated with the things that we're sending? So we've got the destination and the source, the message and the requirements. All of these make up the building blocks of modern communications that we're going to do with real-time communications. That's even a bit more complicated. Now I want to go back to something that I did, well, in December of last year, and that was to go and write letters. I do that every year now to thank the customers that I have, the clients, the partners, the suppliers, and people that I work with and enjoy working with. I do that also with friends. So this is my, you know, the desk that I have at home, and then that's in the post office. I used to write the letters by hand, decide who to write them to, and then go to the post office and send it. You can also see a box in, in there somewhere. This box over here. I actually sent boxes to a few of my colleagues. Um, so there are different types of letters here with different types of priorities that I want from there. So I came to the post office, I waited in line, go to the clerk, and she asked me, well, do you want to send it as a direct message? The letters, do you want them to be priority sending in one day? And you'll also have markings that they got to their destination, like you need to— they'll be tracked. I asked, okay, how much does this cost? And the answer was too expensive for the number of letters that I had. I had over 100 letters in total. So I went for the ones that are just— they go over the, you know, go over the post office. In Israel, it was between 7 to 14 days. That's what they said. It took a bit more for some destinations in abroad. It was something like around a month to get them to their destination. Um, the other thing was that when the boxes came, she said, well, we need to do these as tracked, and they would be there faster. The boxes came to their destinations abroad faster than the letters in Israel got to the places that they had to go. Okay, think about it. It's bigger, it goes a longer distance, and it was there a lot faster. How is that? The answer is that there were different requirements for the boxes than there were for the letters. The letters were one category of what I'm going to send, of communications, and they had a price tag on them. And the boxes had the higher price tag and the different set of requirements that had to be accommodated for. One thing that the boxes had was I had to actually sit there and wait and write down things on a small paper and get the sticker to put and to weigh to be able to track them. Now, even if the cost was okay, I wouldn't do that for 100 letters in hindsight because it would have taken too much time for me within the post office. Now, why did I do all of this explanation and all of this thing? What we have here is actually modern messaging in a way. So we've got here the letter, there is the destination, and here as well on the other side of the envelope you You'll actually have the from, the source. Inside the envelope is the actual letter, the message that I'm sending. And these stamps here indicate what are the requirements that I have for this specific letter, for this specific message, how I want that to be reached to the other side. The box had different types of stamps that had different types of requirements on them. So how do we take that to our world today of real-time communications and messaging? I think we can look at it as the things we care about. One of them is reliability. We saw that. Do I want the message to arrive on the other end, or I don't really care? Okay, with the letters, I didn't really care. I had a lot of them, and if some got lost, that was fine. Because the cost of having reliability in there with the post office was too high for my needs. Then there's ordering. Do I want the messages to get to the other side in the same order? I can send different type of letters even to the same destination with different priorities. Some of them would get there in 24 hours, others within a week or two or a month. Same with networks. Now, when I did that in the class, they immediately had an example of where we don't have ordering in our modern communications, and that's in WhatsApp messages. How exactly? So if I'm going to send a video message and then 3 text messages, the text messages might arrive a lot earlier than the video message. So WhatsApp would prioritize text messages over other types of messages like video. Why? Because it would rather have lower latency for these messages than ordering. With text messages, you will see them in the exact order that they were sent. Why? Because WhatsApp decided that it makes more sense to do it that way, which is kind of makes sense. Then there's latency, okay? How quickly do we want the messages to arrive on the other side? Simple. Now, something important here: the faster I want the message to get to the other side, the more this is going to cost me, the more energy and resources I need to invest in order to get there faster. This is true for the post office. It's also true for communication software. This video is going to be sent to you once you click the play button, and there are a few seconds until it gets loaded and gets to your machine and gets played. Then that's fine. Nobody cares. Latency there, a few seconds is okay. The same would not be okay for a real-time video calling or a surgery. Remote surgery won't work with a few seconds delay. Okay, so bear that in mind. Then there's frequency. I might want to send one message or 10 messages to the same destination, or continuous messages. And with voice and video calling, there continuous messages going at the frequency of every 10, 20 milliseconds. A message on the network needs to be there, otherwise it won't be played back nicely on the other side. So that's another type of requirement that we might have from our network and from the tool that we're using. As an example, Wi-Fi access points. If you— the farther away you are from the access point, the more bursty it is going to be in the way it's going to send the data and receive the data over the network. It's going to take the frequent messages, bundle them together, and send them as a single block, which isn't that nice for real-time communications, for example, because it adds to the latency. We've got congestion that's on the network side. Things can go wrong. The network might be congested. Too many people are going to send data across the network, either here, there, along the route, wherever. And that's going to affect other things that we're sending. It's going to affect the frequency, the reliability, the ordering of how things going to get to the other side, and the latency— the time it's going to take me to actually get the message from here to there. Last but not least, on the main points here, it's going to be the cost. Again, if I want things to be at higher frequency, at lower latency, with lower congestion, with higher reliability, All of these things are going to cost me more. The more of these requirements that I'm going to pile up, the higher the cost is going to be. And it's not that obvious that I want and willing to pay that cost. The thing I want to look at now is ordering and reliability, just as two examples of what to do in the network in order to put ordering and reliability take into consideration the fact that the networks are not reliable, the messages are not sent ordered, and we don't exactly know what's happening. There are no guarantees. You send the message over the network and it might get there or might not get there. The web and browsing and the internet got us into the illusion that it's reliable and ordered at all times, and it's not. So for that, we're going to have these two friends here, the fox and the sheep, and they want to communicate with each other. Now, a few things about that. First, they're not going to send a single message. The fox wants to send multiple messages toward the sheep, not only one, a few. It's not going to do the thing that I'm doing once a year. It's going to send all the time these messages. The other thing is that sending a message takes time. I'm sending it, but I'm not going to assume that it gets received at the same time that I'm sending. It takes time to go over the network, you know, the speed of light, things that happens within machines, queues inside different devices, switches, routers, my own machine doing things. Okay, things take time, and we need to take— we need to give that a place in what we're building. So let's see ordering. What happens if these messages that I'm sending get reordered along the route? What now? How do I fix that? Okay, how can the sheep know that the first message route arrived second and then reorder them back to the order that they should be? The easy answer is that we're going to do something on the envelope. On the header or the data that we're going to put along the payload, along the message that we are trying to send. Then what we're going to add there is sequence numbers. Usually the first message is going to be 1, the second message is going to be 2, the third 3, and so forth and so on. Okay, and then if the sheep receives message 2, it knows that message 1 is missing and it will wait until message 1 arrives, and then it will reorder them since it waited. Ordering messages that come unordered means adding latency because now I need to wait for things to happen before I can consume some of the data. Okay, remember, everything that you do has a cost to it in one of the other parameters. The other thing that I want to show you is reliability. The fox now sends 3 messages, and guess what? Message number 2 didn't arrive. What do we do now to fix that? Well, we can use retransmissions, sending messages more than once, or acknowledgments and acknowledgments. Okay, the sheep can say, well, acknowledge message 1 and 3, didn't receive message 2, and then message 2 will be sent again. That would be a retransmission. How does that exactly happen? That depends on the exact protocol. There are acknowledgments of these are the messages I received. There are negative acknowledgments, these are the messages that I haven't received. And there is forward error correction. I'm going to send more data, I'm going to send the same packet more than once so you receive at least one of these alternatives. An example where this is going to be really, really important, if we're going to do a call with someone on Mars. The time to send data over there is going to be well above a second. Waiting for retransmissions or acknowledgments is just going to take too long. I can just send data more than once, and that would be forward error correction, so that I received multiple times and just delete the things that I don't need. Okay, so for reliability, we can do things like retransmissions and acknowledgments. And again, adding these mechanisms add latency. So if I want reliability, I'm going to lose a bit on the latency part. So we can either get things that are fast and happen really, really quickly, or reliable. You can't really have both. At some point, you need to make some concessions about what you're going to do. You're going to, let's say, reduce the speed at which you're doing things to get a bit more reliable in what you're doing. And getting the exact balance of what you need for a specific use case and latency and scenario is not that easy. In WebRTC, we almost automatically say, well, fast is better than reliable. Almost always, hands down, this is a decision that is made there. Now, before we end, I want to show you this. And that's TCP and UDP, in a way, the two protocols that we have. It's to show you TCP and UDP, they're almost yin and yang. They're opposite ends of the same thing. TCP is a reliable protocol that deals with a lot of the things that we just discussed and I showed you, and a lot more. And UDP is the one that gives you nothing. It's like, I'm unreliable, unordered, you get nothing out of me besides getting messages from here to there really, really quickly, but without any guarantees. Now, most of the internet today runs over TCP or over HTTP, which provides you that reliability, sometimes done over UDP today with HTTP/3. Not going to get in there now. So we're used to thinking that way, that everything is reliable at all times, and the answer is no, it's not. Reliability is there in TCP and everything built on top of it. But a lot of the things that we're now doing on the internet start moving towards UDP to provide slightly different guarantees or different requirements than what TCP gives us. We want a bit less than what TCP gives us to be able to do a lot more or to do other things. Now, WebRTC and real-time communications, the ability to send media really, really fast at low latency, doesn't work that well on TCP. That retransmissions and that reliability are things that are going to go and hurt us in a lot of different ways. So we prefer doing them over UDP and then putting the guarantees that we need as we need them. For example, adding sequence numbering on our own to do ordering and not assume that UDP or TCP will do it for us. UDP doesn't do it for us, TCP has that built in. For example. At the end of the day, we use both UDP, TCP, and everything in between to build modern applications. Now, if you want to 10x your implementations in WebRTC, get faster in the market in what you're doing, I'm here to help. Reach out to me. And don't forget to follow me at bloggeek.me. And if you want courses on WebRTC, go to webRTCcourse.com. Thank you.