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.