The Internet Real-Time Laboratory Henning Schulzrinne September 2003 .

The Internet Real-Time The Internet Real-Time LaboratoryLaboratory

Henning SchulzrinneSeptember 2003

http://www.cs.columbia.edu/IRT

Networking research at Networking research at Columbia UniversityColumbia University Columbia Networking Research

Center spans EE + CS 15 faculty – one of the largest

networking research groups in the US

about 40 PhDs spanning optical networks and

wireless channels to operating systems, security and applications

theory (performance analysis) to systems (software, protocols)

Laboratory overviewLaboratory overview Dept. of Computer Science: 32 faculty IRT lab: 13 PhD students

includes 3 part-time students working at IBM, Lucent, Telcordia

2 MS GRAs visitors (Ericsson, Fujitsu, Mitsubishi,

Nokia, U. Coimbra, U. Rome, NTT, …) China, Finland, Greece, India, Japan,

Portugal, Spain, Sweden, US, Taiwan ~15 MS and undergraduate project

students

Laboratory supportLaboratory support

Equipment grants and student support

IRT topicsIRT topics Internet multimedia protocols and

systems Internet telephony and radio (J. Lennox, X.

Wu, K. Singh, W. Jiang, J. Rosenberg, A. Dutta, K. Koguchi; K. Butler, A. Nambi, S. Narayanan, A. Khwaja, S. Sridhar)

Content distribution networks (L. Amini, Y. Nomura)

Internet event distribution (P. Koskelainen, K. Arabshian)

Wireless ad-hoc networks (M. Papadopouli, S. Sidiroglou)

IRT topicsIRT topics

Quality of service Pricing for adaptive services (RNAP)

(X. Wang) Scalable resource reservation

protocols (P. Pan) BGRP for aggregation, YESSIR for

applications, GIMPS for general signaling Fair multicast resource allocation (P.

Mendes)

IP telephony: QoS IP telephony: QoS estimationestimation

QoS estimation of voice traffic influence of loss correlation + FEC estimation via objective methods automated MOS estimation via

speech recognition Planning: tools for automated end-

to-end assessment

CINEMACINEMA Web interface

Administration User

configuration Unified

Messaging Notify by email rtsp or http

Portal Mode 3rd party IpTelSP

CINEMA componentsCINEMA components

RTSP

sipum

Cisco 7960

sipvxmlSIP

rtspdsipconfLDAP server

MySQL

PhoneJack interface

sipc

T1T1

sipd

mediaserver

RTSP

SIP-H.323converter

messagingserver

unified

server(MCU)

user database

conferencing

sip-h323

VoiceXMLserver

proxy/redirect server

Cisco2600

Pingtel

wireless802.11b

PBX

MeridianNortel

plug'n'sip

CINEMACINEMA Goal: fully integrated

communications platform: synchronous + asynchronous

collaboration calendaring multimedia collaboration: G.711 and

high-quality audio, video, shared whiteboard, chat, shared applications

Web control or VoiceXML interaction support pure VoIP and hybrids

Internet telephony: sipcInternet telephony: sipc Cross-platform tool for integrated

multimedia communications Windows 98/NT/2K/XP Solaris, Linux, FreeBSD

Support media plug-ins Screen sharing IM and presence programmable logic (cgi, CPL) Device control (electric appliances) (Emergency) notification Conference control (in progress)

PSTN interworkingPSTN interworkingNortel PBXPSTN

External T1/CAS

Regular phone(internal)

Call 93971341

SIP server

sipd

Ethernet

3

SQLdatabase

4 7134 => bob

sipc

5

Bob’s phone

GatewayInternal T1/CAS(Ext:7130-7139)

Call 71342

5551212

Internet telephony: Internet telephony: emergency emergency communicationscommunications

911 services architecture

emergency notification

EPAD

REGISTER sip:sos

Location: 07605

302 MovedContact: sip:[email protected]: tel:+1-201-911-1234

SIP proxyINVITE sip:sos

Location: 07605

Languages for service Languages for service creationcreation

