WEBVTT

1
00:00.000 --> 00:09.250
So, as I'm sure you're aware, TCP, the reliable transport in the TCP/IP suite,

2
00:09.250 --> 00:09.400
has

3
00:09.400 --> 00:12.000
been around for quite some time.

4
00:12.000 --> 00:15.080
In fact, it was developed back in the 1970s.

5
00:15.080 --> 00:18.750
So it's been around for a really long time, and while quite frankly it's done a

6
00:18.750 --> 00:19.080
really

7
00:19.080 --> 00:23.120
good job, because we've had really no reason to replace it.

8
00:23.120 --> 00:28.440
However, that doesn't mean things can't be optimized and changed over time.

9
00:28.440 --> 00:31.870
People have different ideas how to handle things, and we can implement those
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:28.440 --> 00:31.870
People have different ideas how to handle things, and we can implement those

10
00:31.870 --> 00:32.600
things without

11
00:32.600 --> 00:34.960
completely breaking the protocol.

12
00:34.960 --> 00:39.000
That's the idea that we're going to be discussing in this video.

13
00:39.000 --> 00:44.280
Changes in optimizations that we can make to TCP to, well, let's just say help

14
00:44.280 --> 00:44.640
it do

15
00:44.640 --> 00:46.200
its job better.

16
00:46.200 --> 00:50.810
Of course, we can't break TCP in the process, as other devices on the network

17
00:50.810 --> 00:51.440
may not be

18
00:51.440 --> 00:53.560
aware of these optimizations.

19
00:53.560 --> 00:57.600
But we have to make sure that these optimizations are just going to be, for

20
00:57.600 --> 00:59.000
example, just between

21
00:59.000 --> 01:01.440
SD-WAN-edge devices.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:59.000 --> 01:01.440
SD-WAN-edge devices.

22
01:01.440 --> 01:03.360
And that's what we're going to be talking about.

23
01:03.360 --> 01:08.080
What we actually do between those two devices, to optimize TCP.

24
01:08.080 --> 01:12.570
So that said, let's jump in and take a look at the different TCP optimization

25
01:12.570 --> 01:13.200
options we

26
01:13.200 --> 01:18.240
have available in App QOE.

27
01:18.240 --> 01:22.930
So let's begin here with just a little bit of a history, because SD-WAN is

28
01:22.930 --> 01:24.160
actually not

29
01:24.160 --> 01:29.280
Cisco's only technology that uses TCP optimization.

30
01:29.280 --> 01:33.100
And possibly in your environment, you're not using SD-WAN, so you should
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:29.280 --> 01:33.100
And possibly in your environment, you're not using SD-WAN, so you should

31
01:33.100 --> 01:34.040
probably at least

32
01:34.040 --> 01:36.840
be aware that there are other options.

33
01:36.840 --> 01:42.560
So TCP optimization is available on a couple of the different platforms.

34
01:42.560 --> 01:48.290
First is Cisco Wide Area Acceleration Service, which I usually just refer to as

35
01:48.290 --> 01:48.960
WAS.

36
01:48.960 --> 01:53.040
This uses an algorithm called Cubic.

37
01:53.040 --> 01:57.000
And that's actually not an acronym, that's just the name of it.

38
01:57.000 --> 02:02.170
But it does several things like caching and several other things to help with
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

38
01:57.000 --> 02:02.170
But it does several things like caching and several other things to help with

39
02:02.170 --> 02:03.720
TCP optimization.

40
02:03.720 --> 02:09.720
We also have Viptela OS itself, which of course is what SD-WAN is built on.

41
02:09.720 --> 02:15.680
So for the Viptela OS, it actually uses BBR-1.

42
02:15.680 --> 02:20.020
And if you're not familiar with BBR, let's just go ahead and bring up our next

43
02:20.020 --> 02:20.520
platform

44
02:20.520 --> 02:24.560
here, because I did put in what BBR is for.

45
02:24.560 --> 02:34.150
So BBR is actually bottleneck bandwidth and round-trip, well, propagation time,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:24.560 --> 02:34.150
So BBR is actually bottleneck bandwidth and round-trip, well, propagation time,

46
02:34.150 --> 02:34.960
but for

47
02:34.960 --> 02:39.320
whatever reason, propagation time didn't quite make it into the acronym.

48
02:39.320 --> 02:43.040
So it's sort of an acronym.

49
02:43.040 --> 02:48.600
The BBR sort of makes sense, the bottleneck bandwidth and round-trip.

