1. Prescriptive Network Theories Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22

2. Existing Theories • Much existing network theory is • Theoretical (models, simulation) • Descriptive • Possibly Predictive • (queuing, control, graph,insert yours here) • Disjoint in ownership and application • Identifiers, Paths and Protocols • What is really needed to design them right?

3. Prescriptive • Tells you what to do… • not just what its like, when you’ve done it. • Architects use design patterns - • but this is after the innovation - • It’s a way of scaling out their work • So prescriptive architecture isn’t patterns - • it is some higher level methodology • It’s generative

4. 1. Layers and Constraints • John Doyle (caltech) talks about de-constraining constraints Highly optimized tolerant systems • Specifically, the constraint of IP • In the narrow waist of the hourglass • Afords design freedoms below IP • And above • One could argue that • midboxen+TCP has moved this up a level • to the HTTP appspace • So in modular systems, a careful choice of limitations in a key module (with high centrality in the “call graph” can allow great flxibility later

5. Architecting Middleboxes • So if we want to do prescriptive arch for middle box • What is the minimum functionality that is simple enough, but no simpler? • Would you include caches in the arch? • What about integrity of content there (c.f. DTN custody protocol)? • How about flow and object naming? -Unify (and crypto-assigned?)? • If we got this right, could combine DTN, CCN and IPng

6. Getting it wrong - SIP • SIP was about the most extensible protocol ever • VOIP signaling/call setup protocol • Basic job is easy (MJH’s 1st code worked in a couple of hours - see rat) • So why have a turing complete call handler as part of any protocol • Now cannot write SIP DDoS defense coz SIP proxy can be hit by halting problem :-(

7. 2. Counter examples - identifiers • Internet Addresses - serve several functions • Interface id • Routing hint • Part of flow tuple • Implicit part of IPC end point (socket) • Lack of precision allowed “innovation” • Aggregation/Longest prefix match • NATs…

8. 2 continued [ack Brian Carpenter] • IPv6 isn’t innovative - • inherits most the same properties • but doesn’t prescribe or afford much new • IPNL is innovative (see also signpost) -Name based end point frees up IPC end point to support • Referrals • Multihome Failover • Multipath TCP • Migration/Roaming • Renumbering • Virtualisation/Better scale aggregation • …

9. Why combine these? • Resource pooling extended to storage • Traffic management extended over both space and time • Decoupling transmission/publication from reception, subscription, consumption • Disruption and delay tolerant…

10. Multipath, mobility etc again • The future context is multiscale • 1024 core is a couple of years off - what is IPC on OS on that? • Data center systems > 1 M cores abound • The net of mobile end systems is 5B devices (-> Interet of Things etc) • We need to matchmake in this impedence mismatched world, and • It would be good to retain a single system to do it

11. 3 Graph Theory and Routing • Huge effort measurind and modeling graphs • No-one’s using it to design routing • LS&DV&PV routing + Hierarchy are heavy handed tools • Why not start from path properties of graph • And derive a routing algorithm… … …

12. Conclusions, Discussion • Keep it as simple as possible… • …but no simpler • Ack Cambridge Mphil students • On Network Architecture module