Get documents about "NEC
Shared by: YL02220T
-
Stats
- views:
- 48
- posted:
- 11/9/2011
- language:
- English
- pages:
- 125
Document Sample
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, 1981
1980?
TCP 1974 1981
telnet 1969 1983
ftp 1980 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. 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 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 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)
Transit cost (OC-3, NY –
London)
Disk storage cost (IDE)
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:
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 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 questions:
Scaling, Reliability, Security
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 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
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 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-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)
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 engineering@hp.com”)
SIP presence architecture
REGISTER
a@foo.com: SUBSCRIBE
128.59.16.1
watcher
PA
NOTIFY
Alice Bob
<?xml version="1.0" encoding="UTF-8"?>
<p:presence xmlns:p="urn:…"
PUAs PUBLISH 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 SIP-
enabled
third-party call control
Session mobility via 3PCC
pc42
INVITE speakerphone 192.0.2.1
m=audio
c=pc42
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
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 (SLP)
Version 2 standardized June 1999
SrvRqst
SA
UA
SrvRply SA
SrvReg
DA
SrvRqst SrvReg
DAAdvert
SLP attribute example
URL 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 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”
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 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
Locations
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 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 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 BlueTooth-
based 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:
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 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 delivery@pizza.com 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-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
watcher everything
PUA PA watcher "vague"
PUBLISH
NOTIFY watcher CPL
INVITE
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
a@foo.com:
INVITE 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)
Local/long distance Telephone
1-212-5551212 switch rtspd: media server Quicktime
Single machine
RTSP
sipconf:
RTSP clients
Department Conference server
sipum:
PBX Unified
Internal
Telephone messaging
713x sipd:
Extn: 7040
Proxy, SQL
redirect, database Web
registrar server
SIP/PSTN Gateway Web based
server
configuration
SNMP
(Network
Extn: 7134 Management)
Extn: 7136 H.323
siph323:
SIP-H.323 NetMeeting
xiaotaow@cs translator
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
programmer, end user
carrier
network SIP servlets, CPL
servers sip-cgi
end system VoiceXML VoiceXML (voice),
LESS
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
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 example
CPL 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: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
language- no Java only yes own
independent
secure no mostly can be yes
end user no yes power users yes
service
creation
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
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 data 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 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 screen-
scraping
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
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 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
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 All 99.53%
succeeded, 292 Internet2 99.52%
failed 99.53%
Internet2+ 99.56%
availability
Commercial 99.51%
roughly constant
across I2, I2+, Domestic (US) 99.45%
commercial ISPs International 99.58%
Domestic 99.39%
commercial
International 99.59%
commercial
Overall network loss
PSTN: once connected, loss 0% 5% 10% 20%
call usually of good All 82.3 97.48 99.16 99.75
quality ISP 78.6 96.72 99.04 99.74
exception: mobile phones
I2 97.7 99.67 99.77 99.79
compute periods of time
I2+ 86.8 98.41 99.32 99.76
below loss threshold
US 83.6 96.95 99.27 99.79
5% causes degradation
for many codecs Int. 81.7 97.73 99.11 99.73
others acceptable till US 73.6 95.03 98.92 99.79
20% ISP
Int. 81.2 97.60 99.10 99.71
ISP
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
Network outages
no. of % duration duration total (all, outages >
outages symmetric (mean) (median) h:m) 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 all 1.53%
to abandon call I2 1.16%
from E.855 survey: P[holding] I2+ 1.15%
= e-t/17.26 (t in seconds) ISP 1.82%
half the users will abandon US 0.99%
call after 12s Int. 1.78%
2,566 have at least one US ISP 0.86%
outage Int. ISP 2.30%
946 of 2,566 expected to be
dropped 1.53% of all calls
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
delay
high low
bandwidth
high 7DS 802.11
(peak)
hotspots
low satellite voice (2G,
SMS? 2.5G)
Cost of networking
Modality mode speed $/MB (= 1 minute of 64 kb/s
videoconferencing or 1/3 MP3)
OC-3 P 155 Mb/s $0.0013
Australian DSL P 512/128 $0.018
kb/s
(512/128 kb/s)
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 access
• Spectrum is very expensive
Locatio what cost
n
UK 3G $590/person
Germany 3G $558/person
Italy 3G $200/person
New York Verizon $220/customer
(20MHz)
• 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
7DS
access sharing
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
7DS
Examples of services using news
WAN
events in campus,
pictures
where is
the closest service location queries pictures,
Internet measurements
café ?
traffic, weather,
maps, routes, gas station
schedule info
autonomous cache
Information sharing with 7DS
WLAN
data query
WAN Host A Host D
cache miss
Host C
query WLAN data cache hit
Host B
Host A
Simulation environment
pause time 50 s
mobile user speed 0 .. 1.5 m/s
host density 5 .. 25
hosts/km2
querier wireless coverage 230 m (H),
wireless coverage 115 m (M), 57.5 m (L)
dataholder
randway model
ns-2 with CMU mobility,
wireless extension &
randway model
Simulation environment
pause time 50 s
mobile user speed 0 .. 1.5 m/s
host density 5 .. 25 hosts/km2
querier wireless coverage 230 m (H),
1m/s pause wireless coverage 115 m (M), 57.5 m (L)
mobile
host data holder
ns-2 with CMU mobility,
wireless extension
Simulation environment
pause time 50 s
mobile user speed 0 .. 1.5 m/s
host density 5 .. 25 hosts/km2
wireless coverage wireless coverage 230 m (H),
v1 115 m (M), 57.5 m (L)
data
v2
v3
ns-2 with CMU mobility,
wireless extension
Dataholders (%) after 25 min
high transmission power
P2P
Mobile Info Server
Fixed Info Server
2
Average delay (s) vs. dataholders (%)
Fixed Info Server
one server in 2x2
high transmission power
4 servers in 2x2
medium transmission power
Average Delay (s) vs Dataholders (%)
Peer-to-Peer schemes
high transmission power
medium transmission power
Fixed Info Server
simulation and analytical results
high transmission power
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 B
Host A
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
Messages (%) relayed after 25 min
(average number of buffered messages : 5)
2
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 to gateway after 25
min
2
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:
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
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
Related docs
Other docs by YL02220T
Planilha1 UNIDADE CATEGORIA TITULO Psicologia Social e Saúde Sexual Reprodutiva
Views: 102 | Downloads: 0
