WEBVTT

1
00:00.000 --> 00:09.330
So let's begin with an overview of application quality of experience or app QOE

2
00:09.330 --> 00:10.000
.

3
00:10.000 --> 00:11.000
What is it?

4
00:11.000 --> 00:13.000
What features does it bring to the table?

5
00:13.000 --> 00:18.170
And most importantly, why we want it in our SDWAN environment when we're

6
00:18.170 --> 00:18.600
talking about

7
00:18.600 --> 00:20.880
optimizing WAN links.

8
00:20.880 --> 00:25.450
So we'll talk about the different features that it has in this video just again

9
00:25.450 --> 00:25.840
as an

10
00:25.840 --> 00:31.150
overview will of course be jumping into many of these in the upcoming videos as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:25.840 --> 00:31.150
overview will of course be jumping into many of these in the upcoming videos as

11
00:31.150 --> 00:31.720
we jump

12
00:31.720 --> 00:32.720
into more detail.

13
00:32.720 --> 00:40.080
But let's go ahead and get started with just an overview of the basic features.

14
00:40.080 --> 00:44.310
So the first things we're going to look at here are things directed

15
00:44.310 --> 00:45.960
specifically at WAN

16
00:45.960 --> 00:47.680
optimization.

17
00:47.680 --> 00:52.850
Things that we would do on a wide area network as opposed to a LAN or a local

18
00:52.850 --> 00:54.160
area network.

19
00:54.160 --> 00:57.560
Some of those things include for example compression.

20
00:57.560 --> 01:02.670
Now compression is actually sort of an interesting topic even when it comes to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:57.560 --> 01:02.670
Now compression is actually sort of an interesting topic even when it comes to

21
01:02.670 --> 01:03.200
the WAN.

22
01:03.200 --> 01:06.160
So first what are we really talking about?

23
01:06.160 --> 01:12.100
Well if you compress the data what you're going to be doing is sending less

24
01:12.100 --> 01:13.240
data across

25
01:13.240 --> 01:14.640
that circuit.

26
01:14.640 --> 01:19.320
Of course if you're sending less data well then it can be transmitted quicker.

27
01:19.320 --> 01:21.920
But here's where we have to be careful.

28
01:21.920 --> 01:26.860
Then a compression to improve performance is sort of one of those things where

29
01:26.860 --> 01:27.480
you have

30
01:27.480 --> 01:30.760
to do a very very careful balancing act.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:27.480 --> 01:30.760
to do a very very careful balancing act.

31
01:30.760 --> 01:35.410
You have to make sure that the time it takes to do the compression and of

32
01:35.410 --> 01:37.280
course the decompression

33
01:37.280 --> 01:42.990
on the other side actually takes less time than just transmitting the full

34
01:42.990 --> 01:43.800
amount of

35
01:43.800 --> 01:45.720
data to begin with.

36
01:45.720 --> 01:51.290
And to be honest with you over the years this has sort of been a flip-flop as

37
01:51.290 --> 01:51.840
computers

38
01:51.840 --> 01:57.730
and CPUs get faster and then wide area connections get faster and then CPUs get

39
01:57.730 --> 01:58.680
faster.

40
01:58.680 --> 02:01.760
So there's sort of always been this back and forth.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:58.680 --> 02:01.760
So there's sort of always been this back and forth.

41
02:01.760 --> 02:06.760
Is it actually faster to compress the data than it is to just send it without

42
02:06.760 --> 02:08.200
the compression.

43
02:08.200 --> 02:11.640
And again this is that balancing act we have to keep an eye on.

44
02:11.640 --> 02:16.000
Of course it's about CPU versus the speed of the link.

45
02:16.000 --> 02:20.070
The faster the link of course the less benefit you're going to get from

46
02:20.070 --> 02:21.080
compression.

47
02:21.080 --> 02:25.560
So you might just be adding more time to the overall transport if you do

48
02:25.560 --> 02:26.800
compression.

49
02:26.800 --> 02:31.240
So basically what we need to do is just keep in mind the balance between doing
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:26.800 --> 02:31.240
So basically what we need to do is just keep in mind the balance between doing

50
02:31.240 --> 02:32.120
compression

51
02:32.120 --> 02:36.680
or not doing compression based on the speed of the link.

52
02:36.680 --> 02:41.840
The thing we can do for optimization is data deduplication.

53
02:41.840 --> 02:46.640
This simply means we're not going to be sending redundant data across the WAN

54
02:46.640 --> 02:47.240
link.

55
02:47.240 --> 02:52.560
Hopefully for obvious reasons that's usually a bad thing.

56
02:52.560 --> 02:58.960
We don't want multiple copies of the exact same data going across the same link

57
02:58.960 --> 02:58.960
.

58
02:58.960 --> 03:02.800
However there are times we actually want to do the opposite.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:58.960 --> 03:02.800
However there are times we actually want to do the opposite.

59
03:02.800 --> 03:05.840
And as we go through this skill we're going to find out that one of the

60
03:05.840 --> 03:06.640
features of app

61
03:06.640 --> 03:14.720
QOE is to actually do packet replication and therefore send multiple copies.

62
03:14.720 --> 03:20.040
So generally speaking we don't want redundancy with our data like this.

63
03:20.040 --> 03:23.400
However there are times we may choose to use it.

64
03:23.400 --> 03:26.400
We'll talk more about that a little later.

65
03:26.400 --> 03:31.000
Another option is just some overall TCP optimization where we're really
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:26.400 --> 03:31.000
Another option is just some overall TCP optimization where we're really

