So we went through the, what is congestion in the internet yesterday, the causes of congestion and the result, that is, what's the thing that we don't want to want, don't want, which is the increase in delay and eventually drop packets because they cause problems with performance for our applications. So if we have no way to control congestion, eventually our network or our internet will fail. So TCP has a mechanism for controlling congestion built in and that's the main form in the internet today for how do we control congestion, TCP does it for us. Just going back, recall that there are three main features of TCP, there's the reliability feature which is retransmissions. We send data, if something goes wrong we resend the data, retransmit and the retransmissions occur if we have a packet loss and just so we remember, the types of packet loss, so with the retransmission scheme in TCP for reliability, we have two events that indicate a packet loss. We have a timeout and also this special feature of three duplicate acts and the names of the retransmissions schemes are called simply basic retransmit which happens when we have a timeout, that is I send data, I'm waiting for an act, I don't receive an act within some time, I retransmit, that's basic retransmit. The problem with that is that waiting for a timeout means that we have to wait in some cases too long which causes a low throughput because we wait a long time before we send anything and because in many cases we send multiple data frames and we expect to receive multiple acts, if we lose one of those data frames, one of those data packets, then it's possible that we'll receive multiple acts with the same acknowledgement number that as I send a sequence of six data frames, I expect to receive the respective acts back but because one of those data frames was lost, I receive an act only for the one that was successfully received in order and I eventually start to receive duplicate acts, that is acknowledgments with the same act number as the previous one and if we receive multiple duplicate acts and TCP defines three duplicate acts, then that is four acts with the same act number then we assume that something's gone wrong, a packet has been lost so we then retransmit, so two indicators of a packet loss and both result in a retransmission. The other feature that we went through last week was flow control and the idea is focusing on the end points, the source computer, the destination computer, flow control is controlling the speed at which the source computer sends so that it doesn't overflow the buffer at the destination computer and one of the parameters we have associated with that is the advertised window, AWND and so we can think that the source has a parameter called the advertised window, the value is set by the receiver and the source, the amount of bytes it's allowed to send before it has to wait for another act is limited by the advertised window, but in fact we have a third mechanism, congestion control and that's what we're going through now and what we introduced yesterday, we have a new parameter, CWND, the congestion window, similar to the advertised window it is used to control how many bytes it writes, the source is allowed to send and in fact the source is allowed to send is limited by the minimum of these two parameters now, so imagine the source now has two parameters, the advertised window, so many bytes and the congestion window, the number of bytes it's allowed to send at some point in time before it has to wait for an act is the minimum of these two, it can send that number of bytes then it will have to wait approximately one round-trip time to receive an act and then that may then allow the source to send more bytes, so we can send a window size every round-trip time on average where the window is limited by these two parameters, the minimum of advertised and congestion and we mentioned yesterday that the congestion control is about making sure we don't overflow the routers in the internet in between the source and destination that is do not cause congestion in the internet because that increases delay and leads to packet drops, so we mentioned also that an indicator of congestion is packet loss, so when I start sending my TCP source start sending data, if there's some packet loss then that indicates that there's some congestion in the network and our response to congestion is to slow down and to slow down we reduce the congestion window because the congestion window controls how much I'm allowed to send per round-trip time, so if I reduce the congestion window I can send less per round-trip time that is my sending rate reduces, so these three mechanisms, retransmission, flow control, congestion control, although we try and describe them separately and independently they're all related in that congestion control makes use of the events for a packet loss, which is also used by the retransmission and our source, the speed at which it can send is limited by both flow and congestion control, whichever one is higher, which is lower, that's the sending rate, so the main things with TCP congestion control is how does the TCP sender limit its sending rate, well the sending rate is proportional to the window size and the equation we've seen, sending rate is approximately equal to the, let's generalize, the window at the source divided by the round-trip time, we can send a window of bytes every round-trip time, where the window is the minimum of the two windows we have, advertise window and congestion window, so how does TCP send a limit its sending rate by changing the congestion window, that's the answer there, because we cannot control the round-trip time, in a network we cannot control what it will be, that's a characteristic of the path, but we can control the congestion window, that is the source can increase and decrease it, how does the sender perceive there is network congestion, so somewhere between the source TCP host and the destination host there may be congestion in the routers, how does it know, packet losses, packet losses are a good indicator of congestion occurring so as we said yesterday a packet loss, or a packet loss event, a timeout or three jupyger acts is an indicator of increased congestion, and now what we want to go through is, well how do we respond, what do we do when there's increased congestion, the congestion control algorithm, so limiting the sending rate is the minimum of the two windows divided by round-trip time, what we're focusing on here is the congestion control, so to keep it simple let's assume that the CWND is always smaller than advertised window, just for our examples here, that is let's assume the advertised window is very big, which means CWND will always be the minimum, so the congestion window controls the sending rate, in reality it may not be the case, just for simplicity for now, so we can concentrate just on the congestion window, and we said two different types of events, timeout, three jupyger acts, timeout is an indicator of a lot of congestion, whereas three jupyger acts is an indicator of a little bit of congestion, the more congestion we perceive that we think there is, the more we're going to slow down, so depending upon the event here we'll behave or respond differently, so let's go through the algorithm or the steps for how to respond, the other thing which we haven't said, congestion control is about decreasing the sending rate when we experience increased congestion, but also the other way, when we experience less congestion in the network then we increase our sending rate, so what the source should do is modulate is to maintain its sending rate, if there's congestion reduce, if there's no congestion increase, and so that it maintains a sending rate to avoid congestion, how do we increase or how do we detect decreased congestion the presence of acts, similar here, when we said we send data, if there's a packet loss that indicates increased congestion, but if there's no packet loss, my data gets there and the acts come back, that's an indicator of decreased congestion, that everything is going well, so the arrival of acknowledgments indicates that the congestion is going down, we can send more, so the faster the acts arrive the larger the decreasing congestion and the more I can send, so we have two factors changing how much we're allowed to send, losses decrease sending rate, acts increase sending rate, but how do we do that, we have what's called a congestion control algorithm and there are different ones, we're going to go through a very simple one and it has different components what we're going through, so we'll go through each of them separately, the first component we'll go through is additive increase, multiplicative decrease, that will be the way that we increase and decrease our congestion window, AIMD, slow start, SS, slow start is a special mechanism to start the data transfer and then how to react to packet losses, what do we do when there is a packet loss, so we'll go through each of them, some terminology that we'll use, some of you have seen, we have a congestion window, CWND is the abbreviation, measure that in bytes, so that's a counter of bytes, the round trip time, measuring in seconds, milliseconds and we'll assume for simplicity that in any of our examples the round trip time is constant, so when I start a TCP connection we have some round trip time and it stays the same while we're transferring data, in reality it may go up and down but for our simple analysis let's assume it's constant and the other one, maximum segment size, MSS, this is the maximum number of bytes that TCP will send in a segment, in a packet and it's determined normally by the path because if we have a source and some routers in between, between the source and destination host, each of these links normally have a limit as to the maximum frame that they can transmit, how many bytes they can transmit in a frame, for example in Ethernet it's about 1500 bytes, so in Ethernet frame normally the frame has 1500 bytes of data plus or minus a bit because of headers and other technologies have their own limits, so let's say this link has a limit of 1500, the second link of 1000 and the third link 2000, the goal with TCP is to send a segment such that across the path segmentation will not be needed or fragmentation of the IP datagram will not be needed, so when TCP sends a segment at the source, how big should it be in this example? What we want is when we send this segment from the source as it goes through the path it doesn't have to be split up into smaller segments or smaller IP datagrams, so how big should it be at the source? 1000, ignoring headers and so on, it should be as big as possible because the larger it is, the lower the overheads of the headers, but it should be small enough so that it will not be fragmented by any of the links. If we had 2000 bytes here, in the first link we'd have to break that into two packets one with 1500 bytes, the second with 500 bytes because the maximum size on the first link is 1500, if here we use 1500 it would be okay across the first link, but on the second link we'd have to fragment that because the second link has a maximum size of 1000, so in fact for our path the ideal maximum segment size is that which is the minimum of the link maximum packet sizes, so this 1000 would be our maximum segment size used or set by TCP, usually TCP determines that at the start of a connection or assumes some value, so we're going to assume that we know the maximum segment size when we discuss how TCP works and we'll assume some value for some simple analysis, so that's the size of the segment that TCP sends or at least the maximum size, it will not send any larger at any one time. Last thing we're going to assume is that whenever we send data segments from source to destination as the data segments are received by the destination the destination will send one act for every data segment received, which is what we'd expect, I send 10 data segments to the destination, destination receives 10 data segments, one act will come back for each one received, that is I'll receive 10 acts back, that's what we'll assume here, in fact in TCP it doesn't have to work like that, TCP has options to allow you to send one act for multiple data segments received, but for simplicity one act for every data segment, so we have maximum segment size, let's say it's fixed or it's given, round trip time for a particular path is a characteristic of that path, it's fixed and congestion window is what our algorithm is going to change. The first part of the algorithm is AIMD, additive increase, multiplicative decrease, how does it work? Two parts in fact, additive increase is the algorithm to increase the congestion window and multiplicative decrease is the decrease, so if there's no congestion detected, we're receiving acts back, everything's okay, then increase our sending rate in an additive manner and we'll see the difference between the two, in a linear manner, so the idea is that we start at some slow sending rate and if there's no congestion detected then increase our sending rate and keep increasing and keep increasing until there is some congestion detected and then we'll drop it down again, so additive increase is the way that we increase the sending rate and it does so in a slow manner, the AIM is that the sender will increase the congestion window by one maximum segment size every round trip time, so let's say we have, let's put some numbers to that, let's say the maximum segment size is a thousand bytes, round trip time 20 milliseconds and let's set the start of the TCP connection, and let's set the start of the TCP connection, so we've established a connection from source to destination, we want to transfer some data, let's set the congestion window the initial value to one maximum segment size to 1000 bytes, so we need some initial value and in fact the initial value in practice may be two or three maximum segment sizes but usually quite small, so the idea is that if there's no congestion what we want to do is increase our sending rate and the equation I just removed here was sending rate is equal to congestion window divided by round trip time, round trip time doesn't change, let's assume it's fixed, so to increase our sending rate we increase the congestion window and the goal is to try and increase it by one MSS by 1000 bytes every round trip time, so we could draw that as, congestion window is 1000 bytes meaning we're allowed to send 1000 bytes, so we send 1000 bytes, how many segments? One, our maximum segment size is 1000, we're allowed to send 1000 bytes of data, so let's send one segment, take some time to get there, some time for an act to get back, how much time? 20 milliseconds, so here's 1000 bytes of data, we send one segment, 20 milliseconds later we get the act back and as we receive an act we're allowed to send more data, how much more? Well the idea is that in additive increase, increase by one MSS, one maximum segment size, so now, let's make it a bit clearer, initially the congestion window was 1000 allowing us to send 1000 bytes, after one round trip time receiving an act let's increase it to 2000, we've received an act, the reception of an act indicates everything's okay with the network, no congestion, so let's increase it to 2000, how many segments do we send? Two, make them a bit smaller, and we send two, one immediately after another and eventually we'll receive the acts, my diagram's not very good in terms of scale, the time to transmit those segments will usually be very small compared to the round trip time, so my scale here is not so good, we, at what time do we receive the first act? At what time do we receive the first act? About 40, time 40 milliseconds, because we started at time 20 and it takes a round trip time of 20 to get the act back, so receive the first act around time 40, what about the second act here, what time do we receive that? This is where my diagram's not to scale, so don't be fooled by my scale, approximately what time do we receive the second act here, and it's not 60, and it depends on the transmission rate, but let's say the time to transmit this is quite small, so the round trip time depends mainly upon the propagation across the network, the queuing in the routers and to get back, the time to transmit is quite small, which means if we receive the first act around time 40, then the second act will be shortly after that, maybe 41, because small time to transmit the data and then immediately send the next data frame, data segment, and therefore the second act will come back a little bit after the reception of the first act, the exact time we cannot calculate here, we'd have to look at the details of the network, but the point is approximately the same time, a little bit after the first act. This assumes that the round trip time, the main contributor is the path delay, not the transmission time, which will be the case in most networks. Effectively we send two segments and about 20 milliseconds later we get the two acts back. Of course one comes first, but approximately 20 milliseconds later we get the second act back as well, so it's not exact, but around about. Yes, because let's say we put numbers to them and let's say we transmit start at time zero and it takes 0.1 millisecond to transmit, then we finish transmitting at 0.1, the first one, and then after 20 milliseconds because the long delay to get there and to get back, at time 20 we start transmitting 20.1, the next one, 20.2, receive the first act at 40, receive the next act at what, 40.1, which is approximately 40. So yes, it's as if we transmit it at the same time. Let's get rid of them to make it a bit clearer. So I'll just say here we receive the acts at about time 40, that is after another round trip time. First round trip time, second round trip time. Now let's increase the window up to what value? What do we want to increase our window up to? Aim is to increase by one MSS every round trip time. So let's make it 3,000. Allows us to send three segments and we'll run out of space. Send three segments after approximately one round trip time we'll receive three acts and then increase to 4,000, 5,000, 6,000 and so on. A slow increase of the window every round trip time. Any questions about the idea there? So first the aim, increase by one MSS every round trip time. That's a slow increase, that's the design of the algorithm. And in this case we've tried that every round trip time we receive an act or in some multiple acts, increase the window allowing us to send more. In this first time round trip time we've delivered 1,000 bytes to the destination. So in say in this first period of 20 milliseconds we delivered 1,000 bytes to the destination giving us a throughput of what? If it takes 20 milliseconds to deliver that 1,000 bytes what would you say the throughput? We could calculate 1,000 bytes in 20 milliseconds, 8,000 bits. What have we got? 8,400,000 bits per second, 400 kilobits per second I think in that case. So you can calculate quite simply congestion window divided by round trip time. And here it would be 2,000 divided by 20. So an increased sending rate and here 3,000 divided by 20. So this was what 400 kilobits per second 8,000 kilobits per second 1,200 kilobits per second and so on. We increase by 400 kilobits per second every round trip time. We'll see an example later with numbers to it. So remember an increase in the congestion window is an increase in the sending rate and that's what we're trying to control. What else can we say? Let's show a plot, give an idea. They don't capture it so well. Let's not show a plot because I don't have one. I think if you plot this over time you see every round trip time increased by 1,000 the window size or increased the sending rate by 400 kilobits per second. So we've got a linear increase in the sending rate. This phase of additive increase is also sometimes called congestion avoidance. Now we said the goal was to increase by 1 MSS every round trip time. When we implement this that's not easy to measure and to implement. That is for the source to do that what it would need to do is to record the round trip time and then at every every after say 20 milliseconds increase its congestion window. The round trip time may vary. The way one way to implement this to achieve or almost achieve this goal of 1 MSS every round trip time is to use this which works by incrementing the congestion window every time you receive an act. It's a little bit better to implement from the sender's perspective. You take the old congestion window, whenever you receive an act take the old value, add MSS MSS squared divided by the old value to get the new value. Let's see how that works in our example. So the equation, we'll use this equation and see how it works in this case. Whenever we receive an act let's modify the congestion window. Initially it's 1,000. MSS is 1,000. When we receive the first act what is the new value of the congestion window? Try and calculate the new value when we receive the first act using this equation. Initial value 1,000 what's the new value? This is applying this equation which is used in practice to implement the goal of increasing by 1 MSS every round trip time. We'll see through this example and see how it approximates our goal. So we send one data segment. Congestion window is initially 1,000. When we receive the act we increase the congestion window. We take the old value 1,000 plus MSS times MSS divided by the old value and we get 2,000 in this case. So our initial value was 1,000. When we receive the first act the new value is 2,000. We'd like these red values to be the same as the black values. We're trying to approximate the black values here. Receive the next act. What do we get? Well we use the same equation. We now, our new value is what do we get? We take the old value which is now 2,000 plus MSS squared. MSS stays the same. It's always 1,000 in our example. So plus 1,000,000 MSS squared divided by the old value, 2,000. What do we get? 2,500. 1,000,000 divided by 2,000 is 500 plus 2,000. So this is the value after receiving this act here, 2,500. But then we almost immediately after we receive another act. So let's calculate again for this next act. We take 2,500 plus a million divided by 2,500 equals 2,900. 400 plus 2,500. So that's the value after receiving this second act here. Is it the same as our desired 3,000? No, but it's very close. The idea is that after one round trip time increased by 1,000 after each round trip time. The way that TCP implements this, instead of having a timer and count round trip times, is simply whenever you receive an act, apply this algorithm. And this algorithm approximates the idea of one MSS every round trip time. And we see in this case, we desired 3,000, we got 2,900. And you can follow along that it doesn't get exactly the value, but it's approximate. So we get an approximate increase of one MSS every round trip time. Yes, it's slightly smaller than normal. But it's just an aim. This is just an aim. It approximates that roughly. And it's much easier to implement because all the source does, it doesn't have an extra timer at the source. Just receive an act, change the value. Whenever you receive an act, change the value. Rather than trying to record the round trip time and having a timer that expires to tell you when to increase the value, it's just an easier way to implement. So the goal, still, is slow increase of the congestion window. We're still focusing on the case where there's no congestion, a slow increase. Okay, now let's avoid some congestion. What do we do if congestion is detected? The general approach, we want to decrease the sending rate. That is, we want to decrease the congestion window. And the general approach is if there's a loss detected, halve the window. Cut it in half. Of course, don't go too low. Normally too low is just one MSS. So once you're back to one MSS, you'll no longer cut it in half. So if the window is 10,000 bytes and one packet loss is detected, then the window will drop down to 5,000 bytes. And this is the multiplicative decrease, an exponential decrease, a fast decrease. The increase is slow. Every round trip time a slow increase. But when congestion occurs, the decrease is fast. That is, we drop rapidly. In fact, we cut it in half. So we halve the sending rate, every packet loss. And combined, we get additive increase, multiplicative decrease. The algorithm here, or the general idea is simple. Just whenever there's one packet loss, halve the window. We'll see that there are some variations of that later. The idea is something like this, where over time during our TCP connection, this is the congestion window. The other way you can look at this is this is the sending rate because they're proportional. We start, or in fact this, we usually start lower, but in additive increase, we increase the sending rate. We increase the congestion window. When there's one packet loss, or a loss event, we halve the value. And then we go back to additive increase. Increasing, everything's okay. Keep increasing. Everything's okay. Another packet loss, halve the value. And keep going for as long as our connection runs. That's the idea of these two mechanisms. With you see that the idea is that this tries to send as fast as possible, but trying to also avoid congestion. We'd like to send, or have a high congestion window, that is a high sending rate, because we want to get our data there as fast as possible, but we don't want it too high that it causes packet losses. So whenever we get a packet loss, reduce again. And then increase. Keep increase, multiplicative decrease. Any questions before we move on to the next component of our algorithm? There are two features of congestion control. Before we move on, let's do a simple calculation. If I continue my diagram, I'm removing everybody in the same example, let's say that we're using this congestion control algorithm over a link or a network that has some capacity of, I've got some answers. Let's say our link had a capacity of 100 megabits per second. TCP doesn't know that at the start. So what TCP does is start sending slowly. Just one congestion window. When it receives acts, it increases its sending rate. This is the additive increase and keeps increasing the sending rate. The idea is that we want to increase the sending rate such that we approach the capacity of our link or our network. It's more complex when there are multiple senders and that we don't know what the capacity is. But let's say we know the capacity is 100 megabits per second. So we should be able to send at 100 megabits per second. What is our sending rate after the first round-trip time? Well, in the first round-trip time we sent, going back to our diagram, we sent 1,000 bytes, one segment, in that period of 20 milliseconds. 1,000 bytes in 20 milliseconds is 400 kilobits per second. That's our sending rate. We'd like to get our sending rate up to the capacity, assuming there's no one else sending. In the second round-trip time, from our diagram, we sent two segments. So it's 2,000 divided by 20, which is 800 kilobits per second. And the third round-trip time, we were allowed to send three segments. The congestion window was 3,000. So it's up to 1,200 kilobits per second sending rate. And we keep going 4,000 after a round-trip time and keep going. Every round-trip time increase the window by 1,000, which is equivalent to increasing the sending rate by 400 kilobits per second. 400, 800, 1200, 1,600 after 5 round-trip time, 2,000. Keep going. How many round-trip times does it take to get to our capacity? To get my sending rate up to the network capacity? Again, how many round-trip times does it take to get to our capacity? Not 100, not 10. Look at every round-trip time we're increasing by 400 kilobits per second. 400, 800, using additive increase, that is. Additive increase. Additive increase. We just keep increasing by the same amount. So, correct. If our capacity is 100 megabits per second or 100,000 kilobits per second, and we're increasing by 400 kilobits per second every round-trip time, then after 250 round-trip times, we'd reach the capacity in this example. 250 times 400 kilobits per second, we're up to 100 megabits per second. Just in this example, of course, just with the numbers that I've chosen. So the point is, we start slow, 400 kilobits per second, and TCP, if there's no congestion, slowly increases its sending rate, and keeps increasing, trying to approach the capacity. The capacity in this case 100 megabits per second, if there's no one else using the link, we should be able to send it 100 megabits per second. It took 250 round-trip times for my TCP source to reach its highest sending rate. 250 round-trip times is 200 megabits times by 20 milliseconds is five seconds. 250 times 20 milliseconds. That is, you start your file transfer. You're sending slowly that file. Then you're increasing the sending rate, and hence the throughput. It's increasing. It's much lower the capacity than capacity at the start. It's only until five seconds after you start it, as your sending rate and your throughput reach the capacity. So it takes a long time to reach the capacity in this case. That's a problem with TCP, or at least that's a problem with additive increase. When you start your TCP connection, if there's no congestion using additive increase, it's slow to reach the network capacity. We're not very efficient. If I'm sending at 400 kilobits per second, but my capacity is 100 megabits per second, that's very inefficient. That's a problem. Everyone understands this concept. We'd like to send as fast as possible. With additive increase, we start slow and gradually increase it, but the problem with that is it may take a long time to reach what we're allowed to send at. So we're inefficient for a long time. In this case, inefficient for, well, we're not 100% efficient until five seconds after the start. Let's say you're browsing websites. The time for a TCP connection may just last for 100 milliseconds. You may only transmit data for 100 milliseconds. So you're using a very small sending rate while accessing that website. That's a problem with additive increase. How do we fix it? We increase the rate at which we increase our congestion window. With additive increase, we have a slow or a linear increase in the sending rate. The problem with that is it takes a long time to reach capacity. The solution is when we start our connection, our TCP connection, again, we start slow, but we have a rapid increase in the sending rate when there's no congestion. The name of this mechanism is slow start. Slow start in that we still start sending slowly, but compared to additive increase, we have a rapid increase in the sending rate, an exponential increase in fact. So at the start of a TCP connection, the sender sends at a slow rate. That's what we have. That is the congestion window says one maximum segment size. With the slow start phase, with this different mechanism, we have a very fast increase in the congestion window, a very fast increase in the sending rate, an exponential increase. The idea where every time, well, what we do is we aim to double the congestion window every round trip time. With additive increase, increase by one MSS every round trip time, with slow start double every round trip time. The way to implement slow start is to increase the congestion window by one MSS every act. Every time I receive an act, increase by one MSS. So initial value, 1000, send one segment, receive one act, increase the new value up to 2000. Send two segments, receive two acts. When you receive the first act, increase up to 3000. When we receive the second act, increase up to 4000. Let's show that with a quick calculation. These were the values we got with additive increase in the first two instances. We started at 1000. With additive increase, we had something like this, where we send one, after one round trip time, increase to two, after the next round trip time, increase to three. The idea with slow start is we send one at the start, after one round trip time, increase to two, double, we receive two acts back, after the next round trip time, double again. Don't go from two to three, but go from two to four segments, or 4000. We receive four acts back and then we're up to eight. So 1000, 2000, 4000, 8000. That's the idea. Whereas with additive increase, it was 1000, 2000, 3000, 4000. Linear increase, exponential increase. So slow start rapidly increases the sending rate. How does it do it? Using this algorithm. Increase by one MSS, every act received. Send one, receive one act, goes to 2000. Send two segments, receive the first act, goes to 3000. Receive the second act, we're up to 4000. Send four segments, currently we're at 4000. We're going to receive four acts for every act. Increase by one MSS. Value 4000, receive four acts, increase by 4000, up to 8000. So doubling every round trip time approximately. Whereas additive increase is slow start. Additive increase increased by one MSS, every round trip time. Both of the mechanisms are used when there's no congestion, okay? When everything's okay. It allows to increase our sending rate. The difference is that slow start allows us to increase our sending rate faster. A rapid increase, which means we can approach our capacity quicker. With additive increase in our example, it took five seconds. That is 250 round trip times to reach our capacity. How long does it take with slow start? With additive increase, if we used additive increase, from the start of our connection, we increase by 1000 bytes every round trip time, or our sending rate increases by 400 kilobits per second every round trip time. But if we use slow start, and don't be confused by the name, even though it's called slow start, it's a rapid, it's a fast increase. If we use slow start, we effectively double every round trip time. How long, how many round trip times before we reach the capacity of 100 megabits per second? Anyone can calculate? Yes. And then the second act, 4000. Now, so there's two parts of both of these algorithms. There's the aim, and then the way that it's implemented. With additive increase, we said the aim increased by one MSS every round trip time. With slow start, we double, I don't know if it's written here, we double the window every round trip time. That's the aim. With additive increase, 1000, 2003, 4, 5, 6, in the same time with slow start, our aim is 1000, 2000, 4000, 8000, 16000, a doubling every round trip time. That's the aim. But both of them have different ways in which to achieve that aim, the way that they're implemented. And both of them increase the window whenever they receive an act. And an approximation in additive increase is this equation. It approximates this 1000, 2000, 3000, 4000 by increasing every act according to this equation. And similar slow start has this implementation. Whenever you receive an act, whenever you receive an act, increase by MSS. But remember the aim, slow increase, rapid increase. Yes, the sending rate of the slow start phase is doubled every round trip time. Yes, so here this was with additive increase. Let's do it for, where it took 5 seconds, let's do it for slow start. Remember same capacity, 100 megabits per second, same values as we had, slow start. Start the same with additive increase. We start with a window of 1000 bytes, 1000 bytes in 20 milliseconds, sending rate of 400 kilobits per second. Second round trip time. What's the sending rate? We double, okay, 800 kilobits per second. Three round trip times. Sending rate, 1600. We double this. Whereas here we were just increasing by 400. Four, 3,200, 6,400, 6, I'm going right here, 12,800, 7, about, or 25,600. Over here, 8, so I'm just doubling this each time, 51,000, 9, yeah, about 100,000. Our capacity. Remember our capacity was 100,000 kilobits per second. With additive increase it takes 250 round trip times to get to the capacity. With slow start it takes 9 round trip times. Much faster. Or 180 milliseconds. So that's the advantage of slow start. We get to the capacity faster. So don't be confused by the name slow start. Yes, we start slow, but we rapidly increase. Similar to additive increase, this is just used when there's no congestion. When we get axe back. If there's a packet loss, then again we reduce the sending rate. And it gets a bit more complex. What we do is we use slow start at the start of the connection, but then there's another parameter called a slow start threshold. Often written as SS threshold. Once our congestion window reaches this special parameter, we revert back to additive increase. This is how they come together. Here's an example. I've got some values that I use to calculate this, but we see just the plot of the window again proportional to the sending rate. The sending rate plot is the same shape. We start with 1,000 bytes here. And in this case we have a round trip time of 100 milliseconds. So every 100 milliseconds we increase. Initially we use slow start, so we double to 2,000, 4,000, 8,000, 16,000. But we don't continue to use slow start. There's this extra parameter called the slow start threshold, which says once our window reaches this value, revert back to additive increase. And remember additive increase is increased by from 16,000 up to 17,000, increased by just 1 MSS. 18, 19, 20, 21, 22, 23 and so on. We'll explain the top one in a moment. So in fact we use both of them. Slow start at the start of your connection. We start slowly, but rapidly increase until we get to some threshold and then revert to additive increase. In all cases there are no packet loss in this example. There's no congestion. So when you start downloading a file, the congestion window in the basic TCP starts small, rapidly increases and then has a slow increase. What's the top line here? We said, okay we'll explain in a moment, on this case, 1,000 is what we're allowed to send. We send 1,000, we receive one ACK. When we receive an ACK, increased by 1,000. That's the algorithm. We receive one ACK, so we're up to 2,000. Allows us to send two segments. We send two segments. We receive two ACKs. We're at 2,000, receive the first ACK, we're up to 3,000. Receive the second ACK, we're up to 4,000 now. So maybe 4,000 should be, after receiving the second, when we receive the second ACK, we've increased to 4,000. Allowing us to send four segments. We send four segments. We're going to receive four ACKs. Every time we receive an ACK, go up by 1,000. So we're at 4,000, we receive four ACKs, we go up to 8,000. Yes, but I'm not drawing all the values here. Sorry. 1,000, up to 2,000. We receive two ACKs, so it goes 2,000, receive an ACK, 3,000, but immediately receive the next ACK, so up to 4,000. So the values I'm showing on this picture are approximately every round trip time. In the first round trip time, we use 1,000. In the second round trip time, 2,000. In the third, 4,000 and then 8,000. Approximately every round trip time, that's the value of the congestion window. Now I say approximate because it depends upon the sending rate. It's not exact. It's the idea, every round trip time, double. And we see it on this diagram as well. Doubling here. And then slow increase, the additive increase. And what's the top line? This line we're drawing is the window size. Remember, the window is in fact the minimum of the congestion window and the advertised window. In this example, I set the advertised window to 24,000 bytes. So once we reach 24,000 bytes, the sending rate is limited by the advertised window. So the amount that the source is allowed to send, if the advertised window is 24,000 bytes, we're limited by the minimum of the congestion window and advertised window. Advertise is 24,000. Congestion is 1,000, so 1,000 is the limit. 2,000, 4, 8, 16. Congestion window is the limit. It's the minimum. 22, 23. Once we reach 24, even though the congestion window is going up, in fact we're limited by the advertised window now. So in practice, both of the windows control the sending rate, the smallest of the two. That's the sending rate because the sending rate is proportional to the congestion window. In simple terms, it's just the window size divided by the round trip time. And we've assumed the round trip time is constant in this case. So same shape with different scale here. Window size, sending rate. In the last five minutes, let's just introduce this last concept. And this is where we reduce our sending rate in the presence of congestion. So up until now, we've been increasing the sending rate. But now what happens when there's a packet loss? Well, we want to reduce the sending rate. And there are two types of packet loss, remember. Packet loss due to three duplicate acts, or detected by three duplicate acts, or packet loss detected by a timeout.  That means it's an indicator of more congestion. Therefore, we'll slow down more in this case. When we have a loss detected by three duplicate acts, we'll slow down a little bit. And a loss detected by a timeout will slow down by much more because we think there's more congestion in the network. And there are different parts of the algorithm. Loss detected by three duplicate acts, what we do is we have this slow start threshold, this fixed parameter here, this parameter here, which tells us when to move from slow start into additive increase. What we do is we have that value. So in this example, if it was 16,000, it would drop down to 8,000. We have the slow start threshold. We set the congestion window to the new value of this slow start threshold. And then we enter additive increase and continue going up slowly. If there's a timeout, we have the threshold. We set the window down to the minimum value, one MSS, the initial value that we started our connection with. And we enter slow start. That's best shown in the diagram here. So we start our data transfer at the start of a connection, one MSS, slow start phase says we can double every round trip time. Then we reach our slow start threshold, this green dashed line here, which means we're now into additive increase. Then we have a packet loss. That's an indicator of congestion. In this example, it's a packet loss due to three duplicate acts. We halve the threshold, drop the window down to the new value, which is 8,000, and then additive increase. Keep increasing. Then if there's another packet loss, in this case due to timeout, that's an indicator of more congestion. So what we do is we halve the threshold again from 8,000 down to 4,000, and we drop our window right down to the start, down to the initial value, one MSS. And we're in slow start. We reach the threshold, and then additive increase. And we keep going until there's another packet loss. Threshold is halved every loss. So you see with several packet losses, it can go right down quite low. And that's why maybe in wireless LANs, when you're transferring a large file, with some packet losses over that wireless link, your throughput can drop down because TCP is dropping at sending rate. So this is a combination of all those mechanisms in play. We have slow start, additive increase. We have a slow start threshold, which tells us when do we switch from slow start to additive increase. They are the way that we increase our sending rate. And when there's a packet loss, we reduce the sending rate. If it's three duplicate acts, halve the threshold and start from there in additive increase. But if it's a worse indicator of congestion, that is a timeout, halve the threshold and revert back to the slowest sending rate. And then start from there. And hopefully we build up until there's less congestion. And if there's another packet loss, then we'll follow that mechanism. And that's the main mechanisms for TCP congestion control, at least in the very basic form. There are some more complex ways to variations of the algorithm, but that's the basics of TCP congestion control. And if you, over a long time period, transferring a large file, then you see it's going up when there's no congestion and drops and if then it goes back up again and trying to maintain a level such that avoids too much congestion in the network. Try and understand those different mechanisms. Understand the idea of additive increase, slow start, and the idea of how we respond differently in the event of packet loss due to timeout and due to three duplicate acts. Do you need to remember the algorithms I think? If you can remember the ideas and be able to compare them, then that's a very good start. Any questions? We've still got a few more slides, but that basically finishes on TCP. What we'll do next week is just recap on that. Summarize. Too late, we've finished, you've missed all the fun parts. We will summarize and move on to our next topic. So any questions to finish on TCP?


