WEBVTT

1
00:00.000 --> 00:07.480
A rule in networking is that applications were not all created equal.

2
00:07.480 --> 00:11.680
We don't have this sense in our modern networks nor should we.

3
00:11.680 --> 00:16.200
Because if we think about the network facilitating all kinds of communications,

4
00:16.200 --> 00:16.920
we have users

5
00:16.920 --> 00:22.680
trying to do their work, they're trying to communicate to servers, but we also

6
00:22.680 --> 00:23.940
have phones

7
00:23.940 --> 00:29.160
out here and so users are trying to have phone calls with one another.

8
00:29.160 --> 00:33.770
Meanwhile, we have somebody on their phone over here trying to stream maybe
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:29.160 --> 00:33.770
Meanwhile, we have somebody on their phone over here trying to stream maybe

9
00:33.770 --> 00:34.240
some kind

10
00:34.240 --> 00:37.000
of movie from the internet.

11
00:37.000 --> 00:41.550
And then we've got users who are trying to maybe send major large files across

12
00:41.550 --> 00:42.800
the network.

13
00:42.800 --> 00:46.240
We see we have all kinds of applications.

14
00:46.240 --> 00:51.920
And so we do see some number of important, maybe we'd call them critical types

15
00:51.920 --> 00:53.400
of applications,

16
00:53.400 --> 00:55.640
but those even come in different forms.

17
00:55.640 --> 01:01.640
For example, we've got time sensitive applications, meaning we care how long it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:55.640 --> 01:01.640
For example, we've got time sensitive applications, meaning we care how long it

18
01:01.640 --> 01:02.680
takes for the

19
01:02.680 --> 01:05.000
packets to make it across the network.

20
01:05.000 --> 01:10.950
So we think about voice and video here being usually two of the primary drivers

21
01:10.950 --> 01:11.800
for quality

22
01:11.800 --> 01:13.760
of service conversations.

23
01:13.760 --> 01:17.680
So we have these two users who are trying to have a phone call with one another

24
01:17.680 --> 01:17.840
.

25
01:17.840 --> 01:23.930
If the voice on the line is delayed by even 500 milliseconds, well, that's a

26
01:23.930 --> 01:25.360
major problem.

27
01:25.360 --> 01:28.510
Meanwhile, we know that this internet communication here where I'm just

28
01:28.510 --> 01:29.560
streaming some kind of

29
01:29.560 --> 01:34.880
video, if there's a 500 millisecond delay on this communication versus a 500
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:29.560 --> 01:34.880
video, if there's a 500 millisecond delay on this communication versus a 500

30
01:34.880 --> 01:35.720
millisecond

31
01:35.720 --> 01:41.190
delay on this communication, we know that there's going to be major problems

32
01:41.190 --> 01:41.840
with the

33
01:41.840 --> 01:45.200
phone call and absolutely no problems.

34
01:45.200 --> 01:49.800
In fact, probably not even noticed on the internet stream, thanks to buffering

35
01:49.800 --> 01:50.560
and just

36
01:50.560 --> 01:53.640
the nature of transferring large data.

37
01:53.640 --> 01:58.010
In fact, even this situation where this user is transferring a large file to a

38
01:58.010 --> 01:58.920
server somewhere

39
01:58.920 --> 02:05.180
on the network, if it takes 500 milliseconds longer for it to show up, then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:58.920 --> 02:05.180
on the network, if it takes 500 milliseconds longer for it to show up, then

40
02:05.180 --> 02:06.320
again, we might

41
02:06.320 --> 02:10.410
not even notice unless we're doing a lot of smaller transactions, maybe that

42
02:10.410 --> 02:10.960
starts to

43
02:10.960 --> 02:12.600
add up over time.

44
02:12.600 --> 02:18.140
But in these cases, we see that one of these types of applications is highly

45
02:18.140 --> 02:19.560
time sensitive.

