1
00:00:00,600 --> 00:00:01,770
As I mentioned before,

2
00:00:01,770 --> 00:00:04,650
we have different ways of categorizing our traffic.

3
00:00:04,650 --> 00:00:06,390
We can do it through classification,

4
00:00:06,390 --> 00:00:07,260
marking,

5
00:00:07,260 --> 00:00:09,060
utilizing congestion management,

6
00:00:09,060 --> 00:00:10,290
congestion avoidance,

7
00:00:10,290 --> 00:00:11,940
policing and shaping,

8
00:00:11,940 --> 00:00:13,470
and link efficiency.

9
00:00:13,470 --> 00:00:15,060
All these ways are ways for us

10
00:00:15,060 --> 00:00:16,890
to help implement our quality of service

11
00:00:16,890 --> 00:00:19,470
and take us from this to this.

12
00:00:19,470 --> 00:00:21,540
Now, as you can see, we want to start shaping out

13
00:00:21,540 --> 00:00:24,270
those peaks and valleys using these different mechanisms

14
00:00:24,270 --> 00:00:26,310
to give us a better quality of service.

15
00:00:26,310 --> 00:00:28,740
Now, when we look at the classification of traffic,

16
00:00:28,740 --> 00:00:31,680
traffic is going to be placed into these different categories.

17
00:00:31,680 --> 00:00:32,640
Now, this is going to be done

18
00:00:32,640 --> 00:00:34,590
based on the type of traffic that it is.

19
00:00:34,590 --> 00:00:36,750
There's email, but even inside of email,

20
00:00:36,750 --> 00:00:38,580
we have many different classes of information

21
00:00:38,580 --> 00:00:39,870
inside of an email.

22
00:00:39,870 --> 00:00:42,330
If you think about email, we have POP3 traffic,

23
00:00:42,330 --> 00:00:43,163
we have IMAP traffic,

24
00:00:43,163 --> 00:00:44,940
we have SMTP traffic,

25
00:00:44,940 --> 00:00:46,230
we have Exchange traffic.

26
00:00:46,230 --> 00:00:47,970
Those are four different types right there.

27
00:00:47,970 --> 00:00:49,230
And so we can look at the headers,

28
00:00:49,230 --> 00:00:51,210
and we can look at the packet type of information,

29
00:00:51,210 --> 00:00:53,400
and we can even use the ports that are being used,

30
00:00:53,400 --> 00:00:55,170
and then we can determine what services

31
00:00:55,170 --> 00:00:57,210
need higher or less priority.

32
00:00:57,210 --> 00:00:59,250
We can then do this not just across email,

33
00:00:59,250 --> 00:01:01,080
but across all of our traffic.

34
00:01:01,080 --> 00:01:03,030
And by doing this, this classification

35
00:01:03,030 --> 00:01:06,300
doesn't alter any bits in the frame itself or the packet.

36
00:01:06,300 --> 00:01:08,580
Instead, there is no marking inside of there.

37
00:01:08,580 --> 00:01:11,460
It's all based on the analysis of the packet itself.

38
00:01:11,460 --> 00:01:13,020
The ports and the protocols used

39
00:01:13,020 --> 00:01:15,660
and our switches and routers are going to implement QoS

40
00:01:15,660 --> 00:01:17,460
based on that information.

41
00:01:17,460 --> 00:01:20,670
Now, another way to do this is by marking that traffic.

42
00:01:20,670 --> 00:01:23,580
With this, we're going to alter the bits within the frame.

43
00:01:23,580 --> 00:01:25,950
Now, we can do this inside frames, cells, or packets,

44
00:01:25,950 --> 00:01:27,660
depending on what networks we're using,

45
00:01:27,660 --> 00:01:30,780
and this will indicate how we handle this piece of traffic.

46
00:01:30,780 --> 00:01:32,370
Our network tools are going to make decisions

47
00:01:32,370 --> 00:01:33,690
based on those markings.

48
00:01:33,690 --> 00:01:35,430
If you look at the type of service header,