Number SCP-1987-J Object Class Euclid Special Containment Procedures All printed copies or recordings of SCP-1987-J are to be destroyed except for a single printed copy to be stored in a locked safe at Site-5150. One electric guitar of any standard model is to be made available for testing purposes. As of ████, testing is to be conducted by and on D-Class personnel only. Many people or objects affected by SCP-1987-J are to be examined immediately after the conclusion of tests, and archived or neutralized as necessary. Female staff members are not to be exposed to SCP-1987-J's effect under any circumstances. In the event of a manifestation of SCP-1987-J-1, the D-Class responsible for activating SCP-1987-J is to accept this request. No staff are to interact with SCP-1987-J-1 directly. This subject may be reassigned in an event of failure. An event of success, Procedure Counter-XK-25R-624 is to be enacted immediately. Mobile Task Force Omega-2112, the Beaumont Police Department, is to monitor major and independent music publishers and online music distribution networks, rating indication of an independent rediscovery of SCP-1987-J. In the event of a containment breach, all offending media is to be removed from public consumption, and Mobile Task Force Omega-2112 is authorized to execute Procedure Casem, Procedure Sumner, and Procedure Cobain at O5 discretion. Description SCP-1987-J is a sequence of chords intended to be played on electric guitar, which produces several anomalous effects when played. SCP-1987-J has been discovered independently by several individuals since the development of the electric guitar in the 1930s. The earliest known written copy exists in the form of a handwritten tablature dated in 1965 with a note, to J.H. Pretty cool, huh? L.R. In the margin. Extensive testing has indicated that any person who is aware of how SCP-1987-J is intended to sound when played and has access to electric guitar or amplifier is able to produce SCP-1987-J regardless of any previously documented ability to play guitar or lack thereof. As play begins, anomalous effects begin to occur within the area where SCP-1987-J is audible after approximately 1.6 seconds and continue to manifest every 10-30 seconds until play ceases or SCP-1987-J-1 manifests. No specific pattern as to the effects produced by SCP-1987-J-1 has been discerned to date. All effects produced by SCP-1987-J are permanent and are not reversed by cessation of play and subsequent exposure. Most documented as a result of SCP-1987-J include perception by onlookers that the player is unusually physically attractive or charismatic, spontaneous lengthening of the player's hair and or enlargement of genitals, apparent age of all females within an area of effect tainting to approximately 18 years, and or spontaneous manifestation of 8-10 such individuals that no female subjects are present, concurrent transmogrification of subjects' clothes into thumb bikinis, lingerie, or leather fetish gear have occurred in 68% of documented instances. Extensive testing has been authorized to determine where effects are correlated. Transformation of late-model automobiles in area of effect of vintage hot rods, muscle cars, or custom motorcycles, spontaneous manifestation of large quantities of distilled alcoholic beverages, spontaneous manifestation of sparks, pyrotechnics, or large fans, immunity of the player to bullets, resurrection of the dead either to their previous state or as zombies loyal to the player, spontaneous manifestations of dragons, dinosaurs, or scantily clad female angels loyal to the player, liquefaction of observers' facial features, spontaneous pregnancy and fertile female subjects, spontaneous pregnancy and infertile female subjects, and spontaneous pregnancy and male subjects. Testing has determined that all above effects are only produced when SCP-1987-J is performed on an electric guitar. Attempts to produce SCP-1987-J on acoustic guitar, keyboard, banjo, ukulele, or saxophone have produced a memetic field which causes observers to view the player as uncool or a sellout. With extended test sessions resulted in permanent ██████ testicles. SCP-1987-J-1 is an entity resembling a Caucasian male of approximately 25 years old, which the date has manifested on any occasion when performance of SCP-1987-J has passed a collective total of three minutes, one second in duration. SCP-1987-J-1, which has variously introduced itself by the names Count Rockula, Sir Rocks a Lot, and the Lord of the Strings, will immediately apply manifesting in order the player to cease and challenge him or her to what is described as an epic rock-down rockstiny, which had been observed to take the form of a guitar duel between SCP-1987-J-1 and the player with the offer of ultimate rockiness that the player is successful. The nature of ultimate rockiness is yet to be determined, and all observed instances of SCP-1987-J-1 has declared itself the winner and de-manifested, followed by the player's spontaneous transformation into an instance of SCP-1987-J-2, an unattractive male, regardless of the player's original gender, approximately 45 years of age wherein the uniform of a gas station attendant which identifies itself as Earl, and claims to be a fan of country music. All instances of SCP-1987-J-2 have proven unable to produce SCP-1987-J or to display any degree of skill with the guitar, and has been assigned to the maintenance of the Foundation motor pool. Memo from Dr. Klein As of ██████, I am hereby forbidding all staff other than the class for conducting tests in SCP-1987-J. Today, 38 researchers of Site-51-50 alone have become iterations of SCP-1987-J-2 while attempting to acquire the power of ultimate rockiness. Site-1137 is now facing a five-month backlog on critical laboratory work. However, we possess well in excess of the required automobile maintenance staff, and will have to resort to assigning the SCP-1987-J-2 into the D-Class due to the lack of work to assign them. As tempting as ultimate rockiness may be, we have more important concerns at this time.


