Networking Research – Networking Research – Vision and Vision and OpportunitiesOpportunities
Henning SchulzrinneDept. of Computer Science
Columbia [email protected]
OverviewOverview 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 Networking is getting into middle yearsmiddle years
idea current
IP 1969, 1980?
1981
TCP 1974 1981
telnet 1969 1983
ftp 1980 1985
Technologies at ~30 yearsTechnologies 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 researchMaturing 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, …)?
StandardizationStandardization Really two facets of standardization:
1. public, interoperable description of protocol, but possibly many (Tanenbaum)
2. 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 progressObservations on progress 1960s: military professional consumer
now, often reversed Oscillate: convergence divergence
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 networkingHistory 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 networkingTransition 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 evolutionNetwork 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 Commercial access cost (T1)(T1)
1996 1998 2000 2001 2002 2003
T1
$0
$100
$200
$300
$400
$500
$600
$700
$/month
Year
Transit cost (OC-3, NY – Transit cost (OC-3, NY – London)London)
1,000
10,000
100,000
1,000,000
9-Feb-99 28-Aug-99 15-Mar-00 1-Oct-00 19-Apr-01 5-Nov-01 24-May-02 10-Dec-02
Date
Disk storage cost (IDE)Disk storage cost (IDE)Cost
$1.00
$10.00
$100.00
$1,000.00
$10,000.00
$100,000.00
May-79 Feb-82 Nov-84 Aug-87 May-90 Jan-93 Oct-95 Jul-98 Apr-01 Jan-04
Date
$/GB
Research directionsResearch 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 What’s fashionable (and not)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 Observations on network researchresearch Frustration with inability to change network
infrastructure in less than 10 -- 20 year horizons: IPv6 Layer-3 multicast QoS Security
Network research community has dismal track record for new applications
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 researchNetwork research Old goal: "new universal network"
IP, OSI, ATM New goal: "niche networks"
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 Infrastructure research questions: Scaling, Reliability, questions: Scaling, Reliability, SecuritySecurity
Scaling no major changes for 20+ years (link-state, DV,
etc.) two-layer (intra/inter) other routing paradigms
Reliability 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 issuesScaling – practical issues
Scaling is only backbone problem Depends on network evolution:
continuing addition of AS to flat space deep trouble
additional hierarchy
QoSQoS
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 layerTransport 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
ApplicationsApplications 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 applicationsNew applications New bandwidth-intensive applications
Reality-based networking (security) cameras
Distributed games often require only low-bandwidth control information current game traffic ~ VoIP
Computation vs. storage vs. communications communications cost has decreased less
rapidly than storage costs
Security challengesSecurity 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 over-
abundance
Fundamental re-thinkingFundamental 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
Ubiquitous SIPUbiquitous 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
OverviewOverview
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 What is ubiquitous computing?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 Ubiquitous computing aspectsaspects 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 Components of ubiquitous communicationscommunications
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” Example “ubicomp” projectsprojects 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 Ubiquitous computing using SIP – what’s different?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?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
SIP event notificationSIP 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:[email protected] SIP/2.0To: <sip:[email protected]>From: <sip:[email protected]>;tag=78923Call-Id: [email protected]: <sip:[email protected]>
NOTIFY sip:[email protected] SIP/2.0…Event: message-summarySubscription-State: active
Messages-Waiting: yesMessage-Account: sip:[email protected]: 2/8 (0/2)
SIP event architectureSIP event architecture Does not try to route notifications (“application
layer multicast”) as in SIENA Filtering at PA under discussion (for low-bandwidth
devices) rate content
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
can encrypt via S/MIME However, can build redistribution “exploders” and
list subscriptions (“subscribe to [email protected]”)
SIP presence architectureSIP presence architecture
PA
[email protected]: 128.59.16.1
watcher
PUAs
Alice Bob
PUBLISH
REGISTERSUBSCRIBE
NOTIFY
<?xml version="1.0" encoding="UTF-8"?><p:presence xmlns:p="urn:…" entity="pres:[email protected]"><p:tuple id="sg89ae"> <p:status> <p:basic>open</p:basic> </p:status> <p:contact>tel:09012345678</p:contact></p:tuple></p:presence>
Session mobilitySession 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 SIP-enabled
third-party call control
Session mobility via 3PCCSession mobility via 3PCC
INVITE speakerphonem=audioc=pc42
INVITE displaym=videoc=pc42
192.0.2.1
192.0.2.7
INVITE pc42m=videoc=192.0.2.7m=audioc=192.0.2.1
pc42
How to find services?How to find services? Two complementary developments:
smaller devices carried on user instead of stationary devices devices that can be time-shared
large plasma displays projector hi-res cameras echo-canceling speaker systems wide-area network access
Need to discover services in local environment SLP (Service Location Protocol) allows querying for services
“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 Service Location Protocol (SLP)(SLP)
Version 2 standardized June 1999
UA
DA
SA
SA
SrvReg
SrvRply
SrvRqst
SrvRqst SrvReg
DAAdvert
SLP attribute exampleSLP attribute exampleURL service:printer:lpr://igore.wco.ftp.com/draft
scope-list Development
Language tag
en
Attributes (Name=Igore),(Description=For developers only), (Protocol=LPR),(location-description=12th floor), (Operator=James Dornan \3cdornan@monster\3e), (media-size=na-letter),(resolution=res-600),x-OK
Other service location Other service location mechanismmechanism DNS SRV/NAPTR DNS TXT records (Apple Rendezvous) DNS-SD UPnP uses SSDP:
multicast HTTP over UDP
M-SEARCH * HTTP/1.1S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6Host: 239.255.255.250:reservedSSDPportMan: "ssdp:discover“ST: ge:fridgeMX: 3
HTTP/1.1 200 OKS: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6Ext: Cache-Control: no-cache="Ext", max-age = 5000ST: ge:fridgeUSN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6AL: <blender:ixl><http://foo/bar>
Service mobilityService mobility Allow access to service parameters anywhere –
“payphone problem” address book incoming call rules source name (SIP From)
Existing solutions: 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 servicesLocation-based services 3 major factors for services and
personalization: universal persona (certs, IM, email, SIP) time (NTP) space not much yet
Most location-based services: "find nearest X" customized popup ads – eagerly await! 911
We focus on computational, network and communication services in the environment
current and future locations
LocationsLocations Geographic location
latitude, longitude, altitude, velocity, heading Civil location (≠ postal location!)
street address, city some countries are a bit difficult…
Categorical office, library, theater, hospital, …
Behavioral “public location, don't expect privacy” “silence is encouraged, don't ring the phone”
Determining locationsDetermining 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: “in Fayette County” (within driving distance of service or person) “on campus” “in room 815” “in corner, talking to Bob”
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: DHCP (same broadcast domain) PPP (tail circuit)
Not always true with VPNs, but end system knows that it’s using a VPN
DHCP for locationsDHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information
DHCPserver
458/17 Rm. 815458/18 Rm. 816
DHCP answer:sta=DC loc=Rm815lat=38.89868 long=77.03723
8:0:20:ab:d5:d
CDP + SNMP8:0:20:ab:d5:d 458/17
Determining locationsDetermining locations For many devices,
can’t afford hardware to determine location Implementing
BlueTooth-based location sensor networks
CU 7DS project: offer local content + location
Developing programmable active badges with IR and RF capabilities
DHCP for locationsDHCP for locations Proposal: DHCP extensions for geographic and
civil location geographic: resolution (bits), long/lat, altitude
(meters or floors) civil:
what: end system, switch or DHCP server hierarchical subdivisions, from country to street,
landmark name, occupant Also, some LAN switches broadcast port and
switch identification 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 servicesLocation-based services Services:
Location-aware call routing “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 [email protected] to nearest branch”
Location-based events 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-SIP extensions for location-based servicesbased 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 dataRPIDS: 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
PA
watcher
PUA watcher
watcher
PUBLISH
NOTIFY
everything
"vague"
CPL
INVITE
Aside: SIP caller Aside: SIP caller preferencespreferences
SIP core philosophy: many devices, one identifier Address people, not plastic
Aside: SIP caller Aside: SIP caller preferencespreferences 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”
[email protected]: 128.59.16.1
sip:[email protected];languages="es"sip:[email protected];languages="en";q=0.2
sip:[email protected];languages="en"
INVITE sip:[email protected]: *;languages="en"
INVITE
REGISTER
RPIDS: Rich presence data 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 exampleRPIDS example<tuple id="7c8dqui"> <status> <basic>open</basic> <contact>sip:[email protected]</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 filteringEvent 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 languageLocation 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 Columbia SIP servers (CINEMA)(CINEMA)
InternalTelephoneExtn: 7040
SIP/PSTN Gateway
Department PBX
Web based configuration
Web server
Telephoneswitch
SQLdatabase
sipd:Proxy, redirect, registrar server
Extn: 7134
xiaotaow@cs NetMeeting
H.323
rtspd: media server
sipum: Unified messaging
Quicktime
RTSP clients
RTSP
Extn: 7136
713x
Single machine
SNMP(Network Management)
sipconf: Conference server
siph323: SIP-H.323 translator
Local/long distance1-212-5551212
Location-based services in Location-based services in CINEMACINEMA 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)
Service creationService creation
programmer, carrier
end user
network servers
SIP servlets, sip-cgi
CPL
end system VoiceXML VoiceXML (voice),LESS
Promise of faster service creation traditionally, only vendors (and sometimes carriers) learn from web models
sip-cgisip-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 examplessip-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:[email protected]/) { foreach $reg (get_regs()) { print "CGI-PROXY-REQUEST $reg SIP/2.0\n"; print "Priority: urgent\n\n"; }}
Call Processing Language Call Processing Language (CPL)(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
CPLCPL Location set stored as implicit global variable
operations can add, filter and delete entries Switches:
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 exampleCPL example
String-switchfield: from
match:*@example.com
otherwise
proxytimeout: 10s
locationurl: sip:jones@
example.comvoicemail.
merge: clear
locationurl: sip:jones@
example.com
redirect
Call
busy
timeout
failure
CPL exampleCPL example<?xml version="1.0" ?><!DOCTYPE call SYSTEM "cpl.dtd">
<cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?
user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:[email protected]&Subject=lookup%20failed" /> </failure> </lookup> </incoming></cpl>
CPL example: anonymous CPL example: anonymous call screeningcall 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 Service creation – a comparisoncomparison
API servlets sip-cgi CPL
language-independent
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 Service creation for presence services (work-in-progress)services (work-in-progress) Accept or deny subscriptions Shape presence notifications
different level of detail for family, friends and colleagues
particularly important for geo data Subscriber can filter detail
primarily, wireless bandwidth constraints rate limit notifications XPath?
Mostly, condition/reaction CPL can be extended to most of these functions
Pushing context-sensitive Pushing context-sensitive data to usersdata to users User with mobile device should get location
information when entering city, campus or building
flight and gate information maps and directions local weather forecast special advisories (“choose security checkpoint 2”)
Often does not require knowing user 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 Summary: ubiquitous computing using SIPcomputing 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
screen-scraping
Network reliability and Network reliability and QoS measurementsQoS measurements
Henning SchulzrinneColumbia University, New
YorkUniversity of Cincinnati
March 2003
Assessment of VoIP Assessment of VoIP Service AvailabilityService Availability
Wenyu JiangHenning SchulzrinneIRT Lab, Dept. of Computer Science
Columbia University
OverviewOverview
(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 availabilityService availability Users do not care about QoS at least not about packet loss, jitter, delay
FEC and PLC can deal with losses up to 5-8% rather, it’s service availability how likely is it
that I can place a call and not get interrupted? availability = MTBF / (MTBF + MTTR)
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 metricsAvailability – PSTN metrics
PSTN metrics (Worldbank study): fault rate
“should be less than 0.2 per main line” fault clearance (~ MTTR)
“next business day” call completion rate
during network busy hour “varies from about 60% - 75%”
dial tone delay
Measurement setupMeasurement setupNode 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 setupMeasurement 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 probabilityCall 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 lossOverall 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 OutagesNetwork 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 outagesNetwork outages
0.0001
0.001
0.01
0.1
1
0 50 100 150 200 250 300 350 400
Com
plem
enta
ry C
DF
outage duration (sec)
US Domestic pathsInternational paths
1e-05
0.0001
0.001
0.01
0.1
1
0 50 100 150 200 250 300 350 400
Com
plem
enta
ry C
DF
outage duration (sec)
all pathsInternet2
Network outagesNetwork outagesno. of outages
% symmetric
duration (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 Outage-induced call abortion proabilityproability 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%
ConclusionConclusion 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 Multimodal Wireless Networking: From Message Networking: From Message Forwarding to Forwarding to Infrastructure NetworksInfrastructure Networks
Henning Schulzrinnejoint work with
Maria Papadopouli and Stelios Sidiroglou
Computer Science DepartmentColumbia University
http://www.cs.columbia.edu/[email protected]
OutlineOutline
Introduction A taxonomy of wireless networks Motivation Overview of 7DS
Performance analysis on 7DS Conclusions Future work
Multimodal networkingMultimodal 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 networkingMultimodal 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 modalitiesAccess modalities
high low
high 7DS 802.11hotspots
low satelliteSMS?
voice (2G, 2.5G)
band
wid
th(p
eak)
delay
Cost of networkingCost of networkingModality mod
espeed $/MB (= 1 minute of 64
kb/s videoconferencing or 1/3 MP3)
OC-3 P 155 Mb/s $0.0013
Australian DSL(512/128 kb/s)
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 (160 chars/message) P ? $62.50
Motient (BlackBerry) P 8 kb/s $133
Wireless WAN accessWireless WAN access
Location
what cost
UK 3G $590/person
Germany
3G $558/person
Italy 3G $200/person
New York
Verizon(20MHz)
$220/customer
• Spectrum is very expensive
• 3G bandwidth is very low (around 60 kb/s)
Limitations of 802.11Limitations 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 accessMobile 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 pointsA family of access points
Disconnected Infostation
2G/3G
access sharing7DS
Connected Infostation
WLAN
Limitations of Limitations of infostations & wireless WANinfostations & 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: 7DSOur Approach: 7DS7DS = Seven Degrees of SeparationIncrease 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 7DSExamples of services using 7DS
schedule info
WANWAN
autonomous cache
newsevents in campus,pictures
where is the closest Internet café ?
service location queries
traffic, weather, maps, routes, gas station
pictures, measurements
Information sharing with 7DSInformation sharing with 7DS
Host B
Host C
data cache hit
cache miss
data
Host A
query
WANWAN Host A Host D
query
WLAN
WLAN
Simulation environmentSimulation environmentpause time 50 smobile user speed 0 .. 1.5 m/shost density 5 .. 25 hosts/km2
wireless coverage 230 m (H), 115 m (M), 57.5 m (L)
ns-2 with CMU mobility, wireless extension & randway model
dataholder
querier
randway model
wireless coverage
Simulation environmentSimulation environment
pause time 50 smobile user speed 0 .. 1.5 m/shost density 5 .. 25 hosts/km2
wireless coverage 230 m (H), 115 m (M), 57.5 m (L)
ns-2 with CMU mobility, wireless extension
pause1m/s
mobile host data holder
querierwireless coverage
Simulation environmentSimulation environment
pause time 50 smobile user speed 0 .. 1.5 m/shost density 5 .. 25 hosts/km2
wireless coverage 230 m (H), 115 m (M), 57.5 m (L)
ns-2 with CMU mobility, wireless extension
v1
v2
v3
wireless coverage
data
0
10
20
30
40
50
60
70
80
90
100
0 5 10 15 20 25
Density of hosts (#hosts/km )
Da
tah
old
ers
(%
) P2P data sharing(power cons.)
P2P data sharing
P2P data sharing & FW(power cons.)
Fixed Info Server
Mobile Info Server
Dataholders (%) after 25 Dataholders (%) after 25 minmin
high transmission power
2
Fixed Info Server
Mobile Info Server
P2P
Average delay (s) vs. dataholders Average delay (s) vs. dataholders (%)(%)
0
200
400
600
800
1000
1200
0 5 10 15 20 25 30 35Dataholders (%)
Avera
ge D
ela
y (
s)
Fixed Info Server(medium transmission power) 4 initial dataholders (servers) in 2x2
Fixed Info Server (high transmission power ) one initial dataholder (server) in 2x2
one server in 2x2high transmission power
4 servers in 2x2medium transmission power
Fixed Info Server
Average Delay (s) vs Dataholders (%)Average Delay (s) vs Dataholders (%)Peer-to-Peer schemesPeer-to-Peer schemes
0200400600800
1000120014001600
0 10 20 30 40 50 60 70 80 90 100Dataholders (%)
Ave
rag
e D
elay
(s)
P2P (high transmission power) one initial dataholder & 20 cooperative hosts in 2x2
P2P(medium transmission power) one initial dataholder & 20 coperative hosts in 1x1
medium transmission power
high transmission power
Fixed Info ServerFixed Info Serversimulation and analytical simulation and analytical resultsresults
0
20
40
60
0 500 1000 1500 2000 2500 3000Time (s)
Dat
aho
lder
s (%
)
simulation model
Probability a host will acquire data by time t follows 1-e-at
high transmission power
Message relaying with 7DSMessage relaying with 7DS
Host B
Messagerelaying
Host A
messages
Gateway
WAN
Host AWLAN
WLAN
Message relayingMessage 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
0
20
40
60
80
100
5 10 15 20 25Density of hosts (#hosts/km )
Mes
sage
rel
ayed
(%
)
High transmission power (No FW)High transmission power (FW 6)Medium transmission power (No FW)Medium transmission power (FW 6)
2
Messages (%) relayed after 25 minMessages (%) relayed after 25 min (average number of buffered (average number of buffered messages : 5)messages : 5)
7DS Implementation7DS 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 implementation7DS 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
020406080
100
5 10 15 20 25Density of hosts (#hosts/km )
Mess
age r
ela
yed (
%)
High transmission power (No FW)High transmission power (FW 6)Medium transmission power (No FW)Medium transmission power (FW 6)
2
Message relayed to gateway Message relayed to gateway after 25 minafter 25 min
Epidemic modelEpidemic 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
E[T]=1/a i=1
N-1
i(N-1)1
ConclusionConclusion Research in transition:
foundational operational universal niches
Downward migration: servers, PCs embedded systems professionals residential users
IRT research examples: location-based ubiquitous communication
services network reliability multimodal networking
Other on-going IRT research Other on-going IRT research topicstopics 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