So, our challenge, given a network, find the best path from source to destination from one node to another in the network. And we define the terminology, we have links, we have paths made up of a set of links. Links are assigned costs. So the numbers in this example indicate some cost of using the link, where we want to use the path which has the least cost, where the path cost is the sum of the link costs on that path. So, we had an example, we had two paths from node one to node six, where if we want to go from node one to node six, we said if we care about the number of hops, a hop is to traverse one link, to hop across one link. The number of hops to node one to node six, the least hop path, or the least cost path, if we consider cost as the number of hops, is one, three, six. There are two hops on that path. The other hops take three or more part. The other paths take three or more hops. But if we consider the numbers on the links to be the cost that we care about, then the least cost path from n one to n six is one, four, five, six. So, we have a cost path cost of four units, whereas the other path had a cost of ten units. So, choose the path with the lowest cost. Easy. How do we do that when we have a large network? Dykstra algorithm, Bellman forward and other algorithms can calculate that for us. We don't sit there and look at it and try and find the path. There are algorithms that will do that reasonably efficiently. In this course, we can do it on small networks, but in practice, a computer would do it for us. So, given that we have a way to calculate the least cost path, then the challenges are, how do we know about the network topology? Let's say you are node one. You're the computer for node one. You want to calculate the least cost path to node six. To do that, you need to know this topology. You need to know that you have links to node two and node four, and the costs are one and two. And you need to know that node four has links to five and six and so on. So, you need to have a picture of that network topology to calculate the least cost path. Learning that information is what we'll look at. What are the approaches for learning about that information? And one of the problems with that is that once you learn that the topology is as it is, then over time that may change, especially the costs of the links may change over time. So, if the cost changes, I'm currently using the path one, four, five, six to get to six because it's the least cost path. But all of a sudden, the link from node four to node five has some problems. Maybe the performance goes down. So, the cost of that link goes up to maybe ten. So, now the path I'm using, one, four, five, six has a path cost of 13. It's no longer the optimal path. So, as the conditions change in the network, we will need to recalculate the least cost paths. And that's the challenge with routing. Finding the information about the network and then keeping that information up to date. So, let's look at that. Some of the things that we need to be able to do, the questions are here and some of the possible answers are here. So, let's talk about some of them. First about the cost listed here is the performance criteria. The number that I put on that line on those links, what does it represent? Well, it's up to the network operator or the network designer to choose what do they care about in terms of the cost. And there are different metrics or criteria. Some can be more accurate in terms of indicating if it's the best path. Some are simple. The simpler one is the number of hops. A simple way to calculate or to consider the cost is to say choose the path with the fewest number of hops. That often approximates the best path if we think about performance. Generally the more hops we have, maybe the more delay we'll have to get from source to destination and maybe the more chance we'll have lower throughput. So a simple way to measure cost is the hops. But sometimes that's not accurate to indicate what is the best path to get my data from A to B. So there may be other factors that we take into account. A couple listed here. Financial costs. If you think of a network connecting across the world and connecting different telecom companies or internet service providers across the world, then how it generally works in the internet is that one company maybe owns their network in their country or in their city and then they have a contract with another company to send their data through another country. For example, in Thailand, an ISP like TOT or CAT owns the network inside the country. But when the customers of that ISP want to send data to the US, then that data needs to go through other people's networks. So TOT or CAT need to have a commercial agreement with other companies to send data via their networks. So sending data via other people's networks incurs some cost, some financial cost here. So generally, if we wanted to deliver our data via other people's networks, we would like to choose the path which has the lowest financial cost. We don't pay as much. So financial cost is one way to consider the least or the best path. Other times we care about performance. I want to get data from A to B. I want to get there as fast as possible so delay is another metric. Choose the path with the smallest delay from A to B. Or I've got a lot of data to transfer. So it's not about getting one packet from A to B. It's about I've got a stream of data to transfer, so I care about throughput. Choose the path that gives me the highest throughput from A to B. So that are some examples of how we can determine the general cost of a link. And it's up to the operator or the user to choose those. There are others as well. Maybe in large networks choose a path where my data will not go through a country that I don't like. I don't like because maybe there are laws in my country saying I cannot send my confidential information through another country. So we may have routing based upon other policies, security policies, legal policies that say data should not go through this location. So there are different criteria there. Let's look at delay and throughput as a simple example. Let's consider a very simple network where we have five nodes, node one. We have two paths to get the destination node four. One path takes it via two and three. And another path takes us via node five. And we focus on one direction from getting data from one to four, just to keep it short and simple. These are our two possible paths to get data from one to four. So consider we're at node one and we know this network topology. We want to choose one of two paths to get data to node four. Let's say we know something about the network links. I know that the throughput of the links, let's say this is five megabits per second. So the throughput or the data rate, I'll measure in megabits per second. I will not write it. So five megabits per second for this link. For this link, it's three. This link, let's set it to eight. And these two links are two and two. So we know those characteristics of the network. And also we know the delay. Let's assume we know the time it takes to get the, say a packet across each of those links. The delay, let's say we measure in milliseconds. So we know that this link has a delay of six milliseconds. This one's six, 100. This one's 10 and 12 here. So let's say I know, I'm node one. I know the network topology. I know that there are four other nodes and the links between them. And I know the current performance characteristics of those links. That is the data rate or throughput, the speed at which I can send data, and the delay to send, say, one packet across those links, which the delay includes, of course, takes into account the data rate, but also the length of the link, maybe propagation delay and other processing delays. So I want to choose the best path to node four. Well, it depends upon what I define as the criteria for best. If I say best is equivalent to lowest delay, then what I do is I assign costs to those links. So the numbers I've written are not the cost yet. They're just the performance characteristics. I assign a number to each link, which we can then use to calculate the least cost path. With delay, it's easy. If I know the delay, the path delay is the summation of the link delays, and the best path is the one with the lowest delay. So in fact, we can say delay is proportional to cost in this case. So what I could say, if the delay of link one to five is 10 milliseconds, then let's say the cost of using that link is 10. Not the financial cost, but some general cost independent of the metric. So the cost can be equivalent to delay in this case. So the general cost in this case, we can say is the same as the delay. So the cost of link one to five would be 10. Five to four would be 12. That's easy. Now, the same numbers. And then what's the best path? 154. The total path cost, if I use 154, is 22 units. If I go one, two, three, four, it's 112 units. Okay? So if I consider delay, I choose the path 154. If I used a different metric, so we'll just record that, that would give us the path. The best path is 154 in that case. If I used number of hops, then it would also be 154. Because number of hops may be another metric. If the best path was something different is the number of hops, we defined a different metric, lowest number of hops, then what's the cost that we assigned to each link? If we want a different metric and say choose the path which is the lowest number of hops from source to destination, we need to assign a number to each link to indicate the general cost. What would it be for each link? What would I assign the link 1 to 5? What's the cost of this link? 1. It's 1 hop. So in fact, every link would have the cost of 1 in that case. That's maybe the simplest of cases. So the cost from 1 to 5 is 1. From 5 to 4 is 1. It's 1 hop. So again, we could calculate the least cost path. We could use the same algorithm and we'd find it's 154. So this is just illustrating we use different costs depending upon the criteria we care about. Now let's consider throughput. Let's say we care about a path. I've got a lot of data to send. Continuously, I want to send data. So I care about what's the highest throughput I can achieve across that path. I would say the best is the highest throughput or data rate. What do we assign as a cost on each link? If we care about choosing the path with the highest throughput, maybe look at the network and see which path is only 2 to choose from is the best in your perspective. So now I say I'll define best as the highest throughput and given that I need to assign some cost to each link, the cost should be related to the throughput and the cost should be such that if we use least cost routing, find the path with least cost, it will give us the best path. So what cost do we assign to our links now? First, looking at the blue numbers, which are the throughput measures, which path do you think is best? The top one or the bottom one? Hands up for the top one. Hands up for the bottom one. We get some for the most for the top, some for the bottom. Why do you think the top one is the best? Looking at the blue numbers, which are the throughput, we get a throughput from 1 to 2 of 5 megabits per second from 2 to 3 of 3 and 3 to 4 of 8, whereas on the bottom path, 2 and 2. Well, throughput's a bit harder than delay to consider. Across a path, the throughput of that path will be limited by the slowest throughput across that path. What we call the bottleneck link. That is, the path from 1, 5, 4, we can send it 2 megabits per second continuously to 5 and that can send it 2 onto 4 so we can get 2 all the way from 1 to 4. That's easy. Going from 1, 2, 3, 4, we can send a 5 to 2, but from 2 to 3 we can only send it 3 megabits per second. So if we send a 5 through to 2 and 3 to do 3, then somewhere that remaining 2 megabits per second is going to be lost. It's not going to get through. That is, if we send 5 into 2 and 3 out, the amount that we're going to deliver to the end is limited by 3. We cannot do more than that. And even if we send 3 megabits per second into node 3, and that can send 8 out, on average getting data from node 2 to node 4 is going to be limited at 3 megabits per second. So in fact, across a path, the path throughput is limited by the bottleneck link. The bottleneck link is the slowest link. In this case, we say this is the bottleneck link in the top path. So we can say that the path throughput would be 3 in the top path and it would be 2 in the bottom path. Which one's better? Top or bottom? The top one's better. Higher throughput is better. So be careful. Delay and throughput, we want low delay, but we want high throughput. So now, what cost do we assign to each link? We need to assign some numbers to the link such that our least cost routing will choose, in this case, it should choose the top path. Well, the first approach we can think is think of the inverse. That is, if we want, if we have a high throughput, the cost should be low. So if the the throughput is 5, then the cost should be and the second link, the throughput is 2. For the throughput of 5, the cost should be lower than a throughput of 2. So we can think we need to do some inverse. 1 divided by 5 may be the cost. And 1 divided by 2 the cost on this link. And then, again, the cost routing always simply finds the path where the sum of the costs is the least. So here we have a bit of a challenge. What do we assign as the cost of those links? Just taking the inverse is usually not sufficient. The general approach to use is to consider of all your links in the network, what's the maximum, and then take that maximum and divide it by the actual throughput. Or take some potential maximum and divide it by the actual. I'll show you an example of that. Let's say potentially the throughput can go up to 100 megabits per second, just to make a nice number. So what we could say, if we think the throughput goes up to 100, then this link we would set the cost to be 100 divided by 5. 20. This link would be 100 divided by 3. 33 approximately. This link, 100 divided by 8. Where this 100 we would choose as a parameter and say, right, that's our upper limit and we'll see how it works. That's about 12. This would be 100 divided by 2. 50. And 100 divided by 2 as well. So we'd assign these costs to the links. 20, 33, 12, 50 and 50. Now let's just do a sanity check. The higher throughput should give us a lower cost. Yes, 5 gives us 20. 2 gives us 50. So we've got the inverse there. That's working. And now the reason for taking this maximum when we add them up what do we get? 20 plus 33 plus 12 is what, 65. The path cost is 65 units. The bottom path, 50 plus 50 gives us 100 units. Least cost path is the top one. 65 is less than 100. Therefore we'd choose that path. So that's usually the way that it's done in practice if we have throughput or data rate. First we need the inverse to determine the cost. It should be the inverse of actual throughput or data rate. And to make the numbers such that when we add them up we'll get the best path. That doesn't work all the ways but in most cases we can select some number such that when we add them up the one with the lowest sum will indicate the one with the lowest throughput. And the common is to choose some upper limit in a network say 100 megabits per second or it can be higher or a different value depending on the network. It doesn't always work because there may be cases where the bottleneck is in the wrong path, is in the path that we select. The lowest throughput on the path doesn't correspond to the lowest sum. But in practice in most cases it will is a way to convert throughput into a generic cost where we can still use least cost routing. 100 was in this example was a value I chose and the idea where it comes from is think in our network what's the highest throughput that we can get on any link? Well in this particular example we used 8 what would we have had? The numbers may not have been easy would have been 8 divided by 5 1.3 or whatever 8 divided by 3 2.0 8 divided by 8 1 8 divided by 2 is 4 8 divided by 2 is 4 this path would have been 8 4 plus 4 this would have been the 1 it would have been the least it would have worked if we use 8 as well so it should be at least the maximum of the maximum of all the link data rates or throughputs I chose 100 because it makes nice numbers when I divide by rather than having decimals we can get close to integers it's a little bit easier to work with so that comes from the maximum you can find a case where it doesn't work you may be able to find a scenario where using the approach with particular link rates the least cost path chosen will be the one with which is not giving the highest throughput so it doesn't always work but most cases it will so converting the metric to cost is not easy with delay it was easy proportionally related with hops it was easy with throughput it was a little bit harder what did we do we said some maximum value divided by the actual value the maximum throughput of all the links divided by the actual throughput the actual needs to be down the bottom so that it's the inverse and we use the maximum to give numbers such that we'll get the least cost path most cases if we want to deal with other performance metrics then we need to consider other ways to convert them to a cost, to a number such that we can still use least cost routing questions on the costs or performance criteria for selecting the best path of course for this to work node 1 needed to know about the costs needed to know about the performance metric it needed to know that the link from 2 to 3 had a throughput of 3 megabits per second and a delay of 6 milliseconds if it didn't know that this approach wouldn't work let's look at the other problems and we'll arrive at how do we learn that information that's about performance criteria there are different ones that we can choose from and it would be defined for a particular network which one to use when do you choose a route when do you make the decision to use this particular route and there are again different approaches different ones with datagram packet switching for every packet you choose a route we make the decision to use a particular route that is that one of the nodes has a packet to send and it looks and chooses which route to send it on it doesn't necessarily recalculate the best path but it chooses a route for that packet the next packet it chooses again it may get a different path and we saw that when we looked at datagram packet switching versus virtual circuit packet switching with virtual circuit packet switching we first set up a connection sometimes called a session so when I set up that connection I choose the path to use and for all of the packets during that session during that data transfer so there the decision time is done when we set up the session and it applies to all the packets with datagram packet switching then normally we make a decision for each packet separately so there are the two common approaches there the result is with datagram packet switching packets may take different paths through the network with virtual circuit packet switching packets belonging to that one virtual circuit or session will take the same path who makes the decision and who calculates the best paths three basic approaches each node does it themselves each node calculates the path and makes a decision I have a packet look at the destination of that packet and make a decision where to send that so that's a distributed approach each node makes the decision and the calculation a centralized approach we have some special node in the network maybe some special server that calculates the paths and decides for all the other nodes and the third approach is that the source node the one that's creating the data makes the decision and that's called source routing in practice in the internet or large networks the distributed approach is most commonly used the nodes themselves will calculate what they think are the best paths to reach some destination and when they have a packet they will use that best path the problem with the distributed approach is that some nodes may have different viewpoints of the network node 1 may think the best path to node 6 is via this direction node 5 may think it's via a different direction because they maybe have different information about the network so in a distributed system they will be able to move coordinating those nodes so we'll see an example of that as we go through the next two so the next two are how does a node know the current network topology and how do we keep that information up to date so let's look at several cases of how to do that and we'll use an example to do that let's consider another network let's say we are node 1 in our network and I want to send data to some other nodes and in this case I know that there's another node in the network called node 7 I want to send a node 7 I know there is a node 7 in the network here's node 7 so I have data to send a node 7 and I know there are some paths to node 7 hopefully there are we are node 1 where do I send a node 7 where do I send it where does node 1 send the packet how does it calculate the best path to node 7 what is the best path to node 7 what is it no idea we don't know yet because why don't we know we don't know about the other nodes in the network or any of the links so let's say I am node 1 and I just booted the computer I just started the device and when it boots up that's the knowledge that node 1 has about the network it knows nothing about the entire network so if I want to send to node 7 and I know nothing about the network can I do that can I send to node 7 without knowing anything about the network yes how send to everyone so I create a packet I say the destination address is 7 send to everyone alright well everyone when my device boots up someone plugs in the cables and when they plug in the cables then I know that if there is 3 cables plugged in what I would do is I'd send a copy of that one packet on all 3 links all 3 cables someone will receive it I don't care who gets it and then I'll tell them when you get this packet send to all of your neighbors and then they will send to all of their neighbors and eventually it will get to node 7 if there is a path to node 7 so that's an approach which is very simple even if we know nothing about the network we can still get data to node 7 and it turns out a packet would take the best path through the network to get to node 7 that is the next technique we'll look at not yet this is called flooding we'll come back to that technique of flooding a better approach we want to take just one path let's be a little bit smarter so the first thing we can do is when I boot up so we can make routing decisions with no knowledge of the network knowing nothing about the network but let's boot up and let's say when I boot my computer and the links start their cables plugged in then I can learn without my neighbors I can learn who's at the other endpoint of the links so when my computer starts up it connects to some other device at the other end of the link and finds its address so let's say we have some neighbors and in this case we have two neighbors node and we learn the addresses node 2 and node 5 so that's commonly assumed that a node can easily learn about its neighbors so it knows I'm connected to node 5 I'm not connected to 7 I've learned that I still want to get my data to 7 what's the best path to take to get to 7 let's say we don't want to take this approach of sending to everyone because that's really a waste which path do I take to get to 7 do I send a 2 or 5 a game we don't really know which one to send to we could choose randomly node 2 tomorrow let's try node 5 and hope our data gets there across the best path but most times or many times it will not so that's not so good so we need to know something about the potential paths so after we've booted up we learn about 2 and 5 and the other thing that we can often learn is what is the cost of each path of each link let's say the cost we know maybe the costs of measuring delay and again it's quite easy for a node to know that the cost of its current link is some value it doesn't take much to learn that information and it doesn't take much to keep up to date about that information that is this cost changes something goes wrong or the delay the delay goes up for some reason so the cost goes from 2 to 3 again node 1 will know that almost immediately so we know about our local or our neighbors and the links to those neighbors so now which path do I choose I want to send to node 7 where are you going to choose you choose 5, Y5 so node 5 has a lower cost among that link so if this is all we know we could choose to send to node 5 and remember node 5 would also know about its neighbors we as node 1 don't know its neighbors not yet at least but node 5 knows its neighbors and it could do the same thing I choose node 5 because of my 2 neighbors it has the lowest cost node 5 gets the packet and then choose from its neighbors the one with the lowest cost and then they choose the lowest cost and hopefully the data gets to 7 but it may not be the lowest cost path that's the problem so what else can we do I want to be more certain that the path I take is the lowest cost path what can I do ask, ask who ask 2 and 3 ask 2 and 5 ask my neighbors who are their neighbors and what are the costs so this involves some overhead so what I do a routing protocol what it will do is send a message from node 1 to 5 saying who are your neighbors please tell me your neighbors and node 5 would send back a message saying my neighbors are these nodes and these are the cost of the links so this is some overhead of collecting this information so let's say we do that and we do learn the neighbors node 2 has 2 neighbors node 4 so we've sent a message to node 2 node 2 sends back a message saying my neighbors are 6 and 4 and they also tell me the cost of those links the cost from 2 to 6 is 8 and the cost from 2 to 4 is 2 and I do the same thing for node 5 my other neighbor send a message and he sends back a message saying my neighbor is 3 and the cost of the link from 5 to 3 and node 5 tells us node 1 is 5 so by exchanging messages with other nodes we can learn more about the network topology and that may help us finding the best path from node 1 to node 7 now node 1 needs to choose which path before someone chose 5 someone said 5 any other alternatives now maybe going via node 4 looks like a potential good path it has a cost of 5 units so the decision you made before is maybe wrong or maybe you're lucky we'll see but you see the more information we learn the more chance we have of choosing the best path now again the link cost may change over time so in a large network the cost may change so if the link cost from 2 to 4 changes it increases up to 10 then how does node 1 know it changes so I know it's 2 now because I sent a message to 2 and they sent back my link cost to 4 is 2 so now I look like I'm going to use that path but the cost changes from 2 up to 10 that's the best path now so for node 1 to get an accurate record of the current network not only does it have to discover but it has to continuously get updates I have to continually send a message to my neighbours saying tell me your neighbours and the cost of the links to those neighbours do it again and again and again so there's more overhead here if the network changes a lot it will continually get updates to get an accurate record we still don't have the best path or not necessarily the best path to 7 so the next step is not only do I ask my neighbours but I ask my neighbours about their neighbours and I learnt this in the same time all the other nodes are doing that node 5 asks its neighbours 1 and 3 about their neighbours and when node 5 asks 3 about its neighbours node 3 sends back a response to 5 and the next time I node 1 asks node 5 node 5 not just tells me about its direct neighbours but about its neighbours' neighbours so each node keeps up to date of what they know about the network for example when node 5 asks node 3 node 3 sends back a response saying my neighbours are 4, 6 and 7 they are the neighbours of 3 so when 5 sent a message to 3 3 sent back a response saying my neighbours are 4, 6 and 7 and the costs of those links are 1, 4 and 7 so 5 knows this the next time node 1 sends a message to node 5 5 tells node 1 about its neighbours but also the other information it knows 5 knows that the neighbours of 3 are 4, 6 and 7 so 5 tells 1 that so now 1 knows the neighbours of 3 are 4, 6 and 7 similar the other nodes node 4 has neighbours so when we ask node 2 node 2 tells us about 4's neighbours and 6's neighbours and these are the links in our network and the costs so when 2 sends a response back to 1 it says my neighbours are 4 and 6 and they have told me in the past that their neighbours are the ones connected via these links so now this is the view of the entire network from node 1's perspective and in this example that is the entire network there are no more links we would keep going if the network was connected to node 1 importantly for node 1 to discover about the network topology and the costs of the links it needs to ask other nodes needs to send packets special routing packets to other nodes saying tell me about your links and because the network topology may change over time links may disappear new links may come up costs may change we just do it once and hope that that gives us the best information and that's the challenge of routing try to do that by minimizing the overhead we don't want to send too many packets to do this but we want to get an up-to-date view of the network once node 1 knows this information it simply uses Dijkstra's algorithm or whatever to calculate the path to node 7 and we find which is it anyone can see the path to node 7 the least cost path can anyone get a cost less than what 12 anyone get a cost from node 7 less than 12 153 someone said at the start send via 5 that's not so good because even though it's 2 to 5 another 5 that's 7 but then 7 here maybe we could go here it doesn't help much 1 to 2 is 3 to 4 is 5 to 3 is 6 to 6 is 10 to 7 is 12 so here the least cost path actually one of the longer paths so the more information we know the greater the chance we would choose the best path but the more information we know the more overhead in collecting that that's the trade-off here and some of those issues are summarised in these points so let's just recap so the 2 issues are where do we get the information from about the network topology and how often do we update that information and some of the alternatives are listed here well we said where do we get the information from at the very start let's say we know nothing about the network can we do routing we know we have none no information no routing but it may not be very good we said there's an approach called flooding which we'll return to later just send to everyone local means use the information on your node when a device boots up it knows something about itself so it can use local information with very little overhead adjacent nodes is really just a neighbor nodes so we saw if we talk to our neighbors and we know the links to the neighbors we can make a decision on routing based upon their information or we could extend that and say the neighbors neighbors the neighbors neighbors neighbors and so on eventually we could ask all the nodes in the network and if we know about all the nodes then we know everything about the network so the more information we collect the more accurate we are in choosing the best path the other aspect is we need to continuously or we would like to update that information sometimes we can get a continuous update node 1 always knows about the cost to node 5 because it's actually directly connected to that link so it knows that so we got a continuous update if this changes to 3 we know immediately but if this cost changes from 5 to 6 the only way we know is by asking our neighbor or our neighbor telling us so we can have continuous updates or we can do it periodically every one minute I send a message to my neighbors please tell me about the latest cost of your links do it on a periodic basis or maybe when there's a major change in the network instead of waiting on a periodic basis when node 5 realizes the link to 3 goes up to a different value maybe it changes to 10 here a major increase in the cost then node 5 tells its neighbors the link which I passed told you was 5 has now gone up to 10 you may want to change the paths so a major change or node 3 disappears a major change in the topology if node 3 disappears node 5 should tell node 1 3 is no longer there update your view of the network so there are different ways or different places to collect information from and different ways to update that information and now the challenges with routing in general get up to date information but minimize the overhead of doing so any questions so far we've covered the basics of routing learn the information about the network then apply some algorithm to calculate the least cost routes not so hard the next thing we'll look at is how do we store this information that is node 1 finds the least cost paths and it will try to find not just to node 7 but generally we'd like to find the least cost path to all potential nodes so when I have data to send I don't then go and find the path when I have data to send if I know the path already I'll just send the data let's return to our original example that you have in your notes and we'll look at the case of how can we store the information so now what we'd like to do is to we'll separate the process of finding the routes from the process of sending data sending data we need to know the route to send a via calculating the routes is a separate process what's common in networks today and the internet is that the process of finding the route called routing is done independently in the background the process of sending the data along the route called forwarding is done whenever we have data to send so let's focus on the process of routing and how do we store the information of the routes so let's in this example network first how many routes are there in the entire network how many possible routes do we need least cost routes are there in this network how many least cost routes are there let's say I have a server that needs to store all of the routes all the possible routes in the network the paths how many are there that I need to store you can try and calculate them all or they may be an easier way than every other node there are five other nodes so there's five node two needs a least cost route or path to every other node there's another five paths note that the path node one to node two may be a different path than from node two to node one because our links are asymmetric we have different cost of the links if they were the same cost the same path in both directions so node one should have five least cost paths node two needs another five least cost paths and each node needs five least cost paths so in this network there are 30 paths in total so there are two main approaches for calculating them or for storing them one is that we have a central server that calculates this maybe computer seven looks at the network learns the topology and then calculates and then tells every node about those paths more commonly today is that the nodes do that independently node one goes away and calculates its path to the other five node two does it and each node does that and we'll consider that case so let's record some of them for node one calculate all the least cost paths from node one to every destination so the source node is node one I want you to find the paths to all the other potential destinations two three four five and six let's record that information the path the least cost path we're talking about here we'll talk about also the cost of that path let's record that what's the least cost path from node one to node two well from node one direct to node two the cost is two can anyone see a path less than two no there's no path less than two to node two so we say node one to node two the path is one and two and the cost is two to node three least cost path to node three not so hard look through some of them you'll quickly find the path and then do it for the other nodes from node three to node at node one to node three one two three has a cost of five that's not good what about one four five three has a cost of three so be careful there one four five three has a cost of three units node one to node four least cost path and here you can of course you can see it on the picture but one shortcut if the least cost path from node one to node three goes via four then it means the least cost path to node four from node one must be this segment of the path that is from node one to node four the least cost path is one direct to four if there was a lower cost path from one to four then that means there would be a lower cost path from one to three for example and it's not in the network if there was a path one eight four which had a lower cost than one direct to four if there was that means there would be a path from one to three one eight four five three with a lower cost than three but since we already know this is the least cost path that it must be that the least cost path from one to four is one direct to four and that's an important thing that we can take advantage of the path cost if we look at the network it's three in that case and similar here we know that to go to three we go via five that means that there is a least cost path one four five and you can check the cost and one four five six we've seen before the cost there was three is it or four four just record the costs here as well the path costs so what node one does is it learns the network topology it calculates the five least cost path to each destination and stores this information now when I have a data packet to send it's very simple I have a data packet to send if the destination is node three I can look up okay the path to node three goes via node four and five send the packet to node four if the destination is node five then also send to node four so the way that we use this information is now that when we have data to send just do a look up to see who to send it to next and by this concept that we said that if a least cost path from one to three goes via four then it implies that there's a least cost path from one to four similar if there's a least cost path from one to three that goes via four there is a least cost path from four to three which is four five three if one four five three is a least cost path then it means the segments segments in that path are also least cost paths. 453 must be a least cost path. From node 4's perspective, when it calculates the least cost paths, it will say from 4 to 3, it will find the path 453. You can check that. But the point is, because of that, node 1 doesn't care, in fact, about the entire path. Once it calculates the least cost path, it only needs to know the next node in the path. What node 1 will do, it knows to reach 3, we need to send to the next node 4. It will send the packet to node 4. Node 4 will have its least cost path, and to reach node 3 from node 4, the least cost path will be 453, and node 4 will know to send it node 5. Node 5 will have its least cost path, and will send it to 3. The end result, once we calculate the least cost paths, we only need to store the next node in the path. So we don't need to store the entire path. So from node 1 to node 2, the next node is node 2, here it's node 4. So even though we can calculate the path, there's no need to store that. And that makes it simpler for the nodes when we have long or large networks, and there's no need to update anything about the other paths. It makes it simpler for the nodes to recalculate the best paths. So the key information that node 1 stores, for each destination, what is the next node in the least cost path to reach that destination? And every node does that. We optionally also store the cost, and that will be used later. And that information is what we call a routing table. It's a table that we store information about the routes or least cost paths in. We call it a routing table. And to finish, you may have a look at the routing table. Here's what we've arrived at. Every node in a distributed approach stores for each potential destination, node 1, node 2, node 3, what is the next node in the least cost path, and usually optionally the cost of that path. We don't store the path, we just store the next node because of this concept of that the segments in a least cost path are also least cost paths. And the routing table for node 1, here it's listed as a routing directory, but we usually call a routing table, is this table. To reach destination 2, 3, 4, 5 and 6, the corresponding next nodes are 2, 4, 4, 4, 4. That is this column and the next node column. That's our routing table. So we'll spend some time arriving at routing tables. We can see how to create a routing table, and then they become very important in the Internet because we use routing tables to know where to send our data in the Internet. So we'll stop there, we'll look next lecture at some extensions of the routing tables, some other examples, and then look at return to flooding and see that basic approach send to everyone to do routing and compare the different routing strategies.


