1 / 45

Internet Ecosystem Evolution: Innovating beyond Walled Gardens

Explore internet design philosophy, advanced VoIP services, peer-to-peer VoIP approach, network neutrality, stakeholders' perspectives, and the impact of walled gardens on internet innovation. Uncover the challenges and opportunities shaping the digital landscape.

fjohnny
Download Presentation

Internet Ecosystem Evolution: Innovating beyond Walled Gardens

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. Making services bloom outside the walled garden Henning Schulzrinne (with Jong Yul Kim, Kundan Singh, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Columbia University Dept. of Computer Science

  2. Overview • Internet design philosophy – an attempt at a summary • Advanced VoIP services and issues • emergency calling • location-based services • secure VoIP • spam/spit • quality-of-service • A peer-to-peer approach to VoIP Telekom - February 2006

  3. Internet philosophy • Innovation is created at the edges • providers benefit by increased usage • content innovation • Wikipedia, Flickr, blogs, eBay • cf. WAP • service innovation • IM, Skype, distributed games • Reliability and ubiquity are created by the network • room for improvement (99.5% now) Yahoo iTunes Google MSN mySpace Skype eBay services & applications (HTTP, SIP, RTSP, …) OS vendors software services sockets ISP (IP, DHCP, DNS) enterprise consumer ISP RJ-45 network access (fiber, copper, wireless) natural monopoly or oligopoly geographic range enterprise consumer ISP Telekom - February 2006

  4. Internet philosophy • Small number of narrow and stable interfaces: • HTML (+ PDF, flash) for content • socket API for applications • RJ-45 (Ethernet) for landline & enterprise • 802.11/16/… for wireless • Provides sufficient scale as incentive • reduces uncertainty on platform and access • Allows same applications in enterprise and consumer space • cf. difficulty with wireless applications • Allows same company to provide all three layers • avoids collapse of monopoly rent if bypass succeeds Yahoo iTunes Google MSN mySpace Skype eBay services & applications (HTTP, SIP, RTSP, …) OS vendors software services sockets ISP (IP, DHCP, DNS) enterprise consumer ISP RJ-45 network access (fiber, copper, wireless) natural monopoly or oligopoly geographic range enterprise consumer ISP Telekom - February 2006

  5. IP “hourglass” email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio... Steve Deering, IETF Aug. 2001 Telekom - February 2006

  6. The real Internet hourglass (slightly simplified) p2p (port 80) web web services HTTP TCP IP Ethernet Telekom - February 2006

  7. Internet eco-system Telekom - February 2006

  8. Walled gardens • Walled garden = certain applications can only be provided by the access provider (e.g., wireless carrier) • due to handset lockdown • due to network restrictions • due to lack of service interface (e.g., QoS) • Economic argument: “provides monopoly rent” • variation: don’t just want to be “dumb bit pipe” • but marketing, size, trust advantages don’t depend on this • Technical argument: “reliable, consumer-friendly services require it” • Hard to make work for corporations • doesn’t integrate well with enterprise networks and applications • at best, requires extra servers (BlackBerry email) • Corporations and universities don’t have email carriers, either • some may outsource (e.g., to gmail) • VoIP: large enterprises may contract directly with PSTN gateway provider • everything else can be run in-house Telekom - February 2006

  9. Stakeholders and arguments • Customers • low cost • avoid lock-in • new applications and services • ease of use • Carriers • extract differential value of different kinds of bits • user value of voice vs. email vs. web vs. video • avoid commodization • “Technically necessary” vs. “good for my business” • Will focus on technical issues Telekom - February 2006

  10. Network neutrality • = network does not favor particular applications (or packets) • does not filter, drop, delay based on ports, sources or destinations • “information networks ought to be as neutral as possible between competing content, applications and services” (Wikipedia) • more precise: same services available to everyone, as unbundled service elements • e.g., if QoS, can be purchased separately • e.g., location available without buying restaurant guide • FCC: Powell 2004 • Consumers are entitled to access the lawful Internet content of their choice; • Consumers are entitled to run applications and services of their choice, subject to the needs of law enforcement; • Consumers are entitled to connect their choice of legal devices that do not harm the network; and • Consumers are entitled to competition among network providers, application and service providers, and content providers. • Legal discussion in the US • revision of Telecom Act of 1996 • Variations (Wikipedia) • Most Favored Nation: operators must offer to all companies transit on equal terms, and cannot discriminate as between them; • Radical Bit Anti-Discrimination: operators must pass all packets blindly, and never make any decisions based on information specific to any packet; • Enough and as Good: if operators prioritize bandwidth, they must leave enough and as good bandwidth to permit non-prioritized services to reach consumers; • Tiering only: Operators may discriminate as between their customers, but must offer the same services to content, application and service providers; • Police what you own: Operators may exercise discrimination with respect to entirely private networks, but not inter-networks. Telekom - February 2006

  11. Evolution of VoIP “how can I make it stop ringing?” long-distance calling, ca. 1930 “does it do call transfer?” going beyond the black phone “amazing – the phone rings” catching up with the digital PBX 1996-2000 2000-2003 2004- Telekom - February 2006

  12. Classical IETF interfaces “UNI” “NNI” router proxy server SIP SIP signaling DNS DNS name mapping host end system UA DHCP, PPP BGP OSPF L3 config IPv4/IPv6 IPv4/IPv6 L3 Ethernet SONET L2 Telekom - February 2006

  13. Interconnection approaches Telekom - February 2006

  14. SIP division of labor Telekom - February 2006

  15. IETF “4G” (access-neutral) model Check reputation of columbia.edu sip:alice@columbia.edu  sip:bob@example.com TLS columbia.edu example.com Visited network NSIS NTLP for QoS 802.1x DIAMETER server AP alice@isp.net isp.net Telekom - February 2006

  16. Emergency calling • Location-based service  • route calls to best PSAP based on caller’s location • deliver location information to PSAP to dispatch help • Has to work even if • caller is roaming • has a VSP from another country (or no VSP) • bought phone in Finland • But also supports • better resiliency during catastrophes (Katrina-like events) • multimedia • situational awareness • Standardization efforts: • IETF ECRIT working group  protocols • NENA (National Emergency Number Association)  requirements, overall architecture, transition • ETSI EMTEL  architecture? requirements? • Implemented all-IP prototype at Columbia University • testing with real PSAPs emergency call center Telekom - February 2006

  17. Components of emergency calling now transition all IP Contact well-known number or identifier 112 911 112 911 dial 112, 911 signal sos@ Route call to location-appropriate PSAP selective router VPC DNS Deliver precise location to call taker to dispatch emergency help phone number  location (ALI lookup) in-band  key  location in-band Telekom - February 2006

  18. The core emergency calling problem Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call Telekom - February 2006

  19. UA recognition & UA resolution DHCP (w/loc) LLDP-MED (L2) GPS (outdoors) mapping location  URL 9-1-1 leonianj.gov INVITE sip:psap@leonianj.gov To: urn:service:sos <location> INVITE sip:psap@leonianj.gov To: urn:service:sos <location> Telekom - February 2006

  20. UA recognition & proxy resolution mapping 9-1-1 provider.com INVITE urn:service:sos To: urn:service:sos <location> INVITE sip:psap@leonianj.gov To: urn:service:sos <location> Telekom - February 2006

  21. UA recognition & proxy resolution(proxy location determination) mapping 9-1-1 provider.com INVITE urn:service:sos To: urn:service:sos INVITE sip:psap@leonianj.gov To: urn:service:sos <location> how does proxy insert location? redirect? Telekom - February 2006

  22. Proxy recognition & proxy resolution mapping 9-1-1 provider.com INVITE sip:psap@leonianj.gov To: sip:911@provider.com;user=phone Location: <location> INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone Telekom - February 2006

  23. LUMP architecture G tree guide G G G broadcast (gossip) T1: .us T2: .de G resolver T2 (.de) seeker 313 Westview Leonia, NJ US T3 (.dk) T1 (.us) Leonia, NJ  sip:psap@leonianj.gov Telekom - February 2006

  24. Location-based services • Guidance and mapping services • including meta-data such as traffic information • Finding services based on location • physical services (stores, restaurants, ATMs, …) • electronic services (media I/O, printer, display, …) • needs to use end system location information • Using location to improve (network) services • communication • incoming communications changes based on where I am • proximity triggers communications • configuration • devices in room adapt to their current users • awareness • others are (selectively) made aware of my location • security • proximity grants temporary access to local resources Telekom - February 2006

  25. GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) target location server location recipient notification interface publication interface GEOPRIV PIDF-LO SUBSCRIBE presentity presence agent watcher SIP presence PUBLISH NOTIFY caller callee SIP call INVITE INVITE Telekom - February 2006

  26. The role of presence for call routing • Presence as cross-system glue • narrow interface for location information, device state, user behavior, … • Two modes: • watcher uses presence information to select suitable contacts • advisory – caller may not adhere to suggestions and still call when you’re in a meeting • user call routing policy informed by presence • likely less flexible – machine intelligence • “if activities indicate meeting, route to tuple indicating assistant” • “try most-recently-active contact first” (seq. forking) PUBLISH PA NOTIFY translate RPID CPL LESS INVITE Telekom - February 2006

  27. Location data & privacy • Location = • civic location (street) • geo (longitude + latitude) • descriptive (“hotel”) • All presence data, particularly location, is highly sensitive • Basic location object (PIDF-LO) describes • distribution (binary) • retention duration • Policy rules for more detailed access control • who can subscribe to my presence • who can see what when <tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1“ srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z </gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple> Telekom - February 2006

  28. Presence & location privacy rules Conditions identity, sphere, validity time of day current location identity as <uri> or <domain> + <except> Actions watcher confirmation Transformations include information reduced accuracy User gets maximum of permissions across all matching rules Extendable to new presence data rich presence biological sensors mood sensors Telekom - February 2006

  29. Example privacy rules document <rule id=1> <identity><id>user@example.com</id></identity> <conditions> <sub-handling>allow</sub-handling> <actions> <provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme> </provide-services> <provide-person>true</provide-person> <provide-activities>true</provide-activities> <provide-user-input>bare</provide-user-input> <ruleset> <transformations> Telekom - February 2006

  30. Location-based service language NOTIFY true false action alert IM alert incoming proximity message outgoing log conditions occupancy actions events notify call message time transfer subscription join Telekom - February 2006

  31. Secure VoIP • What is security? • Caller privacy protection: media + signaling •  secure RTP (SRTP) + TLS or S/MIME • Anonymity protection • the anonymity of large providers • Theft-of-service protection • access link: 802.1x and similar (+ RADIUS) • voice service: SIP Digest authentication + RADIUS/DIAMETER for roaming • Conflicts of goals • theft-of-service protection ↔emergency calling • anonymity, caller privacy ↔ legal intercept Telekom - February 2006

  32. Secure VoIP, cont’d. • Assume secure channel (TLS) and/or SIP payload (S/MIME) • Session keys are exchanged in-band between parties • e.g., via SDP • Used for SRTP keying • Possibly use SIP preconditions to require use of secure channel and negotiate crypto algorithms Telekom - February 2006

  33. Quality of service • QoS = packet-level loss & delay + reliability (longer outages) • latter tends to be more of a problem… • Per-flow resource reservation scales well in access networks • Difficulty: most of the time, high-priority traffic sees same backbone queueing delay (~0) and loss (0) as low-priority traffic • thus, incentive to label traffic best effort most of the time • Hypothesis: most QoS problems are self-interference and access link problems • can be solved with DiffServ and 802.11e • may need rate limit for high-priority traffic on access link self-interference backbone access links peering Telekom - February 2006

  34. New IETF signaling protocol architecture: NSIS NAT/FW, QoS, measurement, … • Generalized version of RSVP: • separating transport & signaling applications • allows use of secure transport • supports node mobility • Support signaling-layer protocol (NSLP) transport layer (NTLP) (GIST) transport layer (RA + UDP; TCP [+ TLS]) Telekom - February 2006

  35. Unsolicited calls and messages: “SPIT” • SPIT = Spam for Internet Telephony • spim = spam for IM • Possibly at least as large a problem as email spam • more annoying (ring, pop-up) • Bayesian content filtering unlikely to work •  identity-based filtering • PKI for every user unrealistic • Use two-stage authentication • well-proven domain-level authentication via TLS certs • SIP identity work  outbound proxy certifies • uses Digest auth locally (shared secret) • “I, example.com have verified that this is Alice”\ • Also proposed: • computational puzzles • e-postage mutual PK authentication (TLS) home.com Digest Telekom - February 2006

  36. Spam for Internet Telephony (SPIT) • Black lists only modestly helpful • “bad” users can likely get fresh identities  personal whitelist (called, emailed)  domain reputation  user reputation relies on trustable identity Telekom - February 2006

  37. SPIT: domain classification • Classification of domains based on their identity instantiation and maintenance procedures plus other domain policies. • Admission controlled domains • Strict identity instantiation with long term relationships • Example: Employees, students, bank customers • Bonded domains • Membership possible only through posting of bonds tied to a expected behavior • Membership domains • No personal verification of new members but verifiable identification required such as a valid credit card and/or payment • Example: E-bay, phone and data carriers • Open domains • No limit or background check on identity creation and usage • Example: Hotmail • Open, rate limited domains • Open but limits the number of messages per time unit and prevents account creation by bots (CAPTCHA) • Example: Yahoo Telekom - February 2006

  38. P2P for VoIP • SIP VoIP is peer-to-peer • media and mid-call requests are sent end-to-end • but fixed server set registered in DNS for AOR domain •  p2p = user nodes perform server functionality • Motivation • scalable growth: server count grows with user population • quick deployment in network islands • Skype envy  • Functions that can be placed on peer-to-peer nodes • Signaling and identifier mapping • map AOR alice@example.com  one or more contacts • Presence • publish and subscribe • NAT traversal • discover external IP address (STUN) + relaying where needed • Media storage • voice mail, ring tones, recordings, … • Conferencing • mixing and replication Telekom - February 2006

  39. P2P-SIP: Using an External P2P network (DHT) Data model Treat DHT as database Service model Join DHT to provide service [5] bob [3] [2] bob 192.1.2.3 [1] DHT [1] Service node (128.3.4.5) [4] [5] [3] DHT alice [2] [1] join(128.3.4.5) [2] lookup(H(bob)) gives 128.3.4.5 [3] REGISTER sip:bob to 128.3.4.5 [4] lookup(H(bob)) gives 128.3.4.5 [5] INVITE sip:bob to 128.3.4.5 alice [1] put(k,192.1.2.3), k is H(bob) [2] get(k) gives 192.1.2.3 [3] INVITE sip:bob to 192.1.2.3 Telekom - February 2006

  40. P2P-SIP: Logical Operations • Contact management • put (user id, signed contact) • Key storage • User certificates and private configurations • Presence • put (subscribee id, signed encrypted subscriber id) • Composition needs service model • Offline message • put (recipient, signed encrypted message) • NAT and firewall traversal • STUN and TURN server discovery needs service model Telekom - February 2006

  41. P2P-SIP: Implementation in SIPc • OpenDHT • Trusted nodes • Robust • Fast enough (<1s) • Identity protection • Certificate-based • SIP id == email • P2P for Calls, IM, presence, offline message, STUN server discovery and name search Telekom - February 2006

  42. P2P-SIP: What is OpenDHT? • Service model, unlike earlier library model of Chord or CAN • DHT accessed via SunRPC & XML-RPC • Easy deployment and maintenance • 200-300 Bamboo DHT nodes on PlanetLab • Public DHT service running since April 2004 • Many existing applications: i3, CFS, Ostream, HIP,… • DHT API (server side on Bamboo nodes) • PUT(key,value,H(secret),ttl) where H() is SHA1 • GET(key)  (value,H(secret),remaining-ttl) • REMOVE(key,H(value),secret,ttl) • ReDiR API (client side for lookup/join/leave) • Can build anycast, multicast, range search using this • Fair resource (disk) allocation among clients (IP addr) Telekom - February 2006

  43. Hybrid architecture • Cross register, or • Locate during call setup • DNS, or • P2P-SIP hierarchy Telekom - February 2006

  44. Concerns about 3G + NGN • Complexity • many signaling hops  server cost, delay • Assumption of heavy-weight peering • “lawyer employment act of 2004” • rather than email-style “all I need is a name” peering • Coupling of application signaling and network signaling • incentive to bypass if cost/byte is higher • makes it more costly to add new QoS-sensitive applications • IPTV, remote instrumentation, etc. • got us tromboning before: mobility issues Telekom - February 2006

  45. Conclusion • Importance of few, narrow, stable interfaces • Finished or emerging solutions for providing • emergency calling • location-based services • VoIP security • SPIT protection • QoS • as building blocks, not monolithic architecture • allow change as technology improves • Walled gardens are failure prone • if wall falls, sudden collapse ($1/minute  0 minutes) • Client-server SIP complemented by peer-to-peer SIP • quick setup situations • low-cost installations (SOHO) Telekom - February 2006

More Related