66
03:31.000 --> 03:32.720
focusing on the performance

67
03:32.720 --> 03:38.530
of TCP doing things like adjusting window size and we can do something called

68
03:38.530 --> 03:39.000
selective

69
03:39.000 --> 03:40.240
acknowledgments.

70
03:40.240 --> 03:44.000
Again we'll be hitting this in more detail coming up.

71
03:44.000 --> 03:50.120
But TCP optimization is one of the features that we can use in app QOE.

72
03:50.120 --> 03:54.880
Also following under this umbrella is your application aware routing.

73
03:54.880 --> 03:58.700
Now we have discussed this previously in the course but I want to make sure we

74
03:58.700 --> 03:59.240
include

75
03:59.240 --> 04:03.640
it here because it does fall under the app QOE umbrella.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:59.240 --> 04:03.640
it here because it does fall under the app QOE umbrella.

76
04:03.640 --> 04:10.480
And of course what this does is it allows us to use deep packet inspection or D

77
04:10.480 --> 04:10.520
PI to

78
04:10.520 --> 04:15.600
give us control over how each of the different applications is treated.

79
04:15.600 --> 04:18.160
In other words should it be compressed.

80
04:18.160 --> 04:23.360
Does it need data deduplication or should this do packet replication?

81
04:23.360 --> 04:26.850
So we have to choose how each of the different applications are going to be

82
04:26.850 --> 04:27.680
treated in app

83
04:27.680 --> 04:28.680
QOE.

84
04:28.680 --> 04:33.280
Of course the first part of that is being able to identify it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:28.680 --> 04:33.280
Of course the first part of that is being able to identify it.

85
04:33.280 --> 04:38.200
Also we need to be able to send it down the most appropriate path.

86
04:38.200 --> 04:42.320
We want that to change based on real time conditions.

87
04:42.320 --> 04:45.790
Things change on networks and we want to make sure that our environment is

88
04:45.790 --> 04:46.600
going to change

89
04:46.600 --> 04:50.960
dynamically and application aware routing can do that.

90
04:50.960 --> 04:57.640
So up next we have a topic called traffic prioritization and QOS.

91
04:57.640 --> 05:01.080
At the end of the day traffic prioritization is QOS but we are sort of going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:57.640 --> 05:01.080
At the end of the day traffic prioritization is QOS but we are sort of going to

92
05:01.080 --> 05:01.640
break this

93
05:01.640 --> 05:06.600
up to talk about application based prioritization.

94
05:06.600 --> 05:11.340
And again this is going to be based on the applications priority where

95
05:11.340 --> 05:12.560
traditional QOS

96
05:12.560 --> 05:19.210
or quality of service is generally managing that bandwidth based on the type of

97
05:19.210 --> 05:20.280
traffic.

98
05:20.280 --> 05:25.680
Now quite commonly those are going to be very similar topics.

99
05:25.680 --> 05:30.880
The type of traffic may be directly related to the application.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
05:25.680 --> 05:30.880
The type of traffic may be directly related to the application.

100
05:30.880 --> 05:32.280
Maybe it's not.

101
05:32.280 --> 05:36.470
Again the big difference here is the application based prioritization is going

102
05:36.470 --> 05:39.040
to be doing DPI

103
05:39.040 --> 05:45.030
where the standard QOS is simply going to be looking at different fields in the

104
05:45.030 --> 05:46.520
IP header.

105
05:46.520 --> 05:51.900
So again that may be specific TCP or UDP port numbers, sources or destinations

106
05:51.900 --> 05:53.400
for IP addresses

107
05:53.400 --> 05:54.600
and so on.

108
05:54.600 --> 05:58.740
So maybe it's just traffic from a specific subnet where the application based

109
05:58.740 --> 05:59.720
prioritization

110
05:59.720 --> 06:04.680
is going to be strictly based on a particular application.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
05:59.720 --> 06:04.680
is going to be strictly based on a particular application.

111
06:04.680 --> 06:08.720
One of the other big topics we're going to want to talk about in this skill is

112
06:08.720 --> 06:09.040
forward

113
06:09.040 --> 06:12.220
error correction or FEC.

114
06:12.220 --> 06:16.640
This is in a way, RAID for your network.

115
06:16.640 --> 06:22.160
If you're familiar with RAID specifically something like RAID 5 on storage encl

116
06:22.160 --> 06:23.720
osures we use something

117
06:23.720 --> 06:30.040
called parity to do error correction in real time in the event of a failure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
06:23.720 --> 06:30.040
called parity to do error correction in real time in the event of a failure.

118
06:30.040 --> 06:33.270
And we're going to be basically doing the same thing here for our real time

119
06:33.270 --> 06:33.880
traffic.

120
06:33.880 --> 06:38.510
Again we'll be talking in much more detail on this coming up but forward error

121
06:38.510 --> 06:39.280
correction

122
06:39.280 --> 06:44.920
is a great feature for our WAN that we get from app QOE.

123
06:44.920 --> 06:48.810
So in this video we just jumped in and talked about some of the features that

124
06:48.810 --> 06:49.880
we have available

125
06:49.880 --> 06:54.000
with app QOE to help optimize the WAN.

126
06:54.000 --> 06:57.410
Of course a lot of these we're going to be talking about in more detail in the

127
06:57.410 --> 06:57.960
upcoming

128
06:57.960 --> 07:03.320
video starting with TCP optimization which we're going to jump into next.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:57.960 --> 07:03.320
video starting with TCP optimization which we're going to jump into next.

129
07:03.320 --> 07:12.480
[BLANK_AUDIO]