Robots are getting smarter, but how, Sarah, tell us. NVIDIA Eureka, that's powered by GPT-4, trained robots to do around 30 tasks. The training was done by having the robot software simulate the tasks repeatedly. Then the large language model evaluated them and reinforced improvements. This let training that might otherwise take days take minutes. The automatic response here, especially when I see it spinning the pen like that, I mean that kind of dexterity is something that researchers have been trying to figure out with robots for decades and decades and decades. I like the fact that they always roll this out with a robot that will clean your house before it kills you. So I look forward to the brief happy time where the robot cleans my house. Let's be fair, it'll clean after too to cover its tracks. Will it? Why bother, really? Clean, murder, clean. Now that's a smart robot.


Studying Macbeth, here's how you can analyse Act 1 scene 3 when Macbeth first meets the witches. Macbeth notices that the weather is foul and fair and this oxymoron echoes what the witches said in Act 1 scene 1. Banco then notices the witches and he wonders how they are so withered and wild. Now their literation hair shows how horrifying these witches look. Banco notices that they're women however they have beards. This highlights that they are supernatural creatures, they do not look like normal natural women. The witches then speak in these exclamatory sentences which plant the seeds of ambition in Macbeth's mind. Banco is then annoyed that he doesn't have a prophecy because the caesero hair highlights he wants to also know his future. They then tell Banco that his kids will be kings and this plants the seeds of division between Macbeth and Banco. Macbeth wonders how he can be Thane of Cordor if the Thane of Cordor lives and the hyperforo hair shows that he didn't realise he killed the previous Thane of Cordor. We can see here that Macbeth and Banco are now becoming jealous of each other. Ross then enters and tells Macbeth that he's now Thane of Cordor meaning the witch's prophecy has come true and Macbeth's aside after getting the news shows his growing ambition.


