1 / 12

Prescriptive Network Theories

Prescriptive Network Theories. Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22. Existing Theories. Much existing network theory is Theoretical (models, simulation) Descriptive Possibly Predictive (queuing, control, graph,insert yours here) Disjoint in ownership and application

hiroshi-miura
Télécharger la présentation

Prescriptive Network Theories

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related