So now we know what the congestion control
mechanism is, let's actually take a look
at some algorithms and how they work. So
let's remember it this way. The congestion
control mechanism TCP determines how
aggressively that a sending TCP station
will utilize bandwidth on a network. It
also determines how quickly that device
will back off and recover if it
experiences loss or high latency. Now
let's put some names to this. What is a
congestion control algorithm? And maybe
you have heard of some of these before. We
have Vegas, we have Reno, newReno, Tahoe,
CUBIC, Fast, CTCP, BBR, and more. There
are lots of different algorithms out
there. Now as time goes on and networks
change, we find that these are tuned to
better perform over different types of
networks. So, for example, when long fat
networks came out or when networks got
higher bandwidth with higher latency, for
example, a 40 GB connection across the
ocean, we started to realize that there
were changes that needed to be made to the
TCP sending algorithms, maybe make them a
bit more aggressive so they can take
better advantage of those links without
needing to throttle back just because they
see a single lost packet. So again, these
are some common congestion control
algorithms that you'll see out there, and
depending on our operating system, what
version of TCP we're using, what patches
that we have installed, that will
determine which one of these we use. But
let's take a deeper look and see why these
algorithms are different. It all comes
down to the way that they use the
different components of congestion
control. So let's take a look at the first
one. One core component is the initial
window size, and what the initial window
is is basically the number of full‑size
MSS packets that a sender will put out at
once at the beginning of transferring a
file. So let's just say that this server
was using a very conservative congestion
control mechanism and it only throws out
two full‑size packets at once. What it
does is it waits for the acknowledgements
to those packets to come back before it
begins sending more data, it figures, hey,
I sent out two packets. Everything got
there. Now I can go ahead and begin
sending a little more. Now what determines
the initial window, how many packets are
actually put out on the wire, that depends
on the congestion control mechanism use.
So in some implementations of new Reno, we
saw four maximum segment size packets get
sent out initially, that was our initial
window setting, or with cubic, there are a
lot of installations of CUBIC where they
use 10 MSSs at the beginning of
transferring a file. So remember that core
component is initial window, that's how
much do we begin sending initially?
Another core component of the congestion
mechanism is slow start. So what this
means is here is our server, it puts out
those two full MSS segments out on the
wire, it receives an acknowledgement back
from the client, it figures, you know,
that worked out pretty well. Let me
measure the latency between sending that
data and receiving the acknowledgements
and then I'm going to double the amount of
MSSs that I put out next time. So in the
next batch that it sends, it will send
four MSSs and then wait for those
acknowledgements to come back. So what
this allows that server to do is to slowly
ramp up that data so it puts out a couple
packets, waits for the acknowledgement,
doubles the amount of packets that it puts
out, waits for the acknowledgements, and
doubles again. So this is a common
mechanism that you'll see in some of the older algorithms like Reno and NewReno.