So when we do delay-based congestion inference it gets a little more involved. this one limitation here is TCP Vegas, we talked about. we have to break out the RTT really to see how this is done. to see what magnitude above the current or the current whatever the minimum RTT we're in now. so, consider this diagram right here, it shows the two main components that will form the delay in the [UNKNOWN] time. If you consider a packet coming up into a router here. it's going to have to wait a certain amount of time in the queue before the router will send it across to the next link. so, this is we call this the queueing delay. And just the red packet here. The black packets, they're suppose to be other packets which are already in the queue. so, it goes through some amount of queueing delay, some [UNKNOWN] time it has to wait in here. And then when it actually goes across the link, it it experiences what's called propagation delay. Right? And that's literally just the speed of light limitation. Right? So, how, how fast can you travel across a link, and and then it gets to queueing delay. Again, when you get to the next router. So propagation delay strictly speaking is the time it takes to go through the links. that is in variant with congestion. Right? So, once you're on the link. Right? It's kind of like when you get outta the traffic jam, there's no traffic. You, you know, you drive the speed limit, which be like the, the whatever limitation was of the material that you're propagating through here. but on the other hand, queuing delay is like the time you're spending in the traffic jam, or and that's really what we're concerned with here. That's what What affects the congestion once the that's what the congestion signal really is. That's the time a packet needs to wait in the queue, and that does vary with congestion. So these are the two main components. The RTT, there's other ones that are more subtle, but these are the main ones that we would be considering here what we would see impacting the RTT. So we have to estimate the queuing delay, and the way that we do that is by the way that we could do that is by comparing the no-congestion RTT. Right? So whatever that was because we said across the US might be 50 milliseconds, suppose. so the current RTT, so the current RTT was 60 milliseconds, we'd say. Alright, well, we'll subtract 60 minus 50, which would mean we weren't wait in the queue at all. So there's 10 milliseconds of delay due to queuing. Right? And then that gets higher so as it goes to like 100 or something, and that's 50 milliseconds of queuings. So the queuing is doubling the time, in that case, that it takes to get for the acknowledgement to get back. So, what TCP Vegas does actually is it compares transmission rates rather than queue the transmission delay. So, the queuing delay really would be the transmission delay, it compares the transmission rates. Which is really similar. It's very related. it's just that we have to take in the window size into account. Higher rate is better, where as a lower delay is better. So, they're just inversely related. But if we take the current congestion window size as the number of packets we send out per round trip time. And if we divide that then by the RTT that gives us the number of packets per second that we're sending, which is really like a transition rate. So, if we're sending five packets and in 50 milisecods, then we can divide those two to, to get 0.1 Kbps or 500 bps, whatever it may be. 500 packets per second. So, so, the current RTT we can do, take the current congestion window size and divide it by the RTT that we just measure. And for the no-congestion RTT, we can take the current window size and divide it by the minimum RTT. Right? So, that's the minimum RTT that would, we would, that we've seen in the past little while in par, in a certain window amount. so, as the minimum RTT clearly is going to be lower than whatever the current RTT is, because this is the minimum of all the RTT's. So, the no-congestion transmission rate is always going to be higher than current congestion transmission rate. So again, the inverse relation here. But we subtract these to give us the difference. Right? the difference between the two [INAUDIBLE] that we take the no-congestion and we subtract the the current rate from the no-congestion rate. So, we take the window size and we divide the minRTT, and we subtract the window size over the current RTT. And that's the difference in the rates. And so the, the higher this is the the worse of that we're doing in terms of the RTT right now. So we want this to be lower, which means that the current RTT is approaching the minimum RTT. And the higher this gets, that means that we would have more congestion. So, each each round trip time, or each acknowledgement rather we have to compare the difference to some threshold. And that's really what we do each time we get an acknowledgement. When we were doing TCP Reno, it was each round trip time. Here, it's actually at each acknowledgement, so it's a finer grained scale. so we compare the difference to some threshold, so say that that's three packets per second. it could be well, we'd say so we want to compare whatever this difference is to three and see. So, if it's smaller than three. Right? So, if it's smaller than three then that means that this is within three units of the, the ideal transmission rate, or the no congestion transmission rate. in that case we increase the congestion window. Right? because it means that's there's really no congestion we're experiencing. If it's larger, then we decrease the window size by one. Right? So if it's greater than three, then that means that we're farther away so we can [UNKNOWN]. Maybe we should call it thresh, THRESH, because it doesn't have to be three. So, if it's less than the threshold, then we increase it by one. If it's larger than the threshold, then we decrease it by one. And this is not a less than, a greater than or equal to. So, it shouldn't pu, underline it. But if it's the same, then we keep the congestion window the same. Or if it's within some window around it. Like if it's, you know, if it's 2.9 to 3.1 or something like that. and so this is how we update. And this should give you the idea. If it's, if it's smaller. Right? If the difference is smaller, then that means that we're approaching the ideal [UNKNOWN]. And therefore we want to ramp up and try to send more, because we're not seeing any congestion. If it's larger, then we want to decrease it. Right? Because we're going too far away, we're getting much, too far away from the ideal conditions. And if it's the same, then we keep the congestion window the same. Right? So that's that threshold is really where we want to get and where we would like to stay if we could, if we had some sense of an equilibrium.