Over time units measured by round trip times. Lets assume round trip time is

fixed for now. Actually it does vary and can vary quite a lot if there is a lot of

congestion variations. Lets say we start with congestion window being five packets.

Okay. And after one round trip time, okay. Here's the source. Here's the destination.

Separated by the distance. And this again is the time axis vertically. So five

packets got sent. Let's say they all properly received by the destination and

then five acknowledgements are sent. So this time is one round trip time. RTT.

Okay? And therefore the sliding window slided five times. Plus there is an

increase. So slide plus increase. Now how much do you increase? For each

acknowledgement you received an increase by one over CWND. But there are CWND

number of acknowledgements. So amounts to adding the window size by one. And now,

the next time when you send, tou can send one, two, three, four, five. Because you

slide the window by five. And one more, cause you are, increase the window size by

one. Okay. And this keeps on going. So you got six packets. And then assuming that

there's no congestion and therefore, at therefore, at least for wire line network,

there's no loss, you have to go to seven after another round-trip trip time and

then go to eight. So as you can see, this is a linear additive increase in order to

try to get the most efficient usage of the network capacity. But it turns out at this

point, together with the actions of transmitting packets from the other

sources. In get, congestion is induced, somewhere in the network, along the path

used by this particular source. And how do you know that? Well, you may know that by

time out timer, you may know that by three duplicated acknowledgement and therefore

you say oops there is a loss or these are in further there is a loss somewhere in

the network and that implies in turn that today's congestion. All right I'm going to

therefore penalize myself in a multiplicative way. Okay? Try to avoid

congestion now by reducing the transmission right by reducing the

congestion window size, CWND. Cutting eight in half down to four and now this

keeps on going again. On the other hand, if this is a delay based congestion

interference for example in fast or in TCP Vegas, then the story is a little

different. Now first we have to decompose the overall and to end delay into four

components. Okay, a propagation delay, queuing delay, transmission delay, and

processing dela y. Now, propagation delay is due to the fact

that you have to traverse a physical distance and you can't be faster than the

speed of light. Queuing delay is what we are most interested in here, because they

refer to the time you spend waiting inside a router for the egress link to be

available, of output port, as we saw in the last lecture on routing. So this is

congestion induced. If there's no congestion, then the egress link on alpha

port is always available. There is no queuing delay. But as condition gets

heavier and heavier, queue and delay also will go up. Then there's the transmission

delay. Because a packet is a finite size, so starting from transmitting the first

bit to the last bit takes some time. Finally there's processing delay, for

example looking up at the forwarding table. Usually we say that the

transmission and processing delay are relatively insignificant compared to long

distance propagation delay and the possibility of congestion induced queueing

delay. So if we look at these two main component in a normal situation, you see

that when congestion's very light you basically looking at a round-trip time

being the propagation delay. As congestion goes up, your total round-trip time or

delay goes up. So if you are looking at the transmission rate, assuming there is a

minimum queuing delay with almost no congestion at all, then you are talking

about the transmission rate x being, CWND over RTT mean. Okay. Smallest RRT that you

have experienced, in recent past. But if you're looking at a transmission rate x

when there are some levels of congestion, then n equals the congestion window over

the current RTT. So RTT mean is some constant. You have to estimate RTT, This

one is the current time t, okay. To be more precise, you have to multiply by the

average packet size, measured in bits, okay? But if you measure it by packets per

second, then you can just compare this with this. And what happens is that you

would say. Let me look at the difference between the transmission of rate with a

minimum queuing delay, versus actually transmission ray I'm currently getting.

Okay? And if this difference is very big. Okay? Then that gives me some information

about the current congestion, condition. Okay? For example, if this difference is

very big, that means that this ruptured time at this point is very big. Okay? And

therefore you know, this number is small and therefore the difference between these

two numbers is big. So if this difference between this ratio and this ratio is

bigger than the threshold. Okay? For example threshold is three units then that

means there is some congestion and I'm going to reduce the congestion, window. So

let's look at this difference. If it's bigger than some threshold beta, that

implies CWND should be reduced, say by one unit. On the other hand, if this

difference is smaller than a threshold, let's say the same threshold, then that

means CWND can go up because if it's smaller than a threshold that means that

this current round trip time is not too much bigger than the minimum round trip

time. But what about if the difference is exactly equal to this threshold beta? Then

you'll say well this beta is basically telling you how many packets you can

tolerate to be in the flight between the source and the destination. Okay? And you

say all right, then I can tolerate this many packets in transit from the source

and destination and the congestion window size would remain the same. CWND no

change. Okay, you don't increase it by one; you don't decrease it by one. So,

when all the sources have their difference of, between these two ratios equal to

beta, then there's no one is changing. And that reaches an equilibrium. We haven't

touch upon equilibrium concepts in a while. We talked about gain throughout an

equilibrium in strategic thinking. We talked about equilibrium in a fixed upon

equation. And this is the equilibrium for integrated procedure. Like this congestion

control protocol. So it's a compare between these two different philosophies.

This is loss based, this is delay based. Typical chart you'll see of congestion

window over time t. For loss based it will linearly increase then it will have a

sharp drop multiplicate of decrease, linear increase sharp drop. So you see the

zig-zag, zig-zags going up. Whereas, for delay based because you're using a early

and continuous signals instead of a late and binary congestion signal you might

hope for the convergence of this oscillation through some kind of damping,

and eventually converge with very little ups and downs around a desirable

equilibrium. And that will be the target. The target is to say that distributively,