Transcript NEC - Columbia University

Networking Research –
Vision and Opportunities
Henning Schulzrinne
Dept. of Computer Science
Columbia University
[email protected]
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
[email protected]:
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:[email protected] SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=78923
Call-Id: [email protected]
Contact: <sip:[email protected]>
NOTIFY sip:[email protected] SIP/2.0
…
Event: message-summary
Subscription-State: active
Messages-Waiting: yes
Message-Account: sip:[email protected]
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 [email protected]”)
SIP presence architecture
REGISTER
[email protected]:
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:[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 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 [email protected] 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:[email protected];languages="es"
sip:[email protected];languages="en";q=0.2
INVITE sip:[email protected]
Accept-Contact: *;languages="en"
REGISTER
INVITE
[email protected]:
128.59.16.1
sip:[email protected];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:[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 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:[email protected]/) {
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:[email protected]&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: AB  BA
spatially correlated: AB   AX
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
[email protected]
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-at
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