end to end protocols for the Future Internet scope & goals

1. end to end protocols for the Future Internetscope & goals Bob BriscoeChief Researcher, BT GroupDagstuhl, Jun 2008

2. why invite you? • from the theoretical end of practice and the practical end of theory “The gap between theory and practice is greater in practice than in theory”Steve Crocker • people from distributed systems, data transport & internetworking fields; some cover both/all • mix of industry & academia • no attempt to be representative of ‘industry positions’ • expected to be able to take devils’ advocate positions • expected to question & argue • expected to desire timely consensus

3. goals • dialogue between fairly disconnected communities • (re)designing end-to-end data transport • (re)designing internetworking • reduce controversy over placement of functions • better consensus on layer interactions • both have to be clear for a robust system • produce prioritised research agenda • initial process towards architectural change (at end)

4. careful not to invent problems to fit the research we want to do research agenda from DARPA NewArch (2000) all still unsolved ‘solved’ = rough consensus and deployable code (ideally all solutions coherent) routing, naming, addressing (n) policy controls on inter-provider routing robustness & availability, inc mobility reachability through middleboxes resource control (0) highly time-variable resources capacity allocation extremely long propagation delays heterogeneity – cross-cutting agenda enabling conflicting socio-economic outcomes (0) enabling a variety of technical outcomes (n) management (0) policy-driven auto-configuration failure management security (n) attack resilience traceability you can’t have your dessertuntil you’ve eaten your vegetables (x) : no. of projects funded as ‘Future Internet’ (Spring 2007)

5. scope • future = changes with significant dependencies may take 5-10yrs to deployment so must last ~30yrs • Internet = globally interoperable platform for applications of computer communication • control & management focus more than data plane • routing, mobility, naming, addressing, interconnection • resource sharing, congestion control, framing/fragmentation • churn, rapid change of path characteristics • diversity of scale, technology diversity, availability, predictability • social & economic as well as technical control • not sexy but elegant – all pretty low level stuff

6. scoping &e2e terminology • recursion can be powerful or can confuse • end-to-end interaction in a distributed system / overlay network • end-to-end data communication • end-to-end of one internetwork hop over a network of links

7. ...you should be interested in: • new communication paradigms and network architectures • cross-disciplinary motivations for new architecture – social, commercial and economic • applications enabled or improved through advanced networking and transport mechanisms • performance characteristics of new communication protocols and network architectures • availability and robustness aspects of new architectures • handling of unwanted traffic • transition and deployment aspects of new network architectures • formal principles of architecture and transport

8. out of scope • e2e issues not crossing traditional layer boundaries • information security • data integrity • multiplexing / demultiplexing • loss detection & repair • same order delivery • duplicate detection • flow control • specific link technology issues • application-specific networks

9. economic & social issuescan we stop others being myopic? • a different sort of research problem • if we agreed on a function placement ...say: • traffic engineering should be done by endpoints (role of networks is to give them the right incentives) • QoS should be done by endpoints (ditto) • policing should be done at outer trust boundaries • others would still pull control into their bailiwick • operators will still traffic engineer within their own network • the IEEE will still do QoS on each link • vendors will still put policing on each box

10. broken tension between e2e design principle and design for tussle • 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 video telephony system out of best effort Internet parts ... • creates low cost systems out of low cost parts with all the smarts at the ends... • creates profitable value chains out of unprofitable players...?

11. publicInternet open closed telco/NGN cellular satellite 1995 2008 open has not meant open minded • is the Internet only for those who want openness? • the worship of evolvability has to be balanced by a desire for the fruits of evolution to be enjoyed & exploited • it’s a tough research problem to enable both of: • intense competition & excess profits • distributed & centralised control • open & closed • designing for lock-in isn’t natural for most of us

12. end to end protocols for the Future Internetscope & goals Q&Aquestion & argue

13. goals – recap • dialogue between communities • placement of functions • layer interactions • prioritised research agenda • process towards architectural change