Print Page
Making the Cloud Invisible
2/12/2013
What does it
take to make
the cloud “invisible?”
Put another
way, in the context of
an end user running a
media-focused application,
what parameters
create an environment
such that the user cannot
discern if the app is running locally
or in a remote cloud? For example, using
a video editor app and doing the classic
jog/shuttle function across the timeline,
can a user tell by the “feel of the app” that
the runtime code is local or remote? If
the app feels local in all aspects then the cloud is
invisible to the end user. For SaaS
apps in particular it’s good to aim for this
goal; users will demand it.
For sure, it’s not easy to create an invisible
cloud environment. There are many
aspects of “Quality of Service” that determine
the user experience. The main quality
domains are:
• Transport QoS from premise to cloud
including the lossey and delay prone
Internet;
• Compute QoS including deterministic
latency of a short operation and speed
of a long operation (e.g., transcode);
• Storage QoS including IOPS, bandwidth,
deterministic latency and other
storage related parameters;
• Availability QoS including uptime
percentage,
access latency to a service or
resource. This is tightly bound to systems
reliability, and
• Security QoS including access control,
authentication, encryption, DDoS attacks
prevention and more.
This column is the first of several to explore
the QoS of the cloud from the perspective
of a user or system component at
a remote facility. Let’s start by examining
transport QoS (No. 1 in list). Fig. 1 outlines
the salient aspects of transport QoS.
THE
BIG FOUR QOS METRICS
Transport QoS is measured using four
main parameters; bandwidth (data rate),
latency, packet jitter and packet loss. Internet
marketing has corrupted the meaning
of “bandwidth” to mean data rate so
I use this term reluctantly. Of course,
availability (uptime) is also a measure
of transport QoS, but for now let’s treat
availability separately. Fig. 1 shows that
the end-to-end QoS is divided across three
areas; facility premise, Internet (or direct
connect) and cloud provider. Each of
these areas contributes to the QoS either
positively or negatively.
Here is a brief summary of the effects
of each of the big four contributors:
•
Data rate (bandwidth); sufficient to
meet the simultaneous and peak needs
of all the apps and services required
at the premise. Some apps will require
continuous streaming bandwidth and
others can use variable file transfer
rates. Key is not to starve any media
streams.
•
Round trip latency; the lower the better.
Delay is the enemy of reliable file
transfer. TCP (FTP and HTTP use) is
very delay sensitive and can operate
~80 times slower in the presence of
large (200ms) RT delays compared to
small delays (10ms). There are practical
ways to circumvent the slowdown using
“transfer acceleration” techniques.
•
Jitter; this is the time variation in
latency.
For most apps and modest jitter
(±25ms), this metric is not critical.
Large jitter values ruins TCP transfer
rates.
•
Packet loss; lower the better. The raw
Internet has a packet loss of about .1
percent although this can vary widely
depending on traffic conditions. Also,
loss is often not directionally symmetric
and this can adversely affect transfer
rates due to TCP’s performance.
TCP-based data rate is reduced by
about a factor of 3 when loss increases
by a factor of 10.
THE QOS CHAIN
There are three links in the overall
QoS chain. Let’s consider the middle link first. Fig. 1 shows two
paths from premise
to the cloud. The most common connection
is the “best effort” internet, path
A. No carrier will guarantee internet delay,
loss or bandwidth; you get what you
get. Of course, your facility connection to
the internet (the so-called “last mile”) has
some QoS guarantees but this is a small
contributor to the overall Internet QoS.
So, purchasing a 100 Mbps clean pipe to
the Internet does not guarantee 100 Mbps data end-to-end transfers by any
means.
An alternative to Internet connectivity
is to purchase a direct connection to your
cloud vendor, (path B in Fig. 1). Amazon,
Terremark and other cloud providers offer
this option. An example of this relies
on the famous One Wilshire telecom hub
in Los Angeles. It has direct paths to many cloud vendors, bypassing the
Internet. It’s
possible to link from a media facility to
One Wilshire using Metro Ethernet (for
example) thus creating an Internet bypass
and guaranteeing an excellent QoS for the
facility-to-cloud transport chain.
For sure, paths A or B are big contributors
to the overall transport QoS, but next
in line is usually the local premise QoS.
Running apps and other services in the
cloud puts strict demands on the in-house
networking and some facilities are not
geared to support the required QoS. This
could make the facility the weak link in
the transport chain. Don’t assume “all will
be OK” with in-house networks. Run tests,
measure performance and don’t assume
anything; measure it.
The good news is that facility managers
have total control over local transport
QoS so you have a good chance of an excellent
overall end-to-end QoS. Finally, the
cloud-provider portion should offer the
best QoS performance in the three link
chain.
It has been shown that the cloud can
be invisible if transport QoS parameters
are sufficiently defined, measured and
managed on a daily basis. I have personally
used a video editor app executing 4K
RT miles from the UI and the cloud was
invisible for my tests. My first experience
of this made me a believer in the promise
of the cloud.
Transport QoS is only one aspect of the
total “quality of experience.” In the next
column other cloud QoS metrics will be
considered.
Al Kovalick is the founder of Media
Systems consulting in Silicon Valley. He
can be reached via TV Technology.
Print Page