Transcript BTexact Research Edge Lab - Home Page of Bob Briscoe

designing for tussle
case studies in
control over control
Bob Briscoe
BT Networks Research Centre
Jun 2004
role of communications research?
• pushing forward bounds of the possible
• help industry/society with comms technology choices
• to make an impact
• not just technical; also social, commercial
– inseparable interwoven issues
– ideal: multi-disciplinary expertise
– sufficient: reasonable cross-discipline awareness
• otherwise will not make impact
communications control
• problem: evolvability vs. infrastructure viability & abuse
end point control enables fast evolution
of new scalable services ‘e2e design principle’...
...but
• commoditises network operators who
add value through service bundling
• requires end points to co-operate
towards common goal
commercial
responsibility
viability
simple
scalability
secure
• who should be in control?
• DARPA NewArch articulated problems
[BradenClarkShenkerWroclawski00]
freedom
evolvable
control assumptions: examples
• authentication: who checks id?
• denial of service attack or congestion?: who decides?
• resource sharing: who decides fairness criterion?
• peer to peer sharing/ad hoc: why share resources?
• end-point vs. middle control: purely technical?
• aim to explicitly state control assumptions
control assumptions in typical papers
• neutral
 not so common
• unformed
 fine
• unconscious
 worst
• conscious unstated
 rarely succeeds
• conscious stated
 fine
• control over control
 subject of this talk
– decide control model at run-time, not design time
– improve infrastructure evolvability and viability...
evolution of evolvability research
end to end arguments [SaltzerReedClark84]
• protect generic investment, surrender control to foster innovation
end of e2e [ClarkBlumenthal00]
• ends not trusted to co-operate with whole
• middle needs investment incentive
end of (end of e2e) [Shenker, Kelly, Varian, Crowcroft, Anderson etc]
• game theoretic mechanism design
argument is the end [ClarkSollinsWroclawskiBraden02]
• design for tussle
comms infrastructure control
a history of tussle
centralised (operator)
distributed (customer)
legend
predominant model today
feasible range (at large scale)
(ineffective)
(inefficient)
configuration
address alloc
comms accounting
differential quality
admission control
large
scale
feasibility
* = with (dumb) central support
retransmit control
rate control*
service creation
*
authenticity/integrity
privacy
session control
caching
denial of service protection
geographic location
presence
unicast forwarding
multicast forwarding
access net routing
service accounting
access net provisioning (open spectrum)
broadcast forwarding
core routing
core provisioning
(intellg’nt centrl supt)
(p2p)
(p2p)
(p2p)
(p2p)
(p2p)
(theoretical)
*
*
*
(inefficient)
(inefficient)
*
1978
1988
1994
?
?
1994
1994
1997
1997
1997
1999
1999
2000
2000
2000
2001
2001
2001
2003
2003
n/a
n/a
n/a
spectrum of control
materials &
process equip
com
ponen
ts
equi
p
mak
ers
netwo
rk
owner
s
servic
e
provi
ders
conten
t&
applic
s
• having designed for extremes
• can also move control to intermediate points
appl
iance
s
en
d
us
ers
DoS case study
case study: denial of service mitigation
e2e: iTrace: ends: detection& trace; middle: previous hop
• 1:1M data packets trigger ICMP iTrace packet at each router
• message to dest address giving present & previous hop address
• dest under attack can trace back to earliest honest address on path
• push-back filters into network
e2e problems
• ends not trusted: spoof attack to install false filters
• middle needs incentive to invest in iTrace upgrades
e2e fixed
• authenticate filter requests hop by hop
design for tussle
• move detection & trace to proxy one notch in from ends
DoS case study
case study: denial of service mitigation
attacker
detection & tracing
only on hosts
victim,
attack detection
& path trace
attacker
network reveals
raw iTrace
messages
attacker
detection &
tracing services
from network
tussle
can move
across spectrum
with competition
detection
& tracing
proxy
network offers
DoS protection
based on iTrace
internally
attacker
victim
access routing case study
case study: contractual mobility
personal router
F-EP2
F-EP1
billing
C-EP
clearing
assessment
decision
payment
$
same
functional
components
and
intelligence
required in
both cases
classical
international roaming
offers publicly
announced and
optimised against
session reqs
automatically
location
tussle
Broker
EP1
offers announced only
to international
can move
roaming
partners
across spectrum
billing
with competition
Broker
clearing
Broker
EP2
profile
offers
trust
Broker
assessment
payment
QoS case study
case study:
quality
service
com
equi
netwo of servic
conten
materials &
process equip
ponen
ts
p
mak
ers
rk
owner
s
e
provi
ders
t&
applic
s
appl
iance
s
en
d
us
ers
e2e: TCP/IP: ends: congestion control; middle: forwarding
• transmission control protocol (TCP) [VanJacobsen88]
explicit congestion notification (ECN) [Floyd94]
e2e problems
• ends not trusted: VoIP free-riding
• middle needs investment incentive
Intserv [BradenClarkShenker94], Diffserv [ClarkWroclawski97]
e2e fixed
• shadow pricing, proportional fairness [GibbensKelly99]
design for tussle
• guaranteed QoS synthesis [Karsten02]
• control over control [Briscoe02]
QoS case study
QoS context: cost realities
b-w cost,
C
£/bps
0
app
trans
net
link
phys
C 1
B
pipe bandwidth, B /bps
0
QoS case study
 e2e design
