designing for tussle case studies in control over control

1
designing for tusslecase studies incontrol
over control

• Bob Briscoe
• BT Networks Research Centre
• Jun 2004

2
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

3
communications control

• problem evolvability vs. infrastructure
  viability abuse
• who should be in control?
• DARPA NewArch articulated problemsBradenClarkShe
  nkerWroclawski00

• 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

4
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

5
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...

6
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 ClarkSollinsWroclawskiBraden0
  2
• design for tussle

7
comms infrastructure controla history of tussle
8
spectrum of control
materials process equip
comp-onents
equip makers
network owners
service providers
content applics
appli-ances
end users

• having designed for extremes
• can also move control to intermediate points

9
case study denial of service mitigation
DoS case study

• e2e iTrace ends detection trace middle
  previous hop
• 11M 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

10
case study denial of service mitigation
attacker
DoS case study
detection tracing only on hosts
victim, attack detection path trace
detection tracing servicesfrom network
network reveals raw iTracemessages
attacker
attacker
tussle
detection tracingproxy
network offersDoS protectionbased on
iTraceinternally
can move across spectrum with
competition
attacker
victim
11
case study contractual mobility
same functional components and intelligence
required in both cases
personal router
access routing case study
classicalinternational roaming
offers publicly announced and optimised against
session reqs automatically
tussle
offers announced only to international roaming
partners
can move across spectrum with
competition
12
case study quality of service
QoS case study
materials process equip
comp-onents
equip makers
network owners
service providers
content applics
appli-ances
end users

• e2e TCP/IP ends congestion control middle
  forwarding
• transmission control protocol (TCP)
  VanJacobsen88explicit congestion notification
  (ECN) Floyd94
• e2e problems
• ends not trusted VoIP free-riding
• middle needs investment incentiveIntserv
  BradenClarkShenker94, Diffserv
  ClarkWroclawski97
• e2e fixed
• shadow pricing, proportional fairness
  GibbensKelly99
• design for tussle
• guaranteed QoS synthesis Karsten02
• control over control Briscoe02

13
QoS context cost realities
QoS case study
b-w cost, C /bps
C ? 1 ?B
0
0
pipe bandwidth, B /bps
14
e2e designTCP business model
QoS case study
T1
T2
? always fills capacity ? equality weighted by
distance ? voluntary algorithm on end systems ?
Internet collapse without co-operation
15
e2e problemsgreed breeds policing
QoS case study

• 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

16
e2e gets fixedexplicit congestion notification
(ECN)
QoS case study

• 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)

17
e2e gets fixedDIY QoS
QoS case study
target rate
a
inelastic(streammedia)
a
a
a
a
(shadow) price
a
a
target rate
congestion marking (shadow) price
a
target rate
ultra-elastic(p2p)
max
ave.util/
TCP
(shadow) price
100
(shadow) price
18
design for tussleguaranteed QoS synthesis
QoS case study

• guarantees over simple middle
• allows vertically integrated media business at
  edge
• DIY QoS one notch in
• uses 3 QoS standards but not their architectures
• PSTN replacement but evolvable business model...

ReSerVation signalling
congestion pricing
congestion pricing
congestion pricing
guaranteed
best effort
19
case study QoS
target rate
QoS case study
DIY QoSon hosts
(shadow) price
QoS as networkservices
per-session QoSsignalling
can move across spectrum with
competition
20
case study multipoint messaging
multicastlistener
all networksmulticastenabled
messagingonly on hosts
all networksmulticastenabled
messaging case study
multicastlistener
but priced per session forstreaming media- too
high for messaging
multicastannouncer
offer multicast so that applications can create
DIY messaging services
messaging servicesfrom network
unicastlistener
multicastlistener
messagingproxy
tussle
messagemcast addressmappingproxy
offer messaging services using multicast
efficiency internally
can move across spectrum with
competition
unicastannouncer
unicast proxiedmulticastlistener
multicastlistener(addresssubset)
messagingproxy
21
lesson downstream knowledge upstream
10
propagation timecongestionhop countetc
16
7
11
3
16
16
16
11
11
11
14
R1
10
10
16
8
S1
R2
S2
22
packet re-feedback
all network nodes know as much about downstream
path as data source - level playing field
downstream knowledge upstream
propagation timecongestionhop countetc
metric,m
m0(tT)
m0(t)
3
Dm1
nodesequenceindex,i
1
mz
0
1
2
i
n
...
...
mn
me(t)
2
receiver
sequence of nodes on a network path
sender
23
control over control?
network owners
service providers
content applics
appli-ances
end users

• control can migrate
• sell different control models to different
  markets
• DIY and do it for you customers
• equipment makers 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

equip makers
24
summary of approach

• design as if e2e
• include proofing against greed
• based on underlying science
• design edge interception of e2e protocols
• let the tussle commence
• capture market share with free, open product
• pull in control from ends to edge
• competition gradually commoditises
• giving up control stimulates new innovation
• layer under next product

25
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

26
questions?

• control over control

27
further info

• Bob.Briscoe_at_bt.com
• 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)277288 (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 (TPRC00), 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.pd
  f (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/tuss
  le.pdf (Aug 2002)

28
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

29
(No Transcript)
30
spareslides

• Bob Briscoe

31
seamless resource control

• traditional (optional)optimise ea subnet
  separatelye.g. Diffserv (open-loop)
• new (required)optimise all paths together

• signal reqs down price reqs
• signal congestion up
• price congestionQoS synthesised by the
  ends (closed-loop)

32
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...?