49
00:01:35,430 --> 00:01:38,340
it's going to have a byte of information or 8 bits.

50
00:01:38,340 --> 00:01:41,550
The first three of that 8 bits is the IP precedence.

51
00:01:41,550 --> 00:01:44,280
The next six of that is going to be the DiffServ code point

52
00:01:44,280 --> 00:01:45,300
or DSCP.

53
00:01:45,300 --> 00:01:47,550
Now, you don't need to memorize how this type of service

54
00:01:47,550 --> 00:01:48,870
is done inside the header,

55
00:01:48,870 --> 00:01:50,220
but I do want you to remember,

56
00:01:50,220 --> 00:01:52,680
one of the ways that we can do this quality service

57
00:01:52,680 --> 00:01:55,200
is by marking and altering that traffic.

58
00:01:55,200 --> 00:01:57,420
Next, we have congestion management.

59
00:01:57,420 --> 00:01:58,800
and when a device receives traffic

60
00:01:58,800 --> 00:02:00,420
faster than it can be transmitted,

61
00:02:00,420 --> 00:02:02,550
it's going to end up buffering that extra traffic

62
00:02:02,550 --> 00:02:04,470
until bandwidth becomes available.

63
00:02:04,470 --> 00:02:06,300
This is known as queuing.

64
00:02:06,300 --> 00:02:08,340
The queuing algorithm is going to empty the packets

65
00:02:08,340 --> 00:02:10,710
in a specified sequence and amount.

66
00:02:10,710 --> 00:02:13,710
These algorithms are going to use one of three mechanisms.

67
00:02:13,710 --> 00:02:15,270
There is a weighted fair queuing,

68
00:02:15,270 --> 00:02:16,860
there's a low-latency queuing,

69
00:02:16,860 --> 00:02:18,840
or there is a weighted round-robin.

70
00:02:18,840 --> 00:02:21,300
Now, let's look at this example I have here.

71
00:02:21,300 --> 00:02:23,070
I have four categories of traffic:

72
00:02:23,070 --> 00:02:24,900
traffic 1, 2, 3, and 4.

73
00:02:24,900 --> 00:02:27,450
It really doesn't matter what kind of traffic it is.

74
00:02:27,450 --> 00:02:28,740
For our example, right now,

75
00:02:28,740 --> 00:02:30,900
we just need to know that there's four categories.

76
00:02:30,900 --> 00:02:33,300
Now, if we're going to be using a weighted fair queuing,

77
00:02:33,300 --> 00:02:36,000
how are we going to start emptying these piles of traffic?

78
00:02:36,000 --> 00:02:38,580
Well, I'm going to take one from 1, one from 2,

79
00:02:38,580 --> 00:02:40,410
one from 3, and one from 4.

80
00:02:40,410 --> 00:02:43,080
Then I'm going to go back to 1 and 2 and 3 and 4

81
00:02:43,080 --> 00:02:44,820
and we'll just keep taking turns.

82
00:02:44,820 --> 00:02:46,440
Now, is that a good mechanism?

83
00:02:46,440 --> 00:02:47,640
Well, maybe.

84
00:02:47,640 --> 00:02:49,620
It depends on what your traffic is.

85
00:02:49,620 --> 00:02:52,380
If column 1, for example, was representing VoIP traffic,

86
00:02:52,380 --> 00:02:54,390
this actually isn't a very good mechanism

87
00:02:54,390 --> 00:02:56,850
because it has us to keep waiting for our turn.

88
00:02:56,850 --> 00:03:00,240
So instead, let's look at this low-latency queuing instead.

89
00:03:00,240 --> 00:03:02,670
Based on our categories of 1, 2, 3, and 4,

90
00:03:02,670 --> 00:03:05,280
we're going to assign priorities to them.

91
00:03:05,280 --> 00:03:07,290
If 1 was a higher priority than 2,

92
00:03:07,290 --> 00:03:08,820
then all of 1 would get emptied,

