1 / 75

Principles and Lessons for a New Internet and 4G Wireless Networks

Principles and Lessons for a New Internet and 4G Wireless Networks. Prof. Henning Schulzrinne Dept. of Computer Science Columbia University. Overview. Interest in revising Internet architecture What didn’t we think of the first time What has made the Internet successful

EllenMixel
Download Presentation

Principles and Lessons for a New Internet and 4G Wireless Networks

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. Principles and Lessons for a New Internet and 4G Wireless Networks Prof. Henning Schulzrinne Dept. of Computer Science Columbia University WWIC (Coimbra, Portugal)

  2. Overview • Interest in revising Internet architecture • What didn’t we think of the first time • What has made the Internet successful • Built-in vs. bolted on • User issues: what bothers users • Internet infrastructure: the plumbing • Network management • Talking meta: research and standardization WWIC (Coimbra, Portugal)

  3. Outline • Applications and upper layers • Internet protocol infrastructure • Network management • Network standards • Networking research WWIC (Coimbra, Portugal)

  4. The three Cs of Internet applications grossly simplified... communications commerce community what users care about what users care about research focus WWIC (Coimbra, Portugal)

  5. Killer Application • Carriers looking for killer application • justify huge infrastructure investment • “video conferencing” (*1950 – †2000) • ? • “There is no killer application” • Network television block buster  YouTube hit • “Army of one” • Users create their own custom applications that are important to them • Little historical evidence that carriers (or equipment vendors) will find that application if it exists • Killer app = application that kills the carrier WWIC (Coimbra, Portugal)

  6. Internet transition: applications • Moving analog applications to Internet • digitization of communication largely completed • Extending reach of application • mobile devices • vehicles • Broadening access • Minitel: SNCF had train schedule service • web: anybody can have a blog • Allowing customization and creation • web pages to code modules WWIC (Coimbra, Portugal)

  7. Completing the migration of comm. applications WWIC (Coimbra, Portugal)

  8. Migration of applications WWIC (Coimbra, Portugal)

  9. Building Internet applications 80% care about this level extensible CMS, Wiki (Drupal, Mambo, Joomla, ...) Ruby on Rails, Spring, ... Ajax, SOAP PHP, Java w/libraries Java RMI, HTTP taught in Networking 101 C/C++ with sockets custom protocols on UDP, TCP WWIC (Coimbra, Portugal)

  10. User issues (guesses) • Lack of trust • small mistakes  identity gone • can’t tell when one has “lost the wallet” • waste time on spam, viruses, worms, spyware, … • Lack of reliability • 99.5% instead of 99.999% • even IETF meeting can’t get reliable 802.11 connectivity • Lack of symmetry • asymmetric bandwidth: ADSL • asymmetric addressing: NAT, firewalls  client(-server) only, packet relaying via TURN or p2p • Users as “Internet mechanics” • why does a user need to know whether to use IMAP or POP? • navigate circle of blame WWIC (Coimbra, Portugal)

  11. Left to do: glue protocols • Lots of devices and services • cars • household • environment • Generally, stand-alone • e.g., GPS can’t talk to camera • Home • home control networks have generally failed • cost, complexity • Environment • “Internet of things” • tag bus stops, buildings, cars, ... WWIC (Coimbra, Portugal)

  12. Left to do: event notification • notify (small) group of users when something of interest happens • presence = change of communications state • email, voicemail alerts • environmental conditions • vehicle status • emergency alerts • kludges • HTTP with pending response • inverse HTTP --> doesn’t work with NATs • Lots of research (e.g., SIENA) • IETF efforts starting • SIP-based • XMPP WWIC (Coimbra, Portugal)

  13. GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) target location server location recipient notification interface publication interface GEOPRIV SUBSCRIBE presentity presence agent watcher SIP presence PUBLISH NOTIFY caller callee SIP call INVITE INVITE WWIC (Coimbra, Portugal)

  14. Configuration complexity • 65% of attacks exploit mis-configured systems • Human error accounts for 48% of wide area network outages • Yankee Group 2002: operator error is the largest cause of failures and largest contributor to time to repair; in two of the three (surveyed) ISPs, configuration errors are the largest category of operator errors. • 45% WAN operations cost attributed to component configuration • Yankee Group, 1998 • Although setup (of the trusted computing base) is much simpler than code, it is still complicated, it is usually done by less skilled people, and while code is written once, setup is different for every installation. So we should expect that it’s usually wrong, and many studies confirm this expectation. (B. Lampson) WWIC (Coimbra, Portugal)

  15. Ideally, applications should only need a user name and some credential password, USB key, host identity (MAC address), … More than DHCP: device needs to get application services SMTP, IMAP, POP, ... security variations policy information (“sorry, no video”) user data (address book) Multiple sources of configuration information local network application service provider Configuration information may change dynamically event notification Needs to allow no-touch deployment of thousands of devices Open issues: Configuration WWIC (Coimbra, Portugal)

  16. Mobile systems - reality GPS • idea: special purpose (phone) --> universal communicator • idea is easy... • mobile equipment: laptop + phone • sufficiently different UI and capabilities • we all know the ideal (converged) cell phone • difficulty is not technology, but integration and programmability • (almost) each phone has a different flavor of OS • doesn’t implement all functionality in Java APIs • no dominant vendor (see UNIX/Linux vs. Microsoft) • external interfaces crippled or unavailable • e.g., phone book access location data WWIC (Coimbra, Portugal)

  17. Outline • Applications and upper layers • Internet protocol infrastructure • Network management • Network standards • Network research WWIC (Coimbra, Portugal)

  18. What has made the Internet successful? • 36 years  approaching mid-life crisis  time for self-reflection •  next generation suddenly no longer finds it hip • Transparency in the core • new applications (web, VoIP, games) • Narrow interfaces • socket interface, resolver • HTTP and SMTP messaging as applications • prevent change leakage • Low barrier to entry • L2: minimalist assumptions • technical: basic connectivity is within • economical: below $20? • Commercial off-the-shelf systems • scale: compare 802.11 router vs. cell base station WWIC (Coimbra, Portugal)

  19. What has gone wrong? • Familiar to anybody who has an old house… • Entropy • as parts are added, complexity and interactions increase • Changing assumptions • trust model: research colleagues  far more spammers and phishers than friends • AOL: 80% of email is spam • internationalization: internationalized domain names, email character sets • criticality: email research papers  transfers $B and dial “9-1-1” • economics: competing providers • “Internet does not route money” (Clark) • Backfitting • had to backfit security, I18N, autoconfiguration, … •  Tear down the old house, gut interior or more wall paper? WWIC (Coimbra, Portugal)

  20. In more detail… • Deployment problems • loss of transparency (NATs, deep-packet inspection, ...) • Layer creep • Simple and universal wins • Scaling in human terms • Cross-cutting concerns, e.g., • CPU vs. human cycles • we optimize the $100 component, not the $100/hour labor • introspection • graceful upgrades • no policy magic WWIC (Coimbra, Portugal)

  21. Internet design principles did not anticipate cyber attack, exfiltration, malicious control cooperative protocols --> insider threat “permit-by-default” instead of “deny-by-default” malicious use of resources remains anonymous & untraceable J Christopher Ramming, IAMANET briefing, April 2006, based on D. Clark, SIGCOMM 1998 WWIC (Coimbra, Portugal)

  22. Core goals for new networks • reliability • diagnosability • sustainability • adaptability • survivability WWIC (Coimbra, Portugal)

  23. Survivability • Real world: locks keep out the honest • until the police arrives • Internet: assumption of lawlessness • no global law enforcement • carriers have little interest in policing their users • bots, spam • must survive extended periods of attacks • From permit-by-default to deny-by-default WWIC (Coimbra, Portugal)

  24. Reliability • From secondary medium to core • Office without phone vs. without Internet • Applications: 2 servers exponentially better than 1 • costs “only” doubles • but most application protocols don’t fail over automatically • examples: HTTP, IMAP, POP, NFS • exceptions: SMTP, SIP • Networks: 2 networks exponentially better than 1 • most (US) residences are served by 3 networks: DSL, cable, cellular • no good multi-homing technology that scales • economics dubious - via neighbors? WWIC (Coimbra, Portugal)

  25. Internet ca. 2005 H. Zimmermann ca. 1980 Internet ca. 1995 application application presentation SOAP application session HTTP transport TCP TCP network IP IP-in-IP IP MPLS, PoE link 802.3 PoS, ATM physical physical physical The transformation of protocol stacks WWIC (Coimbra, Portugal)

  26. Cause of death for the next big thing WWIC (Coimbra, Portugal)

  27. Simple wins (mostly) • Examples: • Ethernet vs. all other L2 technologies • HTTP vs. HTTPng and all the other hypertext attempts • SMTP vs. X.400 • SDP vs. SDPng • TLS vs. IPsec (simpler to re-use) • no QoS & MPLS vs. RSVP • DNS-SD (“Bonjour”) vs. SLP • SIP vs. H.323 (but conversely: SIP vs. Jabber, SIP vs. Asterisk) • the failure of almost all middleware • future: demise of 3G vs. plain SIP • Efficiency is not important • BitTorrent, P2P searching, RSS, … WWIC (Coimbra, Portugal)

  28. Measuring complexity • Traditional O(.) metrics rarely helpful • except maybe for routing protocols • Focus on parsing, messaging complexity • marginally helpful, but no engineering metrics for trade-offs • No protocol engineering discipline, lacking • guidelines for design • learning from failures • we have plenty to choose from – but hard to look at our own (communal) failures • re-usable components • components not designed for plug-and-play • “we don’t do APIs”  we don’t worry about whether a simple API can be written that can be taught in Networking 101 WWIC (Coimbra, Portugal)

  29. Possible complexity metrics • new code needed (vs. reuse)  less likely to be buggy or have buffer overflows • e.g., new text format almost the same • numerous binary formats • security components • necessary transition: bespoke  off-the-rack protocols • new identities and identifiers needed • number of configurable options + parameters • must be configured & can be configured (with interop impact) • discoverable vs. manual/unspecified • SIP experience: things that shouldn’t be configurable will be • RED experience: parameter robustness • mute programmer interop test: two implementations, no side channel • number of “left-to-local policy” • DSCP confusion • start-up latency (“protocol boot time”) • IPv4 DAD, IGMP WWIC (Coimbra, Portugal)

  30. Democratization of protocol engineering • Traditional Internet application protocols (IETF et al.): • one protocol for each type of application: • SMTP for email, ftp for file transfer, HTTP for web access, POP for email retrieval, NNTP for netnews, … • slow protocol development process • re-do security (authentication) for each • each new protocol has its own text encoding • similarity across protocols: SMTP-style headers • Content-Type: text/plain; charset="us-ascii"; format=flowed • large parsing exposure  new buffer overflows for each protocol • Separate worlds: • most of the new protocols in the real world based on WS • IETF stuck in bubble of one-off protocols  more fun! • re-use considered a disadvantage • insular protocols that have local cult following (BEEP) WWIC (Coimbra, Portugal)

  31. The transformation of protocol design • One application, one protocol  common infrastructure for new application • Old model: • RPC for corporate “one-off” applications • custom protocols for common Internet-scale applications • Far too many new applications • and not enough protocol engineers • network specialist  application specialist • new IETF application protocol design takes ~5 years • Many of the applications (email to file access) could be modeled as RPC custom text protocol (ftp) ASN.1-based (SNMP, X.400) RFC 822 protocol (SMTP, HTTP, RTSP, SIP, …) use XML for protocol bodies (IETF IM & presence) SOAP and other XML protocols WWIC (Coimbra, Portugal)

  32. Why are web services succeeding(*) after RPC failed? • SOAP = just another remote procedure call mechanism • plenty of predecessors: SunRPC, DCE, DCOM, Corba, … • “client-server computing” • all of them were to transform (enterprise) computing, integrate legacy applications, end world hunger, … • Why didn’t they? • Speculation: • no web front end (no three-tier applications) • few open-source implementations • no common protocol between PC client (Microsoft) and backend (IBM mainframes, Sun, VMS) • corporate networks local only (one site), with limited backbone bandwidth Corba DCOM SunRPC WWIC (Coimbra, Portugal) (*) we hope

  33. Time for a new protocol stack? • Now: add x.5 sublayers and overlay • HIP, MPLS, TLS, … • Doesn’t tell us what we could/should do • or where functionality belongs • use of upper layers to help lower layers (security associations, authorization) • what is innate complexity and what is entropy? • Examples: • Applications: do we need ftp, SMTP, IMAP, POP, SIP, RTSP, HTTP, p2p protocols? • Network: can we reduce complexity by integrating functionality or re-assigning it? • e.g., should e2e security focus on transport layer rather than network layer? • probably need pub/sub layer – currently kludged locally (email, IM, specialized) WWIC (Coimbra, Portugal)

  34. NSF “Green Field” approach • US National Science Foundation (NSF) working on new funding thrust  next-generation Internet • idea: incremental components  new architecture • vs. traditional “brown field” approach • Two major components • GENI: large-scale experimental testbed for testing next-generation ideas • building on PlanetLab (hundreds of public-access servers)  p2p, CDN, measurement infrastructures • probably offers circuits (optical or virtual with bandwidth guarantees) • ~$300M (not yet allocated) • FIND: • regular research program within NETS ($15m) • prepare architecture designs WWIC (Coimbra, Portugal)

  35. NSF: FIND and GENI, cont’d • Fundamental notions: • not constrained by existing Internet architecture • Difficulties: • not coordinated  too many moving pieces? • no single research team can do everything • point optimization: Internet for • benchmarks missing • how do you compare architectures? • are there quantifiable requirements? • are there metrics to compare different approaches? • user-related metrics? • Cynic’s prediction based on the past: • IPv6: “you’ll get security, QoS, autoconfiguration, mobility, …” • IPv4: “good ideas, I’ll do those, too” WWIC (Coimbra, Portugal)

  36. Maintain success factors, such as service transparency low barrier to entry narrow interfaces New guidelines optimize human cycles, not CPU cycles design for symmetry security built-in, not bolted-on everything can be mobile, including networks sending me data is a privilege, not a right reliability paramount isolation of flows New possibilities: another look at circuit switching? knowledge and control (“signaling”) planes? separate packet forwarding from control better alignment of costs and benefit better scaling for Internet-scale routing more general services (My) guidelines for a new Internet WWIC (Coimbra, Portugal)

  37. More “network” services • Currently, very specialized and limited • packet forwarding • DNS for identifier lookup • DHCP for configuration • New opportunities • packet forwarding with control • general identifier storage and lookup • both server-based and peer-to-peer • SLP/Jini/UDDI service location  ontology-based data store • network file storage  for temporarily-disconnected mobiles • network computation  translation, relaying • trust services ( IRT trust paths work) WWIC (Coimbra, Portugal)

  38. More than just encryption! Need identity and role-based certificates May want reverse-path reachability (bank  customer) Security WWIC (Coimbra, Portugal)

  39. NGN or what’s wrong with 3G • NGN = next-generation network • roughly, 3G on landline • really, ISDN 2.0 on packets • SIP for signaling, IPv6 • Problems • complexity: gateways to old world • coupling: link-layer properties only available to certain applications • e.g., voice-specific link behavior (FEC, delay) • closed: may be difficult to integrate with enterprise systems • regular SIP phones may not work properly WWIC (Coimbra, Portugal)

  40. What’s (my) 4G? • Definition: fixes all the things that 3G got wrong... • voice legacy (3G ~ B-ISDN) • high cost • system complexity • Wireless as access network • already happening: 3G-802.11 bridges • application shouldn’t care about access mode or carrier --> more applications • But with discoverable and configurable path properties • not a wireless-specific issue! • May be less a technical than economics problem • same bits, different value --> capture consumer surplus WWIC (Coimbra, Portugal)

  41. Internet (re)engineering: summing up • Traditional protocol engineering • “must do congestion control” • “must do security” • “must be efficient” • New module engineering • must reduce operations cost • out-of-the-box experience • re-usable components • most protocol design will be done by domain experts (cf. PHP vs. C++) • What would a clean-room design look like? • keep what made Internet successful • generalize & adjust to new conditions WWIC (Coimbra, Portugal)

  42. Outline • User perspective • Internet protocol infrastructure • Network management • Network standards • Networking research WWIC (Coimbra, Portugal)

  43. Network Management  Transition in cost balance • Total cost of ownership • Ethernet port cost  $10 • about 80% of Columbia CS’s system support cost is staff cost • about $2500/person/year  2 new PCs/year • much of the rest is backup & license for spam filters  • Does not count hours of employee or son/daughter time • PC, Ethernet port and router cost seem to have reached plateau • just that the $10 now buys a 100 Mb/s port instead of 10 Mb/s • All of our switches, routers and hosts are SNMP-enabled, but no suggestion that this would help at all WWIC (Coimbra, Portugal)

  44. Circle of blame probably packet loss in your Internet connection  reboot your DSL modem ISP probably a gateway fault  choose us as provider OS VSP must be a Windows registry problem  re-install Windows app vendor must be your software  upgrade WWIC (Coimbra, Portugal)

  45. Diagnostic undecidability • symptom: “cannot reach server” • more precise: send packet, but no response • causes: • NAT problem (return packet dropped)? • firewall problem? • path to server broken? • outdated server information (moved)? • server dead? • 5 causes  very different remedies • no good way for non-technical user to tell • Whom do you call? WWIC (Coimbra, Portugal)

  46. VoIP user experience • Only 95-99.5% call attempt success • “Keynote was able to complete VoIP calls 96.9% of the time, compared with 99.9% for calls made over the public network. Voice quality for VoIP calls on average was rated at 3.5 out of 5, compared with 3.9 for public-network calls and 3.6 for cellular phone calls. And the amount of delay the audio signals experienced was 295 milliseconds for VoIP calls, compared with 139 milliseconds for public-network calls.” (InformationWeek, July 11, 2005) • Mid-call disruptions common • Lots of knobs to turn • Separate problem: manual configuration WWIC (Coimbra, Portugal)

  47. Traditional network management model X SNMP “management from the center” WWIC (Coimbra, Portugal)

  48. Old assumptions, now wrong • Single provider (enterprise, carrier) • has access to most path elements • professionally managed • Problems are hard failures & elements operate correctly • element failures (“link dead”) • substantial packet loss • Mostly L2 and L3 elements • switches, routers • rarely 802.11 APs • Problems are specific to a protocol • “IP is not working” • Indirect detection • MIB variable vs. actual protocol performance • End systems don’t need management • DMI & SNMP never succeeded • each application does its own updates WWIC (Coimbra, Portugal)

  49. Management what causes the most trouble? network understanding fault location we’ve only succeeded here configuration element inspection WWIC (Coimbra, Portugal)

  50. Managing the protocol stack protocol problem authorization asymmetric conn (NAT) media echo gain problems VAD action RTP SIP protocol problem playout errors UDP/TCP TCP neg. failure NAT time-out firewall policy IP no route packet loss WWIC (Coimbra, Portugal)

More Related