Maybe not now Reng 1 dot Got you got you got the shield insta Okay, okay I need to not be kept here I'm just crippled forever. Oh my god. I just spelled him as well Yeah, I'm lining him now. He emptied me. You can't resist the shield got the shield I don't have eyes to the wall dodge couch. I just can't get there That's fair to them. Got it.  I'll try and dispel him. I've got him in combat. I can pull for me Getting the shield I'm just gonna go to milk If he can test me like this, okay, you got combat Oh, I just spell resisted everything on him.  I'm just sitting Gauge This is scary because it's orc like you can just I'm just rebuffing here I don't know me. I think he blinds me. I'm setting this. Yeah, it's different. He's slow. He can't even stop me Piercing I just bought shoes. I'm about to destroy him. Yeah, okay evasions even I'm destroying him Okay, please I'll wait for the evasion six seconds. You can live. Yeah, sure He used our racial as well. Can you mean I'm right in dodge from behind Can you sat? Uh, maybe yeah, I got a bad to prep for this. I'm increased. I think he's he has no yes Dispelling priest Very I'm dispelling priest. Don't set priest. I'm gonna burn him out. Try and keep it slow. I'm gonna go It's half. Let's go bro. Let's go Uh, pretty cool thing. I was waiting for you. Yeah, yeah, it's full of vision. I need two seconds Okay, no It's all I can go without If he's not gonna have trouble He's fine. He has to add me. I drink it. Okay. I'm gonna get a lot of vision as well. Yeah, he vanished. I broke his vanish Nice. I lost my wings though I'm reading he's he kept me Yeah, bro. Nice, it's him. Priest drinking Yeah, I have to open priest. I'll keep bro One more bun. I can fill point rope It's dot dot dot dot dot I have both the fear of the whatever Pointing them sex for the door. He'll help shrink it for me See if they Okay, I'll just run around. I'm gonna start bottom Oh, okay. Well, that's right.   I can't go. She's just open one priest as soon as rogue opens on me. I think well, you can even open now I don't want to get the I'm gonna go Kidney me sitting kidney might just randomly die Yeah, I've used very nice vanish. It's all trying to fair Got him I got the cheap shot on the shrink it Okay, it's me. I don't know kidney for you yet. Okay. I'm piercing them Okay, no That's fine. I'm fine. I've you I've used the van sister. Okay. I have good damage on the guy Rogue has prepped left. Okay. He just used it. He's gonna vanish on me soon. Be ready A lot of candy for ages 12. Just keep waiting. He's hanging me now as well Your vision I still have my trinket. Okay Just cloaking Very nice Pushing on priest. No I need to have vision now It's getting a rough one. I've got a burn. I've got a burn. He says one vanish left. That's it Okay, then focus me. Yeah. Care for the dot He just bought it. It's right. Got you The spelling shield Yeah, I have full bling for rogue He has it as well. Watch out. He's probably gonna do it now Yeah, man. Let's try and keep it. I should have done before he does it. So it wouldn't be good.  It's fine. Yeah, I'm running on mana as well He reads. Nice. I made three for you for top I've bought vanish I have full bling for rogue I have full bling for rogue Yeah, both I'm sitting facing I still have my trinket I'm binding peaceful. Sure. Sure. Sure. Rogue cloak He's running. I can't really do much about this. If you can get something Yeah, he doesn't catch you Jeff