Traditionally, telecom services created by switch vendors

Web model: allow users and organizations to create custom services

Two models: sip-cgi and CPL Sip-cgi: cgi scripts for call handling

logic

Internet telephony: APIsInternet telephony: APIs

APIs for IM and presence (JAIN JSR) design and implementation cooperation with Panasonic

Call Processing LanguageCall Processing Language

XML-based language<incoming>

<address-switch field="origin" subfield="host">

<address subdomain-of="example.com">

<location url="sip:[email protected]">

<proxy>

<busy> <sub ref="voicemail" /> </busy>

<noanswer> <sub ref="voicemail" /> </noanswer>

<failure> <sub ref="voicemail" /> </failure>

</proxy>

</location>

</address>

<otherwise>

<sub ref="voicemail" />

</otherwise>

</address-switch>

</incoming>

Mobile ad-hoc networks: Mobile ad-hoc networks: 7DS7DS

Wireless infrastructure slow to emerge (Metricom , 3G $$$)

802.11b cheap and simple to deploy

Mobile devices spread data in densely populated areas (e.g., NYC)

7DS7DS

Content-independent: works for any web object

Uses standard caching mechanism After 25’, 90% of interested users

have data (25 hosts/ ) Also, data upload:

2km

Ad-hoc wireless Ad-hoc wireless infrastructureinfrastructure

7DS research issues7DS research issues Effects of power conservation,

collaboration mechanism, wireless coverage range, density of devices on information dissemination e.g., how fast does information

spread in such setting ? what is the average delay that a host experience until it gets the data ?

Performance analysis via simulations and diffusion controlled processes theory

Dotslash – A WebDotslash – A WebHotspot Rescue SystemHotspot Rescue System

Web Hotspot A sudden, dramatic surge of request

rate Short-term overload: long delay or no

service Challenges

Hard to predict Build up quickly Large magnitude

DotslashDotslash Motivation

One site can dramatically vary in request rate insufficient capacity

A group of sites peak at different time, spared capacity at some sites

Rescue service Dynamic collaboration among

different sites Enable a site to expand its capacity

dynamically and quickly

Functional ComponentsFunctional Components

Workload monitoring Discovery of spare capacity at

other sites Request distribution and

redirection Dynamic virtual hosting Dynamic replication of content Rescue relationship management

Basic ArchitectureBasic ArchitectureExtend Apache: mod_dots, dotsd, DNS, mSLP

State Transition

Fairness for multicastFairness for multicast

Intolerant (loss&delay) applications will use DiffServ Premium services, while tolerant applications can use Assured services;

Multimedia flows multicast to heterogeneous receivers will use Assured services;

Problem: Resources aren’t fairly distributed between flows inside a DiffServ service.

Differentiated Service (DiffServ) networks Differentiated Service (DiffServ) networks divide traffic into different service quality divide traffic into different service quality levels, considering their quality levels, considering their quality requirements:requirements:

Multi-receiver fair Multi-receiver fair allocationallocation

The number of receivers in each multicast flow;

A maximal utilization of resources; Differential dropping between flows that

overpass their share of service resources; A Multi-Receiver Utilization Maximal fair

mechanism (MRUM) is being developed.

Provide fair distribution of Provide fair distribution of AssuredAssured services resources between multimedia services resources between multimedia multicast flows considering:multicast flows considering:

Quality of service: pricingQuality of service: pricing

Bandwidth: decrease of marginal returns adaptive services

Bandwidth

CostU1 U2

U3 Budget

Bandwidth pricingBandwidth pricing

Congestion pricing See GWB, turnpike, electricity Higher overall utility Prices constant for periods O(min) Auction or tatonnement pricing

Charge for usage and reservation

Service locationService location

Enhancements to Service Location Protocol (SLP): reliability and scaling (meshed SLP) remote discovery attributes

Summary and future plansSummary and future plans Personal and session mobility Service creation for VoIP Integrating the natural environment into

IP communications Conferencing and conference control Ad-hoc and hybrid ad-hoc/infrastructure

networks Emergency communications Network reliability