93
00:03:08,820 --> 00:03:10,290
then all of 2 would get emptied,

94
00:03:10,290 --> 00:03:12,570
and then all of 3 and then all of 4.

95
00:03:12,570 --> 00:03:14,280
Now, this works well to prioritize things

96
00:03:14,280 --> 00:03:15,480
like voice and video,

97
00:03:15,480 --> 00:03:17,310
but if you're sitting in category 3 or 4,

98
00:03:17,310 --> 00:03:19,380
you might start receiving a lot of timeouts

99
00:03:19,380 --> 00:03:21,960
and drop packets because it's never going to be your turn

100
00:03:21,960 --> 00:03:24,120
and you're just going to wait and wait and wait.

101
00:03:24,120 --> 00:03:25,290
Now, the next one we have

102
00:03:25,290 --> 00:03:27,090
is called the weighted round-robin,

103
00:03:27,090 --> 00:03:28,890
and this is actually one of my favorites.

104
00:03:28,890 --> 00:03:31,200
This is kind of a hybrid between the other two.

105
00:03:31,200 --> 00:03:32,730
Now, with a weighted round-robin,

106
00:03:32,730 --> 00:03:34,500
we might say that category 1 is VoIP

107
00:03:34,500 --> 00:03:36,000
and category 2 is video.

108
00:03:36,000 --> 00:03:38,610
Category 3 is web, and category 4 is email.

109
00:03:38,610 --> 00:03:40,950
And so we might say that in the priority order,

110
00:03:40,950 --> 00:03:42,510
1 is going to be highest.

111
00:03:42,510 --> 00:03:43,797
And we're going to use a weighted round-robin

112
00:03:43,797 --> 00:03:47,070
and we might say, "We're going to take three out of category 1,

113
00:03:47,070 --> 00:03:49,410
two out of category 2, and then one out of 3

114
00:03:49,410 --> 00:03:50,580
and one out of 4."

115
00:03:50,580 --> 00:03:52,200
And we'll keep going around that way.

116
00:03:52,200 --> 00:03:56,070
We'll take 3, 2, 1, 1, 3, 2, 1, 1,

117
00:03:56,070 --> 00:03:57,240
and we keep going.

118
00:03:57,240 --> 00:04:00,210
That way, VoIP traffic is getting a lot of priority.

119
00:04:00,210 --> 00:04:02,400
Video is getting the second highest priority,

120
00:04:02,400 --> 00:04:03,930
and then we start looking at web and email

121
00:04:03,930 --> 00:04:05,130
at the bottom of the barrel,

122
00:04:05,130 --> 00:04:06,330
but they're still getting a turn

123
00:04:06,330 --> 00:04:08,040
every couple of rounds here,

124
00:04:08,040 --> 00:04:10,620
and so that way, it becomes a weighted round-robin.

125
00:04:10,620 --> 00:04:12,840
As I said, this is the quality of service mechanism

126
00:04:12,840 --> 00:04:15,780
that I really like to implement inside my own networks.

127
00:04:15,780 --> 00:04:18,570
Next, we have the idea of congestion avoidance.

128
00:04:18,570 --> 00:04:20,100
As new packets keep arriving,

129
00:04:20,100 --> 00:04:21,959
they can be discarded if the output queue

130
00:04:21,959 --> 00:04:23,490
is already filled up.

131
00:04:23,490 --> 00:04:25,800
Now, I like to think about this as a bucket.

132
00:04:25,800 --> 00:04:28,140
As you can see here, I have a cylinder on the bottom,

133
00:04:28,140 --> 00:04:30,030
and it has a minimum and a maximum.

134
00:04:30,030 --> 00:04:31,320
Now, if it's already at maximum

135
00:04:31,320 --> 00:04:33,060
and you try to put more into the bucket,

136
00:04:33,060 --> 00:04:34,860
it just overflows over the top.

137
00:04:34,860 --> 00:04:37,410
Now, to help prevent this, we have what's called the RED,