46
02:19.560 --> 02:24.640
The phone calls have to get there in a certain amount of time.

47
02:24.640 --> 02:30.510
And furthermore, the reliability matters because we do need these services to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
02:24.640 --> 02:30.510
And furthermore, the reliability matters because we do need these services to

48
02:30.510 --> 02:31.640
be working.

49
02:31.640 --> 02:35.330
That phone call does have to go through because it might be an emergency phone

50
02:35.330 --> 02:35.840
call.

51
02:35.840 --> 02:40.640
It might be a medical situation and we're trying to dial out to emergency

52
02:40.640 --> 02:41.600
services.

53
02:41.600 --> 02:46.910
And so not only is it time sensitive, but it is from a reliability perspective,

54
02:46.910 --> 02:47.280
very

55
02:47.280 --> 02:48.560
important.

56
02:48.560 --> 02:54.250
Another way of saying this is this type of traffic must be prioritized over all

57
02:54.250 --> 02:54.600
of the

58
02:54.600 --> 02:57.480
other traffic types.

59
02:57.480 --> 03:04.000
Now we can have some other critical services as well that are not time
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:57.480 --> 03:04.000
Now we can have some other critical services as well that are not time

60
03:04.000 --> 03:06.120
sensitive, meaning

61
03:06.120 --> 03:11.970
that maybe we've got business applications that have to happen, but they don't

62
03:11.970 --> 03:13.040
necessarily

63
03:13.040 --> 03:15.520
have to happen as fast as possible.

64
03:15.520 --> 03:19.520
So we think about maybe inside of the data center space here.

65
03:19.520 --> 03:24.780
Maybe I have another server over here and I want to do some kind of live

66
03:24.780 --> 03:25.880
migration between

67
03:25.880 --> 03:26.880
the two.

68
03:26.880 --> 03:27.880
This involves virtual machines.

69
03:27.880 --> 03:31.240
It's a pretty common application inside the data center.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:27.880 --> 03:31.240
It's a pretty common application inside the data center.

70
03:31.240 --> 03:35.920
It involves moving server services from one physical box to another.

71
03:35.920 --> 03:40.440
Now the good news about this is while it's transferring, it remains online.

72
03:40.440 --> 03:44.830
So I'm still receiving this file, I'm still servicing all of these different

73
03:44.830 --> 03:45.480
stations

74
03:45.480 --> 03:51.820
and users throughout the network while my data is also migrating on the back

75
03:51.820 --> 03:52.480
end.

76
03:52.480 --> 03:54.840
So is this a critical service?

77
03:54.840 --> 03:55.840
Absolutely.

78
03:55.840 --> 03:59.800
This is a mission critical service inside of the data center.

79
03:59.800 --> 04:01.360
But is it time sensitive?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
03:59.800 --> 04:01.360
But is it time sensitive?

80
04:01.360 --> 04:03.040
No, it's not time sensitive.

81
04:03.040 --> 04:07.880
If it takes 500 milliseconds longer, then nobody's going to notice because

82
04:07.880 --> 04:08.640
again we're

83
04:08.640 --> 04:11.560
online while this is happening.

84
04:11.560 --> 04:15.200
If we were offline while it's happening, it's a different conversation.

85
04:15.200 --> 04:18.320
And so we're going to say that, yeah, that's a critical service.

86
04:18.320 --> 04:22.170
And so what we'd like to do is still have some amount of reservation around the

87
04:22.170 --> 04:22.800
resources

88
04:22.800 --> 04:23.800
involved.

89
04:23.800 --> 04:27.730
And when we're talking about resources on the network, we are typically talking

90
04:27.730 --> 04:28.120
about

91
04:28.120 --> 04:30.120
bandwidth.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:28.120 --> 04:30.120
bandwidth.

92
04:30.120 --> 04:34.360
For example, if I have to transfer a bunch of data and I say, okay, well, I'm

93
04:34.360 --> 04:34.960
going to