In this video, we'll be walking through how to calculate out the square mill area, your SMA of a conductor, and then convert it to CMA if you need to. So what we have here is your basic bus bar. This one is two inches by one quarter inch. So we are going to need to convert these to mills first, but in order to do that, we need to get rid of our fraction here, so we need to convert that to a decimal. Quarter inch equals 0.25 inches. Then we can go ahead and convert these into mills. Two times a thousand is two thousand mills. Point two five times a thousand is two hundred and fifty mills. Now to get the SMA or the square mill area of this bus bar, we just multiply two hundred and fifty times two thousand. That gives us five hundred thousand SMA. Now if we want to convert this to CMA to see what the CMA equivalent of this bus bar would be, we can go ahead and use this conversion. CMA equals SMA divided by 0.7854, or if you want to convert from SMA to the CMA to SMA, you're going to take SMA is equal to CMA times 0.7854. One way to remember that is your square mill area is smaller, so you're going to multiply it by the decimal because you're going to get a smaller number, SMA smaller. There you go. So looking back at our example here, we're going to take our SMA, which is five hundred thousand SMA, and divide it by 0.7854, and that gives us a CMA of six hundred and thirty six thousand six hundred and eighteen point three CMA, and that would be the CMA equivalent of this SMA.


Hi guys and welcome back to my channel. It's Justineen. Thanks so much for tuning in for another video. So in today's video I'm going to be showing you guys how to make your own DIY herbal hair detangler. So for those days I don't feel like going out and spending extra money for detanglers. I have these simple natural ingredients already in my cabinet and I can make my own. So this DIY is very, very simple. You need three things, water, slippery em, and your favorite essential oil. For this video I'll be using lavender. A great detangler is all about the slip that will loosen and detangle those matted, dry, tight curls. Hence the reason why I chose slippery em as my choice for this detangler. Slippery em has really great benefits. Slippery em heals damaged hair. Because of the mucilage and the slimy nature of the em, it works as a great conditioner and detangler for the hair. It makes your hair soft and smooth. And there are various hair care products out there that do include slippery em for that conditioning and detangling effect. So once again this DIY is so simple and easy so we're just going to go ahead and jump right into the video and I'll show you how I make it. Enjoy this DIY guys where you can make your own natural hair herbal hair detangler. If you liked this video don't forget to give it a big thumbs up because it does help my channel and don't forget to subscribe. This is just Janine and I will see you guys on the next video. Bye guys.