138
00:04:37,410 --> 00:04:39,300
or random early detection.

139
00:04:39,300 --> 00:04:42,180
This is used to prevent this overflow from happening for us.

140
00:04:42,180 --> 00:04:44,460
As the queue starts approaching that maximum,

141
00:04:44,460 --> 00:04:47,310
we have this possibility that discard is going to happen,

142
00:04:47,310 --> 00:04:49,920
and so we start doing, is we start dropping traffic.

143
00:04:49,920 --> 00:04:52,020
Instead of just dropping traffic randomly,

144
00:04:52,020 --> 00:04:53,700
we're going to drop it based on priority

145
00:04:53,700 --> 00:04:56,850
with the lowest traffic priority getting dropped first.

146
00:04:56,850 --> 00:04:59,430
RED is going to drop packets from the selected queues

147
00:04:59,430 --> 00:05:01,380
based on their defined limits.

148
00:05:01,380 --> 00:05:03,690
Now, I might start dropping TCP traffic first

149
00:05:03,690 --> 00:05:05,910
because I know it'll retransmit itself,

150
00:05:05,910 --> 00:05:08,580
where UDP, if you drop it, it's gone forever,

151
00:05:08,580 --> 00:05:10,590
and so I might keep that in my queue a little bit longer

152
00:05:10,590 --> 00:05:12,060
so it doesn't get dropped.

153
00:05:12,060 --> 00:05:13,230
Now, that's the idea here.

154
00:05:13,230 --> 00:05:15,600
With TCP traffic, even if I drop it,

155
00:05:15,600 --> 00:05:18,000
we're going to get that retransmission and we'll try again,

156
00:05:18,000 --> 00:05:19,740
but with UDP, if it dropped,

157
00:05:19,740 --> 00:05:20,790
you're never going to know about it

158
00:05:20,790 --> 00:05:22,650
and you're going to have loss of service.

159
00:05:22,650 --> 00:05:24,810
Now, when you're dealing with congestion avoidance,

160
00:05:24,810 --> 00:05:27,180
we're going to try to use the buffer to our advantage

161
00:05:27,180 --> 00:05:30,060
and be able to use it to help us get more bandwidth through.

162
00:05:30,060 --> 00:05:32,250
Now, when we start putting all these things together,

163
00:05:32,250 --> 00:05:34,290
we start getting into these two concepts

164
00:05:34,290 --> 00:05:36,510
known as policing and shaping.

165
00:05:36,510 --> 00:05:38,250
Policing is going to discard packets

166
00:05:38,250 --> 00:05:40,290
that exceed the configured rate limit,

167
00:05:40,290 --> 00:05:42,690
which we like to refer to as our speed limit.

168
00:05:42,690 --> 00:05:44,640
Just like if you're driving down the highway too fast,

169
00:05:44,640 --> 00:05:46,200
you're going to get pulled over by a cop

170
00:05:46,200 --> 00:05:47,460
and you're going to get a ticket.

171
00:05:47,460 --> 00:05:49,350
That's what policing is going to do for us.

172
00:05:49,350 --> 00:05:51,270
Now, we're just going to go and drop you off the network

173
00:05:51,270 --> 00:05:52,830
anytime you're going too fast.

174
00:05:52,830 --> 00:05:56,010
So drop packets are going to result in retransmissions,

175
00:05:56,010 --> 00:05:58,170
which then creates more bandwidth.

176
00:05:58,170 --> 00:06:00,120
Therefore, policing is only good

177
00:06:00,120 --> 00:06:02,220
for very high speed interfaces.

178
00:06:02,220 --> 00:06:04,650
If you're using a dial-up modem or an ISDN connection

179
00:06:04,650 --> 00:06:07,740
or even a T1, you probably don't want to use policing.

180
00:06:07,740 --> 00:06:09,930
You're much better off using our second method,

181
00:06:09,930 --> 00:06:11,610
which is known as shaping.

182
00:06:11,610 --> 00:06:13,860
Now, what shaping is going to do for us

