2005-2006

Projects Overview Projects Overview Andrea ForteAndrea Forte

Fast L3 handoff Passive DAD (pDAD) Cooperative Roaming (CR) Highly congested IEEE 802.11

networks – Measurements and Analysis

2005-2006

Fast L3 HandoffFast L3 Handoff We optimize the IP address acquisition

time as follows: Subnet Discovery Checking Cache for a valid IP Temp_IP (Cache miss) The client “picks” a

candidate IP using particular heuristics. SIP re-invite The CN will update its session

with the TEMP_IP. Normal DHCP procedure to acquire the final IP SIP re-invite The CN will update its session

with the final IP.

2005-2006

Fast L3 Handoff - ResultsFast L3 Handoff - Results

22

108

29

22

29

29

0

20

40

60

80

100

120

140

160

180

SD + Tem pIP SD + Cached IP Cached IP

Average L3 Handoff Time (msec)

Signaling overhead

SIP Stack overhead

DHCP Process ing tim e

Getting TEMP_IP

Subnet Discovery (SD)

2005-2006

Passive DAD - ArchitecturePassive DAD - ArchitectureAddress Usage Collector (AUC)DHCP server

Router/Relay Agent

SUBNET

AUC builds DUID:MAC pair table (DHCP traffic only). AUC builds IP:MAC pair table (broadcast and ARP traffic). The AUC sends a packet to the DHCP server when:

a new pair IP:MAC is added to the table a potential duplicate address has been detected a potential unauthorized IP has been detected

DHCP server checks if the pair is correct or not and it records the IP address as in use. (DHCP has the final decision!)

IP MAC ExpireIP1 MAC1 570

IP2 MAC2 580

IP3 MAC3 590

Broadcast-ARP-DHCP

Client ID MACDUID1 MAC1

DUID2 MAC2

DUID3 MAC3

TCP Connection

IP Client IDFlag

2005-2006

Cooperative Roaming (CR)Cooperative Roaming (CR) Stations can cooperate and share

information about the network (topology, services).

Stations can cooperate and help each other in common tasks such as IP address acquisition.

Stations can help each other during the authentication process without sharing sensitive information, maintaining privacy and security.

Stations can also cooperate for application-layer mobility and load balancing.

2005-2006

CR – Results (1/2)CR – Results (1/2)Handoff without authentication

343.027

867.0333

1210.0603

4.26 11.46 15.730

200

400

600

800

1000

1200

1400

CR Legacy Handoff

ms

L2

L3

Total

2005-2006

CR – Results (2/2)CR – Results (2/2)Handoff with authentication (IEEE 802.11i)

10

664.6

772.4

612.8

11.4

867897967

21.4

1531.6

1669.5

1579.8

0

200

400

600

800

1000

1200

1400

1600

1800

EAP-TLS (1024) EAP-TLS (2048) PEAP/MSCHAPv2(1024)

CR

ms

L2

L3

Total

2005-2006

Wireless measurements in Wireless measurements in highly congested 802.11 highly congested 802.11 networksnetworks

IETF meeting in Dallas (IETF-65) Three days of measurements (~8GB of

data). 400~500 people in one room (plenary). IEEE 802.11a/b Multiple APs on same channel. Congestion analysis (throughput, retries,

ARF), handoff analysis (Apple vs. others), unusual behaviors (broadcast feedback), load balancing (num. of clients vs. bandwidth).

2005-2006

Projects OverviewProjects OverviewKundan SinghKundan Singh

P2P-SIP using external DHT Thread and event models Conference server scalability

2005-2006

SIP-using-P2PSIP-using-P2PP2P-SIP using an external distributed hash table P2P-SIP using an external distributed hash table (DHT)(DHT)

Data vs service modes Data: treat DHT as data storage using put/get/remove Service: join DHT to provide registrar/presence service

using join/leave/lookup Logical operations

Contact management put (user id, signed contact)

Cryptographic key storage User certificates and private configurations

Presence put (subscribee id, signed encrypted subscriber id) Composition needs service model

Offline message put (recipient, signed encrypted message)

NAT and firewall traversal STUN and TURN server discovery needs service model

Proposed an XML-based data format

2005-2006

SIP-using-P2PSIP-using-P2PImplementation in SIPc with the help of Xiaotao Implementation in SIPc with the help of Xiaotao WuWu

OpenDHT Trusted nodes Robust Fast enough (<1s)

Identity protection Certificate-based SIP id == email

P2P forCalls, IM, presence, offline message, STUN server discovery and name search