50
02:48.600 --> 02:53.980
I don't know why they didn't just make it BBR-PT and include the propagation

51
02:53.980 --> 02:54.640
time, but

52
02:54.640 --> 02:55.640
they didn't.

53
02:55.640 --> 02:59.430
So we have to remove propagation time, that's not part of the algorithm, but it

54
02:59.430 --> 02:59.840
is part

55
02:59.840 --> 03:01.240
of the name.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:59.840 --> 03:01.240
of the name.

56
03:01.240 --> 03:04.640
And it was just for reference here created by Google.

57
03:04.640 --> 03:08.040
This is of course just the method that we're using.

58
03:08.040 --> 03:13.090
And with app QOE, which of course is our current topic, specifically running on

59
03:13.090 --> 03:14.640
iOS Xe, we are

60
03:14.640 --> 03:17.160
using BBR version two.

61
03:17.160 --> 03:21.170
Now, we're not going to get into all the details of the difference between BBR-

62
03:21.170 --> 03:21.640
1 and

63
03:21.640 --> 03:22.640
BBR-2.

64
03:22.640 --> 03:26.480
It's not really relevant for this course, but naturally there have been

65
03:26.480 --> 03:27.320
progressions

66
03:27.320 --> 03:30.480
in BBR creating version two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
03:27.320 --> 03:30.480
in BBR creating version two.

67
03:30.480 --> 03:34.440
And that's what we're going to be using in app QOE.

68
03:34.440 --> 03:40.850
Our next let's talk about what the aspects of TCP optimization in app QOE

69
03:40.850 --> 03:42.240
really are.

70
03:42.240 --> 03:44.800
So what are those aspects?

71
03:44.800 --> 03:48.360
The first is TCP window scaling.

72
03:48.360 --> 03:53.640
Now this feature I did mention during our overview video, and really what this

73
03:53.640 --> 03:54.440
is talking

74
03:54.440 --> 04:00.680
about is increasing the TCP receive window size.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:54.440 --> 04:00.680
about is increasing the TCP receive window size.

75
04:00.680 --> 04:08.280
Remember the TCP, if you have a sender and a receiver, TCP will send multiple

76
04:08.280 --> 04:09.160
packets

77
04:09.160 --> 04:12.480
before it waits for an acknowledgment.

78
04:12.480 --> 04:15.560
We don't want to acknowledge every single packet.

79
04:15.560 --> 04:17.920
That would be incredibly inefficient.

80
04:17.920 --> 04:24.200
Now of course, the more reliable the network is, the larger the window or the

81
04:24.200 --> 04:25.080
number of

82
04:25.080 --> 04:30.720
packets that we're going to send before we expect an acknowledgment is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
04:25.080 --> 04:30.720
packets that we're going to send before we expect an acknowledgment is going to

83
04:30.720 --> 04:31.080
be.

84
04:31.080 --> 04:36.600
But of course, the downside to a large window size is if for whatever reason

85
04:36.600 --> 04:38.080
this acknowledgment

86
04:38.080 --> 04:42.840
were to fail, then we have to resend the whole window.

87
04:42.840 --> 04:47.090
So there are of course pros and cons to everything we're going to discuss here,

88
04:47.090 --> 04:48.160
but as networks

89
04:48.160 --> 04:54.170
have gotten more and more reliable over the years, the size of this window has

90
04:54.170 --> 04:54.680
gotten

91
04:54.680 --> 04:56.800
considerably larger.

92
04:56.800 --> 05:01.720
And that's been relatively safe because we really haven't had that many issues
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:56.800 --> 05:01.720
And that's been relatively safe because we really haven't had that many issues

93
05:01.720 --> 05:02.160
on most

94
05:02.160 --> 05:03.600
networks.

95
05:03.600 --> 05:07.960
The next feature is fast packet recovery.

96
05:07.960 --> 05:12.400
This feature simply retransmits the lost packets.

97
05:12.400 --> 05:16.810
Again, if we lose any packets over here in our transmission, it's going to res

98
05:16.810 --> 05:17.440
end those

99
05:17.440 --> 05:21.000
lost packets much quicker.

100
05:21.000 --> 05:25.640
Next is selective acknowledgments or SACs.

101
05:25.640 --> 05:30.210
Now this one is a little bit more interesting because let's go back up here to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:25.640 --> 05:30.210
Now this one is a little bit more interesting because let's go back up here to

