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. commercial viability simple scalability responsibility secure freedom evolvable communications control • problem: evolvability vs. infrastructure viability & abuse • who should be in control? • DARPA NewArch articulated problems[BradenClarkShenkerWroclawski00] • 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 [ClarkSollinsWroclawskiBraden02] • design for tussle

7. centralised (operator) distributed (customer) large * = with (dumb) central support scale legendfeasibility predominant model today feasible range (at large scale) (ineffective) retransmit control 1978 (inefficient) rate control* 1988 service creation 1994 configuration * ? address alloc ? authenticity/integrity 1994 privacy 1994 session control 1997 comms accounting (intellg’nt centrl supt) 1997 differential quality * 1997 admission control * 1999 caching (p2p) 1999 denial of service protection * 2000 geographic location 2000 presence 2000 unicast forwarding (p2p) (inefficient) 2001 multicast forwarding (p2p) (inefficient) 2001 access net routing * 2001 service accounting (p2p) 2003 access net provisioning (open spectrum) (p2p) (theoretical) 2003 broadcast forwarding n/a core routing n/a core provisioning n/a 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 • 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

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. F F - - EP2 EP2 offers offers F F - - EP1 EP1 billing billing offers offers C C - - EP EP clearing clearing assessment assessment decision decision $ $ payment payment location Broker EP1 Broker EP2 profile offers trust billing Broker assessment Broker clearing payment 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) [VanJacobsen88]explicit 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. app trans net link phys QoS context: cost realities QoS case study b-w cost, C £/bps C  1 B 0 0 pipe bandwidth, B /bps

14. User 2 b/w (longer RTT, T2) T1 T2 competition forlimited bandwidth User 1 bandwidth (shorter round trip time, T1) 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 a (shadow) price a target rate congestion marking=(shadow) price a target rate ultra-elastic(p2p) max ave.util/ % TCP (shadow) price 100 (shadow) price

18. IP routers Data path processing Reservationenabled Reserved flow processing 1 Policing flow entry to CP RSVP/ECNgateway 2 Meter congestion per peer 4 ECN only Bulk ECN markingCP prioritised over BE 3 1 2 3 3 3 3 4 target rate 1 TCP target rate (shadow) price guaranteed QoS synthesis gateway (shadow) price 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. in both casescongestion markingat all routers= (shadow) price max ave.util/ % 100 expose shadow price so that applications can synthesise their own DIY QoS target rate target rate guaranteed QoS synthesis gateway tussle use shadow price internally to synthesise services (shadow) price (shadow) price target rate TCPstandard congestionreaction (shadow) price 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 messagem’cast addressmappingproxy offer messaging services using multicast efficiency internally can move across spectrum with competition unicastannouncer unicast proxiedmulticastlistener multicastlistener(addresssubset) messagingproxy

21. info control info control& info control control control control 7 before... ...after re-feedback 0 8 R1 8 13 3 0 7 control& info 2 9 S1 control& info control& info 0 control& info R2 S2 control& info -7 -5 -5 -2 -1 -2 -1 -7 control& info 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. probabilityof penalty at policer , p 1 2 probability distributionof metric,Pn shift due tocheating,mc incentives to hit target from above by (shadow) pricing from below by dropping/truncation 1 penalised metric atpolicer,mn 3 4 0 allowed (mean 0) 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(t+T) 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. time bundled vertically integrated closed evolvinginfrastructure productportfolio now next margin free land-grab open time future ultra-competitive commoditised open volume endcomplexity layeredproducts Nethead time Net-head heartBell-head skins Bellhead middle complexity 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@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):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)

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

30. spareslides Bob Briscoe

31. traditional(optional):optimise ea subnet separatelye.g. Diffserv (open-loop) new(required):optimise all paths together signal req’s down& price req’s signal congestion up & price congestionQoS synthesised by the ends (closed-loop) IP IP IP IP IP IP IP IP IP IP seamless resource control

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