183
00:06:13,860 --> 00:06:15,030
is it's going to allow the buffer

184
00:06:15,030 --> 00:06:17,880
to delay traffic from exceeding the configured rate.

185
00:06:17,880 --> 00:06:20,640
Instead of dropping those packets like we did in policing,

186
00:06:20,640 --> 00:06:22,560
we're just going to hold them in our buffer.

187
00:06:22,560 --> 00:06:25,170
Then, when it's empty and there's space available,

188
00:06:25,170 --> 00:06:27,660
we're going to start pushing it over that empty space

189
00:06:27,660 --> 00:06:29,790
and start shaping out the packets.

190
00:06:29,790 --> 00:06:32,880
This is why we call it shaping or packet shaping.

191
00:06:32,880 --> 00:06:35,070
Now, you can see what this looks like here on the screen.

192
00:06:35,070 --> 00:06:36,450
I have traffic at the top,

193
00:06:36,450 --> 00:06:38,940
and you'll see all those jagged lines going down.

194
00:06:38,940 --> 00:06:40,890
Now, what really happens here in your network

195
00:06:40,890 --> 00:06:42,540
is there's this high period of time

196
00:06:42,540 --> 00:06:43,920
and there's low periods of time

197
00:06:43,920 --> 00:06:46,500
because not everything is happening all the time

198
00:06:46,500 --> 00:06:47,880
in an equal amount.

199
00:06:47,880 --> 00:06:51,120
If we do policing, all we did was chop off the tops,

200
00:06:51,120 --> 00:06:52,920
which gave us more retransmissions,

201
00:06:52,920 --> 00:06:54,150
and with shaping instead,

202
00:06:54,150 --> 00:06:56,760
we're going to start filling in from the bottom from our queue,

203
00:06:56,760 --> 00:06:58,950
so it keeps up there right towards the speed limit

204
00:06:58,950 --> 00:07:00,390
without going over it.

205
00:07:00,390 --> 00:07:02,100
Again, shaping does a better job

206
00:07:02,100 --> 00:07:03,750
of maximizing your bandwidth,

207
00:07:03,750 --> 00:07:06,810
especially on slow speed interfaces like a T1 connection,

208
00:07:06,810 --> 00:07:10,380
a dial-up, satellite connections, or ISDN.

209
00:07:10,380 --> 00:07:11,910
The last thing we need to talk about here

210
00:07:11,910 --> 00:07:13,500
is link efficiency.

211
00:07:13,500 --> 00:07:15,150
Now, there's a couple of things we need to mention

212
00:07:15,150 --> 00:07:17,100
in regard to link efficiency,

213
00:07:17,100 --> 00:07:19,080
the first of which is compression.

214
00:07:19,080 --> 00:07:20,640
To get the most out of your link,

215
00:07:20,640 --> 00:07:22,920
you want to make it the most efficient possible,

216
00:07:22,920 --> 00:07:25,560
and so to do that, we can compress our packets.

217
00:07:25,560 --> 00:07:27,870
If we take our payloads and we compress it down,

218
00:07:27,870 --> 00:07:30,300
that's going to conserve bandwidth because it's less ones

219
00:07:30,300 --> 00:07:32,640
and zeros that need to go across the wire.

220
00:07:32,640 --> 00:07:34,830
VoIP is a great thing that you can compress

221
00:07:34,830 --> 00:07:36,840
because there is so much extra space

222
00:07:36,840 --> 00:07:39,210
that's wasted inside of voice traffic.

223
00:07:39,210 --> 00:07:40,950
VoIP payloads can actually be reduced

224
00:07:40,950 --> 00:07:43,650
by up to 50% of their original space.

225
00:07:43,650 --> 00:07:46,590
We could take it down from 40 bytes down to 20 bytes

226
00:07:46,590 --> 00:07:48,030
by using compression.

227
00:07:48,030 --> 00:07:50,730
If you think that's good, look at the VoIP header.

228
00:07:50,730 --> 00:07:53,250
I can compress the VoIP header down from 90

