1 / 26

The Internet Real-Time Laboratory (IRT)

Learn about the Internet Real-Time Laboratory at Columbia University, conducting networking research since 2006. Explore diverse topics such as Internet telephony, multimedia systems, and ubiquitous computing. Engage with the innovative projects and collaborations focused on system evaluation, standardization, and product development.

benmathews
Download Presentation

The Internet Real-Time Laboratory (IRT)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Internet Real-Time Laboratory (IRT) http://www.cs.columbia.edu/IRT Prof. Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY January 2006

  2. Networking research at Columbia University • Columbia Networking Research Center • both Electrical Engineering & Computer Science Department • 13 faculty – one of the largest networking research groups in the US • about 40 PhD students • spanning optical networks and wireless channels to operating systems, security and applications • theory (performance analysis) to systems (software, protocols) Steve Bellovin Keren Bergman Ed Coffman Predrag Jelenkovic Angelos Keromytis Aurel Lazar Nick Maxemchuk Vishal Misra Jason Nieh Dan Rubenstein Henning Schulzrinne Xiaodong Wang Yechiam Yemini

  3. Laboratory overview • Dept. of Computer Science: 35 faculty • IRT lab staff: • 1 post-doc, 3 researchers • 10 PhD students • 7 MS GRAs • visitors (Ericsson, Fujitsu, Mitsubishi, Nokia, U. Coimbra, U. Rome, NTT, …) • China, Finland, Greece, India, Japan, Portugal, Spain, Sweden, US, Taiwan • ~10 MS and undergraduate project students

  4. Laboratory support Equipment grants and student support

  5. Overall IRT lab goals • Reliable, flexible and programmable communication infrastructure for Internet-based collaboration applications • Systematic evaluation by analysis and simulation • Demonstrate capability via prototypes • Contribute protocols to standardization (IETF) • Convert prototypes into products and open-source software • Train students at all levels in current Internet research and engineering

  6. Internet telephony and multimedia CINEMA – VoIP/multimedia and collaboration system QoS measurements network application reliability performance and server architecture APIs for SIP IM and presence systems ubiquitous computing using SIP application sharing P2P SIP systems emergency services (“911”) SIP security reputation systems, spam firewalls service creation languages CPL LESS Mobile and wireless systems 802.11 handoff acceleration 802.11 VoIP performance improvements SIP-based terminal mobility personal, service and session mobility Peer-to-peer messaging  7DS Service and event discovery (GloServ) Generic signaling protocols (GIMPS) for QoS, NAT/FW, … Autonomic computing service discovery  mSLP automated server pooling  DotSlash IRT research topics

  7. IRT and standards • PI and researchers active in IETF since 1992: • RTP – lead author • RTSP – lead author • SIP – original design & core team • SIP mobility • rich presence • privacy and geo-services • emergency calling • SLP – extensions for scalability • GIST – network signaling protocol

  8. Graduated PhD students • Internet telephony services, GSM interoperation (J. Lennox) • QoS and reliability measurements (W. Jiang) • Federated CDNs (L. Amini) • Pricing for QoS, LDAP performance (X. Wang) • Multicast QoS fairness & signaling (P. Mendes) • Internet telephony topics (J. Rosenberg) • Mobile peer-to-peer systems (M. Papadopouli) • Scalable resource reservation (P. Pan) • VoIP service creation (J. Lennox)

  9. Old problems and approaches: efficient codecs ubiquitous reachability audio/video synchronization network-layer mobility quality-of-service APIs and middleware New problems: controlled reachability spam cell phone ringing in lecture service availability information privacy service & personal mobility service creation by non-experts Multimedia systems problems

  10. CINEMA components Cisco 7960 MySQL sipconf rtspd user database LDAP server plug'n'sip RTSP conferencing media server server (MCU) wireless sipd 802.11b RTSP proxy/redirect server unified messaging server Pingtel sipum Nortel Cisco Meridian 2600 VoiceXML PBX server T1 T1 SIP sipvxml PhoneJack interface sipc SIP-H.323 converter sip-h323

  11. SIP emergency calling GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E  Paris fire department

  12. SIP for ubiquitous computing • Focus on inter-domain, scalable systems • Components: • context-aware communications • context-aware service and event discovery • location-based services • global-scale event notification • service creation by end users • terminal, personal, session and service mobility

  13. Context-aware communication • context = “the interrelated conditions in which something exists or occurs” • anything known about the participants in the (potential) communication relationship • both at caller and callee:

  14. RPIDS: rich presence data • Basic IETF presence (CPIM) only gives you • contact information (SIP, tel URI) • priority • “open” or “closed” • Extend to much richer context information watcher everything PA PUA watcher "vague" PUBLISH watcher NOTIFY CPL INVITE

  15. 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

  16. Service mobility: user-adaptive device configuration “all devices that are in the building” RFC 3082? SLP 802.11 signal strength  location device controller REGISTER To: 815cepsr Contact: alice@cs PA HTTP SUBSCRIBE to each room tftp • discover room URI • REGISTER as contact for room URI SIP SUBSCRIBE to configuration for users currently in rooms room 815

  17. Location-based services • Presence-based approach: • UA publishes location to presence agent (PA) • becomes part of general user context • other users (human and machines) subscribe to context • call handling and direction • location-based anycast (“anybody in the room”) • location-based service directory • Languages for location-based services • building on experience with our XML-based service creation languages • CPL for user-location services • LESS for end system services

  18. Location-based IM & presence

  19. Service creation • Promise of faster service creation • traditionally, only vendors (and sometimes carriers) • learn from web models

  20. Service creation environment for CPL and LESS

  21. GloServ: Hierarchical P2P Global Service Discovery Architecture Knarig Arabshian and Henning Schulzrinne Hotel CAN DHT distribution of properties 1 (Wyoming) 50 1) Query for “inn” is issued hostel inn rooming lodging motel 2 4 3 Service hasState Restaurant Travel Medical Communication 2) Map the word “inn” to “hotel” <1,2> <3,2> <1,3> <3,3> <2,1> <2,2> . . . <2,3> <10,2> <10,3> Destination Flights Agencies (Arizona) 3 4) Send the query to the closest high-level server that is known (Alaska) 2 Hotel Bed&Breakfast domain: hotel.destination.service 3) Look up the domain of the equivalent server or closely related server in the primitive skeleton ontology (Alabama) 1 1 (Sports) 2 (Adventure) 3 (Sightseeing) • Classify services using OWL • Use service classification to map ontology to a hierarchical P2P network (using CAN for p2p) • Bootstrap servers using information in ontology • Intelligent registration and querying hasActivity

  22. Capacity QoS in VoIP Wireless Networks: Adaptive Priority Control (APC) • Unbalanced uplink and downlink delay due to fairness in DCF. • Uplink and downlink delay need to be balanced for better QoS and capacity for VoIP. • AP needs to have a higher priority than the wireless nodes for fairness between uplink and downlink. Capacity • Adaptive Priority Control • Decides the priority of the AP adaptively based on • Wireless channel condition • Uplink and downlink traffic volume • Controls the transmission rate of the AP according to the priority of the AP using Content Free Transmission. • No changes in wireless nodes

  23. Client ID MAC DUID1 MAC1 DUID2 MAC2 DUID3 MAC3 IP MAC Expire IP1 MAC1 570 IP2 MAC2 580 IP3 MAC3 590 IP4 DUID4 Accelerating DHCP: P-DAD DHCP server Address Usage Collector (AUC) • AUC builds DUID:MAC pair table (DHCP traffic only) • AUC builds IP:MAC pair table (broadcast and ARP traffic) • New pair is added to table, unauthorized IP detected  AUC sends pair to DHCP server • DHCP server checks if pair is correct and records IP address as in use • ARP checking • AUC scans unused IPs using ARP query periodically • Silent nodes can be detected TCP Connection Broadcast-ARP/DHCP Router/Relay Agent SUBNET

  24. Ad-hoc wireless infrastructure

  25. ./: Rescue service for web servers experiencing 15 minutes of fame Extend Apache: mod_dots, dotsd, DNS, mSLP State Transition

  26. Conclusion • Other topics: • Skype analysis, QoS signaling, QoS for voice-over-802.11 • Focus on Internet multimedia services • fixed & mobile applications • VoIP – protocols, presence, location-based services, service creation, p2p networks • QoS in networks • Protocols, prototypes, performance evaluation

More Related