Networking Research – Networking Research – Vision and Vision and OpportunitiesOpportunities

Henning SchulzrinneDept. of Computer Science

Columbia Universityhgs@cs.columbia.edu

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

WildcardsWildcards

Quantum computing Teleportation

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

Basic SIP message flowBasic SIP message flow

SIP trapezoidSIP trapezoid

SIP trapezoid

outbound proxy

a@foo.com: 128.59.16.1

registrar

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:alice@vmail.example.com SIP/2.0To: <sip:alice@example.com>From: <sip:alice@example.com>;tag=78923Call-Id: 1349882@alice-phone.example.comContact: <sip:alice@alice-phone.example.com>

NOTIFY sip:alice@alice-phone.example.com SIP/2.0…Event: message-summarySubscription-State: active

Messages-Waiting: yesMessage-Account: sip:alice@vmail.example.comVoice-Message: 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 engineering@hp.com”)

SIP presence architectureSIP presence architecture

PA

a@foo.com: 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: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 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 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-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”

a@foo.com: 128.59.16.1

sip:isabel@a.com;languages="es"sip:isabel@a.com;languages="en";q=0.2

sip:bob@a.com;languages="en"

INVITE sip:sales@a.comAccept-Contact: *;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: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 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)

CINEMA systemCINEMA system

All-SIP implementationAll-SIP implementation

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:boss@mycompany.com/) { 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:jones@example.com&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

Example PSTN statisticsExample PSTN statistics

Source: Worldbank

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/IRThgs@cs.columbia.edu

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 node7DS node

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

7DS implementation7DS implementation

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

Application-focused Application-focused researchresearch

Event systems for medical environments

Training for FAA flight controllers Enhanced presence systems CINEMA: SIP-based telecom

infrastructure