Networking Research – Vision and Opportunities Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu Overview Network research topics will focus on L3 and above mostly on software optical and electronic switch work continues systems perspective Some samples of IRT research: location-based services service creation network reliability End-to-end QoS estimation Networking is getting into middle years idea current IP 1969, 1980? 1981 TCP telnet ftp 1974 1969 1980 1981 1983 1985 Technologies at ~30 years Other technologies at similar maturity level: air planes: 1903 – 1938 (Stratoliner) cars: 1876 – 1908 (Model T) analog telephones: 1876 – 1915 (transcontinental telephone) railroad: 1800s -- ? Maturing network research Old questions: Can we make X work over packet networks? All major dedicated network applications (flight reservations, embedded systems, radio, TV, telephone, fax, messaging, …) are now available on IP Can we get M/G/T bits to the end user? Raw bits everywhere: “any media, anytime, anywhere” New questions: Dependency on communications Can we make the network reliable? Can non-technical users use networks without becoming amateur sys-admins? auto/zeroconfiguration, autonomous computing, self-healing networks, … Can we prevent social and financial damage inflicted through networks (viruses, spam, DOS, identity theft, privacy violations, …)? Standardization Really two facets of standardization: 1. 2. public, interoperable description of protocol, but possibly many (Tanenbaum) reduction to 1-3 common technologies LAN: Arcnet, tokenring, ATM, FDDI, DQDB, … Ethernet WAN: IP, X.25, OSI IP Have reached phase 2 in most cases, with RPC (SOAP) and presentation layer (XML) most recent 'conversions' Observations on progress 1960s: military professional consumer Oscillate: convergence divergence now, often reversed continued convergence clearly at physical layer niches larger support separate networks Communications technologies rarely disappear (as long as operational cost is low): exceptions: telex, telegram, semaphores fax, email X.25 + OSI, X.400 IP, SMTP analog cell phones History of networking History of networking = non-network applications migrate postal & intracompany mail, fax email, IM broadcast: TV, radio interactive voice/video communication VoIP information access web, P2P disk access iSCSI, Fiberchannel-over-IP Transition of networking Maturity cost dominates can get any number of bits anywhere, but at considerable cost and complexity casually usable bit density still very low Specialized commodity OPEX (= people) dominates installed and run by 'amateurs' need low complexity, high reliability Network evolution Only three modes, now thoroughly explored: packet/cell-based message-based (application data units) session-based (circuits) Replace specialized networks left to do: embedded systems need cost(CPU + network) < $10 cars industrial (manufacturing) control commercial buildings (lighting, HVAC, security; now LONworks) remote controls, light switches keys replaced by biometrics Commercial access cost (T1) $700 $600 $/month $500 $400 $300 $200 $100 $0 1996 1998 2000 Year 2001 T1 2002 2003 Transit cost (OC-3, NY – London) Disk storage cost (IDE) Cost $100,000.00 $/GB $10,000.00 $1,000.00 $100.00 $10.00 $1.00 May-79 Feb-82 Nov-84 Aug-87 May-90 Jan-93 Date Oct-95 Jul-98 Apr-01 Jan-04 Research directions What’s promising/interesting – two different axes: Intellectual merit interesting analysis, broadly applicable, … Satisfies practical needs may not be a scientific breakthrough Related, but I’ll (mostly) ignore: What’s fashionable/”hot" What’s fashionable (and not) Judging from Infocom submissions and NSF panels: Security of any sort Peer-to-peer networks Ad-hoc and sensor networks Overlay networks Network measurements What’s not: QoS: scheduling, admission control, … Active networks (Native) multicast Observations on network research Frustration with inability to change network infrastructure in less than 10 -- 20 year horizons: Network research community has dismal track record for new applications IPv6 Layer-3 multicast QoS Security web, IM, P2P, … vs. video-on-demand Disconnect from standardization Few attempts to bring research work into standards bodies Standards bodies slow to catch up (e.g., P2P) Network research Old goal: "new universal network" New goal: "niche networks" IP, OSI, ATM may claim universality… peer-to-peer, ad hoc, sensor, mesh, … New research community realizations: difficulty in rolling out new network incrementalism spectrum issues (open spectrum, SDR, …) Infrastructure research questions: Scaling, Reliability, Security Scaling Reliability no major changes for 20+ years (link-state, DV, etc.) two-layer (intra/inter) other routing paradigms reduce operator errors (e.g., XCONF effort in IETF) faster convergence in routing protocols (BGP up to 20-30 minutes!) Security secure routing protocols DOS prevention (pushback, source discovery) Scaling – practical issues Scaling is only backbone problem Depends on network evolution: continuing addition of AS to flat space deep trouble additional hierarchy QoS QoS is meaningless to users care about service availability reliability as more and more value depends on network services, can't afford random downtimes Transport layer After XTP flop, flurry of new protocols: SCTP, DDCP, UDP-lite fill in gaps in TCP/UDP flow control without reliability multiple logical streams with one flow control stream (cf. HTTP/1.1) Issues of very fat pipes single packet loss can wipe out effective throughput Applications Transition of custom protocols to XML, SOAP? but this is the not the first try (DCE, SunRPC, COM, Java RMI, Corba, …) Scalable event systems (research) Presence (SIP/SIMPLE, Jabber, …) P2P systems Application-layer routing, multicast, discovery, … New applications New bandwidth-intensive applications Distributed games often require only lowbandwidth control information Reality-based networking (security) cameras current game traffic ~ VoIP Computation vs. storage vs. communications communications cost has decreased less rapidly than storage costs Security challenges DOS, security attacks permissions-based communications only allow modest rates without asking effectively, back to circuit-switched Higher-level security services more application-layer access via gateways, proxies, … User identity problem is not availability, but rather overabundance Fundamental re-thinking "Hour glass" with single address space multiple gatewayed networks with separate address spaces diversity vs. uniformity Application-neutral connectivity filtered & restricted ( tunneling over port 80) Send first, ask later permission-based networking old default: no (mutual) authentication new: only authenticated users/applications Wildcards Quantum computing Teleportation Ubiquitous SIP Henning Schulzrinne (with Stefan Berger, Stelios Sidiroglou, Kundan Singh, Xiaotao Wu, Weibin Zhao and the RPIDS authors) Columbia University IRT Lab Hewlett Packard – March 2003 Overview What is ubiquitous computing? Core ubiquitous communications functionality Brief introduction to SIP Ubiquitous computing in SIP and SLP On-going work at Columbia What is ubiquitous computing? “Ubiquitous computing has as its goal the enhancing computer use by making many computers available throughout the physical environment, but making them effectively invisible to the user.” (Weiser, 1993) “Ubiquitous computing is not virtual reality, it is not a Personal Digital Assistant (PDA) such as Apple's Newton, it is not a personal or intimate computer with agents doing your bidding. Unlike virtual reality, ubiquitous computing endeavers to integrate information displays into the everyday physical world. It considers the nuances of the real world to be wonderful, and aims only to augment them.” (Weiser, 1993) Ubiquitous computing aspects Also related to pervasive computing Mobility, but not just cell phones Computation and communications Integration of devices “borrow” capabilities found in the environment composition into logical devices seamless mobility session mobility adaptation to local capabilities environment senses instead of explicit user interaction from small dumb devices to PCs light switches and smart wallpaper Components of ubiquitous communications Service discovery discover devices Service mobility configuration information moves to new devices Event notification for context awareness Context-awareness location, user actions, location properties, … Example “ubicomp” projects Ambient Devices EU IST Disappearing Computer Project Aura, CMU user attention UNC “office of real soon now” augmented surfaces [Reki99] Microsoft Easy Living Oxygen, MIT Portolano, Univ. of Washington Endeavour, Berkeley CoolTown, HP Labs Ubiquitous computing using SIP – what’s different? Traditionally, focus on closed environments (lab, single company, home, …) Often, proprietary protocols self-contained environment Here, operate across Internet ( no Corba…) trusted, semi-trusted and untrusted participants use standard protocol mechanisms where possible make minimal assumptions on homogeneity respect user privacy What is SIP? Session Initiation Protocol protocol that establishes, manages (multimedia) sessions also used for IM, presence & event notification uses SDP to describe multimedia sessions Developed at Columbia U. (with others) Standardized by IETF, 3GPP (for 3G wireless), PacketCable About 60 companies produce SIP products Microsoft’s Windows Messenger (4.7) includes SIP Basic SIP message flow SIP trapezoid outbound proxy SIP trapezoid a@foo.com: 128.59.16.1 registrar SIP event notification Named events Typically, used for events within conferences (“Alice joined”) and call legs (e.g., call transfer) Supports arbitrary notification bodies, typically XML SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: <sip:alice@example.com> From: <sip:alice@example.com>;tag=78923 Call-Id: 1349882@alice-phone.example.com Contact: <sip:alice@alice-phone.example.com> NOTIFY sip:alice@alice-phone.example.com SIP/2.0 … Event: message-summary Subscription-State: active Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 2/8 (0/2) SIP event architecture Does not try to route notifications (“application layer multicast”) as in SIENA Filtering at PA under discussion (for low-bandwidth devices) But most ubicomp notification groups are probably small and message volume not likely to provide much bandwidth saving via network-based filtering Greatly simplifies trust model: no intermediaries that need to inspect content rate content can encrypt via S/MIME However, can build redistribution “exploders” and list subscriptions (“subscribe to engineering@hp.com”) SIP presence architecture REGISTER a@foo.com: 128.59.16.1 SUBSCRIBE watcher PA NOTIFY Alice PUAs PUBLISH Bob <?xml version="1.0" encoding="UTF-8"?> <p:presence xmlns:p="urn:…" entity="pres:alice@example.com"> <p:tuple id="sg89ae"> <p:status> <p:basic>open</p:basic> </p:status> <p:contact>tel:09012345678</p:contact> </p:tuple> </p:presence> Session mobility Walk into office, switch from cell phone to desk phone call transfer problem SIP REFER related problem: split session across end devices e.g., wall display + desk phone + PC for collaborative application assume devices (or stand-ins) are SIPenabled third-party call control Session mobility via 3PCC pc42 INVITE speakerphone m=audio c=pc42 192.0.2.1 INVITE pc42 m=video c=192.0.2.7 m=audio c=192.0.2.1 INVITE display m=video c=pc42 192.0.2.7 How to find services? Two complementary developments: smaller devices carried on user instead of stationary devices devices that can be time-shared Need to discover services in local environment SLP (Service Location Protocol) allows querying for services large plasma displays projector hi-res cameras echo-canceling speaker systems wide-area network access “find all color displays with at least XGA resolution” slp://example.com/SrvRqst?public?type=printer SLP in multicast mode SLP in DA mode Need to discover services before getting to environment “is there a camera in the meeting room?” SLP extension: find remote DA via DNS SRV Service Location Protocol (SLP) Version 2 standardized June 1999 SrvRqst SA UA SA SrvRply SrvReg DA SrvRqst DAAdvert SrvReg SLP attribute example URL service:printer:lpr://igore.wco.ftp.com/draft scope-list Development Language tag en (Name=Igore),(Description=For developers Attributes only), (Protocol=LPR),(locationdescription=12th floor), (Operator=James Dornan \3cdornan@monster\3e), (mediasize=na-letter),(resolution=res-600),x-OK Other service location mechanism DNS SRV/NAPTR DNS TXT records (Apple Rendezvous) DNS-SD UPnP uses SSDP: multicast HTTP over UDP M-SEARCH * HTTP/1.1 S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6 Host: 239.255.255.250:reservedSSDPport Man: "ssdp:discover“ ST: ge:fridge MX: 3 HTTP/1.1 200 OK S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6 Ext: Cache-Control: no-cache="Ext", max-age = 5000 ST: ge:fridge USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6 AL: <blender:ixl><http://foo/bar> Service mobility Allow access to service parameters anywhere – “payphone problem” Existing solutions: address book incoming call rules source name (SIP From) SIM card cumbersome to change synchronization (e.g., Palm) not suitable for borrowed devices Server-based services easier with SIP (service-routing), if carrier allows Emerging solutions for SIP systems: Small user token (smart card, RFID, i-button) identifying user Temporarily download configuration from home server Location-based services 3 major factors for services and personalization: Most location-based services: universal persona (certs, IM, email, SIP) time (NTP) space not much yet "find nearest X" customized popup ads – eagerly await! 911 We focus on computational, network and communication services in the environment current and future locations Locations Geographic location Civil location (≠ postal location!) street address, city some countries are a bit difficult… Categorical latitude, longitude, altitude, velocity, heading office, library, theater, hospital, … Behavioral “public location, don't expect privacy” “silence is encouraged, don't ring the phone” Determining locations SIP entities are often far away from physical user or his current network (intentionally) For many devices, can’t afford hardware to determine location different precision requirements: GPS doesn’t work indoors, but Assisted GPS (A-GPS) may Use location beacons: BlueTooth, 802.11 802.11 requires overlapping APs may not offer network connectivity see our 7DS project: offer local content + location Physically close by network entities: “in Fayette County” (within driving distance of service or person) “on campus” “in room 815” “in corner, talking to Bob” DHCP (same broadcast domain) PPP (tail circuit) Not always true with VPNs, but end system knows that it’s using a VPN DHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information 8:0:20:ab:d5:d DHCP server CDP + SNMP 8:0:20:ab:d5:d 458/17 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 458/17 Rm. 815 458/18 Rm. 816 Determining locations For many devices, can’t afford hardware to determine location Implementing BlueToothbased location sensor networks CU 7DS project: offer local content + location Developing programmable active badges with IR and RF capabilities DHCP for locations Proposal: DHCP extensions for geographic and civil location geographic: resolution (bits), long/lat, altitude (meters or floors) civil: Also, some LAN switches broadcast port and switch identification what: end system, switch or DHCP server hierarchical subdivisions, from country to street, landmark name, occupant CDP for Cisco, EDP for Extreme Networks Can also use backtracking via SNMP switch tables locally implemented for emergency services (Perl sip-cgi script) Location-based services Services: Location-aware call routing Location-based events “do not forward call if time at callee location is [11 pm, 8 am]” “only forward time-for-lunch if destination is on campus” “contact nearest emergency call center” “do not ring phone if I’m in a theater” “send delivery@pizza.com to nearest branch” subscribe to locations, not people “Alice has entered the meeting room” subscriber may be device in room our lab stereo changes CDs for each person that enters the room Person + location events We’re implementing SIP, caller-preferences and CPL extensions for these services SIP extensions for location-based services Location information is highly sensitive complete tracking of person stalkers and burglars would kill for this information IETF GEOPRIV principle: “target” can control dissemination of location information restrict time of day, information (location, heading, velocity) resolution, number of times queried, destination, retention, … “Alice is in time zone MET” may be ok for strangers, but “Alice is at 41.872833 N, 087.624417 W, heading NE at 45 mph” is not GEOPRIV still defining application scenarios in many cases, easiest to include location information “in-band” with protocol, as this avoids delegating authorization otherwise, need to give access key to database to recipient we propose adding SIP Location header field RPIDS: rich presence data Basic IETF presence (CPIM) only gives you contact information (SIP, tel URI) priority “open” or “closed” Want to use presence to guide communications everything watcher PUA PA watcher PUBLISH NOTIFY "vague" watcher INVITE CPL Aside: SIP caller preferences SIP core philosophy: many devices, one identifier Address people, not plastic Aside: SIP caller preferences But caller sometimes has preferences among devices SIP caller guides call routing: “I hate voicemail!” “I hate people!” “I prefer voicemail” Multilingual lines “Caller proposes, callee disposes” sip:isabel@a.com;languages="es" sip:isabel@a.com;languages="en";q=0.2 INVITE sip:sales@a.com Accept-Contact: *;languages="en" REGISTER INVITE a@foo.com: 128.59.16.1 sip:bob@a.com;languages="en" RPIDS: Rich presence data Integrates caller preferences information into presence announcements <activity>: on-the-phone, away, appointment, holiday, meal, meeting, steering, in-transit, travel, vacation, busy, permanent-absence <placetype>: home, office, public <privacy>: public, private, quiet <from>, <until>: status validity <idle>: activity for device <relationship>: family, associate, assistant, supervisor <class>: labeling and grouping <icon>, <card>, <info>: labeling presentities RPIDS example <tuple id="7c8dqui"> <status> <basic>open</basic> <contact>sip:secretary@example.com</contact> <cap:capabilities> <cap:feature name="Media"> <cap:value>voice</cap:value> <cap:value negated="true">message</cap:value> </cap:feature> </cap:capabilities> </status> <ep:relationship>assistant</ep:relationship> <note>My secretary</note> </tuple> Event filtering Events are core attribute of ubiquitous computing systems tell devices about people actions tell people about device presence e.g., “Alice has entered Room 815” devices that know Alice’s preferences subscribe to Alice locations may also have presence e.g., for occupancy sensors, switches Location filtering language SIP presence information will be updated using REGISTER and UPDATE Need to constrain who is allowed to see what detail presentity privacy who wants to see what detail how often what granularity of change Proposal to allow SUBSCRIBE to include frequency limitation Working on CPL-like language invoked (logically) at publication time classes of users, e.g., based on entry in my address book classes get mapped to restriction “12 bits of long/lat resolution, 6 bits of altitude resolution, 0 bits of velocity” “time zone only”, “category only” watchers can then add filters that restrict the delivery: location difference > threshold entering or leaving certain area entering or leaving category or behavioral type Columbia SIP servers (CINEMA) Telephone switch Local/long distance 1-212-5551212 Internal Telephone Extn: 7040 Single machine Department PBX 713x SIP/PSTN Gateway Extn: 7134 rtspd: media server RTSP sipconf: Conference server sipd: Proxy, redirect, registrar server RTSP clients sipum: Unified messaging SQL database Web server Web based configuration SNMP (Network Management) H.323 Extn: 7136 xiaotaow@cs Quicktime siph323: SIP-H.323 translator NetMeeting Location-based services in CINEMA Initial proof-of-concept implementation Integrate devices: lava lamp via X10 controller set personalized light mood setting Pingtel phone add outgoing line to phone and register user painful: needs to be done via HTTP POST request stereo change to audio CD track based on user Sense user presence and identity: passive infrared (PIR) occupancy sensor magnetic swipe card ibutton BlueTooth equipped PDA IR+RF badge (in progress) RFID (future) biometrics (future) CINEMA system All-SIP implementation Service creation Promise of faster service creation traditionally, only vendors (and sometimes carriers) learn from web models end user network servers programmer, carrier SIP servlets, sip-cgi end system VoiceXML VoiceXML (voice), LESS CPL sip-cgi web common gateway interface (cgi): oldest (and still most commonly used) interface for dynamic content generation web server invokes process and passes HTTP request via stdin (POST body) environment variables HTTP headers, URL arguments as POST body or GET headers (?arg1=var1&arg2=var2) new process for each request not very efficient but easy to learn, robust (no state) support from just about any programming language (C, Perl, Tcl, Python, VisualBasic, ...) Adapt cgi model to SIP sip-cgi RFC 3050 sip-cgi examples Block *@vinylsiding.com: if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ "sip:*@vinylsiding.com") { print "SIP/2.0 600 I can't talk right now\n\n"; } Make calls from boss urgent: if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ /sip:boss@mycompany.com/) { foreach $reg (get_regs()) { print "CGI-PROXY-REQUEST $reg SIP/2.0\n"; print "Priority: urgent\n\n"; } } Call Processing Language (CPL) XML-based “language” for processing requests intentionally restricted to branching and subroutines no variables (may change), no loops thus, easily represented graphically and most bugs can be detected statically termination assured mostly used for SIP, but protocol-independent integrates notion of calendaring (time ranges) structured tree describing actions performed on call setup event top-level events: incoming and outgoing CPL Location set stored as implicit global variable Switches: operations can add, filter and delete entries address language time, using CALSCH notation (e.g., exported from Outlook) priority Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...) Reject and redirect perform corresponding protocol actions Supports abstract logging and email operation CPL example busy Call String-switch field: from location url: sip:jones@ example.com proxy timeout: 10s match: *@example.com otherwise location url: sip:jones@ voicemail. example.com merge: clear redirect timeout failure CPL example <?xml version="1.0" ?> <!DOCTYPE call SYSTEM "cpl.dtd"> <cpl> <incoming> <lookup source="http://www.example.com/cgibin/locate.cgi?user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming> </cpl> CPL example: anonymous call screening <cpl> <incoming> <address-switch field="origin" subfield="user"> <address is="anonymous"> <reject status="reject" reason="I don't accept anonymous calls" /> </address> </address-switch> </incoming> </cpl> Service creation – a comparison API servlets sip-cgi CPL languageindependent no Java only yes own secure no mostly can be yes end user service creation no yes power users yes GUI tools no no no yes Multimedia some yes yes yes call creation yes no no no Service creation for presence services (work-in-progress) Accept or deny subscriptions Shape presence notifications Subscriber can filter detail different level of detail for family, friends and colleagues particularly important for geo data primarily, wireless bandwidth constraints rate limit notifications XPath? Mostly, condition/reaction CPL can be extended to most of these functions Pushing context-sensitive data to users User with mobile device should get location information when entering city, campus or building Often does not require knowing user flight and gate information maps and directions local weather forecast special advisories (“choose security checkpoint 2”) but interface with (e.g.) calendar Example Columbia implementation: OBEX data exchange over BlueTooth PDA pushes current appointment or event name base station delivers directions and map Summary: ubiquitous computing using SIP SIP + auxiliary protocols supports many of the core requirements for ubiquitous computing and communications: mobility modalities: terminal, user, session, service service negotiation for devices with different capabilities automatic configuration and discovery with SLP or similar event notification and triggered actions automatic actions: event filtering, CPL, LESS (for end system services) SIP offers a loosely-coupled approach (cf. Jini or object models) Also need data push functionality Avoid tendency to assume SIP users are human – want to interconnect different components and devices SIP device configuration needs automation, rather than screenscraping Network reliability and QoS measurements Henning Schulzrinne Columbia University, New York University of Cincinnati March 2003 Assessment of VoIP Service Availability Wenyu Jiang Henning Schulzrinne IRT Lab, Dept. of Computer Science Columbia University Overview (on-going work, preliminary results, still looking for measurement sites, …) Service availability Measurement setup Measurement results call success probability overall network loss network outages outage induced call abortion probability Service availability Users do not care about QoS at least not about packet loss, jitter, delay rather, it’s service availability how likely is it that I can place a call and not get interrupted? availability = MTBF / (MTBF + MTTR) FEC and PLC can deal with losses up to 5-8% MTBF = mean time between failures MTTR = mean time to repair availability = successful calls / first call attempts equipment availability: 99.999% (“5 nines”) 5 minutes/year AT&T: 99.98% availability (1997) IP frame relay SLA: 99.9% UK mobile phone survey: 97.1-98.8% Availability – PSTN metrics PSTN metrics (Worldbank study): fault rate fault clearance (~ MTTR) “next business day” call completion rate “should be less than 0.2 per main line” during network busy hour “varies from about 60% - 75%” dial tone delay Example PSTN statistics Source: Worldbank Measurement setup Node name Location Connectivity Network columbia Columbia University, NY >= OC3 I2 wustl Washington U., St. Louis I2 unm Univ. of New Mexico I2 epfl EPFL, Lausanne, CH I2+ hut Helsinki University of Technology I2+ rr NYC cable modem ISP rrqueens Queens, NY cable modem ISP njcable New Jersey cable modem ISP newport New Jersey ADSL ISP sanjose San Jose, California cable modem ISP suna Kitakyushu, Japan 3 Mb/s ISP sh Shanghai, China cable modem ISP Shanghaihome Shanghai, China cable modem ISP Shanghaioffice Shanghai, China ADSL ISP Measurement setup Active measurements call duration 3 or 7 minutes UDP packets: 36 bytes alternating with 72 bytes (FEC) 40 ms spacing September 10 to December 6, 2002 13,500 call hours Call success probability 62,027 calls succeeded, 292 failed 99.53% availability roughly constant across I2, I2+, commercial ISPs All 99.53% Internet2 99.52% Internet2+ 99.56% Commercial 99.51% Domestic (US) 99.45% International 99.58% Domestic commercial 99.39% International commercial 99.59% Overall network loss PSTN: once connected, call usually of good quality exception: mobile phones compute periods of time below loss threshold 5% causes degradation for many codecs others acceptable till 20% loss 0% 5% 10% 20% All 82.3 97.48 99.16 99.75 ISP 78.6 96.72 99.04 99.74 I2 97.7 99.67 99.77 99.79 I2+ 86.8 98.41 99.32 99.76 US 83.6 96.95 99.27 99.79 Int. 81.7 97.73 99.11 99.73 US ISP 73.6 95.03 98.92 99.79 Int. ISP 81.2 97.60 99.10 99.71 Network Outages sustained packet losses arbitrarily defined at 8 packets far beyond any recoverable loss (FEC, interpolation) 23% outages make up significant part of 0.25% unavailability symmetric: AB BA spatially correlated: AB AX not correlated across networks (e.g., I2 and commercial) Network outages 1 US Domestic paths International paths 0.1 0.01 0.001 0.0001 Complementary CDF Complementary CDF 1 all paths Internet2 0.1 0.01 0.001 0.0001 0 50 100 150 200 250 300 350 400 outage duration (sec) 1e-05 0 50 100 150 200 250 300 350 400 outage duration (sec) Network outages no. of outages % duration symmetric (mean) duration (median) total (all, h:m) outages > 1000 packets all 10,753 30% 145 25 17:20 10:58 I2 819 14.5% 360 25 3:17 2:33 I2+ 2,708 10% 259 26 7:47 5:37 ISP 8,045 37% 107 24 9:33 4:58 US 1,777 18% 269 20 5:18 3:53 Int. 8,976 33% 121 26 12:02 6:42 Outage-induced call abortion proability Long interruption user likely to abandon call from E.855 survey: P[holding] = e-t/17.26 (t in seconds) half the users will abandon call after 12s 2,566 have at least one outage 946 of 2,566 expected to be dropped 1.53% of all calls all 1.53% I2 1.16% I2+ 1.15% ISP 1.82% US 0.99% Int. 1.78% US ISP 0.86% Int. ISP 2.30% Conclusion Availability in space is (mostly) solved availability in time restricts usability for new applications initial investigation into service availability for VoIP need to define metrics for, say, web access unify packet loss and “no Internet dial tone’’ far less than “5 nines” working on identifying fault sources and locations looking for additional measurement sites Multimodal Wireless Networking: From Message Forwarding to Infrastructure Networks Henning Schulzrinne joint work with Maria Papadopouli and Stelios Sidiroglou Computer Science Department Columbia University http://www.cs.columbia.edu/IRT hgs@cs.columbia.edu Outline Introduction A taxonomy of wireless networks Motivation Overview of 7DS Performance analysis on 7DS Conclusions Future work Multimodal networking "The term multimodal transport is often used loosely and interchangeably with the term intermodal transport. Both refer to the transport of goods through several modes of transport from origin to destination." (UN) goods packaged in containers packets and messages Networking combine different modes of data transport that maximize efficiency Multimodal networking Speed, cost and ubiquity are the core variables cf. pipelines, ships, planes, trucks Traditional assumption of value of immediacy from PSTN demise of Iridium Access modalities bandwidth (peak) delay high low high 7DS 802.11 hotspots low satellite SMS? voice (2G, 2.5G) Cost of networking Modality mode speed OC-3 P 155 Mb/s $0.0013 Australian DSL P 512/128 kb/s $0.018 GSM voice C 8 kb/s $0.66-$1.70 HSCSD C 20 kb/s $2.06 GPRS P 25 kb/s $4-$10 Iridium C 10 kb/s $20 SMS P ? $62.50 P 8 kb/s $133 videoconferencing or 1/3 MP3) (512/128 kb/s) (160 chars/message) Motient (BlackBerry) $/MB (= 1 minute of 64 kb/s Wireless WAN access • Spectrum is very expensive Locatio n what cost UK 3G $590/person Germany 3G $558/person Italy 3G $200/person New York Verizon (20MHz) $220/customer • 3G bandwidth is very low (around 60 kb/s) Limitations of 802.11 Good for hotspots, difficult for complete coverage Manhattan = 60 km2 6,000 base stations (not counting vertical) With ~ 600,000 Manhattan households, 1% of households would have to install access points Almost no coverage outside of large coastal cities Mobile data access Hoarding: grab data before moving 802.11, 3G, BlueTooth: wireless as last-hop access technology Ad-hoc networks: Wireless nodes forward to each other Routing protocol determines current path Requires connected network, some stability Mobility harmful (disrupts network) 7DS networks: No contiguous connectivity Temporary clusters of nodes Mobility helpful (propagates information) A family of access points WLAN Connected Infostation Disconnected Infostation 2G/3G access sharing 7DS Limitations of infostations & wireless WAN • Require communication infrastructure not available field operation missions, tunnels, subway • • • • Emergency Overloaded Expensive Wireless WAN access with low bit rates & high delays Our Approach: 7DS 7DS = Seven Degrees of Separation Increase data availability by enabling devices to share resources – Information sharing – Message relaying – Bandwidth sharing Self-organizing No infrastructure Exploit host mobility Examples of services using 7DS news events in campus, pictures where is the closest Internet café ? service location queries traffic, weather, maps, routes, gas station schedule info autonomous cache pictures, measurements WAN Information sharing with 7DS WLAN data query Host A WAN cache miss Host C query WLAN data cache hit Host B Host A Host D Simulation environment querier wireless coverage pause time 50 s mobile user speed 0 .. 1.5 m/s host density 5 .. 25 hosts/km2 wireless coverage 230 m (H), 115 m (M), 57.5 m (L) dataholder randway model ns-2 with CMU mobility, wireless extension & randway model Simulation environment querier 1m/s pause mobile host wireless coverage pause time 50 s mobile user speed 0 .. 1.5 m/s host density 5 .. 25 hosts/km2 wireless coverage 230 m (H), 115 m (M), 57.5 m (L) data holder ns-2 with CMU mobility, wireless extension Simulation environment wireless coverage v1 v2 data v3 pause time 50 s mobile user speed 0 .. 1.5 m/s host density 5 .. 25 hosts/km2 wireless coverage 230 m (H), 115 m (M), 57.5 m (L) ns-2 with CMU mobility, wireless extension Dataholders (%) after 25 min high transmission power Dataholders (%) 100 P2P 90 80 P2P data sharing (power cons.) Mobile Info Server 70 P2P data sharing 60 50 P2P data sharing & FW (power cons.) Fixed Info Server 40 Fixed Info Server 30 20 10 Mobile Info Server 0 0 5 10 15 20 25 2 Density of hosts (#hosts/km ) Average delay (s) vs. dataholders (%) Average Delay (s) Fixed Info Server 1200 1000 one server in 2x2 high transmission power 800 600 400 4 servers in 2x2 medium transmission power 200 0 0 5 10 15 20 25 30 35 Dataholders (%) Fixed Info Server(medium transmission power) 4 initial dataholders (servers) in 2x2 Fixed Info Server (high transmission power ) one initial dataholder (server) in 2x2 Average Delay (s) Average Delay (s) vs Dataholders (%) Peer-to-Peer schemes 1600 1400 1200 1000 800 600 400 200 0 high transmission power medium transmission power 0 10 20 30 40 50 60 70 80 90 100 Dataholders (%) P2P (high transmission power) one initial dataholder & 20 cooperative hosts in 2x2 P2P(medium transmission power) one initial dataholder & 20 coperative hosts in 1x1 Dataholders (%) Fixed Info Server simulation and analytical results high transmission power 60 40 20 0 0 500 1000 1500 simulation model 2000 2500 3000 Time (s) Probability a host will acquire data by time t follows 1-e-at Message relaying with 7DS WAN messages WLAN Host A Gateway WLAN Message relaying Host A Host B Message relaying Take advantage of host mobility to increase throughput Hosts buffer messages & forward them to a gateway Hosts forward their own messages to cooperative relay hosts Restrict number of times hosts forwards Message relayed (%) Messages (%) relayed after 25 min (average number of buffered messages : 5) 100 80 60 40 20 0 5 10 15 20 25 Density of hosts (#hosts/km2 ) High transmission power (No FW) High transmission power (FW 6) Medium transmission power (No FW) Medium transmission power (FW 6) 7DS node 7DS Implementation Cache manager (3k lines) GUI server (2k lines) HTTP client & methods (24k lines) Proxy server (1k lines) UDP multicast & unicast (1k) Web client & server (2k) Jar files used (xerces, xml,lucene, html parcer) 7DS implementation Initial Java implementation on laptop Compaq Ipaq (Linux or WinCE) Inhand Electronics ARM RISC board Low power PCMCIA slot for storage, network or GPS 7DS implementation Message relayed (%) Message relayed to gateway after 25 min 100 80 60 40 20 0 5 10 15 20 25 2 Density of hosts (#hosts/km ) High transmission power (No FW) High transmission power (FW 6) Medium transmission power (No FW) Medium transmission power (FW 6) Epidemic model Carrier is “infected”, hosts are “susceptible” Transmit to any give host with probability ha+o(h) in interval h Pure birth process T=time until data has spread among all mobiles N-1 E[T]=1/a S i(N-1) i=1 1 Conclusion Research in transition: Downward migration: foundational operational universal niches servers, PCs embedded systems professionals residential users IRT research examples: location-based ubiquitous communication services network reliability multimodal networking Other on-going IRT research topics Geographic service discovery Generic state signaling protocol (IETF NSIS) ./ ad-hoc web server rescue End system service creation (LESS) Black box QoS measurement and diagnosis Fully distributed multimedia conferencing Conferencing floor control MarconiNet: multicast mobility Application-layer mobility Application-focused research Event systems for medical environments Training for FAA flight controllers Enhanced presence systems CINEMA: SIP-based telecom infrastructure