1. 2005-2006 Projects Overview Andrea Forte Fast L3 handoff Passive DAD (pDAD) Cooperative Roaming (CR) Highly congested IEEE 802.11 networks – Measurements and Analysis

2. 2005-2006 Fast 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.

3. 2005-2006 Fast L3 Handoff - Results

4. 2005-2006 Passive DAD - Architecture Address 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!) IPMACExpire IP1MAC1570 IP2MAC2580 IP3MAC3590 Broadcast-ARP-DHCP Client IDMAC DUID1MAC1 DUID2MAC2 DUID3MAC3 TCP Connection IPClient IDFlag

5. 2005-2006 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.

6. 2005-2006 CR – Results (1/2)

7. 2005-2006 CR – Results (2/2)

8. 2005-2006 Wireless measurements in highly congested 802.11 networks 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).

9. 2005-2006 Projects Overview Kundan Singh P2P-SIP using external DHT Thread and event models Conference server scalability

10. 2005-2006 SIP-using-P2P P2P-SIP using an external distributed hash table (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

11. 2005-2006 SIP-using-P2P Implementation in SIPc with the help of Xiaotao Wu OpenDHT Trusted nodes Robust Fast enough (<1s) Identity protection Certificate-based SIP id == email P2P for Calls, 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 proxies Should this be made open source?

12. 2005-2006 SIP proxy performance Effect of software architecture and multi-processor hardware Calls/s for stateless proxy, UDP, no DNS, 6 msg/call Architecture /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-based1550400150600 Thread per msg1300500100500 Pool-thread per msg (sipd)1400850110600 Thread-pool15001300152750 Process-pool160013501601000 Calls/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-based1150300160400 Thread per msg60017590300 Thread-pool (sipd)850340120300 2 stage thread-pool1100550155500 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

13. 2005-2006 Not much concurrency in stateful mode: needs more investigation Should sipd use 2-stage thread pool architecture?

14. 2005-2006 SIP conference server Performance For G.711 audio mixing on a 3 GHz Pentium 4 with 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

15. 2005-2006 Cascaded conference server     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

16. 2005-2006 Projects Overview Xiaotao 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

17. 2005-2006 CUTE (Columbia University Telecommunication service Editor)

18. 2005-2006 Survey 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=909901973 365

19. 2005-2006 Service learning and service risks Service learning and service risks 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

20. 2005-2006 Feature interaction handling Feature interaction handling accept Tree merging + = If time is between 10:00AM and 11:00AM If address is hgs Forward to conf Incoming call If time is between 10:00AM and 11:00AM If address is hgs reject Forward to conf reject accept Take actions from both scripts. Simply setting precedence rules cannot work.

21. 2005-2006 Service management Service management