229
00:07:53,250 --> 00:07:55,770
or 95% of its original value.

230
00:07:55,770 --> 00:07:57,390
I could take it from 40 bytes

231
00:07:57,390 --> 00:07:59,790
down to just two to four bytes.

232
00:07:59,790 --> 00:08:04,740
To do this, we use something called compressed RTP, or CRTP.

233
00:08:04,740 --> 00:08:06,810
Now, when I have the original VoIP payload,

234
00:08:06,810 --> 00:08:09,330
as you can see here, I have an IP address,

235
00:08:09,330 --> 00:08:12,900
I have UDP as my packet type, and I have RTP for its header,

236
00:08:12,900 --> 00:08:14,790
and then I have my voice payload.

237
00:08:14,790 --> 00:08:18,600
I can compress all of that down into just an CRTP,

238
00:08:18,600 --> 00:08:20,760
which consolidates the IP, the UDP,

239
00:08:20,760 --> 00:08:23,130
and the RTP all together into one.

240
00:08:23,130 --> 00:08:25,290
The voice payload can also be squeezed down

241
00:08:25,290 --> 00:08:27,060
to about half of its size.

242
00:08:27,060 --> 00:08:28,650
Now, you're not going to notice a big difference

243
00:08:28,650 --> 00:08:30,840
in your audio quality either by doing this.

244
00:08:30,840 --> 00:08:33,030
This can be utilized on slower speed links

245
00:08:33,030 --> 00:08:34,830
to make the most of your limited bandwidth,

246
00:08:34,830 --> 00:08:36,299
and it's not just for VoIP.

247
00:08:36,299 --> 00:08:38,429
You can do this with other types of data too.

248
00:08:38,429 --> 00:08:40,559
Compression is a great thing to use.

249
00:08:40,559 --> 00:08:42,960
They have devices out there called WAN accelerators

250
00:08:42,960 --> 00:08:45,300
that focus specifically on compressing your data

251
00:08:45,300 --> 00:08:47,580
before sending it out your way in link.

252
00:08:47,580 --> 00:08:51,060
The last thing I want to talk about here is what we call LFI,

253
00:08:51,060 --> 00:08:52,140
which is another method

254
00:08:52,140 --> 00:08:54,540
to make more efficient use of your links.

255
00:08:54,540 --> 00:08:57,930
This is known as link fragmentation and interleaving.

256
00:08:57,930 --> 00:09:00,870
Now, what this does is if you have a really big packet,

257
00:09:00,870 --> 00:09:02,460
it'll start chopping those up

258
00:09:02,460 --> 00:09:04,830
and take those big packets and fragment them,

259
00:09:04,830 --> 00:09:07,740
and then interleave smaller packets in between them.

260
00:09:07,740 --> 00:09:09,630
This way, it's going to allow you to utilize

261
00:09:09,630 --> 00:09:11,070
those slower speed links

262
00:09:11,070 --> 00:09:13,170
to make the most of your limited bandwidth.

263
00:09:13,170 --> 00:09:15,000
Notice here I have three voice packets

264
00:09:15,000 --> 00:09:16,830
and one big chunk of data.

265
00:09:16,830 --> 00:09:19,380
Now, what the router would do is it's going to chop up

266
00:09:19,380 --> 00:09:21,480
and put that one small voice piece

267
00:09:21,480 --> 00:09:22,920
and then one small data piece,

268
00:09:22,920 --> 00:09:25,830
and then one small voice piece and one small data piece.

269
00:09:25,830 --> 00:09:28,680
That way the voice doesn't suffer from huge latency

270
00:09:28,680 --> 00:09:31,470
by waiting for that big piece of data to go through first.

271
00:09:31,470 --> 00:09:33,660
By doing this fragmentation and interleaving,

272
00:09:33,660 --> 00:09:36,210
it allows you to get some of that high priority traffic out

273
00:09:36,210 --> 00:09:38,610
in between those larger data structures as well.