94
04:34.960 --> 04:43.680
reserve 100 megabits per second versus maybe I could reserve 500 megabits per

95
04:43.680 --> 04:44.240
second on

96
04:44.240 --> 04:48.930
a larger connection, well, then that transfer is going to take five times

97
04:48.930 --> 04:49.800
longer on the

98
04:49.800 --> 04:52.120
smaller link reservation.

99
04:52.120 --> 04:56.910
And so we would still want to again, look at these critical services and say,

100
04:56.910 --> 04:57.280
we need

101
04:57.280 --> 05:01.440
to make sure that we're reserving resources so it can still happen as quickly
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:57.280 --> 05:01.440
to make sure that we're reserving resources so it can still happen as quickly

102
05:01.440 --> 05:02.400
as possible.

103
05:02.400 --> 05:09.580
But as far as the individual granular 500 millisecond type of latency, no, that

104
05:09.580 --> 05:10.200
's not

105
05:10.200 --> 05:15.280
really a concern of ours from a time sensitivity perspective.

106
05:15.280 --> 05:22.600
And then naturally, we also have non critical services on the network.

107
05:22.600 --> 05:25.040
And yeah, we can look at entertainment.

108
05:25.040 --> 05:28.760
That's always going to be something that we're going to list.

109
05:28.760 --> 05:33.660
If our organization allows for things like YouTube and Netflix to be watched
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:28.760 --> 05:33.660
If our organization allows for things like YouTube and Netflix to be watched

110
05:33.660 --> 05:34.120
maybe during

111
05:34.120 --> 05:39.330
launches and breaks or for that matter, maybe we need YouTube and Netflix to

112
05:39.330 --> 05:40.240
perform our

113
05:40.240 --> 05:42.360
jobs for one reason or another.

114
05:42.360 --> 05:45.120
Either way, we'd probably still call that non critical.

115
05:45.120 --> 05:49.220
For the most part, we don't typically need to reserve bandwidth and try to

116
05:49.220 --> 05:49.960
prioritize

117
05:49.960 --> 05:50.960
that traffic.

118
05:50.960 --> 05:56.850
But we also have some other types of services that we might think about such as

119
05:56.850 --> 05:57.680
email.

120
05:57.680 --> 06:00.480
Email is work related for sure.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
05:57.680 --> 06:00.480
Email is work related for sure.

121
06:00.480 --> 06:04.360
I mean, these workers over here might be sending their emails back and forth.

122
06:04.360 --> 06:07.560
If I can draw an envelope here, how about that?

123
06:07.560 --> 06:10.880
So we can send our emails back and forth.

124
06:10.880 --> 06:16.680
But again, from a time sensitive perspective, it's not necessary that things

125
06:16.680 --> 06:18.240
get there 500

126
06:18.240 --> 06:19.840
millisecond sooner.

127
06:19.840 --> 06:23.620
And neither do we really need to worry about reserving bandwidth for emails

128
06:23.620 --> 06:24.320
because they

129
06:24.320 --> 06:26.440
will eventually go through.

130
06:26.440 --> 06:31.150
And so when the user expectation is that this application just takes time, it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
06:26.440 --> 06:31.150
And so when the user expectation is that this application just takes time, it's

131
06:31.150 --> 06:32.400
a very slow

132
06:32.400 --> 06:33.800
communications mechanism.

133
06:33.800 --> 06:38.540
Well, then we typically don't need to worry too much about those services from

134
06:38.540 --> 06:39.680
a prioritization

135
06:39.680 --> 06:41.080
perspective.

136
06:41.080 --> 06:46.480
So as we see, we start to establish an order of priority here from the most

137
06:46.480 --> 06:47.640
critical time

138
06:47.640 --> 06:53.920
sensitive services to critical, not time sensitive services and down to non

139
06:53.920 --> 06:55.440
critical traffic

140
06:55.440 --> 06:59.800
that as long as it goes through eventually, then we're all good.

