Traditional wide area networks cause a lot of headaches for us as network
engineers. And we talked about this at the start of the course, but when we're
looking at a WAN circuit here between two locations, these WAN circuits
typically have very low bandwidth and very high latency relative to what we're
used to on the local area network. So over here on the local area network
we've got switches that are usually 1 gig or 10 gig and these days we might
even have 40 or 100 gig again on the local area network. But then we are
taking all of this traffic and having to squeeze it onto this WAN circuit which
has very different types of metric results. And Cisco sees this as an
opportunity for improvement whereby we can deploy some SD-WAN features that
will help us to deal with this problem. And these features are going to be
known as Application Quality of Experience or AppQoE. Application
Quality of Experience is basically saying that hey we want to get the
absolute most out of our WAN circuits. And there's a lot of different ways that
we can try to squeeze more, whatever we want to say, squeeze more juice out of
this WAN circuit at a minimum try to maximize the bandwidth that we have, try
to reduce the latency as best we can. We also often have to deal with loss and so
try to reduce that loss as much as possible. And yes SD-WAN does give us the
opportunity to deploy some clever solutions that can help us to deal with
this. Now one note here is that within the field of Application QoE we're going
to have the concept of quality of service. We've already talked about this
in the course and so we're not going to talk about it within the context of this
skill. But we are going to talk about all of the other features that are part of
this overall suite of, well suite of features. And the first one that we're
going to talk about here is known as TCP optimization. As the name implies we're
looking to optimize TCP. But why does TCP need to be optimized? Well TCP has an
interesting concept which is this windowing feature. And the cool thing
about windowing is it's intended to help us deal with network congestion. TCP is a
connection based protocol. So if we have a host here, and I guess maybe we'll draw
this as an actual host, communicating with another host via TCP. Well we
could have all kinds of network hops in the middle here. And so we know that if
there's a packet that gets dropped then we are going to not receive an
acknowledgement back which means that I will retransmit the frame. And that's
really an important part of TCP and certainly that's the part that gets
talked about a lot is this concept of connection oriented retransmissions when
we have packet loss. But TCP doesn't just work one packet at a time. Our host here
is actually able to send many packets all at once because we don't just want
to send one packet and sit there and wait and then once I know I can send the
next packet I'll send the next packet. That's not what we want. We want to send
a lot of these packets all at once and this is what defines our window. If
network congestion is low I want to stretch this window out and send more
packets all at once. But the creators of TCP recognize that by creating more
traffic from TCP hosts then that's more likely to actually create network
congestion. And so this window is actually a sliding window. If network
congestion is low then I'm going to increase the size of my window and I'm
going to send more traffic. And if network congestion is high then I'm
going to want to scale back my window sizing. The problem with this is that it
has an undesirable result. It creates this sort of shark fin type of pattern
that we see with our link utilization. Because what can happen here is this
concept of TCP global synchronization. What we're saying is that globally or at
least at this site let's say over here we have a lot of TCP hosts and they're
globally going to end up synchronizing their sliding windows. What we mean by
this is that if a bunch of hosts end up transmitting a bunch all at once and
create network congestion they're all going to slide their window back. And so
the way this looks is we're all increasing and increasing and increasing
our utilization of the link. And let's say that this is the max bandwidth for a
particular WAN link. Again the WAN circuit is going to be our limiting
factor in a lot of these types of situations. So I'm measuring my bandwidth
here across time. So this is over the course of time. So I increase my
bandwidth because all of our TCP devices are increasing their windowing. And then
all of a sudden we hit the max bandwidth and we all start dropping packets. What
happens is we all pull back really hard on the amount of traffic that we're
sending. And so we all reduce our window sizes. We realize hey cool
there's no congestion. And so I start increasing and increasing. We hit
that max value again and we drop. And so this just kind of keeps happening over
and over again. So this looks like shark fin sticking out of the water here. We
kind of like that. And so we end up being surrounded by sharks in the network or
otherwise. What we really see here is all of this unused bandwidth. If we kind of
bandwidth the entire time then yes all of this does end up being wasted
bandwidth. A bunch of bandwidth that we could be using but nobody's actually
trying to use. So we have a couple of ways of dealing with this. First of all
in the world of quality of service, which again that's part of application QoE, we
can use the concept of weighted random early detect or just random early detect
or I like to just call it RED. So when we're talking about weighted random
early detect that will help smooth things out. But beyond this Cisco has
created for us a technique known as TCP optimization to really help control this
window sliding. But here's how this works. This is kind of interesting. What Cisco's
going to do with SD-WAN is they're going to intercept the TCP connection.
Remember it's a connection oriented protocol. Typically what ends up
happening here is I send my TCP and have my really my three-way handshake to
build a connection. And so what I end up doing is having a TCP connection between
my hosts. TCP optimization is going to sort of play man-in-the-middle. Remember
when we talked about security and how if these two hosts are sending encrypted
traffic to each other one of the hosts might be launching an attack and we
really want to pick up on that. So what do we do? We played man-in-the-middle. We
built a tunnel here and a tunnel well technically a tunnel like this. But we
played man-in-the-middle so that we could intercept the traffic unencrypted
or decrypt it and then analyze it. We're going to do something very similar here
with TCP optimization. I'm going to form a call it a normal TCP connection here.
I'm going to intercept it and perform the three-way handshake back and forth.
Then I'm going to form an optimized TCP connection between the edges and allow
the remote side edge to have a normal TCP connection. This optimized TCP
connection is going to manage the window sizes in a much more efficient way. We're
also going to make sure that we're using selective acknowledgments. Now selective
acknowledgments are typically used end-to-end as well but we want to make
sure that it's used end-to-end. A selective acknowledgment basically makes
it so that if I send let's say six packets all at once and let's say packet
number four is lost the receiver on the other side is going to get packets one
two three five and six. In traditional TCP networking I'm not allowed to only
request packet number four. I have to say basically that I have packet number three
and I'll keep acknowledging packet three until finally this host resends for five
and six. Well there's no reason for it to resend five and six so selective
acknowledgments allow me to not only acknowledge one through three but also
acknowledge five and six. Then the sending host over here understands it
really only needs to retransmit packet number four. So this is what selective
acknowledgments gives us and that drastically improves the efficiency of
our link. So that's part of TCP optimization the other side of it is
just following its own set of rules for window sliding. But between the window
sliding and selective acknowledgments what we're really doing is again we're
optimizing TCP. But the one of the most important takeaways here is for us to
recognize that it does so by breaking our TCP connection up into three
individual components and so as a result we're gonna have to be a little bit
careful about where we enable this and if we do enable it we need to make sure
that our application or end-user experience ultimately is impacted in a
positive way and if it for any reason causes any problems because of the
segmented nature then we're going to need to make sure that we disable TCP
optimization for those traffic flows.