TCP: business model
User 2 b/w
(longer RTT, T2)
T1
T2
T1
T2
competition for
limited bandwidth
 always fills capacity
 equality weighted by ‘distance’
 voluntary algorithm on end systems
 Internet collapse without co-operation
User 1 bandwidth (shorter round trip time, T1)
QoS case study
 e2e problems
greed breeds policing
• voice over IP
• if experience congestion, send more
• integrated services
• users reserve path resources (ReSerVation Protocol)
• networks control admission then police traffic
• differentiated services
• provision prioritised logical classes of service
• traffic classified (Diffserv field in IP) and policed
• congestion avoided for higher classes, usually
• middle takes control
• can vertically integrate with media business
QoS case study
 e2e gets fixed
explicit congestion notification (ECN)
• without ECN: first sign of congestion is loss
• with ECN:
mark packets randomly as congestion builds
• 2001: ECN standardised into IP & TCP
• extensible for marking before congestion onset (virtual queue)
QoS case study
 e2e gets fixed
DIY QoS
target rate
a
a
a
inelastic
(stream
media)
a
a a
(shadow) price
a
a
congestion marking
= (shadow) price
target rate
target rate
max
100
ave.
util/
%
ultra-elastic
(p2p)
TCP
(shadow) price
(shadow) price
QoS case study
 design for tussle
