I remember someone once telling me that the most efficient packet on a network is the one that we never have to send.
And I'm probably botching that. It's been at least 10 years since somebody told me that.
But it's always kind of stuck with me, this concept of, hey, let's never send certain packets in the network because that will help alleviate the network.
And now we're really talking about something that we can apply to our SD-WAN environment.
And so specifically, we're here to talk about the concept of compression.
If you have only ever been a network engineer, then you might never have really delved into the world of data compression.
If you come from the storage side, then maybe you've seen this or maybe you've just researched it on your own for fun.
But the idea of compression is to take something like a 1500-byte packet and then we're going to receive it on our edge.
We're going to reduce it to, let's say, a 1300-byte packet.
So now it's a little bit smaller. I send it across my low bandwidth link.
The router or the edge on the other side increases it back to 1500 bytes, restoring all of the original data.
And importantly, this process must be lossless. We'll talk about that more coming up.
And then we just send it on its way as its original 1500-byte packet.
This might feel just like looking at it might feel like it's an unnecessary process because we start with 1500 bytes and we end with 1500 bytes and nothing really changed.
But naturally, where it really matters is right here where, again, we have low bandwidth links.
And so sending a 1300-byte packet compared to a 1500-byte packet, that's not quite 20 percent.
But, you know, we're talking about maybe 15 percent of our total packet size there that we ended up saving.
And so effectively, that increases the bandwidth by 15 percent.
I'm sure my math is perfect there. I don't know.
But either way, it is increasing effectively, effectively increasing the bandwidth on our WAN circuit.
Now, as part of Cisco's quality of experience or really application quality of experience, we're going to refer to this as data redundancy elimination.
What we're aiming to do here is to eliminate redundant data.
And so we can abbreviate this as DRE.
This is typically how compression works.
We're looking for redundant information or what we might refer to as common patterns in data that we can represent with fewer bits.
So just completely making something up here.
Let's say in a standard traffic flow, this pattern shows up a lot.
0, 1, 1, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1, 1.
This is 16 bits of information.
And let's say we've identified maybe our top 64 patterns that show up.
Well, for 64 patterns, I really only need 6 bits.
So I could maybe represent this by something that only takes 6 bits.
So what I've done is I've replaced this block of 16 bits with something that's only 6 bits in size.
This is great.
I just saved myself 10 bits.
And if I do that throughout the packet, then, again, I might be able to reduce 1,500 bytes to 1,300 bytes.
Now, this edge on the other side, once it receives it, it's going to reverse this process.
And so this process is originally known as compression.
We're going to compress the data, and then we can decompress the data on the other side.
Now, importantly, we just said that we're going to represent this information with, or, you know, this pattern with an abbreviated set of bits.
Well, that conversion must be stored inside of what we call the cache, or, again, Cisco is going to refer to this as the DRE cache.
The DRE cache is going to exist on both sides of this connection, both of these edges, and it must be synchronized.
Because if I'm going to compress it using this style or this method, then I need to be able to decompress it in the same way.
So we do have to be synchronized with how we're going to make that happen.
So these patterns and replacements are stored inside of that DRE cache.
So where do these patterns come from, and who's defining these?
Well, fortunately, we as network engineers don't need to worry too much about that because there are compression algorithms in the world that we can take advantage of.
And a lot of these compression algorithms are highly standardized at this point.
The powers that be, the people who are really, really smart mathematically have been able to create algorithms that are very effective with the data that we send these days.
And so the algorithm that we're going to use for SD-WAN is known as the LZW algorithm.
And this actually stands for, really, three different last names for the scientists who created it.
It's going to be known as Lempel-Ziv-Welch.
Now we can just abbreviate it as LZW, that's a Z there, LZW.
But as long as we're using the same algorithm on both sides, we should be good.
Now this is not a configurable value.
But it's important for us to understand that.
And the reason for that is because when we talk about algorithms, we are going to find that there are lossless algorithms, like I just mentioned, and that's exactly what LZW is.
And then there are lossy compression algorithms.
And one of the primary lossy algorithms that we use is known as DCT, which isn't very important for the sake of this course.
But it does stand for discrete cosine transform.
Now why do we have a lossless versus lossy?
Well, because they provide two different values.
The lossless is going to be very high in data integrity.
In other words, we're not going to lose a single bit of data, which is very important for us on the network side, but it's going to be a little bit lower on the compression side.
Whereas lossy favors compression for the sake of understanding we're going to lose some amount of data integrity.
And one of the best ways to visualize this is with two different file formats where we use these compression algorithms, specifically our PNG files.
If you've ever really worked with images on a computer, a PNG file is going to be lossless, and it's going to use an algorithm known as deflate.
Whereas a JPEG is going to be lossy, and it uses the DCT algorithm.
So if you've ever pulled up a PNG versus a JPEG, a JPEG is going to be a little bit more fuzzy, especially depending on how high the level of compression is.
And sometimes we actually have control over that when we're creating JPEGs.
And so it gets a little fuzzy because we're sacrificing information in order to create higher compression.
So JPEG files tend to be smaller than PNGs.
Well, same concept here with the networking.
If we were to use a lossy algorithm, that would be no good, and we want to make sure we recover every single bit of information.
And so that's why we use LCW as a lossless algorithm as part of Cisco's data redundancy elimination.