Network rightsizing (2/3): Lloyd’s talent required, please!

The preceding post discussed the importance to size the network not only from the traffic demand, but also from the performance impact on the business. Let's discuss here the concept of "network rightsizing". In a nutshell, we propose the following formula:

Rightsizing = ["sufficient" & "not too much"] * quantity

Sufficient quantity to provide a good quality of experience; not too much to minimize cost - and promote good practices as well as reasonable expectations among employees. Note that rightsizing applies to most of human activities, from food to housing and energy consumption (okay, I know some kids that would protest rightsizing their holidays or pocket money – but this is another story …).

It is not the usage (or the virtually unlimited sum of traffic demands) that should drive network sizing, but rather the quality of experience (QoE) that the network can provide to application users: we need to start from the result (consequence) to define the resource (cause).

When measuring periods of time during which the network negatively impacts users QoE, we must take into account that the probability of resource scarcity is concentrated in working hours. For example, a ratio of 1% of performance brownout time over the week (i.e. 100 minutes) likely means an impact of 20 minutes per working day (over a 5-day week). This may be even a too good performance for a recreational application (Facebook, YouTube…), an acceptable one for a not too critical application (emails, web browsing) while surely not for a business critical one like the company ERP or customer-facing systems.

Let's take the following example for a site with a given traffic and equipped with a traffic management system able to individually manage each user's flow (*). The resource allocation differentiates among applications and users. We then face different situations according to the available access bandwidth (10 Mbps; 4 Mbps and 2 Mbps in our example).

	% of time with poor performance
% of time with impact on QoE	<5%		<2%		<1%		0%
QoE impact per working day	1 h 40 min		40 min		20 min		0 min
Bw = 10 Mbps à OVERSIZED
Very critical app.							X
Non critical app.							X
Recreational app.							X
Bw = 4 Mbps à RIGHTSIZED
Very critical app.							X
Non critical app.					X
Recreational app.			X
Bw = 2 Mbps à UNDERSIZED
Very critical app.				X
Non critical app.		X
Recreational app.	X

Savvy IT managers would likely prefer the rightsized network scenario. Of course, they will only chose it if they trust traffic management systems to protect critical applications at peak time and if they get good predictions of the bandwidth impact on user's QOE (see for example Ipanema's control feature-set).

IT people need Lloyd's amazing talent to successfully get out of epic situations: after all, why take the risk of complaining users?

(*) The lack of differentiation between application flows means identical QoE impacts among them, forcing to size the network to provide a good performance for the less critical applications in order to have the same good performance for the critical ones. It is the typical root of network OVERSIZING.

Illustrations: Harold Lloyd in "Hot Water" (1924) and "An Eastern Westerner" (1920)