guaranteed QoS synthesis
• guarantees over simple middle
IP routers
Reservation
enabled
RSVP/ECN
gateway
ECN only
• allows vertically integrated media
business at edge
Data path processing
1
Reserved flow processing
2
Policing flow entry to CP
4
Meter congestion per peer
3
Bulk ECN marking
CP prioritised over BE
• DIY QoS one notch in
• uses 3 QoS standards but not their
architectures
• PSTN replacement but evolvable
business model...
ReSerVation signalling
1
2
congestion pricing
3
congestion
pricing
3
3
3
target rate
TCP
congestion pricing
best effort
(shadow) price
4
1
target rate
guaranteed QoS
synthesis
gateway
(shadow) price
guaranteed
QoS case study
case study: QoS
target rate
DIY QoS
on hosts
(shadow) price
in both cases
congestion marking
at all routers
= (shadow) price
max
ave.
util/
%
100
target rate
(shadow) price
expose shadow
price so that
applications can
synthesise their
own DIY QoS
per-session QoS
signalling
tussle
can move
across spectrum
with competition
use shadow price
internally to
synthesise services
target rate
TCP
standard
congestion
reaction
(shadow) price
QoS as
network
services
target rate
guaranteed QoS
synthesis
gateway
(shadow) price
messaging case study
case study: multipoint messaging
multicast
listener
all networks
multicast
enabled
multicast
listener
multicast
announcer
multicast
listener
messaging
only on hosts
offer multicast so
that applications
can create DIY
messaging
services
tussle
can move
across spectrum
with competition
offer messaging
services
using multicast
efficiency internally
unicast proxied
multicast
listener
all networks
multicast
enabled
but priced
per session for
streaming media
- too high for
messaging
unicast
messaging services
listener
from network
messaging
proxy
message
m’cast address
mapping
proxy
unicast
announcer
messaging
proxy
multicast
listener
(address
subset)
lesson: downstream knowledge upstream
propagation time
congestion
hop count
etc
info
16
11
16
16
S1 control
10
11
11
-5
10
control
& info
73
-7
R1
control
10
16
-1
control
14
info
8
-2
S2
R2
control
control
before...
13
8
S1
control
& info
...after re-feedback
7 -7
7
-5
control
& info
8
3
-1
control
& info
0
control
& info
2
9
S2
0
control
& info
-2
control
& info
R1
0
R2
packet re-feedback
all network nodes
know as much about
downstream path as
data source
- level playing field
downstream knowledge upstream
propagation time
congestion
hop count
etc
metric,
m
m0(t+T)
m0(t)
1
3
D m1
node
sequence
index,
i
mz 0
mn
sender
1
2
...
i
...
n
2
sequence of nodes on a network path
me(t)
receiver
probability
of penalty at
policer , p
1
2
probability
distribution
of metric, Pn
shift due to
cheating, Dmc 1
incentives to hit target
from above by (shadow) pricing
penalised
metric at
policer,
mn
3
4
0
allowed (mean 0)
from below by dropping/truncation
control over control?
• control can migrate
netwo
rk
owner
s
servic
e
provi
ders
conten
t&
applic
s
appl
iance
s
• sell different control models to different markets
en
d
us
ers
• DIY and “do it for you” customers
•
equi
p
equipment makers
mak
ers
can re-sell control package each time
• how to control where control is?
• offering protocol response at a price ‘switches on’ its importance
• what controls where the control is?
• market advantage, competition
• regulation
bundled
vertically integrated
closed
• design as if e2e
free
land-grab
open
evolving
infrastructure
product
portfolio
margin
summary of approach
• include proofing against greed
ultra-competitive
commoditised
volume
open
• based on underlying science
end
complexity
• design edge interception of e2e protocols
• let the tussle commence
• capture market share with free, open product
layered
products
Net
head
• pull in control from ends to edge
• competition gradually commoditises
• giving up control stimulates new innovation
time
Bell
head
middle complexity
• layer under next product
Net-head heart
Bell-head skins
research agenda implications
• pure technical research sometimes valid
• but often implicit commercial assumptions missed
• encourage articulation of commercial assumptions
• encourage multi-disciplinary research
– at fundamental level, not just applications
questions?
control over control
further info
• [email protected]
•
[SaltzerReedClark84] Jerome H. Saltzer, David P. Reed, and David D. Clark, “End-to-end arguments in
system design,” ACM Transactions on Computer Systems, 2(4):277–288 (Nov 1984)
•
[GibbensKelly99] Richard J. Gibbens and Frank P. Kelly. Resource pricing and the evolution of
congestion control. Automatica, 35, URL: http://www.statslab.cam.ac.uk/~frank/evol.html (1999)
•
[ClarkBlumenthal00] David Clark and Marjory Blumenthal, “Rethinking the design of the Internet: The
end-to-end arguments vs. the brave new world,” In Proc. Telecommunications Policy Research
Conference (TPRC’00), URL: http://www.tprc.org/abstracts00/rethinking.pdf (Sep 2000)
[BradenClarkShenkerWroclawski00] Bob Braden, David Clark, Scott Shenker and John Wroclawski,
“Developing a Next-Generation Internet Architecture,” DARPA White paper, URL:
http://www.isi.edu/newarch/DOCUMENTS/WhitePaper.pdf (Jul 2000)
•
•
[Briscoe02] Bob Briscoe, "M3I Architecture PtI: Principles” Deliverable 2 PtI, M3I Eu Vth Framework
Project IST-1999-11429, URL: http://www.m3i.org/results/m3idel02_1.pdf (Feb 2002)
•
[ClarkSollinsWroclawskiBraden02] David Clark, Karen Sollins, John Wroclawski and Robert Braden,
"Tussle in Cyberspace: Defining Tomorrow's Internet,” In: Proc. ACM SIGCOMM'02, Computer
Communication Review 32 (4) URL: http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.pdf (Aug 2002)
discussion
• design for tussle is subtle
• takes years of hindsight to get right
• too late for early market advantage?
• open, free land grab gives some breathing space
• can tendering process cope with subtlety?
• does designing for commoditisation bring it forward?
• is having no plan B more risky?
• parallels in Microsoft product evolution?
• BIOS, DOS, Win, COM, .NET, Office
spare
slides
Bob Briscoe
seamless resource control
 traditional (optional):
optimise ea subnet separately
e.g. Diffserv (open-loop)
signal req’s down
& price req’s
IP
IP
IP
IP
IP
 new (required):
optimise all paths together
signal congestion up
IP
IP
IP
IP
IP
& price congestion
QoS synthesised by the
ends (closed-loop)
Internet (not telco) industry approach
• creating x-like systems out of un-x-like parts
• where x is some desirable attribute
• creating secure systems out of insecure parts
• creating reliable systems out of unreliable parts
• creating intelligent systems out of unintelligent parts
•
eg. intelligent session control without an intelligent network
• creating QoS control systems out of non-QoS controllable parts
• creating a telephony system out of best effort Internet parts
• ...
• creates low cost systems out of low cost parts
• but the approach puts all the smarts at the ends, which...
• creates profitable value chains out of unprofitable players...?
broken