1. The document argues that pursuing ever higher broadband speeds is leading the industry into a "death spiral" as quality of experience declines faster than networks can be upgraded.
2. It advocates reframing the resource model around quality metrics like loss and delay rather than speed. Prioritizing scheduling of traffic to manage variability in loss and delay is key to improving quality of experience.
3. A multi-class service model is proposed to separate traffic by resilience requirements and allow differentiated pricing to better drive capacity planning and revenue. This fits demand to the underlying constraints of packet networks.
2. PREDICTABLE
NETWORK
SOLUTIONS
The only ex-ante network performance
engineering company in the world.
Consultancy on the future of voice,
cloud and broadband.
Dr Neil Davies Co-founder and Chief Scientist
Ex: University of Bristol (23 years).
Former technical head of joint university/research institute (SRF/PACT).
Martin Geddes Founder
Ex: BT, Telco 2.0, Sprint, Oracle, Oxford University.
Thought leader on the future of the telecommunications industry.
3. Our offer to you today
• Help you to understand the mismatch
between:
– What people are aspiring to achieve (demand)
– What you are actually doing (supply)
• Propose how to close the gap
– Technically grounded in reality
– Practical advice on how to proceed
4. This may be a
difficult message to hear
We’ve had a lot
of experience of
people not
wanting to hear
what we’re
about to tell you
5. Our three key messages
1. Speed (‘bandwidth’) is no longer a
helpful model for broadband.
2. The pursuit of ever more speed
means the broadband business is in
a death spiral.
3. You need to re-frame your
resource model to survive.
13. Service B: High variability
Same satellite,
same location,
similar time,
different service
14. More speed is not necessarily better
SERVICE A
‘Slower’
and
good QoE
SERVICE B
Probably not
what you
would have
expected
‘Faster’
but
poor QoE
15. This is a common issue to
ALL BROADBAND DELIVERY
Was this just a
one-off issue?
No.
16. DSL: same bandwidth, different QoE
Comparison between two LLU broadband providers to same location in the UK
Two customers
serviced off the same
pole in the same
street by two
different wholesale
DSL providers
The one on right has 1/3 the capability of the
left for carrying POTS-quality VoIP
17. Same problem on cable
We see the
same thing on
other networks
(e.g. 3G, small cells)
but cannot share the
data for contractual
reasons
19. A Skype experience (3-way call)
1.8M/448k ADSL – wholesale 20CN
Loss: 0.1%.
Delay: 40ms-50ms
We measured
path loss and
delay (summary
on next slide)
20M/2M Cable broadband
Loss: <0.5%.
Delay (one-way): 50ms-60ms, jumping
to 500ms for a second or two, then back
10M/1M ADSL Business LLU
Loss: Wandering from a typical 0%-2% up
to as high as 48% for a second or two.
Delay: 50-70ms
20. Different speeds & characteristics
SLOW & LOW VARIABILITY OF LOSS/DELAY
Good Experience
Bad Experience
VERY FAST
& VARIABLE DELAY
FAST
& VARIABLE LOSS
21. Speed was not the key differentiator
VARIABILITY
Bad Skype QoE
HIGH
The faster
broadband lines
gave a worse
experience as
reported by Skype’s
own QoE metric
LOW
SLOW
SPEED
FAST
22. Why did these
user experiences differ?
Because they had different
loss and delay
(and that’s it!)
So why are we
promoting
‘speed’?
23. The application hierarchy of need
3. Predictable loss and delay
2. Stable: Good ‘stationarity’
These are not
getting enough
attention
We need more
than just
‘speed’ for
good QoE
1. Feasible: Sufficient capacity
Yes, we need
capacity
Note: exact requirements are application-dependent
!
!
25. Valid reasons for spending capex
• More customers
More revenue
• Increased usage
More revenue
• Regulatory requirement
26. Invalid reason for spending capex
Premature
infrastructure and
capacity upgrades
27. Lots of capex spent on ‘tin’
Spectrum, fibre,
copper, ducts,
street cabinets,
cell towers, and
the transmission
and routing
equipment
Is it being
well spent?
28. More, more, more
When we believe
more speed is the
only answer, we
are doomed to go
round again (and
again)
More supply
More
complaints
and churn
More elastic
demand
Lower QoE
Faster
saturation of
backhaul
More
variability
There is a
‘jackhammer’
effect that gets
worse over
time
29. Service quality
Service Quality
The investment ‘cycle of doom’
QoE declines
faster than
network planning
rules forecast
Time
Rising load makes
service quality fall,
forcing upgrades
Failure of technology to keep
up with ever rising demand
forces shorter upgrade cycles
Undepreciated
asset value
Undepreciated Asset Value
Death via
unserviceable
debt load
Time
30. Telecoms is a capital killer
As an industry,
we’re not
covering our cost
of capital
Something is
very badly wrong
Source: PwC
http://www.pwc.com/en_GX/gx/communications/publications/assets/pwc_capex_final_21may12.pdf
32. Quality of experience
How to think about cost drivers
HEAVEN
HIGH
Network has lots of
users, who feel like the
network is still empty
because they are
suitably isolated from
each other
LOW
HELL
LOW
HIGH
Resource efficiency
33. Quality of experience
As load increases, QoE falls
Add more demand to
today’s packet
networks, and
everyone’s experience
degrades since all your
packets are ‘pollution’
to other users
HIGH
Access
network
LOW
LOW
HIGH
Resource efficiency
34. Quality of experience
Add capacity to resolve falling QoE
HEAVEN
HIGH
HEAVEN
Heaven gets further away
Access
network
LOW
LOW
MEDIUM
Resource efficiency
HIGH
35. Quality of experience
Can’t ensure QoE for applications
with strong stationarity requirements
Current approaches require
all traffic to be schedulable
within very short timescales
HIGH
Access
network
Infeasible
LOW
LOW
MEDIUM
Resource efficiency
HIGH
36. Quality of experience
Broadband networks need to be
kept empty to keep working
HIGH
!
Access
network
The only way
current network elements
can deliver good
enough QoE is by
being idle frequently
Queues
need time
to ‘relax’
!
This microscopic
queueing effect has
massive macroscopic
implications, both
technically and
economically
LOW
LOW
MEDIUM
Resource efficiency
HIGH
37. Quality of experience
Because of this you currently
can’t run networks ‘hot’
HIGH
Access
network
Protocols ‘collapse’
‘Goodput’ plummets
LOW
LOW
MEDIUM
Resource efficiency
HIGH
38. Quality of experience
With every upgrade the QoE
boundary for next upgrade drops
HIGH
Diminishing
returns from
adding more
capacity to solve
excess delay
UPGRADE
THRESHOLD
5
4
3
2
1
LOW
LOW
MEDIUM
Resource efficiency
HIGH
40. Delay (and loss) have a structure
Delay is due to…
G
S
V
Geography
Serialisation
speed
Variability
41. Why trust in increasing
speed is now misplaced
The speed of light
is not changing
G
Pre-IP
Early IP
Now
Geography
42. Why trust in increasing
speed is now misplaced
Historically speed
did correlate with
more value
S
G
Pre-IP
Early IP
Serialisation speed
Geography
Now
43. Why trust in increasing
speed is now misplaced
Not all packets
experience this
much delay, but the
outliers are the
ones that matter to
QoE
Now dominates
application
performance
V
S
Early IP
Serialisation speed
G
Pre-IP
Variability
Geography
Now
47. Networks are ‘trading spaces’
How ‘V’ is
distributed among
competing streams
is how demand
is matched to the supply
48. REVENUE
This makes all the
difference between
commercial success
and failure
Scheduling
SCHEDULING
This is where supply
and demand meet
…and nowhere else
COSTS
49. Quality of experience
The real difference between
telecoms heaven and hell
IDEAL
SCHEDULING
HIGH
LOW
TODAY!
LOW
HIGH
Resource efficiency
50. Your problem: magical thinking
When there is
excessive delay, you are
trying to make V disappear
by building more capacity
rather than distributing it
through scheduling
51. TWO fundamental resource limits
MAX CAPACITY
If you want to
move 10mbits in
1 sec, you need
(at least)
10mbit/sec of
transmission
Schedulability
demand
HIGH
Feasible
LOW
LOW
HIGH
Capacity demand
Infeasible
52. TWO fundamental resource limits
Infeasible
MAX
SCHEDULABILITY
Feasible
Schedulability
demand
HIGH
Even with perfect
knowledge and
mechanisms, you
can only schedule
so well
LOW
LOW
HIGH
Capacity demand
53. TWO fundamental resource limits
Schedulability
demand
HIGH
Infeasible
Feasible
In practise we
aren’t nearly
that good
LOW
LOW
HIGH
Capacity demand
54. TWO fundamental resource limits
We typically hit this
limit first (which is
why adding capacity
is not a good idea)
Schedulability
demand
HIGH
MAX CAPACITY
Infeasible
MAX
SCHEDULABILITY
Feasible
Feasible
LOW
LOW
HIGH
Capacity demand
Infeasible
57. Quality of experience
There is only one feasible route
HEAVEN
HIGH
No slack
means
this is
not
possible
Focus on
scheduling
and QoE
first
We are going
about
broadband the
wrong way
LOW
…then
you get
stuck
here
HELL
LOW
HIGH
Resource efficiency
If you
focus on
resource
usage
first…
58. Is the path to heaven
TECHNICALLY ACHIEVABLE?
Yes
59. Pro-active control over scheduling ‘V’
We built a
demo ISP to
prove what we
say actually
works
HELL
HEAVEN
This network is
still delivering
good QoE at
100% load
Some qualityinsensitive traffic
gets slightly
worse treatment
We used a different resource
model to achieve this
90% of
load
62. Need to frame the supply
differently to make issues soluble
Bandwidth
Quality
‘Quality’ is the
absence of
something
unwanted
‘Bandwidth’ is
the presence of
something
wanted
Speed
Loss and
delay
63. How to use this quality-centric
RESOURCE MODEL?
64. What has to change?
NOW
FUTURE
SUPPLY-PUSH
DEMAND-PULL
Selling
commodity
bandwidth
inputs
Selling
differentiated
application
outcomes
65. What has to change?
Focus on
enabling outcomes
not higher ‘speed’
Properly characterise
your demand
Demanddriven model
67. What has to change?
Understand how
delivered QoE is a function
of loss and delay
Properly characterise
your supply requirements
So your service is
fit-for-purpose
69. Example of a supply approach:
Three layer model
Superior
Superior traffic costs more to deliver…
so should attract a premium
Standard
Standard traffic is today’s off-peak
Internet… but is consistently the same
Economy
Economy traffic does not drive capacity
upgrades
Today’s QoS
mechanisms
don’t deliver
this (or create
a service of no
value trying)
They don’t
understand
the ‘trades’
properly
70. – …but they still have
connectivity
Superior
Standard
• When there is a period of
network stress, some people
may get reduced service…
Standard
– …but not everyone needs it
– So we separate out resilient
traffic from non-resilient
Superior
• Provisioning capacity
for total resilience is
a real cost…
Resilient
Extend this to a five class model
Economy
73. We are in a race to the bottom
This is not
negotiable
We’ve got into a
fight with the
mathematics of
statistical
multiplexing
74. Why so? Demand is not being met
Supply-push business
and technology model
75. Why so? Wrong kind of supply
Failure to align
with underlying
and unchanging
reality of packet
networking
76. Speed (and volume) are not value
We’ve seen
networks
where adding
capacity made
performance
get worse
!
Dangerous myth:
MORE SPEED IS ALWAYS BETTER
!
77. Broadband is becoming
critical national infrastructure
Needs to be dependable
Advanced
services need
predictable and
dependable
supply
No ice cream
(or insulin)
without fridgefreezers, which
need a reliable
power supply
78. We are creating a digital society
We can’t
externalise
our collective
risks
Implicit social contract
82. What operators
should be asking themselves
1. Why am I trying to solve my scheduling
problems with more capacity?
2. For my key customer applications, am I
delivering the network supply that enables
good QoE?
– i.e. am I delivering the right loss and delay?
3. Given that there is a trading space, am I
constructing and offering the right data
transport products?
83. What regulators
should be asking themselves
1. What is the value that I am getting from
demanding more speed?
2. Measurement is de facto regulation,
therefore am I measuring the right thing?
3. What are the key applications that need
managed QoE and cost to drive societal
benefits?
84. To learn more
Free Future of Communications newsletter:
www.martingeddes.com
Follow Martin Geddes on Twitter: @martingeddes
Other presentations:
slideshare.net/mgeddes/
White papers on network performance:
www.pnsol.com