Welcome to the banner bunch. Pretty sure I'm recording. There we go. So, good morning. Standard schedule as usual. Standard agenda. We'll introduce us. Everybody knows each other. Then we'll talk about the standard system. This is January. So, this is our standard thing that we generally do when we're at where we're going. We'll have questions for anybody that has questions like Teresa. All right. Everybody knows Kimmy, Mark, Tyler, Teresa. They kicked me out of that road. Lori, Carl, Lena is back in the office. Catherine, Benub. My name is Gabriel, and Michael Coyer, our CIO.  Yeah. That's the figure. We don't want you to feel left out. So, part of the state of the system, why we do this, part of it's just a plan where it's going to stay in unions in January every year. So, end of the year, everybody has a little time off, they'll reflect. Mostly on family and stuff over our break, but when we get back here, it's a good time to start fresh for a year and have our resolutions and think about what we're going to do and where we've come from. And it's something that we like to do pretty regularly on our crew. Whenever we have a big issue or something like that, we like to have all the lessons learned and we sit down and say, what could we do better next time? This is kind of that sort of thing. So, we'll go over what happened in 2016, and we've had a lot done. I was telling it, I was really impressed. We'll talk about where we're at, mostly about the baseline projects, and then we'll look forward to what are the big challenges coming forward this next year when we have a lot of them. So, 2016 kicked off real early. We did common matching. It was the very first thing that we really implemented. And there was a flurry of activity in January. Common matching was the thing that we had prepped for at the end of 2015, the inner bunch. Common matching is baseline functionality that helps around creating records in manner and making sure we're not creating duplicates or minimizing that as much as possible.  It minimizes that so we can make it manageable. And so we can catch the ones that are created and try to resolve those as quickly as possible. And from our users, we've heard good things to go match. It's pretty intuitive. It saves a little bit of time on searching. And we like it. It's really kicked off a whole year of improvements that we made with dirt. Anyways, we formed a dirt team. Thrice is leading that, made up of people in each functional area that really know the data. They can help us consolidate information from a bad record to a good record, help us remove it. We're creating jobs, helps create a job at the end of the year that will help us identify. Is a record really a duplicate or is it just two people who are really similar? And which one should be the bad record and good record? Dirt or something with a large database, these duplicates are just going to happen. It's one of the natures in the Houston. So it's a long game to just keep improving that over time. And I think we've got a really good foundation for that. And that's how we started out the year. The other big thing that we started out last year with was updates. I don't know how many of you remember that, but we had a massive push back in January of the last year.  Part of that at the end of 2015 was the one person that was handling the duplicates retired, or not duplicates, I'm sorry, updates, retired. And so we actually lost all the knowledge on our team as well.  It took a lot of planning. Carl and Tyler did a ton of work into that. Mark helped out. Kimmy's been helping out. And then since then, every quarter, every calendar quarter, we've kept up to date. We made a plan at the beginning of the quarter, got things into development, assisted with testing, and then rolled into production by the end of it. This first quarter of 2017, Kimmy is leading the charge. And I think Carl's back to the room. And we've got a bunch of tax updates we have to do this month. And then we've got more updates. Kimmy put out a schedule here in the next week or so. And it's becoming operational. Updating the system and keeping it up to date is something that we do now. And it's working very well. About the first half of last year, we also focused on Clean Address. Clean Address is software that helps us maintain all the addresses in our system, the mailing addresses. So they're up to post office codes. They're valid addresses. It's a tool made by a company called Modern Technologies. And it's a really, really good tool. It's a gold standard for banner schools. We had owned it for about a year previously, but we got around to finally implementing it. And it wasn't a plug-in place for an implementation. We had coding that we had to change. Like all the county codes. I don't remember, didn't match up with the national standards. We had to convert all the codes in our system. Part of implementing that is also cleaning up all the addresses in our system. When we went live in July, Mark ran about a half million addresses through the system and cleaned them all up. So now that all of the addresses in our system meet the post office standards and any record coming into the system is clean to start with. It's been a great tool. And Clean Address is something I've had experience in the past, and we've always really appreciated it. The other big thing that came out last year was the banner baseline project. That's something that I know the school had talked about. We had talked about it on our team for years, but it never really gained a lot of traction. Last year, Michael and I worked pretty hard at the beginning of the year to figure out how can we create some structure around this to make it successful. It's something we have to do. Getting to baseline is something that's critical. It's in order to upgrade the system and keep it maintainable and turn on cool tools like degree works and mobile apps, like that we have to be as close to the way the products deliver to make that work here. So we put a lot of project management structure around it. We spent a lot of time with our functional areas discussing definitions. What is this project? What does it mean when we talk about different pieces of the system and how the system is different from the way it's delivered from the museum? We also charted the project. We got an executive sponsor, Dave Henderson. We reported to him on this project. We're accountable for being successful on this project. We meet with him on a monthly and regular basis to report where we're at, what the planning and how things are going, what we need and what we don't need. And so far, I've been pretty impressed with the way that project's gone and I've got a whole other slide where we're going to talk about that next. Because that's currently our number one priority. That's what we're working on at least 50% of our time. We're not fixing things that are broken or updating the system or working on other projects. And the other thing that came out last year, we've been able to... Some of the reason we can get a lot of this done is we've been able to augment our team to be able to get more resources. Part of that's really visible. We've got Catherine. She started in November. She'll be here for 13 years. But we also have been relying on losing it quite a bit. We've got some elevators for support from them so we can refer to them sooner, get cases resolved faster. We're also bringing in consultants. Next week, we're going to have a consultant coming in to sit with HR, walk through a whole business process now. So if we look at how we're using the HR module banner and how can we do it better and what can we do differently to make it as efficient as possible. We've got the most out of the system. We've also got student consultants coming in. There's one coming in at the end of the month here that's going to help us really get ready for degree works. And having those experts come in and help us really shortcuts a lot of the developments. It's a lot of our answers, questions answered quickly. And I really appreciate the effort that they put in as well. Pollution is a great partner for us. In addition to that back last year, I've already moved to the next slide, but one thing I didn't mention is that that's just the highlights of what we did last year. We did a ton of extra work on projects that were big and small every year. I was looking earlier this week, we have a system called CSR. It's our customer service request team. We completed 43 major CSRs last year. And that's above our team. I looked back over the past 10 years. Some years we've had 20, some years we've had 60, but 43 was quite a few. And that's just the major effort we documented. There's a lot of other work that happened on this team. It was just a great fix sort of things or day-to-day operations that we didn't capture that much. So there's a lot of work that happened last year. So the baseline project, this is what we're currently focused on. We've got a few other projects going on, like academic works and Oregon Promise and whatnot. But baseline is where we're focused. And last summer we spent about three, four months building an inventory. Before we had started this project, we knew that we were different from the way that the product was delivered by this team. We didn't know how different. We knew there were modifications. We knew there were things we had built that were new to the system. We didn't know what all of them were. We lost that knowledge over time. It never really been documented 100%. So we built an inventory. And when that was completed back in September, we could tell you now exactly where we're different. We've got a master inventory. In fact, I can show it for a second here if you want to see it. How do I share it differently? You can share the best stuff. We've got a spreadsheet that we're maintaining that's got over 5,000 rows of data in it. And we're keeping track of where our modifications are, what the notes say that they do, who we think owns them, all sorts of information in here. And we've been able to condense that down to a summary that I put out last October when this was done. It's about four pages and it clears up all the definitions of what we have, where we're modified, where we have met new, and what we think the plan is going forward. Now, the inventory didn't solve the problem. They just let us know where we're at. Where is all of our stuff? Since then, we've taken matters for it. We began meeting with all the different functional areas on a bi-weekly basis to look through every single row in that spreadsheet and say, what is this? Why are we modified here? Why did we build this? What value does it provide? Who's using it? Is there a baseline way to do this? Is there not? How would we do this if we hadn't built this on our own? And we've learned quite a bit. One of the things we've learned is that there's a lot of stuff out there that we have built in the past and then stopped using it. Nobody's using it now. The past couple of months, we've actually been spending a lot of time just cleaning up a lot of the low-hanging fruit and obviously the things that nobody's even using, where you can spend a lot of time maintaining it, but they provide no value. Well, they provided value 10 years ago and now it doesn't make sense anymore. After all of that's cleaned up, these are the major efforts that are left over. A few of these are actually completed. Phi Theta Kappa had a couple of spring that rebuilt the system that we've just absolutely because they can get the information elsewhere. Person searching. Last month, we did a banner bunch on. We changed the way returns in searching worked in banner. It wasn't really that far off. We just changed navigation. So we baseline that. If people are using the baseline, person searching out. What the idea to put on here is hotkeys as well. Placement test scores functionally have been obsolete for six months now. We're no longer using the functionality that we've built, but it's still in the system. So Timmy is doing a lot of analysis on how we can remove that from the system without losing all the data and making sure that we don't break something in the process. Direct deposit. We know that functionality that we've built for direct deposit is actually all available in banner 9. So our plan on that is just to wait until we get to banner 9 and then as we migrate to that new system, we'll take out the modifications and move on. Fine grain access control is something that gives us a little bit more granular control or what sort of fields people can access in banner or change or see. We've built a lot of locations to banner that did that same thing. So as we implement fine grain access control, Theresa and I are working on that. We'll be able to obsolete a lot of these modifications that, for example, the email addresses where nobody can change email addresses. We don't even modify that. We can actually put fine grain access control over that and then only give certain people access to change email addresses. Check-in stations are right now in kind of a discovery phase. All the check-in stations across campus, we're looking out there and spending a lot of time doing analysis on why are people using these, especially for FTE, where is that being captured, and how can we do that otherwise. I know that they're used for attendance tracking and so we're having conversations with people about, well, why don't we use Moodle for that or for banner or spreadsheets or whatever makes sense. Or if it's being used to track students, like up in the learning center, they track students as they move around, tutor track, another tool we have, has the same sort of functionality as check-in where you can have a kiosk where a student checks in in each section of the process and you can see where they go and what resources are being utilized. That's one that's going to take a while, but we're already in the way of figuring out how to maintain that without all this net new system built on the side. Elaine over in Financial Aid knows that we need to get to baseline SAP. She wants to do that. Domino's that. Falling away. We got that happening. That's where we're already working on that. Cohort. Tyler will be working on moving cohort. That's usually used by college now. That's mostly what's using the cohorts as we build. And we've already had conversations with them that we can be using attributes in banner or student type or classification or different ways to make that happen. Project management. Catherine is doing a lot of analysis right now and we've had a few demos of project management tools that we can use. The CSRs that I mentioned earlier are a net new system that we built inside banner to do our project management. There's really not a need for that. It works. We've been using it for the past year and a half since I've been here, and it works pretty well, but there's other tools like Basecamp or Jira or Podio or even Word and Excel if you add to manage projects. We don't need to change banner in order to do that. Proxy access refers to FERBA. We built a form in banner that actually works really well to capture whether or not a student is going to allow their parent or third party access to their information. Banner has a system called proxy access that works in the way. I don't know a whole lot about it, but that's the direction we think we're going to go with that one. Black Friday, we have a pop-up itself service that we can probably handle with a go tax. We'll get to that when Black Friday gets closer. Instructor approval of part-time faculty, both are larger systems that impact our part-time faculty that are heavily used. So those two are going to take a lot of planning if anything's going to go wrong. We're going to transition to any other sort of tool of baseline functionality. That's one that we're going to be looking at next week, which John Briggs, our HR expert, is coming in. There may be other ways to handle that. These ones are going to be bigger projects. And probably the biggest project is job submission. The main thing is about Schwartz. And we talked about how Schwartz will eventually go away. That doesn't mean that the jobs that we run, the processes and reports that we love will go away. What that means is that Banner has a job submission, a framework to run those jobs in, and we built our own on the side. It works amazingly well, but it doesn't make sense to maintain two ways to run programs. Two different types of non-organisms, essentially. So baseline right now we're at is where we have done a lot of analysis. We know we need to attack, and now we're trying to run the next six months to get all of this completed. In the case that any of this isn't completed, the only way we're going to be successful in this project in June is if we have a plan in place. We've documented how we're going to complete this in the future. Kind of like direct deposit. That won't happen by the time June comes here, but we know exactly what our plan is going to be. It's going to be turned on in Bandard 9. So we're already starting to talk about 2017. The first half of the year, baseline is still going to be our priority, our new priority. The next priority that's coming in right behind that is degree works, and we're already beginning to work on that. So we've got a student consultant coming in at the end of this month to help us work through some issues. We could turn on degree works tomorrow, and it would break the minute we turned on because we're using certain parts of Bandard, even if they're baseline, like level codes. We're using them in ways that degree works doesn't expect. So when we turn on degree works, it won't work for us. So there's a few projects that we've got to take on before we even get to the point where we can turn on degree works. We think that if we're successful through all this, we could probably go live with the degree works fall of 2018. That's what we're aiming for. But we've got about a year's worth of work before we can get started implementing that. Level code is one that we know about. We use different level codes for curricula versus the student. Bandard and degree works expect those codes to be the same. And that's a major undertaking because we've got a half a million active students out there that have codes that don't match up, and we can't go through manually to touch all those. In fact, automating a hundred algorithms is scary. So that's one of the reasons we're bringing in consultants is to figure out how to unravel that. Part of that's going to be building a readmission process. We have a process here at the community college to just admit people once and their students forever. That's not typical. Typically, people would cycle out. They're still admissible. They're still students, but they're not active students. So there's a way to distinguish that and better. We don't do that here. So we'll move to that process where we have maybe, if you've registered in the past year, then you're an active student. But if we haven't seen it in a year or so, we'll be coming in active and just have to let us know if you want to come back. It'll be a process, right? It's called readmission. And it shouldn't be a barrier. It should be something that's really easy for somebody to do. Turn my student record back on and take another class. But in order to do that, we need a consultant. We'll look at registration status codes. We're going to look at the way it interacts with financial aid because DegreeWorks uses a different system than CAP, which is what we're currently using for financial aid and tracking degree audits. There's a lot of foundation work we have to do for DegreeWorks. We're already prepping for that. Mark is spending a lot of time on Ellucian Solution Manager. That's been his focus for the past year. And what that is, that's a tool that helps us manage our servers. That's on the technical end of things. But we need to have Ellucian Solution Manager to help us with these upgrades. Right now it's a very manual process for our programmers. ESM would help with that. ESM would also help with managing the new hardware that we have in the future. So we're getting that in place. It's also a requirement for Banner 9, as well as a single sign-on. Does everybody know what a single sign-on is? It's essentially, if once you sign it to one system, you can share the credentials with other systems. You can sign it to Banner and then Moodle would know that you're good and you sign it automatically. You're going to have to type in your password again. That's sort of the concept. We have to have a single sign-on already in Banner 9. It's one of the requirements. Do you know, so I don't want you to have a single sign-on, but they don't have single sign-offs.  And I'm wondering if, will that be our case? Did you know that? You probably know that. Well, now I'm wondering about that too. I've been really focused on, the technology is really focused on signing people in. I don't know if there's a lot of people signing people out. Part of that might be handled with an active director when you log off your computer and then log out with everything else at the same time. But that's interesting. I'll have to bring that up at our next SSO meeting. And we'll think about that. Yeah, I didn't know that was an issue. Well, I just, when I was at OSU, I discovered that Greg and I used to joke about having to get back out. We had to keep saying I'm out, I'm out, I'm out and everywhere that you've been, you get another screen that pops up and fits. Well, I'm still here. Catherine came from OSU. Do people even talk about single sign-off there? Yep. I've never even heard of it. Well, if you close your browser, it should be automatic. So maybe it was something bad and I just told Caroline. Yeah, the section of token that would authenticate you to all those sites when you close your browser, it didn't work. Then you're done. Next time you open another browser, you have to start working on it. You've got to get it all over. We'll bring that up though. That's worth looking into. I've never done that. So single sign-on is going to be one of our projects once ESM is up. In fact, you'll probably come with it and become available and then we'll start connecting systems to it. We're working with the network team and the hardware team on how we make that work here on our campus. Banner 9 is kind of that golden egg at the end of the road that we keep working on. We'd love to get to Banner 9. The more Lucian releases for Banner 9, the more we get excited about it. I'd be happy to show anybody what it looks like and what to expect when it gets here. It's a leap forward in the user area we'll see. If you really like the functionality of Banner IMB, the standard banner screens that you go into, all that functionality is still on Banner 9. That's the way it looks. It looks like it came from this decade. It's a lot more intuitive. It gives you a lot of functionality that you'd expect from an open-based service. We really want to get to Banner 9, too, because it's based on some technologies that are slowly going away. You can't use Chrome now because it doesn't support Java. Pretty soon, the Firefox will be the same way and Internet Edge doesn't make it easy to make that work. We're going to have to get to Banner 9 sooner or later. Banner 9, if we're baseline, makes a lot of cool things possible in self-service as well. How do you suppose we'll avail them all and consolidate all the information together for advisors and for folks that deal with students? The employee profile is amazing in Banner 9 self-service. It's pretty cool. We want to get to it. The mobile app will work very well with Banner 9 as well. One of the tools you may not have heard of is ISSM, the International Student Scholarship Management. We'll work with the international folks in the various parts of our office to try on that tool. It will help us manage our international students a little bit closer and report better to Homeland Security on them. If anyone's gone to OSU in the past few years, it's very similar to a tool called HEPASA Alice. Another tool for our foundation is academic works. Tyler's helping them get that up and running. So we've got a lot of projects for this year. These are all big projects. We'll probably have another 40, 50 other little projects that have gone along the way. This is where our focus is at. And this is a pretty ambitious year, but I'm fairly confident we'll get to it. One other thing I want to mention too before I go into questions, this is actually a slide from last year. This is what we presented at our State of the System a year ago. We were going to focus on infrastructure. We're going to focus on Banner. We're going to focus on projects. We've actually shown we have done that. But one thing that I mentioned last year and I want to mention again is change. We're driving a lot of change on this campus by doing these projects. And we want to be very conscious of that effort. We want to manage change here very carefully. We want to make sure people are in the loop on when we're changing things. We want to make sure we're communicating. We want to make sure we're doing training so that we don't catch anybody off guard or pull a rug out from anybody. The work we're doing should be making your lives better every day. And I think we've actually accomplished quite a bit of that. I think we've done a pretty good job. And there's always room for improvement, but that's going to continue to be our focus is making sure that when we change things, it's done in a knowledgeable and planned out and well thought way. The other thing on this slide that I also want to plan out one of the reasons I put this in here is I can't say enough how proud I am of this team. We have a very strong team on this campus. To be able to do this amount of work with three people, now four programmers and Lori and Theresa and Lena and everybody else, I am just constantly in this. And honestly, I think they all deserve a round of applause. I think they're fantastic. So questions, you can have questions about where we've been, where we're going or it could be questions about anything. So go ahead and open it up. What are you saying, Debbie? I'm not going to pass it once. You can go, right in there. How have we done this past year? We did do a lot of work and did a lot of change. The read that I get is that we're doing a pretty good job, but I like the compliments as much as I like the complaints. We need to hear how to create, to make sure that we're on track. Please don't struggle a little bit. Webrunner in the advisory faculty section. It doesn't flow as easy as that. The information in there isn't always exactly what we're the people for. So then we have to have a double check, to get some of your peers and stuff. So, I mean, we work with it. It's not, it's been a good job. I remember when we moved from class information, writing the homegrown system to the baseline, acting as a self-service. That's when we really started focusing on change. Because honestly, the change wasn't managed well. I think we've short of most of the functionality with other ways of doing things, getting class lists and rosters and that sort of thing. I'd love to sit down at some point and either give more training on faculty self-service. We did a banner bunch back last February to March on this. We definitely could revisit it. Or even visit each individual area. We used to part of our college and give a little bit more one-on-one sort of conversation about what works, what doesn't, what can we change and have control over versus what are things that we might actually just look to the future of a banner line. Because it will get a lot nicer than a banner line. Obviously that. I'll touch base with you. Yeah, I mean, it's nothing that we don't work around. It's just a point here. Another thing I have to admit is that banner tends to focus more on administration as a tool than faculty and students. And self-service is always there. And the web apps, the permission and the public prospects. But the focus is more on administration. And so I began managing the mobility as well. Obviously. And I'm starting to spend a lot more time focusing on what are the faculty needs in students on this campus so that I can understand what you do day to day a bit better and how are the tools that we have banner to literally anything else going to help you accomplish your job. And one simple frustration in self-service is when you do pull up a class list or an unofficial transcript or whatever and you print it out. It cuts the page right in the middle of the student. So you have half of the student's name and they go on one page. So you usually have to get a pin out and actually write that person's information out. How interesting. I don't think I've ever seen that before. And that happens a lot. And it just depends on how many students are in the class and if it does break across the page it almost over the space right in the middle of the students. Yeah, I wonder if it's because of the way the browser's displaying it and it's cutting it off the floor or something like that. Let's look into that. Definitely. Other comments, questions. Kevin's not usually shy. Do you have your coffee? Yeah, right. So I was thinking there's at least two major processes that I have that we found either part way through or right before we started them that we needed a more recent version of Banner. So those three years were periods we were talking about. If this team hadn't undertaken that, what they did we would have been left with having to come up with a totally separate manual process. But it's a huge, really tight, intensive place. So the work that you have all done was saved, at least today. I'm sure a lot of people have made several hours. So thank you. I know we're already looking ahead at 1098s for this year and that's the main thing that I'm just going to be helping us with that and push that up in schedule because we can do that. So that's what exactly we're going to do. This upgrade cycle will actually be a little odd because it's also the year-end we will have an abbreviated cycle at the beginning and then the whole quarter cycle will take everything else and we have upgrades to HR, account receivable, position control, and employee self-service. It's all in terms of taxes too and changes that happen in control of the year. In fact, we got really lucky last year that we had taken on doing the updates when we did because if we had waited even a month later we would have been behind the ball with a lot of things we were talking about because we had learned that tax updates previous to that were kind of a non-issue. You just put in the one file and you're done. It turned out that that tax update actually had prerequisites that led to almost all the other updates having to be in place for it to happen. We got lucky honestly and now that we're doing this on a quarterly update or quarterly cycle we want to end up in that position again. Thank you. Anything else? I see a new space in the room and not necessarily like point fingers. I would imagine are you are... Me? No. I don't imagine you are a new gallon of presence office doing... No. No, I don't hear a lot. Oh, that's... Okay. All right. Sorry. I was all excited. There is a new person in our office though working in the curriculum and scheduling department and it's Shauna Hunter. She was previously actually working with Eilord but she's our new schedule coordinator. One thing I've noticed that we've improved upon and part of it's conscious and part of it's the change management we're doing we're communicating as a campus and we have a lot of feedback on this team. Much better. I feel like we're always in the loop and it doesn't seem to catch the soft guard as much and you're in the loop and I think that's fantastic. We've known that we can always improve upon and that it would be a great job of not as well. All right. Well, we've recorded this. It's a new available on YouTube as usual. One of our challenges moving forward is finding more subjects for banner bunches. So let us know if there's anything abandoned that is a pain point. We'd love to learn more about whether you think others would benefit from having one of these. We're going to have one in February, March, April, May. We probably won't have one over the summer. Last year we learned that people aren't here after the summer and don't show up to use it. So we work on that as well. We appreciate you coming here and listening and let us know if you have any questions. Some people over in our area had so I come when you talked about changing the baseline of the swing and everything but a lot of people had missed it and so they had used the old one a lot to look and search by birthday and by address and such and then they couldn't figure out how to do that now that that had changed and so I was able to help them with it but they thought maybe if you did another training you could have a search other way as well with health care and stuff. It was like a way to have some questions and everything. Let me grab your contact info and we'll schedule something. I'm more than happy to have these. They're also available online but we may not have gotten into that granularly in detail in advance. I know there's some issues around the way data for searching works now and that sort of thing. Alright, well thank you guys. Thank you very much.