102
05:30.210 --> 05:31.320
our example.

103
05:31.320 --> 05:36.890
Let's say for a moment that this was say, for example, packet one, packet two,

104
05:36.890 --> 05:37.240
packet

105
05:37.240 --> 05:38.680
three.

106
05:38.680 --> 05:44.680
And during this transmission, this packet failed to arrive.

107
05:44.680 --> 05:50.700
Now what would normally happen in this case is when the ACK is sent back to the

108
05:50.700 --> 05:51.440
sender,

109
05:51.440 --> 05:55.600
the sender is not going to like this acknowledgment because it's not going to

110
05:55.600 --> 05:56.680
be acknowledging

111
05:56.680 --> 05:59.040
the correct number of packets.

112
05:59.040 --> 06:05.810
And as we just said a moment ago, that causes that entire window to be retrans
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

112
05:59.040 --> 06:05.810
And as we just said a moment ago, that causes that entire window to be retrans

113
06:05.810 --> 06:06.320
mitted.

114
06:06.320 --> 06:11.160
Selective acknowledgments allow the receiver to instead just send a blanket

115
06:11.160 --> 06:12.360
acknowledgement

116
06:12.360 --> 06:19.360
to instead say, well, I received packets one and three.

117
06:19.360 --> 06:24.800
And all we have to do then is send the packets that were not received.

118
06:24.800 --> 06:29.630
So again, the way we're wording that here is it allows the receiver to inform

119
06:29.630 --> 06:30.520
the sender.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
06:29.630 --> 06:30.520
the sender.

120
06:30.520 --> 06:35.030
That's the important part about the segments that have been successfully

121
06:35.030 --> 06:35.880
received.

122
06:35.880 --> 06:39.720
So I only have to retransmit the ones that failed.

123
06:39.720 --> 06:44.320
Another cool feature we have is congestion avoidance algorithms.

124
06:44.320 --> 06:50.180
Very simple idea here is before all of the interfaces on our network get backed

125
06:50.180 --> 06:51.080
up, we're

126
06:51.080 --> 06:54.440
going to tell the sender to slow down.

127
06:54.440 --> 06:56.280
So that's the whole idea here.

128
06:56.280 --> 07:00.960
We're going to detect any congestion on the network, hopefully early, and we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:56.280 --> 07:00.960
We're going to detect any congestion on the network, hopefully early, and we

129
07:00.960 --> 07:01.680
adjust the

130
07:01.680 --> 07:03.720
transmission rate.

131
07:03.720 --> 07:06.160
Keep in mind what the alternative is.

132
07:06.160 --> 07:11.580
If the sender just keeps sending faster than the receiver can receive or some

133
07:11.580 --> 07:12.280
device in

134
07:12.280 --> 07:16.280
the path can forward that traffic, what's the side effect?

135
07:16.280 --> 07:20.390
Well, the side effect is going to go up to our example up here where we start

136
07:20.390 --> 07:20.960
dropping

137
07:20.960 --> 07:23.600
packets somewhere in the path.

138
07:23.600 --> 07:26.640
Maybe an interface transmit queue gets full.

139
07:26.640 --> 07:30.040
There's only a finite amount of queuing that can happen on our network.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
07:26.640 --> 07:30.040
There's only a finite amount of queuing that can happen on our network.

140
07:30.040 --> 07:32.760
Therefore traffic drops.

141
07:32.760 --> 07:38.850
More better to adjust that transmit rate and get the traffic to slow down

142
07:38.850 --> 07:39.680
before it gets

143
07:39.680 --> 07:40.680
dropped.

144
07:40.680 --> 07:45.360
We're also going to implement methods of bandwidth utilization.

145
07:45.360 --> 07:50.050
And again, the idea here is we want to make sure that the network's resources

146
07:50.050 --> 07:50.480
are being

147
07:50.480 --> 07:55.880
used efficiently, making sure that the correct traffic gets sent when it needs

148
07:55.880 --> 07:56.320
to.

149
07:56.320 --> 08:01.060
For example, prioritizing interactive traffic above non-interactive traffic,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:56.320 --> 08:01.060
For example, prioritizing interactive traffic above non-interactive traffic,

150
08:01.060 --> 08:01.680
that sort of

151
08:01.680 --> 08:06.870
thing to make sure that the important traffic gets through for a better end

152
08:06.870 --> 08:08.320
user experience.

153
08:08.320 --> 08:13.880
Cisco actually lists another feature here called reduced latency.

