Okay. So next, we're going talk about another category of protocols known as epidemic protocols or gossip protocols. We're going to apply this to routing. These protocols are designed in a way that was inspired by the way epidemics propagate like viruses, the way viruses can spread between people, or the way people gossip, if there's rumors, and things like that, when people talk to each other. So I don't know if you've ever been in a situation where you've heard a rumor about somebody, you go into the office and you hear some story about, all this happened to this person, and guess what they did, and things like that, is rumors that people talk about gossip and things like that. Then people talk to each other about these things and then it spreads out. There's no formal routing algorithm that's being used to communicate this information, this is kind of people walking up to each other and exchanging information, and that's the whole idea behind these protocols. The way these protocols work is, if a node has data, it's going to sit there, it has this data, it's going to wait a random amount of time, and it's going to pick a random target, and it's going to broadcast as data in that direction. So for example, suppose we have this source and we will send the data to node M. What we can do is we can have the data, and we'll sit there and we'll wait a random amount of time, and then we'll broadcast it. In the E and B, I'll do the same thing. E and B will sit there, and this isn't a flood, node there aren't just directly sending this data out, they're going to hold onto it a little bit, and then they're going to send it out. The idea is if we do a flood, that's a lot of messages. If you have N nodes in your networks, that is going to require n-squared messages. The idea behind gossip is trying to do a slower rate, let the information propagate out slower, and then repeat it as well. So this makes it resilient to outages nodes losing information because resilient, you're going to see the same information multiple times. So E and B will get it. Maybe E's timer goes off first logs disseminates I and F, and this process continues, a topology might change, and this data goes out and his policy changes. You can see these nodes are spreading this rumor to each other randomly. Eventually, there's some hope it's going to reach the destination. It's not guaranteed. It's random, but you are guaranteed that if you wait long enough, eventually it'll reach the destination because whatever node is doing is waiting this random amount of time in the sending of the data. So the nice thing about gossip in epidemic algorithms is that they're extremely simple. Kind of geographic writing, you don't have these network wide, coordination going on, you'll have to precisely store distance vector routes in the network and kind of [inaudible] these tables. It's extremely simple, you just sit there and broadcast. So it's a very simple algorithm, very easy to implement. If you want to implement something that simple, you're going to have fewer bugs in your implementation possibly. So there's some advantages to using it. So there's a nice properties of it. If all link failures are transient and reoccurring, then you're guaranteed that the message will eventually reach the destinations. So works for single destination, multiple destinations. If links go down and come back up, eventually your message is going to propagate everywhere. So it's powerful, it works unlike a flood which is going to hit the barriers or your partition that stop, gossip is going to plow through barriers because it's going to wait till links come back up and send across them. So it's a very powerful protocol. It's good because it allows you to reach a single destination, but since you're disseminating outwards, it's you get multicast for free. You can reach all the nodes that you're network because you're sending it out anyway. So it's good for other delivery models besides unicast such as multicasts, anycast and broadcast. However, the downside of it is it can have a high controlled traffic overhead because you're scared of sending it continuously forever. Unlike geographic writing where you can precisely do a unicast between two points, with gossip branding, you do send the data throughout your whole networks, that can have a high overhead. It's slow because you're sitting there and you're waiting a random amount of time. So this is not a good protocol where you need to send information and quickly. But it's a great protocol for when you want to send information reliably, and you don't care about sending data quickly. So to get around the delays there is a improvement that's often used called rumor mongering. The inspiration for this is how rumors propagate between people. So if you think about, if you've ever seen a rumor, people talk about a rumor about something that happened to somebody. In the beginning, it's a really interesting rumor like "Oh boy, that happened to that person? Oh boy, I got to tell everybody about this." So it's a really interesting rumor. So you want to spread it quickly, you want to tell everybody about because it's so interesting. But eventually you're going to sit there and you're going to hear people tell you that same rumor too and you're going to be like, Oh wait, I told people that rumor, now feels like everybody knows about it. It's not a hot rumor anymore. I'm not going to talk about it anymore because everybody seems to know about it, so you're going to slow down in your communication about it. That's the way this protocol works is when a node gets new data, it becomes a hot rumor and it really wants to spread it. So what it's going to do is it's going to send that deed out quickly. But when it encounters many nodes that have the update is going to send it out less frequently. It's going to realize that, okay, pretty much everybody knows it, so I'm going to wait longer amounts of time before I advertise the data because it seems like everybody knows about it already. So the nice thing about this is when new data comes out, it gets disseminated very quickly, but you still have this background slower processes, so keep pushing it out and that's good for your reliability. So this decreases the propagation time at the expense of sending a lot of information quickly. So that's the idea behind gossip routing. So gossip routing is a great protocol for environments where you don't care about really fast propagation times, it's good for environments where you have a lot of disconnected nodes, you want to send it out, you push it out in resilient ways. But it's not a good choice for environments where you really want to care about sending data fast, for those environments you prefer something like DSR or DODV.
