So, let's us consider zoomed out due over time of TCP Reno and TCP Vegas. We've used these as the two examples just before we use Reno for the lost base congestion difference and Vegas for the delay base. so if we sort of zoomed out that picture out a little if we kind of get the following for Reno and following for Vegas. where as under Reno we would, you know, we would increase it slowly and then we would sharply decrease it once we get congestion. And then we would gradually build it back up. Sharply decrease it. Gradually build it back up. Sharply decrease it. Right. And we get sort of the zigzag pattern. Now, obviously there's, you know, this is like a staircase up in here. but this is just over time really zoomed out. And then on the Vegas side of things of course, this is still a staircase moving up but then eventually we would start to. We would start to hit a centerpoint right where we would hold constant for a little bit and then we would start to decrease. So, it kind of smoothes this out a little bit to Vegas because we're responding in a finer granularity, each acknowledgement we're looking at we're either increasing or decreasing the. Window size on the spot right there to send out again. And so this is a typical property in one of the typical comparisons we use between Reno and Vegas. so this is really showing that Vegas can smoothen out this trajectory and it's the advantage of using a non-binary congestion signal, right because with TCP Reno, we're just using one or zero, right? It's either there is congestion or there is no congestion. But with Vegas we're smoothening that out more because we are also considering the magnitude of congestion, right? is how late is this packet, right? Is this packet early? Is it late? So on, and then we can increase quicker or smaller accordingly. And so but another thing to point out though is that it's not always saying TCP Vegas is going to be better than TCP Reno. it depends on the implementation, it depends on the parameters as well, right? So, for instance, what do you set that threshold value to be, right? but as long as you tweak and tune the parameters properly to the right setting you would tend to see that Vegas would have this smoothing effect. And that it may eventually converge to an equilibrium for each of the centers that are on the system. So, that brings us to the next point of distributed congestion control. and for this, let's think back to DPC, our distributive power control for a minute. in that case, where our objective is to match the measured to desired signal to interference ratios. And it was an iterative algorithm, DPC algorithm, right? It was a sing, it was not like a single step algorithm. we would keep, we would compute the measured SIRs. Send them back to the transmitters. Then they recompute their powers. Then we recompute the SIRs. Then recompute the powers and. It will keep going back and forth. And it was also distributed, right? as it's name because it's executed on the device side. And we know that we could reach equilibrium amongst the transmitters, right? And so, distributed congestion control, it's really how we implement congestion control. the objective is to match measure to desired transmission rates. And it's really very similar to distributed power control. they're doing something different but the idea is similar, right? Is that we're trying to match transmission rates. So, where the [INAUDIBLE] match transmission rates we're getting to what's we want to have ideally. instead of, measuring matching SIRs, we're matching transmission rates. it is an iterative algorithm. it is also an iterative algorithm. We can make it iterative. And we can also make it distributed, right? So, we can make each, each sender is doing their own congestion control at the TCP layer. And we can also reach an equilibrium. And so it's it's similar situation that we saw in chapter one or lecture one that we had a tower. And if we had you know, cell phones then we would be able to feed back and forth between them and that they were all causing interference on one another, which is in the form of a negative externality. And here, it's just that we're viewing the internet and we have devices, which are also, you know, that could be cell phones too. But also like laptop computers. can't draw to save my life but it's, you get the idea and they're all sending and receiving feedback signals from the internet itself. in terms of how much congestion there is to how to change, so. They also don't have to communicate with each other and they, they don't They just see kind of what the network is telling them. And then the TCP layer uses that. So, don't get confused. This is DPC. We also saw the the single set TPC algorythm, which led us to DPC and TCP try distributed congestion control protocol not to be confused with transit power control algorithm. And so we don't have time to discuss the multiple transmitter implementation. but actually there is something quite similar to the way DVC works, an implementation we can use over time, to adjust what the sending rates would be in order to reach that equilibrium.