154
08:13.880 --> 08:19.920
But if you notice what it says, it says it reduces retransmission timeouts and

155
08:19.920 --> 08:20.760
improves

156
08:20.760 --> 08:22.960
the handling of acknowledgments.

157
08:22.960 --> 08:28.580
Well, quite honestly, that's really sort of the same thing as the fast packet

158
08:28.580 --> 08:29.360
recovery

159
08:29.360 --> 08:31.880
and the selective acknowledgments.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
08:29.360 --> 08:31.880
and the selective acknowledgments.

160
08:31.880 --> 08:36.720
So reduced latency is sort of using those features together to make sure that

161
08:36.720 --> 08:37.200
we're

162
08:37.200 --> 08:42.840
using our bandwidth and reducing our latency as much as possible.

163
08:42.840 --> 08:48.270
Now the interesting thing about all of this is something has to manage all of

164
08:48.270 --> 08:48.920
this TCP

165
08:48.920 --> 08:50.840
optimization.

166
08:50.840 --> 08:55.900
And the answer to that, the way we handle it in SD-WAN, is we use a node and

167
08:55.900 --> 08:56.840
controller

168
08:56.840 --> 09:01.290
model where of course the controller is the one making the decisions and the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:56.840 --> 09:01.290
model where of course the controller is the one making the decisions and the

169
09:01.290 --> 09:01.880
node are

170
09:01.880 --> 09:07.040
the devices actually doing the TCP optimization methods.

171
09:07.040 --> 09:12.540
Now of course, that means that the WAN edge devices, the actual routers, will

172
09:12.540 --> 09:13.640
be the service

173
09:13.640 --> 09:14.640
nodes.

174
09:14.640 --> 09:20.220
Now, one of those can also be the controller node and it can actually be one of

175
09:20.220 --> 09:21.000
the same

176
09:21.000 --> 09:22.680
devices.

177
09:22.680 --> 09:28.640
So again, you're either going to have one or more of these edge devices being

178
09:28.640 --> 09:29.560
the actual

179
09:29.560 --> 09:30.840
controller.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:29.560 --> 09:30.840
controller.

180
09:30.840 --> 09:34.990
But just because it's controlling the TCP optimization doesn't mean it's

181
09:34.990 --> 09:35.760
actually in

182
09:35.760 --> 09:40.240
charge of anything from the perspective of management.

183
09:40.240 --> 09:46.640
We manage or SD-WAN manager still handles all of the configuration.

184
09:46.640 --> 09:51.960
So the administrative level management is still being handled in our graphical

185
09:51.960 --> 09:52.720
interface

186
09:52.720 --> 09:56.400
in either V-Manage or SD-WAN manager.

187
09:56.400 --> 10:01.910
One last thing to discuss is how the communication actually works between the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
09:56.400 --> 10:01.910
One last thing to discuss is how the communication actually works between the

188
10:01.910 --> 10:03.480
service node and

189
10:03.480 --> 10:05.840
the service controller.

190
10:05.840 --> 10:12.610
The answer to this is we have to have an underlay meaning VPN0 connection to

191
10:12.610 --> 10:15.360
the service controller.

192
10:15.360 --> 10:20.710
This is going to create what's called an app nav tunnel that it's going to use

193
10:20.710 --> 10:22.160
for communication

194
10:22.160 --> 10:26.480
for controlling the TCP optimization.

195
10:26.480 --> 10:31.810
So in this video, we jumped in and we looked at the different TCP optimization
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
10:26.480 --> 10:31.810
So in this video, we jumped in and we looked at the different TCP optimization

196
10:31.810 --> 10:32.600
options that

197
10:32.600 --> 10:36.200
are available, well, mostly in SD-WAN.

198
10:36.200 --> 10:41.690
But we also mentioned that they're available in WaaS, the Wide Area Acceler

199
10:41.690 --> 10:42.840
ation Service

200
10:42.840 --> 10:46.360
and in the Viptela OS in general.

201
10:46.360 --> 10:54.120
But our main focus of course was on BBR2 and the options available in SD-WAN.

202
10:54.120 --> 10:59.490
Next up, let's take a look at data redundancy elimination or deduplication

203
10:59.490 --> 11:01.000
sometimes referred
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
10:59.490 --> 11:01.000
sometimes referred

204
11:01.000 --> 11:03.440
to as dedupl of our data.

205
11:03.440 --> 11:13.340
[BLANK_AUDIO]