paradoxes in internet
play

PARADOXES IN INTERNET S. Keshav University of Waterloo - PowerPoint PPT Presentation

PARADOXES IN INTERNET S. Keshav University of Waterloo ARCHITECTURE Chair, ACM SIGCOMM UNIVERSITY OF WATERLOO UNIVERSITY OF WATERLOO Founded 1957 35,000 students Faculty of Mathematics 250 faculty 8000 undergrads 1000


  1. PARADOXES IN INTERNET S. Keshav University of Waterloo ARCHITECTURE Chair, ACM SIGCOMM

  2. UNIVERSITY OF WATERLOO UNIVERSITY OF WATERLOO Founded 1957 35,000 students Faculty of Mathematics • 250 faculty • 8000 undergrads • 1000 grads

  3. http://www.computerhistory.org/internethistory

  4. http://www.computerhistory.org/internethistory

  5. 1969 vs. 2014

  6. 1969 vs. 2014 http://www.computerhistory.org/internethistory

  7. http://www.ict-mplane.eu/public/about-mplane-intelligent-measurement-plane-future-network-and-application

  8. THE VISION FOR COMPUTER NETWORKING Anytime access to any information by anyone anywhere

  9. ARE WE DONE?

  10. MAYBE NOT…

  11. Images: http://www.cupcakeproject.com/2012/06/homemade

  12. Images: http://www.cupcakeproject.com/2012/06/homemade-spam

  13. Images: http://www.cupcakeproject.com/2012/06/homemade-spam-recipe.html

  14. WHY CAN’T WE SIMPLY BLOCK SPAMMERS?

  15. BACK TO BASICS… http://bit.kuas.edu.tw/~csshieh/teach/

  16. CLIENT SERVER MODEL Spammer You

  17. REALITY You Spammer …

  18. ISP RELATIONSHIP You Spammer Your ISP Spammer’s ISP …

  19. INFORMATION HIDING You Spammer Your ISP Spammer’s ISP …

  20. THE REAL PROBLEM Narrow AS-AS relationship  Data plane: Packet exchange  Control plane: Route information exchange Identities (and QoS) do not traverse AS boundaries AS behaviour is unregulated beyond packet transfer

  21. THESIS Many of the key problems in the Internet today are due to its origins as an academic research project The very things that led to its success lie at the heart of its failures

  22. BACK TO THE BEGINNING… Clark, David. "The design philosophy of the DARPA Internet protocols." ACM SIGCOMM Computer Communication Review 18.4 (1988): 106-114

  23. ORIGINAL DESIGN GOALS

  24. ORIGINAL DESIGN GOALS

  25. VERY SUCCESSFUL! http://fortune.com/2014/06/23/telecom-companies-count-386-billion-in-lost-revenue-to-skype-whatsapp

  26. HOW TO REDUCE COST? FACT: Computer communication is inherently bursty CONSEQUENCE: Allocating a circuit (‘phone call’) to it is expensive Cheaper to share (‘multiplex’) a circuit among many end-to-end communications

  27. A B

  28. A B C D

  29. A B C D

  30. A B C D

  31. A B C D

  32. A B C D

  33. A B C D

  34. A B C D Drop

  35. A B C D Enqueue

  36. A B C D Enqueue But this adds delay!

  37. A B C D Enqueue Amount of delay depends on the load…

  38. M/M/1 QUEUEING DELAY Queueing delay Load

  39. QUALITY OF SERVICE  Four well-known approaches  Overprovisioning  Admission control  Differential service quality: prioritize delay-sensitive flows  Drop packets when the queue size grows, expecting sources to respond

  40. QUALITY OF SERVICE  All approaches have serious problems  Overprovisioning  Expensive  Admission control  Requires end-to-end adoption  Impossible to allocate costs (more later)  Differential service quality: prioritize delay-sensitive flows  Requires changes to scheduling disciplines at every multiplexor  Drop packets when the queue size grows, expecting sources to respond  Requires complex tuning  Assumes cooperation

  41. BOTTOM LINE The primary design goal of the Internet makes it inherently unsuitable for real-time communication

  42. ORIGINAL DESIGN GOALS

  43. ORIGINAL DESIGN GOALS Clark, David. "The design philosophy of the DARPA Internet protocols." ACM SIGCOMM Computer Communication Review 18.4 (1988): 106

  44. THE INTERNET IS A NETWORK OF NETWORKS

  45. ACCOMMODATING HETEROGENEITY

  46. NARROW INTERFACE

  47. NARROW INTERFACE Allows interoperability across heterogeneous technologies Easy to implement Allows independent evolution

  48. VERY SUCCESSFUL The architecture has survived the transition of individual ASs from dialup lines to multi-lambda optical fibers from text-based interaction to multimedia on wireless devices while retaining interoperability!

  49. BUT… Allows interoperability across No support for quality of heterogeneous technologies service Easy to implement Allows independent evolution

  50. AND… Allows interoperability across No support for quality of service heterogeneous technologies Unconstrained implementation Easy to implement  Arbitrary layering Allows independent evolution  Impossible to debug performance

  51. Source: Designing Multi-layer Carrier Networks for Capacity and Survivability, OPNETWORK 2012

  52. ORIGINAL DESIGN GOALS

  53. ORIGINAL DESIGN GOALS Clark, David. "The design philosophy of the DARPA Internet protocols." ACM SIGCOMM Computer Communication Review 18.4 (1988): 106

  54. ORIGINAL DESIGN GOALS Clark, David. "The design philosophy of the DARPA Internet protocols." ACM SIGCOMM Computer Communication Review 18.4 (1988): 106

  55. ORIGINAL DESIGN GOALS Clark, David. "The design philosophy of the DARPA Internet protocols." ACM SIGCOMM Computer Communication Review 18.4 (1988): 106

  56. SUPPORTING MULTIPLE SERVICE TYPES TCP and UDP support a huge variety of protocols An unqualified success! But…

  57. SUPPORTING MULTIPLE SERVICE TYPES Even the 1988 paper abandons real-time services

  58. ORIGINAL DESIGN GOALS Clark, David. "The design philosophy of the DARPA Internet protocols." ACM SIGCOMM Computer Communication Review 18.4 (1988): 106

  59. ORIGINAL DESIGN GOALS

  60. DISTRIBUTED MANAGEMENT Distributes the task of management using Autonomous Systems

  61. WEAK CENTRALIZATION ICANN IANA Registries DNS TLDs

  62. DISTRIBUTED MANAGEMENT Allows rapid deployment Allows independent evolution Delegation allows massive scaling  DNS

  63. DISTRIBUTED MANAGEMENT Allows rapid deployment With narrow interfaces, makes quality of service Allows independent evolution even more challenging Delegation allows massive scaling  DNS

  64. DISTRIBUTED MANAGEMENT Allows rapid deployment With narrow interfaces, makes quality of service even more challenging Allows independent evolution No network-wide identity Delegation allows massive scaling  Security nightmare  DNS  Spam, DDOS, hacking, …

  65. DISTRIBUTED MANAGEMENT Allows rapid deployment With narrow interfaces, makes quality of service even more challenging Allows independent evolution No network-wide identity Delegation allows massive scaling  Security nightmare  DNS  Spam, DDOS, hacking, … No single view into the network  Makes networks unmanageable

  66. DISTRIBUTED MANAGEMENT Allows rapid deployment With narrow interfaces, makes quality of service even more challenging Allows independent evolution No network-wide identity Delegation allows massive scaling  Security nightmare  DNS  Spam, DDOS, hacking, … No single view into the network  Makes networks unmanageable Autonomous systems  Can inspect, modify, and drop packets  No privacy

  67. ORIGINAL DESIGN GOALS

  68. REDUCING ATTACHMENT EFFORT What is needed to get an endpoint on the telephone network?  Verinymous identity!  Endpoint identifier and end-user identity are closely bound  Allows billing and tracing

  69. REDUCING ATTACHMENT EFFORT What is needed to get an endpoint on the Internet ?  IP address, netmask, and IP address of closest router  Makes it very easy to attach a node to the Internet But endpoint identifier and human’s identity are unbound  Enables spam

  70. ORIGINAL DESIGN GOALS

  71. ORIGINAL DESIGN GOALS

  72. ORIGINAL DESIGN GOALS

  73. Images: http://www.cupcakeproject.com/2012/06/homemade-spam-recipe.html

  74. WHAT TO DO?

  75. LET’S REVISIT ONE OF THE GOALS

  76. THIS DESIGN APPROACH IS LONG DEAD… SDN MPLS for traffic shaping Middleboxes  Load balancers  Firewalls  Intrusion detectors  VPN endpoints  …

  77. TELEPHONE NETWORK Can we integrate the best aspects of the Internet with the best aspects of the telephone network?  Prevent spam by allowing identities to be traced  Require privacy from carriers  Make the inter-AS interface richer to allow QoS

  78. Dock Keshav, S.. "Why cell phones will dominate the future internet." ACM SIGCOMM Computer Communication Review 35.2 (2005): 83

  79. TIME TO RETHINK INTERNET ARCHITECTURE

  80. TIME TO BE CREATIVE! Technology trends and future demands  Industrial Internet of Things  Extreme sensing  In-body Internet  Deep Space Internet  Hackers  Need for privacy  Quality of Service

  81. TIME TO BE CREATIVE! Technology trends and future demands  Industrial Internet of Things  Extreme sensing  In-body Internet  Deep Space Internet  Hackers  Spam  Privacy  Quality of Service What should be our new design philosophy? How can we design our future networks to be legacy compatible?

Recommend


More recommend