Well, remember, we're trying to improve our efficiency on the wide area network.
And in order to become more efficient, Cisco SD-WAN says that we can duplicate our packets,
and that will send more copies of packets across the WAN, and that will make us more efficient.
I'm pausing for effect here. That should make us ask a little bit of a question.
Jeff, did you mean to say deduplicate? Are we trying to improve efficiencies by removing data?
That's what we just talked about with DRE. Why are we duplicating traffic to make ourselves more efficient?
Yes, this takes an explanation, because normally we do like to see deduplication.
We think about storage protocols and things like that. We're trying to deduplicate data.
And again, like we just said in the last video, the best amount of data that we, you know,
the most efficient data, I suppose, is the data we never have to send.
But now we're talking about duplicating information. What are we trying to accomplish here?
Well, let's start with a few different premises here. First of all, we can assume something that is correct,
which is that the most inefficient thing that we can do is going to be dropping a packet.
So basically, network loss is one of the most, if not the most inefficient thing we can do.
I think we all agree with that. It's at least one of the worst things that we could do is drop packets.
And premise number two is recognizing that in the world of SD-WAN, we typically have multiple WAN links.
So now we can actually combine premise one and premise two and draw a little bit of a conclusion here.
If we want to say one plus two equals three, which I guess actually in math that works too.
But we'll draw this conclusion. It's that if we send multiple packets across multiple WAN links,
then we can prevent loss by hopefully hoping that one of those copies gets to the other side.
So let's go ahead and diagram this out because a picture is worth a thousand words in this case.
So let's say that we have an edge and we have a remote edge we're trying to get to.
So I've got a host over here. It's sending a packet and maybe it's just part of a traffic flow.
And we're trying to get over here to this receiving host. So what if we have a pair of circuits?
So we've got service provider A here and service provider B.
And we know that we've got tunnels that we could take in either case.
So let's say that we divert this packet out towards service provider A, except service provider A drops the packet.
Therefore it never arrives on the other side. So that is certainly by default what we're going to do.
We're going to have a preferred circuit or a preferred tunnel.
We've talked about all the different ways that we can choose that.
We can load balance. We can pick one as an active with the other one as a backup.
But in the end, we're still by default going to pick one of these service providers and send the packet their way.
And the reality is that this service provider might be having problems.
Maybe it's the Internet and the other side is MPLS and so the Internet's very busy.
But either way, we see that we have lost that copy of the packet that we sent.
So what if we also send a backup copy?
So we copy the packet, we duplicate the packet, and we also send it out towards when service provider B.
Well, now maybe service provider B has no problem processing that packet and it makes it to the other side.
Now, in the scenario where both of them make it, no problem.
Whichever one comes first, let's say this one up here arrives first and this one arrives second.
Well, then this is the one that gets forwarded to the receiving host and we end up dropping this packet here.
But in the event that this packet doesn't make it to the other side and this is the only one that shows up, then it gets forwarded to the receiver.
So in other words, by sending out multiple packets across multiple links, we actually end up preventing loss, which yes, now increases our overall efficiency.
But I will say, if you're like me, you probably did a double take because the first time I was learning about this technology,
I definitely thought that they were spelling deduplication wrong.
It's like, oh, you mean deduplication, right?
No, we're talking about duplicating packets.
The fact that we have multiple WAN circuits allows us to do this in such a way that, again, we're trying our utmost to prevent data loss.
Because by preventing loss, even though, yeah, we're kind of proactively retransmitting or transmitting a second packet,
the reality is that maybe we've got all this bandwidth to spare.
And so it doesn't really matter if I consume bandwidth down here on this service provider.
Unless it's already maximized, I'm maximizing that link, then I have bandwidth to spare.
So it doesn't really cost me much other than potentially some CPU overhead on the part of the router because this side needs to decide to copy the packet.
But the amount of CPU utilization increases overall very small compared to the fact that we're saving ourselves a lot of headaches by ensuring that packets make it to the other side.
So there are a few details to cover as part of packet duplication.
The packet duplication is typically targeting critical flows.
We don't necessarily want to apply this to all of our traffic flows because eventually service provider B is going to have some amount of congestion issues.
We don't want to just overload that service provider link with a bunch of duplicated traffic.
So make sure we're intentionally targeting specific flows.
Another very key piece of information is in order for us to use duplication, it is going to require multiple links.
That's a very fundamental part of all of this is we're leveraging a second circuit in order to send a duplicated packet.
I can't send a duplicated packet if I only have a single link.
So if I have a remote site with a bad internet circuit, this isn't going to help us out too much.
But good news, we do have something that can help us out in single link scenarios we'll be talking about coming up.
But as far as our packet duplication, duplication requires multiple links.
And lastly, it can work with TCP and it can work with UDP.
And so we're just going to have to be careful, though, about the applications that we target because not all applications need or even want this type of behavior.
So it's going to require some amount of testing to make sure that we're optimizing the traffic that we're targeting.
We want to make sure that the traffic responds well and that overall our application quality of experience, which is what Cisco calls this, the app QoE is actually improved for the end user.
And if we enable something like this and it just doesn't work out, once again, we just have to be sensitive to that and recognizing that maybe the target application in that case wasn't properly optimized for this type of redundancy.