So I wanted to talk about flooding a little bit more. Flooding is a very powerful primitive, it provides the ability to disseminate information throughout your network. It's very powerful, it's a great approach because it's very robust. If you have a piece of information that you need to get out to another node or a set of nodes, if there is a working path between the source the destination, it'll discover it. So it's great in a lot of ways. But flooding as a primitive has some downsides too. One problem is that if you flood, your packet goes everywhere, it goes to nodes that don't even need it and that's a problem for scalability. So if you increase the size of your network, if you have n nodes in your network, then you need order n-squared messages if you have a typically size network. So the number of control messages you need increases very quickly. Another problem is privacy, you have a piece of information you need to send it to another guy as private, or you're broadcasting it everywhere, everyone gets it. So if a bad guy is able to infiltrate just one node on your network, they can see everything because everything is broadcast. So flooding isn't so great for privacy, it's not so great for isolating resources, contain resources, doing load balancing, makes access control hard. If you're to control where information goes and what information can go where, it's not about putting an access control at one place in your network, because it'll get flooded around that, you split access controls everywhere and coordinate them, then introduces some problems, and these problems are getting even worse with IoT. So with IoT we deploy more and more devices. We're not building little LANs with a few devices anymore, we're getting tens of thousands of hosts and more. So what can we do about flooding? Can you do better? Well, there's an observation about flooding, and that is when you flood, you don't really need your packets through everywhere. Like for example, take this network, you have a source and a destination, there on separate LANs segments, these LANs segments are connected by a switch B, there's also another switch A which has two ports, and it's connected to another segment. So if you think about it, if you have the source and sending a frame to the destination, which links should it forward on? Well, let's consider the problem from B's perspective. B sitting there, it gets the packet, you can look at this and you can tell B should forward it up, it should forward it up towards the destination. But A is sitting there, A received the packet, should A send the packet up too? It doesn't really need to because the destination is not there. So when you develop Ethernet, when you couldn't use Ethernet, the basic Ethernet algorithm which all switches use is you couldn't just flood things everywhere as we discussed. You received a frame, you're going to forward it on all other LANs, the problem with that is you waste bandwidth because you're flooding everything everywhere. So a better approach which I've been hinting at before is you learn what hosts are. A switch sits there and it listens to broadcast and then it'll forward the data packet on, but it remembers where the sources, it remembers what port the destination, it remembers what port the sources out and it remembers that, and then it can use that for later broadcasts where nodes are sending packets to that source. So this is the idea behind learning switches. So this is an optimization to Ethernet. It's incredibly widely used basically all switches you buy today, you're learning of some sort, it's an optimization. The way it works is a switch sits there and it learns these table entries based on a source address. So it watches these frames go back and forth and it builds this table, and this table is a cache, so it's caching pointers to sources that it hears about. So for example in a switch receives a frame from a host on port one, it'll add that host to it's list of host on port one. Now one problem is networks are not always static, switches can go up and down, links can change, hosts can move and be mobile. So one problem is if you learn this information, the information become out of date, it become stale. So to protect against this, switches will forget these entries over time, they'll timeout these entry so avoid staleness. So here's an example, you can go through if you want to see more detail. We have a switch and we have two LAN segments, the switch has two ports and it has a set of hosts at each of these ports. You can see that over time the switch has learned that port one has A, B, and C on it, and port two has X, Y, and Z on it, and it learns this information by watching these packets go back and forth. So you might see this, you might be thinking, well, okay, for storing all the state, why not just use routing? The whole point of Ethernet was to be plug-and-play, we could just automatically figure things out, and we don't want to store all this state. Ethernet, we want to keep table small and have minimal state because we can't store state for all these data packets, that was the problem. The reason this is different from routing is that the table was an optimization, it's not required and this gives vendors a lot of flexibility, because what they can do is they can build small tables if they want, if you want to build really cheap switches, you just want to sell at $10 a switch, you can do that, you just make it really small table or have no trouble at all or if you want a really powerful switch, something that can have a lot of memory, remember all these frames, you get better performance that way but it costs more. So this gives vendors a lot of control over what they do and gives end-user's control on what they do, because they can log into switches and set the size of these tables as well. So the tables and optimization is something that's not required for correctness but it improves performance. One thing though is with these switches, they can learn pointers to sources, and over time, they can constrain broadcasts. But you don't always want to do that at layer two, because there are some protocols which are discovery protocols that operate at layer two. Protocols like ARP and DHCP, there's also protocols to do peer-to-peer music discovery service, iTunes does this, there's certain protocols that sit there on your LAN and look for other things, printers can do this too, your operating system can go out scan for printers on your network or service discovery services. The way these protocols work is they scan your network, and by scanning, they send out a packet that says, "Hey, are there any printers out there? Are there any other computers running iTunes out there where I could share music with them?" So Ethernet supports broadcast, it supports the ability for a host to initiate a broadcast that's guaranteed to reach all nodes, and Ethernet does that by allowing you to send a frame to special broadcast the address, and this broadcast address is all ones, it's a MAC address of all ones. So for host sends a message to a broadcast address, the switch won't bother caching or constraining broadcast or anything like that, it'll just flood it everywhere, which is great for these services, but can be a problem for security, if you have a host on your network you don't trust, it has the ability to have seen broadcasts and disrupt traffic and things like that, so that's something that we have to be careful about. So this is an overview of learning switches, it's approach that improves the performance of Ethernet.
