WEBVTT

1
00:00.000 --> 00:09.140
So our next topic here is packet duplication, clearly the polar opposite of ded

2
00:09.140 --> 00:10.800
uplication.

3
00:10.800 --> 00:13.240
But why would we want to do this?

4
00:13.240 --> 00:18.000
Clearly we just spent an entire video talking about eliminating, sending

5
00:18.000 --> 00:19.480
duplicate data across

6
00:19.480 --> 00:24.530
the WAN, why in the world would we purposefully create duplicate data to send

7
00:24.530 --> 00:26.160
across the network?

8
00:26.160 --> 00:29.970
Well that's a great question, so why don't we just jump in and take a look at

9
00:29.970 --> 00:30.480
what this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.970 --> 00:30.480
what this

10
00:30.480 --> 00:37.200
actually does and answer why we want to do it along the way.

11
00:37.200 --> 00:42.160
So let's start with asking that first question, why do we want to do this?

12
00:42.160 --> 00:45.800
Why do we want to send duplicate packets across the network?

13
00:45.800 --> 00:48.480
And the answer is actually fairly simple.

14
00:48.480 --> 00:51.880
This is all about reliability.

15
00:51.880 --> 00:56.680
This is clearly not in any way about efficiency.

16
00:56.680 --> 01:00.280
So if we're going to be sending duplicate packets, of course our efficiency is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:56.680 --> 01:00.280
So if we're going to be sending duplicate packets, of course our efficiency is

17
01:00.280 --> 01:00.600
going

18
01:00.600 --> 01:01.880
to go down.

19
01:01.880 --> 01:08.100
But this is more about ensuring that critical traffic gets through even if

20
01:08.100 --> 01:09.180
maybe one path

21
01:09.180 --> 01:11.640
isn't working as it should be.

22
01:11.640 --> 01:17.480
And of course that means we're going to be sending multiple copies of the same

23
01:17.480 --> 01:18.440
packet.

24
01:18.440 --> 01:24.560
Now not only can this prevent packet loss, which hopefully is obvious, but this

25
01:24.560 --> 01:24.960
can also

26
01:24.960 --> 01:30.910
reduce the latency and the jitter because one of the fundamental things here is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:24.960 --> 01:30.910
reduce the latency and the jitter because one of the fundamental things here is

27
01:30.910 --> 01:31.440
we're

28
01:31.440 --> 01:34.240
going to be sending it down different paths.

29
01:34.240 --> 01:39.550
So if the packet happens to arrive from one path before the other, clearly we

30
01:39.550 --> 01:40.240
would be

31
01:40.240 --> 01:45.980
reverting to the packet that arrived first, therefore the one that had less

32
01:45.980 --> 01:46.720
latency and

33
01:46.720 --> 01:51.640
jitter and that could really be coming from any of the alternate paths.

34
01:51.640 --> 01:57.050
So because of the way this works, this is primarily going to be used for things

35
01:57.050 --> 01:57.420
like

36
01:57.420 --> 02:03.000
real time applications such as voice over IP or video.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:57.420 --> 02:03.000
real time applications such as voice over IP or video.

37
02:03.000 --> 02:08.070
Also for mission critical traffic, things that absolutely have to get through

38
02:08.070 --> 02:08.520
above

39
02:08.520 --> 02:10.280
everything else.

40
02:10.280 --> 02:14.440
Now of course, as we've said, it's not efficient.

41
02:14.440 --> 02:17.520
We're purposefully duplicating traffic.

42
02:17.520 --> 02:22.300
So we want to use this very selectively only for this type of traffic we

43
02:22.300 --> 02:23.560
mentioned right

44
02:23.560 --> 02:24.700
up here.

45
02:24.700 --> 02:30.470
So again, real time mission critical, things that absolutely have to get
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:24.700 --> 02:30.470
So again, real time mission critical, things that absolutely have to get

46
02:30.470 --> 02:30.800
through.

47
02:30.800 --> 02:36.440
Now just a couple of its attributes, like we said, this is going to use

48
02:36.440 --> 02:37.720
alternate paths.

49
02:37.720 --> 02:40.280
That's sort of the key to this whole thing.

50
02:40.280 --> 02:45.720
Sending duplicate packets down the exact same path may help a little bit from

51
02:45.720 --> 02:47.020
the reliability

52
02:47.020 --> 02:53.160
standpoint, but it sure wouldn't help with the jitter or the delay.

53
02:53.160 --> 02:56.770
Another few things that hopefully are obvious, but just so we make sure we get

54
02:56.770 --> 02:58.200
them out there,

55
02:58.200 --> 03:03.280
this packet is going to be duplicated on the sending side.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:58.200 --> 03:03.280
this packet is going to be duplicated on the sending side.

56
03:03.280 --> 03:09.940
Instead of course going to be de duplicated on the receiver, we're not going to

57
03:09.940 --> 03:10.440
send

58
03:10.440 --> 03:14.520
both copies to the end device.

59
03:14.520 --> 03:18.760
Only one copy gets sent to the end device.

60
03:18.760 --> 03:23.520
Like the other things we've discussed, packet duplication is only happening on

61
03:23.520 --> 03:25.480
the WAN itself,

62
03:25.480 --> 03:27.520
not to the end points.

63
03:27.520 --> 03:31.700
And one last point, again, we've sort of already mentioned it, but the obvious
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
03:27.520 --> 03:31.700
And one last point, again, we've sort of already mentioned it, but the obvious

64
03:31.700 --> 03:32.320
downside

65
03:32.320 --> 03:36.660
here and the reason we don't want to do it for all of our traffic is clearly

66
03:36.660 --> 03:37.200
this is

67
03:37.200 --> 03:40.040
going to increase our bandwidth usage.

68
03:40.040 --> 03:43.840
We're going to be using multiple paths for all of our traffic.

69
03:43.840 --> 03:49.970
But again, the idea here is it's going to help with real time mission critical

70
03:49.970 --> 03:50.440
traffic.

71
03:50.440 --> 03:55.500
So in this video, we went over the attributes of packet duplication, which of

72
03:55.500 --> 03:56.280
course our

73
03:56.280 --> 03:59.400
main goal here is reliability.

74
03:59.400 --> 04:04.720
But along the way, we can also help with things like latency and jitter as well
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:59.400 --> 04:04.720
But along the way, we can also help with things like latency and jitter as well

75
04:04.720 --> 04:05.360
, since we

76
04:05.360 --> 04:10.720
will be preferring the packet that arrives first, forwarding that on to the end

77
04:10.720 --> 04:11.480
device.

78
04:11.480 --> 04:15.560
That means we'll always be sending the packets as soon as possible.

79
04:15.560 --> 04:19.840
When the duplicate arrives on the other path, we would simply discard it.

80
04:19.840 --> 04:24.000
Again, we only ever send one packet to the end device.

81
04:24.000 --> 04:29.230
So this is going to give us clear advantages for real time and mission critical

82
04:29.230 --> 04:30.480
applications.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
04:29.230 --> 04:30.480
applications.

83
04:30.480 --> 04:34.400
We of course don't want to do it to all of the traffic because of the increased

84
04:34.400 --> 04:35.080
bandwidth

85
04:35.080 --> 04:36.440
usage.

86
04:36.440 --> 04:41.220
But those are some of the advantages that we get with packet duplication.

87
04:41.220 --> 04:47.240
Next up, let's take a look at forward error correction, which we can use to

88
04:47.240 --> 04:48.600
recreate lost

89
04:48.600 --> 04:54.360
data or lost packets specifically without having to do a retransmission.

90
04:54.360 --> 05:04.360
[BLANK_AUDIO]