141
06:59.800 --> 07:05.000
But I think it is worth noting that we do actually want these critical services
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:59.800 --> 07:05.000
But I think it is worth noting that we do actually want these critical services

142
07:05.000 --> 07:05.840
or noncritical

143
07:05.840 --> 07:11.560
services, these still need to be serviced.

144
07:11.560 --> 07:15.620
If my emails aren't going through, if my file transfers, maybe that's another

145
07:15.620 --> 07:16.000
one we

146
07:16.000 --> 07:22.280
could put on here, if my file transfers aren't working and they take hours for

147
07:22.280 --> 07:22.880
me to send

148
07:22.880 --> 07:27.200
even a small file, well, that's, it's not a mission critical service.

149
07:27.200 --> 07:29.440
It's not super time sensitive.

150
07:29.440 --> 07:34.230
And yet it still does need to go through even just something as basic as being
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
07:29.440 --> 07:34.230
And yet it still does need to go through even just something as basic as being

151
07:34.230 --> 07:35.240
able to use

152
07:35.240 --> 07:37.920
the internet and go to our websites.

153
07:37.920 --> 07:42.090
These days we have all kinds of mission critical services that are out there

154
07:42.090 --> 07:42.840
that we still

155
07:42.840 --> 07:48.470
need to be communicating with, even if we're not going to prioritize that

156
07:48.470 --> 07:49.480
traffic.

157
07:49.480 --> 07:52.560
Now a lot of this is going to come down to two concepts.

158
07:52.560 --> 07:56.280
We care about the prioritization of traffic.

159
07:56.280 --> 08:00.570
As we've said, we want to make sure that certain traffic types get favored over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
07:56.280 --> 08:00.570
As we've said, we want to make sure that certain traffic types get favored over

160
08:00.570 --> 08:01.240
others.

161
08:01.240 --> 08:05.820
But another conversation is going to have to do with what we said here with

162
08:05.820 --> 08:06.560
bandwidth

163
08:06.560 --> 08:12.710
that we need to consider the reservation of resources and specifically the

164
08:12.710 --> 08:13.880
reservation

165
08:13.880 --> 08:16.120
of our bandwidth.

166
08:16.120 --> 08:21.350
So it's an interesting aspect to talk about bandwidth reservation because when

167
08:21.350 --> 08:21.920
quality

168
08:21.920 --> 08:27.650
of service was first becoming a big deal, we were talking about having WAN

169
08:27.650 --> 08:28.800
circuits like

170
08:28.800 --> 08:34.680
T1s and E1s that were about one and a half megabits per second.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
08:28.800 --> 08:34.680
T1s and E1s that were about one and a half megabits per second.

171
08:34.680 --> 08:38.960
And we have phones on both sides of these, which are we're trying to make phone

172
08:38.960 --> 08:39.360
calls

173
08:39.360 --> 08:40.640
across T1s.

174
08:40.640 --> 08:46.240
We even had smaller ISDN lines, even the kilobits per second range.

175
08:46.240 --> 08:52.330
And so when we're looking at these very, very small amounts of bandwidth on

176
08:52.330 --> 08:53.920
these links,

177
08:53.920 --> 08:58.050
well bandwidth reservation was kind of a big deal because I need to make sure

178
08:58.050 --> 08:58.560
that there's

179
08:58.560 --> 09:03.040
enough bandwidth for this phone conversation to happen.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
08:58.560 --> 09:03.040
enough bandwidth for this phone conversation to happen.

180
09:03.040 --> 09:06.420
Now if only the phone conversation was happening, this would be plenty of

181
09:06.420 --> 09:07.120
bandwidth.

182
09:07.120 --> 09:11.980
But naturally we've got other users connecting in and trying to send traffic

183
09:11.980 --> 09:12.800
across this

184
09:12.800 --> 09:17.890
link as well, and so if somebody is trying to send a file back and forth, that