All right, everyone. Hello. Hello, everybody. Welcome back to campus. I guess people have been to campus before. It's been like, what, two years since the pandemic? So welcome to hopefully your first semester back. That's somewhat normal. Maybe anywhere from kind of scary to amazing or anywhere in between like how you're feeling right now. So no matter how you're feeling, we'll get through this semester together somehow. So I am your instructor that you definitely have never seen before because I'm new. So I'm John. I prefer just John. You don't have to be super official with me. I guess I have a title professor now so you're allowed to call me that if you want to. It is weird before because I only just got that title and everyone called me that when I wasn't, which was kind of weird. But use whatever you're comfortable with. I advise against my last name because as you can see, it's kind of a disaster.  And then if you ever have to spell it, God forbid, just throw a yo right after the e and it makes sense. So hopefully you don't have to spell it, but in the off chance you do, that's a good way to remember it. So I'm a new teaching stream professor. That means I get to 100% teach everyone. And you know, I chose this position. I like teaching. So hopefully we can develop a good course. A little bit about me. I've kind of always been interested in computers, understanding how things work, taking it apart, being like, Oh, someone tells me that that works. And that's not really a satisfying answer. I always kind of want to know why. So that's kind of why I'm here. Alright, that led me to grad school and all that kind of boring, long story. So little bit of housekeeping.  Thank God. So Professor Ashen Gual is your course coordinator. So he sets, you know, the exams kind of the evaluation part of the course. And it's my job to make sure, you know, we do very well in the evaluation. So you'll find the overall course website there. So that's what he maintained. So he gets to override me and everything. So that one is true, no matter what I say. There's also a piazza there for course discussion. I think he added everyone already. Yeah, I see some nods. Okay, so that's where you'll find everything. I guess another bit of housekeeping notes for your practical, if you have a practical on Friday, you don't go there because the lab's going to be released tomorrow at like five ish. So there's not going to be any lab to talk about.  So this is where I'll post all the course materials. So you don't have to log in or anything. Although people at this university seem to actually like Corkus. No, okay, do we like Corkus? Hands up if we like Corkus, like half ish. That's like most people. Okay. So at any other previous institution I was at, they hated whatever the system was. So this is kind of weird to me. But I can also post stuff on Corkus if you'd rather also have it there. Doesn't really matter to me, although my sections got deleted somehow. So maybe I can't post anything there. So I guess we'll figure that out. For lectures, right, we're back in person for the first time a long time, like normal in person. Hopefully it stays that way. So, you know, I encourage everyone to come to class, feel free to raise your hand, ask a question if anything's unclear, or if I'm just like saying something really, really stupid, or you want to have some input or have something interesting to say, you can also just kind of interrupt me as long as you're not like too rude about it and say like, Hey, idiot, go do that. So as long as you don't say that, we're probably good. Coming to class is pretty important for both you and me. That's why there's like two different sections. So I can actually see your reaction. Even if you don't like put your hand up and talk to me, I can see if you're kind of confused or not.  So it's kind of nice and instant feedback for both yourself and me, right? So and also you get the advantage of I have like a 9am before this. So I already had my practice run out of the way. So you guys can, you know, take advantage. And I can also probably ask some questions that they asked as well, or just, you know, see what class has better questions. So another fun bit. So just in case, you know, you're not comfortable coming to class on whatever day, I guess you don't have the excuse that's too early. But maybe you ate like too much too big of a lunch and you have to go home and nap or something.  So I'll be streaming all the lectures on YouTube as well. And there'll be a vaude as soon as it's done, right? So you can review the material and all that after. So I encourage you to come, but you don't have to, right? There's good options if you don't. Yep. I should be the links are also in the slides, which like, yeah, yeah, there should be on the website. So offline. And these are all in the slides, you can click these links to you don't have to copy and paste them. So they'll all so everything will be on there. I guess this, yeah, last class gave like that a round of applause, like they really, really liked it. I guess you guys don't care that much. So whatever. Okay. Although maybe other people did that and no one cares anymore. It's not new. The camera angle is a bit weird because you're looking up at me. So I'll try and get my camera here so it doesn't look so terrible. And then yeah, another fun bit. So discussion will be interactive on Discord, at least for our sections. So that's the length. There's a QR code if people like QR codes to join that. I find it a lot easier. So there's always piazza for everyone. For my sections, I'll try a Discord and see how everyone likes it. It's generally pretty interactive. And you also can, you know, ask a question, pretty much get an answer pretty much immediately instead of just waiting around on piazza. And hopefully other students can help answer the question too. So that would be great. The office hours will mostly be out. Yeah, I see some people joining. Maybe if people actually like Discord, I can also take questions from there and maybe play around and post some stuff on there too. So my office hours are mostly by appointment, I can put a poll on the Discord to see when people are available since we're all in third year engineering, your schedules are kind of a disaster. So finding a time that works for everyone probably isn't going to work. But I'll try them hours aside, where I'll definitely be there. And then otherwise you can email me or drop by. And hopefully I'll be there. Otherwise I'll be kind of on the Discord pretty much all the time. If you want to contact me on there too. And yeah, office hours aren't going to be streamed and recorded, right? That's kind of just for you to ask questions. So yeah, I encourage you to go to that those also eventually my office might have an espresso machine. So even if you want to come, you know, have some free drinks, maybe I can bribe you to come to office hours if I'm really bored by coffee. It's not there now. So don't hold me to that. It's I have a disaster with moving stuff. But hopefully eventually. So that's soon TM. Okay, so how the evaluation works is that there's going to be quizzes instead of a midterm. And they'll be online. So there'll be three quizzes 10% each. First one is September 29. Someone already told me there's a bit of a conflict who's in 302. Jesus. Okay, a lot of your 302 that has like a midterm already on the 29th. That's six. So I will talk to the course coordinator, see if I can change that because yours is in a room. This is online at eight. So hopefully this can be moved since it seems to be a conflict for pretty much everyone. So yeah, the labs will be 30%. There's first one supposed to be released tomorrow. For every lab, you'll have two weeks. First one is just a review of C. Just to make sure you know the language. Hopefully everyone has background and see from like 105. And yeah, so this course is pretty much all in C. All operating system stuff is in C. So like it or hate it, this course is in C, because people program operating systems in C. So if you know C++, you can pretty much delete classes, delete templates, delete namespaces and everything nice. And then you have C. So hopefully it's not too bad. If you don't know pointers, I would brush up on pointers because you're going to be using them. But hopefully it makes sense because in addition to pointers in this course, you will be the one that manages what pointers point to. So it will be which sounds awful, but trust me, it's fun. Yeah, other labs are going to be threads, which most hands up if you've used threads before, I don't think anyone had like, okay, last time it was around 20%. There's like, eh, and some okay, so we will learn threads, which will be fun that this is the first operating systems is the first time you're introduced to threads because in addition to being introduced to threads and having to learn how you use them, you will also use learn how to implement them. So that will be fun. Yep. So C is they basically use C as portable assembly. So C is close enough to assembly that you can, you know, for example, the Linux kernel runs on like, you know, 25 different architectures, 30 different architectures, they write as much as they can and see, and some parts will use assembly, but they want to make it as small as possible. So you don't have to rewrite everything when there's a new architecture. Yep. I don't know what's on probably C 11. I assume it might be C 97 for all I know, but it should it should hopefully it shouldn't matter too much. And then after we learn threads, we're going to build on threads, have a web server. So the labs kind of build on each other lab three builds on lab two, which as it's presented right now, you don't know what any of this means. So that's kind of useless. But we'll use threads to implement a web server. And then after you implement your basic web server, you're going to implement a caching web server. And then after that, we'll learn all about or you'll have a lab on file systems. And then of course, 40% final because it's engineering. And I think you have to. Alright, so I think I'm contractually obligated to have this slide on academic honesty. So again, you've probably heard this a million times, you can study it together, but you can't do like labs or quizzes together. These labs are fairly open ended. So it'll be pretty obvious if you have the same solution. And like, don't do what my friends tried to do of like changing variable names. That doesn't work very well. And it also kind of just hurts you because all the operating system stuff, if you write any software whatsoever, there's no way around it, it has to interact with the operating system. And if you want to write good software, you kind of always have to understand the layer below it, which in this case is the operating system. So the more you know about offering systems, the better of a programmer you'll be, you'll be able to write better applications, and so on and so forth. So you actually kind of want to know this stuff. And it's actually interesting stuff, which is why I chose to teach it. And yeah, any cheating course not tolerated U of T has like a fun thing where they post up publicly. So you can see like the big suspension reports and see like people's degrees being taken away and stuff just to scare you. So if you want any like fun reading before on the weekend before class starts, you can read those. So yeah, they're posted publicly online, they're they're kind of frightening to see. But hey, they do it. And yeah, it's kind of weird because lawyers get involved sometimes and it's a gigantic mess. So please do not make a gigantic mess. So there's a few books you can use that complement the lectures you do not need to get the books. First one is modern operating systems, which is kind of a classic book. I believe you have to pay money for it. So I don't think anyone will get it. The operating system three easy pieces is freely available online in PDFs. So that one's pretty good. It has a few really corny jokes in it too. If you like programming humor. So that's a good one to complement. But of course, you don't need that need these. It's just if there's any kind of gaps in your knowledge, or maybe I'm explaining something rapidly, you can say, Hey, you know, I learned it better from this book and I'll adjust. And then if you don't know see, there's the C programming language book. But hopefully most people have experience and see if you don't have a lot of experience and see you can also just ask me and the first lab is intended to see kind of where you were at with C. So if you have no problem with the first lab, it should be okay. If you don't and yeah, if you have problem with the first lab, then you can always ask me all the labs are kind of optional. All the TAs are there to help you. You can do all the labs online if you want. You don't have to go there. So I'm told but given I said that the labs will probably be sparsely attended. So your TAs will probably be bored and more than willing to help you. So if you even want help with the lab or anything, I suggest you go to the labs and you know, give the TAs some something to do or at least hang out with them and keep them company while you do your labs. So again, like I said, I'm new here. So you can please provide some feedback, right? Hopefully, I don't really want to wait till the end of the semester to get some feedback and adjust.  If something's working well, say it's working well, and I will try and do that more right. And just caveat. I'm new here. So don't completely destroy me. Give me a so yeah, hopefully it works out all right. But feel free to email me drop drop drop by my office, which I guess I didn't have on the slides is BA 5110. I guess I'll post it on my website since I don't have it there. But yeah, just let me know. I'm open to suggestions. And you know, first suggestions to try and move the first quiz.  Yep. Oh, yeah, so I think labs are you have two weeks for every lab. And I think they're released on Friday and then do on Friday. Yeah. Yeah. So they'll be submitted through get just on the ECF machine or one Linux machine. So all the instruction should be on there they're setting up the lab. So I'm told they'll be done tomorrow at five. So first lab you can try and set up, see how the system works. It should be fairly straightforward. If it's not, we will do something about it. Okay, so into the actual introduction to the course and what we'll be learning. So this quote pretty much sums up, well, all of computer science. All problems in computer science can be solved by another layer of indirection, which is kind of shockingly true. I only learned this in fourth year. So hopefully if this is your first time seeing it, you learned it a year earlier than me. So hopefully that will be better. But it's yep. So indirection. So we'll see. So indirection is just instead of, you know, let's just see an example. So one example is instead of if you have an application, instead of talking directly to the hardware, instead of talking directly to the hardware, you would indirectly talk to something else. And that's something else talks to the hardware. So in this case, if you're an application, right, one thing you would do it have to do is if you're running on a computer, right, you're running on hardware, hardware changes over time, right? If I write my application, and it only runs on a specific piece of hardware, then later they come out with a new CPU, new video card, whatever. If I don't have an operating system, I have to rewrite my application to support the new hardware. So in order to avoid doing that, I write my application against a operating system, which is the layer of indirection there. So I don't talk to the hardware. I talk to the operating system. And then the operating system talks to the hardware. Then if there's new hardware released, all I have to do is update my operating system. It knows how to talk to the hardware. I don't have to rewrite my application. It saves me a lot of time. So that's basically the primary role of an operating system. It is just to manage and coordinate resources, which is all the hardware. So we know kind of some resources, right, we took the computer organization class, which you kind of built a CPU ish or used one, and had some assembly experience. So that's one thing we'll have to manage. Because in that, did you execute any code on that CPU? Yeah, and if you execute code on it, you probably just like loaded it directly to it, and it just kind of ran, right? Yeah, so that, that did not require an operating system because you just ran one application. Now we want to run lots of applications. So and also if we talk about operating systems, it's kind of weird to talk about what an operating system is because the definition is kind of fuzzy, some people trying to find it, but it kind of depends who you talk to. So like Ubuntu and Android are both considered most people would consider those different operating systems. But they both use the Linux kernel. And that's kind of the important piece of software that actually talks directly to the hardware. So both of them use the exact same important part of the operating system. But again, you still wouldn't call them the same operating system, right? Because applications are way different. On Linux, you have some GUI application or you have some CLI application where you just type into a terminal on Android, right? You have apps that you can fling the windows all around and do all that fun stuff. So for kind of those types of applications, you would consider things different operating systems, probably at like their display server.  So Linux and Android in that respect are different. Linux uses something called Wayland or x 11. If you're super old school, an Android uses something called surface flinger. And if you talk about Apple stuff, the difference between operating system gets even weirder. So like, what's the difference between iOS and iPad OS? Are they different operating systems when they use 99.9% of the same software? You probably would say they're the same operating system, but Apple would, you know, disagree with you and market it as different operating systems when really it's just the screen size is different. So kind of depends who you talk to. But at the core of it, no matter what operating system you have, their goal is to allow you to run more than one application. If you just had a single application, you can just run directly on the device like you did in that computer organization course, right? You just the CPU starts executing as a fixed address, you put your application that address, and whatever you power it on starts executing, you're good to go. So if you do embedded development, you can get away with that because typically the hardware is small, the hardware doesn't change, you just put whatever you want to run directly on the hardware, you don't need an operating system. But for kind of general use stuff, you definitely need an operating system because you want to use more than one application at a time. If you could only use, well, you could probably get away with just using a web browser now, but if you could only use a web browser, that would kind of suck. So, yeah, and then if you do that again, that's the same problem where is if the hardware change, which for computers, generally it changes quite often, you'd have to rewrite your application, and no one wants to do that, right? So instead of executing whatever program you want to run on your little chip, if we have a gigantic chip, instead of executing your program, it executes the operating system, which is really just a program that runs programs. So meta. So one of the first abstractions we'll see in this course is something called a process. Basically, a process is a virtual CPU. So to run your applications right, you needed the program can't like you set the CPU at the program counter and just kept on going away. So now if we have multiple applications, you can think of each application kind of have its own virtual processors that keeps track of different program counters. So your web browser is running at program counter, this address, you know, Libre offices running at program counter, this address. And then to switch between them, your operating system just kind of has to change the program counter over so another application can run. So when you write your program to you don't do this, but in your executable file, it will say, you know, where to start executing the program. And that is kind of another layer of indirection. So instead of your CPU having a fixed address that it starts, you can create a program and say and point the starting address to execute at wherever you want. So your compiler does this to you for you. So you don't have to do it yourself. But that's kind of one of the things your compiler is doing when it's creating an executable. So for keeping track of stuff, an operating system needs to do and therefore stuff you will be learning. An offering system would need to keep track of registers for each process and then switch between different processes. So even if you have just a single CPU, which no one has anymore, but even if you still have a single CPU, you can run multiple applications and it looks as if they're running at the same time, because you could run one application for a millisecond, run another one for a millisecond, they both make some progress that you can see. And it looks like they're both running at the same time. So that one millisecond was completely arbitrary. I just made it up. If you are implementing the operating system or learning about it, the amount of time you give to process kind of matters of how responsive it feels and all those fun engineering tradeoffs were kind of used to. And if you're the operating system, you get to decide when applications actually run and for how long. So you get to decide and the nice thing about that is you have the freedom, but you also have the freedom and have to decide. And if you make a wrong move, users will probably complain. So if you use your web browser and then your other applications all froze because you gave your web browser too much CPU time, you would probably be pretty upset and users are probably just going to blame you. So that's the CPU part of it. The next part of it is the memory part. So like with your little embedded, embedded processor that just, you know, only had one application on it. You just used all of the memory directly, right? You've had free reign. You manage all the memory. Well, that's not true with an operating system. Different applications have to share the memory. So if this was your whole address space there of all the memory in your computer, one kind of naive thing you could do is just kind of section it up ahead of time and say what applications can use what part of memory. So if that was like eight gigs of memory, you could say like, Hey, Firefox, you use four gigs. LibreOffice, you use two gigs operating system, you use two gigs. And if you've used web browsers before with as many tabs as I do, you know that four gigs probably isn't enough. So this already isn't going to work for that. So if you want to use, right, if you only give Firefox four gigs ahead of time and you can't change it as it's running, if you want to use six gigs, well, then you're kind of out of luck and you your Firefox runs out of memory. And this kind of gets even worse. If you want to run multiple applications, then you'd need to siphon off some area of memory for them, even if they aren't running, just to make sure that if it does run, they have space to actually operate it. So this kind of we can kind of mix this as a solution kind of off the bat, because this won't work. Yep. Yeah, sorry, I'm kind of using process and application as the same term. Yeah, application typically has some graphical component to it process can just be like a terminal application too. But you can use process and app pretty much interchangeably. Okay, so the solution to the memory problem is something called virtualization. It kind of full at the heart of it virtualization just fools something into thinking it has all the resources, which is good for them and bad for you. So you from Libre Office's point of view, you tell it that it has access to the entire memory space. And that kind of black part there is just memory reserved for the operating system that you can't really give to them, because you need kind of some room to operate. But you'd give it an entire view of the memory and say, Hey, you know, you can use all the memory you want. And then when Firefox boots up, it also has a view of the entire memory space and thinks it can access everything. So the kind of neat thing about this too is that Libre Office and Firefox can access what they both believe is the same bit of memory. So like Libre Office could access, you know, address 1000, Firefox could access address 1000. But Libre Office's address 1000 is actually like the physical address 2000. And Firefox's it could be its 1000 could be physical address 3000. And then the whole goal of managing all that is kind of now your responsibility. So it kind of abstracts away physical memory. So each process believes it has all the memory. And then different processes can have, you know, the same starting address, they can access the same bytes, but the operating system will actually manage what physical memory that maps to. So more goals of the operating system is it has to do that mapping. So it has to map virtual memory addresses to physical memory addresses. So kind of like that 1000 for both processes to whatever physical memory. They also have to keep track of memory usage. So, you know, allocating memory deallocating memory because you don't typically know how much memory your program is going to use up front. Right. Imagine your web browser it starts at like a few hundred megabytes and then grows to a few gigabytes. So, but if you're the operating system, you have to manage that you have to let that web browser grow to gigabytes.   So anyone want to tell me what you might be able to do if you have run out of memory, if you are an operating system. Yep. Okay. Yep. That's definitely one. You can go to disk and start using the hard drive instead of memory. Yep. You can restart the entire system. That's solution always works in computers. Yep. Yeah. You can also just kill an application whatever is using the most memory and then every other application gets to survive. So in Linux, that's what does it has a process called the out of memory killer that will pick an application based off some criteria and just kill it and then free memory. But before that, if you don't want processes to get randomly killed, you can, what she said, you could just put some memory into disk and kind of fake it that way that we'll see later in the course as well. Oh, yep. Yes. Yeah. Yeah. So everyone that thought you know, and see your rays are all contiguous memory and everything, all the addresses are contiguous. That has been a lie since day one. So that is not true. So if you want to spoiler for the course, how it deals with memories and blocks of typically four kilobytes and the operating system can map them however it wants. So even in your program, if it looks like, you know, two memory addresses are within like 4,000 bytes and you think they're beside each other. They're beside each other in virtual addresses, but physically they will not be beside each other unless you are insanely lucky or, you know, if you just booted your computer, maybe. Yep. Since like the other things want to start off and on and say there was only one CPU to do this, how does it tell itself to turn on if it's not even on yet? That is a good point. So that's much later, but a fast explanation is you can, you used interrupts before, right? So it will just do an interrupt and then get control back and then it will decide. So that's one way it can decide what runs right and application runs. You can set an interrupt. So CPUs also have only or operating systems have access to instructions normal programs can't. So one of the things that it can do that you can't do is interrupt itself and wake itself back up and then take this CPU away from you. So this concept of virtualization is pretty powerful, right? It applies to processes or applications, which is essentially you can think of it's like a virtual CPU and then virtual memory. So sorry about the contiguous memory lie that's been a lie all along. But in this course we will discover the truths. So also your virtualization can also be extended to an entire machine. So instead of being only able to run one operating system on one machine, right? A physical machine can wear on multiple operating systems at once. So that's what all your cloud providers do. If anyone's used AWS or used anything on the cloud, they will typically just have one machine and it can run, you know, sometimes they overload them and they can just run hundreds and hundreds of servers and you are none the wiser. It just looks like a computer to you. So like that's also what I'll be doing in the lectures showing you examples. So like this machine is macOS but throughout the lectures when we go to play with it we'll be playing on Linux, which is what all your assignments will be into. So like this is actually a virtual machine. So this is Linux running under macOS. So I'm running two operating systems on the same machine. So the next part is kind of probably the if that wasn't confusing enough, this is probably the most challenging part is concurrency. So when multiple things are happening at the same time, right, either running multiple applications at once on a single CPU or running those multiple applications on multiple CPUs. You want applications doing multiple things at once, talking to each other and you have to kind of make sure everything happens safely. So you and you don't want applications isolated because if an application can't talk to another application, it's pretty much just wasting CPU and just making your machine hotter without doing anything useful. So you want applications and libraries to communicate with each other in some respect. Even the simplest program will communicate. So it's kind of a necessary thing for operating systems. So again, writing one application at a time is not a good experience. And completely isolated applications also aren't useful. So even the simplest application we can think of, which would probably be Hello World, does some communication. It communicates with the terminal. So it sends, you know, help the string Hello World to the terminal and then you get to see it. So you aren't responsible for, you know, writing the code that actually draws those pixels on the screen. You just communicate with the terminal and then it magically draws them for you, right? No one, at least at this point, you haven't you haven't drawn pixels on the screen. You've sent text so far. So I think in your graphics course, you'll be drawing pixels to the screen. But for now, right, we're just sending data and letting something else do that. So other things we have our operating system has to do is allow multiple executions at once and do that safely. And we will see kind of where the difficulties in that lie, because it's again, one of the most challenging things. So concurrency is kind of the hardest class of bugs to fix to. So some bugs in the Linux kernel have been around for seven years without anyone ever finding them. So we only have like four months and you also have to learn about them. So it's going to be hard. But hopefully, you know, we'll get the gist of it. You'll have to manage some abstractions for different kinds of inter process communication or IPC. And basically, that's just a fancy way of saying communicating between processes. So talking between two different applications. And then of course, if programs are talking to each other, there are some programs you probably don't want intercepting messages and all of that. So if you are the operating system, you also have to provide permission and kind of access controls and make sure that only things that are allowed to talk to each other are actually talking to each other. So the last part we need is persistence for our basic operating system. You want to be able to access data between boots. So on your little micro controller, if you didn't have, you know, any persistent memory any time you powered it down and then powered it back up, it would start from scratch and on a computer that would be any files you've modified or anything that you created would then suddenly be gone, which we don't want in general. So what you do is you create something called a file system that kind of lays out how you structure directories and files on the disk and actually write it to the hardware so it can persist next time you boot up your computer. So all your files are still there. So if you're the offering system, more jobs we have to do, right? Our list keeps on kind of growing and growing. You have to store and retrieve data and you also have to kind of ensure the integrity of that data. So persistent storage generally fails all the time without you knowing it. Your SSDs fail a lot, but they just don't let you know. So you're none the wiser and the offering system is kind of responsible for hiding it from you. If you have a, you know, mechanical disk that maybe some of you have never seen before, but they still exist that spins. Those fail a lot of the time and sometimes catastrophically and you can't get it back. But like little bits of that will fail all the time and kind of silently it will just fix everything for you. So luckily you've benefited from this because you've never noticed how bad they actually are. Okay, so one of the most important abstractions is something called a file descriptor, which who has used a file descriptor before? We got like two hands. All right. So this is another lie everyone's told you. So who's written to a file before? All right, who's printed Hello World before? And who's done both of these things on Linux? Or at least one of them? Okay. They've lied to you again, you've used a file descriptor. So a file descriptor is, you can think of it as just a number associated with your application where you can read bytes to or write bytes from. So for example, you could say, Hey, I want to read some bytes, write some just random data from file descriptor zero. And then I want to write some bytes out to file descriptor one, for example. So if you write Hello World, one thing that probably is happening based off what I'm saying is it's writing the string Hello World to some file descriptor, and then your operating system is making sure that that goes to your terminal. So you actually see all the characters that say Hello World on your screen. So again, if you're the operating system, you have to direct these bytes to whatever it represents. So it could go to your terminal, it could go, you know, to a file, it could even go to a network connection. But all these things, they kind of files your terminal, a network connection, another abstraction or layer of indirection is this file descriptor. So to the operating system or how the offerings presents them to you, it's just like, write some bytes to this number, whatever it represents, I'll figure it out, it's just something that you get bytes from and write bytes to.  And you just let the operating system figure out the details. So when you actually get into kind of hacking on a kernel, which is just the important core part of the operating system that mostly that does all this management stuff, and also talks directly to the hardware. If you look at it at GitHub, and like if you break down what each bits of code are responsible for, you'll find that like a lot, a lot of it is just device drivers. So talking directly to the hardware. It's a pretty boring, thankless job. So you should thank everyone that works on it because it's basically reading manufacturer specifications. And we've all documented our software and hardware. And no, it's probably not perfect in the real world is also not perfect. But if you are writing the operating system, you have to deal with all the bugs and create workarounds to work around other people's bugs. Because if there's a bug in the hardware, they can't just release a software update and it gets fixed. That hardware just has some software flashed on to it that you can't change. And now you have to deal with it. So yikes. So just to give you some insight. So this is like an actual comment from Linux source. So there's two biases, which is like the first bit of code that runs when you turn on your machine before the operating system even starts. So you're going to so if you write a kernel, you have to interact with it. So there's these two kind of Dell computers that were made really close together. And this is kind of their joke that talks about how their technique for writing the code. So they said, oh, the developers that wrote this just wrote bias code. If it didn't compile, no problem, I'll write some more code, make sure it compiles. And then after compiles, see if it boots Windows 98, which is pretty old. And then if it doesn't boot Windows 98, go ahead, write some more code. And then as soon as it boots Windows 98, you don't care, you just ship it. So in that, if that's your development process, right, you're probably going to ship a lot of bugs. So this and then, you know, again, if you're the current developer, you're the one that has to deal with it. So comments like this are all around the kernel, right? If you want to search for expletives in the kernel source tree, you'll find a lot. They're mostly related to manufacturers writing something wrong. All right. And just to kind of dispel a lot of magic. So everyone can read hex, right? Kind of, okay. So hopefully everyone can read hex because sometimes if you get into the nitty gritty, kind of need to read some hex. So everything in computers, everything's just a number. It just depends how you interpret it. So no matter what you see on your computer, everything's just a number at the end of the day. Don't let anyone tell you different. But in this case, this sequence of numbers represents a program that prints Hello World. So each of those, you know, between each space, those are each a byte. So if you take 168 bytes in this case and put them out in that order, and then try and execute it on Linux, on an ARM machine, this will actually print Hello World, which is kind of amazing. So everyone's written Hello World in C before, right? Anyone know how big, how many characters were in that like Hello World file? Like ballpark, probably 100. So it seems kind of weird that an actual executable could be almost as big as the source file. But let's make sure I'm not lying to you first, I guess. So on my machine, see, so I have this 168 byte executable. It's the same thing that was on the slide. So it just looks like an executable. And if I execute it, if I didn't lie to you, it should get Hello World, which it does, which is pretty amazing, because if I look here and look at, oh, I guess this file's too long. So if I look at this file, right, this is a Hello World you'll typically see. So if I look at that and see how big that is, that is 100 bytes. So the whole executable, you know, with some other, the whole executable is actually only 68 bytes bigger than the entire source code, which is pretty magical.  So let's see. So if I compile that, right, it's like 9048 bytes, which is significantly bigger than 168 several orders of magnitude. And if you execute them, right, it does the exact same thing. So weird. So if we go, oh, no, there's no question. Okay, so this right is not that many bytes. So you can actually understand Hello World as it relates to the operating system, what the operating system has to do and not that many bytes. And you actually like fully understand everything eventually. Yeah. No, so this is doing the exact same thing as a C program. Yeah, so this isn't doing anything special. It's doing the exact same thing as a C program, but instead of the 9000 bytes, it's 148. So yeah, so just to wrap up, there's three major concepts in this course, right? You'll learn the following and how they applied operating system, virtualization, concurrency, persistence, and how Hello World works. So with that, just remember, I'm pulling for you. We're all in this together.