P2P clients better than proxies:

Less DHT calls OpenDHT quota for

fairness imposes limit on proxiesShould this be

made open source?

2005-2006

SIP proxy performanceSIP proxy performanceEffect of software architecture and multi-Effect of software architecture and multi-processor hardwareprocessor hardware

Calls/s for stateless proxy, UDP, no DNS, 6 msg/callArchitecture/Hardware

1 PentiumIV 3GHz, 1GB, Linux2.4.20(1xP)

4 pentium, 450MHz, 512 MB, Linux2.4.20(4xP)

1 ultraSparc-IIi, 300 MHz, 64MB, Solaris(1xS)

2 ultraSparc-II, 300 MHz, 256MB, Solaris(2xS)

Event-based 1550 400 150 600

Thread per msg 1300 500 100 500

Pool-thread per msg (sipd)

1400 850 110 600

Thread-pool 1500 1300 152 750

Process-pool 1600 1350 160 1000Calls/s for stateful proxy, UDP, no DNS, 8 msg/call

Architecture/Hardware

1 PentiumIV 3GHz, 1GB, Linux2.4.20(1xP)

4 pentium, 450MHz, 512 MB, Linux2.4.20(4xP)

1 ultraSparc-IIi, 360MHz, 256 MB, Solaris5.9 (1xS)

2 ultraSparc-II, 300 MHz, 256 MB, Solaris5.8 (2xS)

Event-based 1150 300 160 400

Thread per msg 600 175 90 300

Thread-pool (sipd) 850 340 120 300

2 stage thread-pool 1100 550 155 500

Better performance as this includes mempool changes Software architecture

further improves performance: S3P3 can support 16 million BHCA

Both Pentium and Sparc took approx 2 MHz CPU cycles per call/s on single-processor

2005-2006

(a) Stateless proxy

0

1

2

3

4

1xP/Linux 4xP/Linux 1xS/Solaris 2xS/Solaris

event based

thread per msg

pool-thread per msg

thread pool

process pool

(b) Stateful proxy

0

1

2

3

4

1xP/Linux 4xP/Linux 1xS/Solaris 2xS/Solaris

event based

thread per msg

thread pool (sipd)

(2 stage) thread pool

Not much concurrency in stateful mode: needs more investigation

Should sipd use 2-stage thread pool architecture?

2005-2006

SIP conference server SIP conference server PerformancePerformanceFor G.711 audio mixing on a 3 GHz Pentium 4 For G.711 audio mixing on a 3 GHz Pentium 4 with 1 GB memorywith 1 GB memory

About 480 participants in a single conference with one active speaker (CPU is bottleneck)

About 40 four-party conferences, each with one active speaker (CPU is bottleneck)

Memory usage: 20 kB/participant Mixer delay: less than 20 ms Increasing the packetization interval to 40

ms improves performance to 700 participants, but also increases mixer delay

Both Pentium and Sparc take about 6 MHz/participant

2005-2006

Cascaded conference Cascaded conference serverserver

I measured the CPU usage for two cascaded servers: supports about 1000 participants in a single conference. The cascaded architecture scales to tens of thousands of participants.

SIP REFER message is used to create cascading

2005-2006

Projects OverviewProjects OverviewXiaotao WuXiaotao Wu

CUTE (Columbia University Telecommunication service Editor) GUI-based service creation tool to

help inexperienced users to create services

Service learning and service management Service learning Service risk management Handling feature interactions

2005-2006

CUTE (Columbia University CUTE (Columbia University Telecommunication service Editor)Telecommunication service Editor)

2005-2006

Survey on CUTESurvey on CUTE Evaluating how likely an end user can create

telecommunication services by himself and how useful and friendly CUTE is

http://www.surveymonkey.com/s.asp?u=909901973365

2005-2006

Service learning and service Service learning and service risksrisks Causal relationship between call

information and call decisions Decision tree induction

Incremental Tree Induction algorithm Service risk management

Identify: Lose connection, privacy, money, attention

Analyze: Possibility, impact, overall risk

Resolve: Change communication methods, transfer, reduce overall risk

Contingency plan

2005-2006

Feature interaction Feature interaction handlinghandling

accept

accept

Tree merging

+ =If time is between

10:00AM and 11:00AMIf address is hgs

Forward to conf

Incoming call Incoming call

Incoming call

If time is between 10:00AM and 11:00AM

If address is hgs

rejectForward to conf

rejectaccept

Take actions from both scripts. Simply setting precedence rules cannot work.

2005-2006

Service managementService management