185
09:17.890 --> 09:18.360
could

186
09:18.360 --> 09:21.640
easily consume all one and a half megabits per second.

187
09:21.640 --> 09:27.020
So having that ability to reserve bandwidth and prioritize that traffic over

188
09:27.020 --> 09:27.840
the rest,

189
09:27.840 --> 09:31.320
that was very important with small bandwidth links.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:27.840 --> 09:31.320
that was very important with small bandwidth links.

190
09:31.320 --> 09:34.820
But now when we think about the modern network, I might have a switch

191
09:34.820 --> 09:36.120
connecting to another

192
09:36.120 --> 09:40.960
switch and this could be a 10 gigabit per second link.

193
09:40.960 --> 09:46.210
And if we're in the data center, we might even be talking about 100 or 400 and

194
09:46.210 --> 09:46.680
yes,

195
09:46.680 --> 09:51.760
even 800 gigabits per second between switches.

196
09:51.760 --> 09:56.230
And so when we look at the amount of bandwidth saying like even if we just have

197
09:56.230 --> 09:56.640
a gig, but

198
09:56.640 --> 10:04.240
let alone something like 10 gigabits per second, is QOS still needed.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

198
09:56.640 --> 10:04.240
let alone something like 10 gigabits per second, is QOS still needed.

199
10:04.240 --> 10:08.890
Because a voice call is extremely small and therefore it doesn't seem like it's

200
10:08.890 --> 10:09.320
going

201
10:09.320 --> 10:15.070
to be a necessity for us to have to deploy quality of service when we have

202
10:15.070 --> 10:16.080
these very

203
10:16.080 --> 10:18.400
large network pipes.

204
10:18.400 --> 10:22.440
Well as you might imagine, we're all here to talk about quality of service and

205
10:22.440 --> 10:22.680
so the

206
10:22.680 --> 10:25.880
answer is an emphatic yes.

207
10:25.880 --> 10:27.800
But why is it still important?

208
10:27.800 --> 10:32.030
Why do we still need it when we're not necessarily talking about these very
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

208
10:27.800 --> 10:32.030
Why do we still need it when we're not necessarily talking about these very

209
10:32.030 --> 10:33.220
small bandwidth types

210
10:33.220 --> 10:35.300
of pipes?

211
10:35.300 --> 10:38.480
Well there are probably a lot of different reasons for that but I'll go ahead

212
10:38.480 --> 10:39.080
and focus

213
10:39.080 --> 10:40.840
on a couple of them.

214
10:40.840 --> 10:47.570
First of all, every pipe, every link, whether it's a very small pipe or a 10

215
10:47.570 --> 10:48.840
gig or a 100

216
10:48.840 --> 10:56.240
gig link between devices, they all have the potential to be full.

217
10:56.240 --> 11:00.620
And so if they are filled up because somebody is just consuming all of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

217
10:56.240 --> 11:00.620
And so if they are filled up because somebody is just consuming all of the

218
11:00.620 --> 11:01.920
throughput, then

219
11:01.920 --> 11:07.490
even in these situations where we have so much bandwidth available, if we're

220
11:07.490 --> 11:08.120
full, then

221
11:08.120 --> 11:11.600
we start dropping packets.

222
11:11.600 --> 11:13.600
And so which packets are we going to drop?

223
11:13.600 --> 11:17.130
Well that's a good question and it depends on how we set up our quality of

224
11:17.130 --> 11:17.800
service.

225
11:17.800 --> 11:21.700
We probably hope that we're going to keep our voice calls online and not drop

226
11:21.700 --> 11:22.080
those

227
11:22.080 --> 11:26.740
packets but we can see that even if a 10 gig connection exists between switches

228
11:26.740 --> 11:27.320
, that there

229
11:27.320 --> 11:32.040
might be a situation where the buffers fill up, the bandwidth is peaked out,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

229
11:27.320 --> 11:32.040
might be a situation where the buffers fill up, the bandwidth is peaked out,

230
11:32.040 --> 11:32.520
and we do

231
11:32.520 --> 11:38.160
need to worry about those voice packets still making it through.

232
11:38.160 --> 11:43.530
And the other aspect of this, so this has to do with our resource reservations,

233
11:43.530 --> 11:43.920
but the

234
11:43.920 --> 11:50.040
other aspect to this is the concept of that prioritization that we talked about

235
11:50.040 --> 11:51.360
and specifically

236
11:51.360 --> 11:54.760
the order of transmissions.

237
11:54.760 --> 12:00.500
Because I might have this very small voice packet, this might be under 100
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

237
11:54.760 --> 12:00.500
Because I might have this very small voice packet, this might be under 100

238
12:00.500 --> 12:01.840
bytes typically.

239
12:01.840 --> 12:04.880
And so it's very small and it just needs to get sent out very quickly.

240
12:04.880 --> 12:10.950
Say okay that's great, except by the time it shows up, it has these monster

241
12:10.950 --> 12:11.840
packets that

242
12:11.840 --> 12:13.120
need to be transmitted first.

243
12:13.120 --> 12:18.800
And each one of these are the ethernet maximum of 1500 bytes that are going to

244
12:18.800 --> 12:19.480
take some

245
12:19.480 --> 12:24.080
amount of time in order to send out the interface.

246
12:24.080 --> 12:28.520
And so this is no different than us showing up in line at an amusement park and

247
12:28.520 --> 12:29.040
having

248
12:29.040 --> 12:31.960
to wait behind people who are in front of us.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

248
12:29.040 --> 12:31.960
to wait behind people who are in front of us.

249
12:31.960 --> 12:36.000
Now in that case we're probably all the same size I would think.

250
12:36.000 --> 12:40.160
But either way we say okay well this packet has to wait its turn.

251
12:40.160 --> 12:43.040
Is that really what we want to have happen on our switches?

252
12:43.040 --> 12:47.000
Do we want this critical voice packet to have to wait its turn?

253
12:47.000 --> 12:52.360
Yeah, from a seconds perspective, it doesn't take that long to send a packet.

254
12:52.360 --> 12:54.440
But what if there's 10 of these in a row?

255
12:54.440 --> 12:59.980
And what if it does add 50 milliseconds of wait time, as humans we typically

256
12:59.980 --> 13:00.800
don't worry
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

256
12:59.980 --> 13:00.800
don't worry

257
13:00.800 --> 13:06.080
too much about 50 milliseconds until again we're on a phone call and now all of

258
13:06.080 --> 13:06.760
a sudden

259
13:06.760 --> 13:10.880
we have a delay when we're trying to communicate with one another.

260
13:10.880 --> 13:14.150
And furthermore the further back in the queue that we are the more likely a

261
13:14.150 --> 13:14.780
packet is to

262
13:14.780 --> 13:18.120
get dropped in the situation where it's full.

263
13:18.120 --> 13:22.730
So these are reasons why quality of service continues to matter even on modern

264
13:22.730 --> 13:23.360
networks

265
13:23.360 --> 13:26.800
where we have these massive bandwidth types of pipes.

266
13:26.800 --> 13:30.480
It's all about making sure that we address the level of criticality of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

266
13:26.800 --> 13:30.480
It's all about making sure that we address the level of criticality of the

267
13:30.480 --> 13:31.080
different

268
13:31.080 --> 13:35.400
traffic types in our network and from an end to end perspective we want to make

269
13:35.400 --> 13:35.800
sure

270
13:35.800 --> 13:41.040
that we are giving the prioritization and the reservation of resources

271
13:41.040 --> 13:42.080
necessary to

272
13:42.080 --> 13:45.920
ensure a very high quality of experience on those critical apps.

273
13:45.920 --> 13:55.440
[BLANK_AUDIO]