1 / 42

Paving the Road to Collaboration Using H.323

Paving the Road to Collaboration Using H.323 Dan Cotton, University of Nebraska Paul, Schopis, Internet2 Technology Evaluation Center (ITEC-Ohio) AISEP Goal:

andrew
Download Presentation

Paving the Road to Collaboration Using H.323

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. Paving the Road to Collaboration Using H.323 Dan Cotton, University of Nebraska Paul, Schopis, Internet2 Technology Evaluation Center (ITEC-Ohio)

  2. AISEP Goal: Bring advanced networking applications to geographically remote campuses and learning centers for purposes of research, teaching and extension.

  3. AISEP Objectives: • explore use of satellite to deliver Internet services to determine compatibility of satellite technology with I2 services and applications • explore deployment and integration of DE applications, including collaborative applications at rural, remote institutions and extension learning centers

  4. Testing, Evaluation & Measurement • ITEC/Ohio (lead) • University of Nebraska (network engineering) • Iowa State (3D Lab work) • Colorado State (satellite engineering) • Internet2 • ITEC/North Carolina • CAIDA • Tachyon

  5. H.323 • Presentation • Physical characteristics • Program design • Application testing

  6. Network Emulation Understanding H.323 Performance Bounds Paul Schopis pschopis@itecohio.org

  7. Overview • Protocol Description • H. 323 bounds testing • QoS models • Implications of applying models • Engineering to need.

  8. Protocol Description • Borrows Q.931 from ISDN Standards encapsulated in TCP • Establishes UDP Channels Video and Audio • Establishes RTP and RTCP for Control Channel ( provides timing for audio video synchronization).

  9. Test Motivation • Desire to better understand application and Network interaction. • Is H.323 suitable candidate for DiffServ? • What really would help? What are the performance bounds? • Desire to develop methodology for network centric application analysis.

  10. Video Artifacts • Spatial Augmentation – Video artifacts are added to the picture. Objects appear that are not in the captured video such as video tiles. • Spatial Depreciation – Parts of the picture or objects in the picture are missing. • Temporal Distortion – Over time the “flow” of an event is distorted by missing data, in mild cases resulting in an inter-frame jerkiness. In more severe cases resulting in video freezing.

  11. Audio Artifacts • Audio Augmentation – Audio artifacts added to audio stream such as pops, clicks and hiss. • Audio Depreciation – Parts of the audio are missing.

  12. Scope of H.323 Bounds Testing • What network conditions can be mapped to certain qualities of video. • It can be highly subjective. • We did not desire to engage in a Cognitive Science experiment. • Needed simple reproducible test procedure.

  13. Test Procedure • Still office scene, count the number of defects over a 60 second sample. • Motion in scene and count the number of seconds needed to recover. • Tested in a variety of setups • Point-to-point • MCU • Cascaded MCUs • Isolated Latency, Loss and Jitter

  14. Emulation vs. Simulation • Advantages of Simulation • Can be cheap and easy to assemble • Tests are controlled and reproducible • Problems of Simulation • Simulation may differ significantly from reality • Virtual environment may not correctly quantify variables

  15. Network Emulator • Operating System: Linux Mandrake 7.2 Kernel recompiled and optimized for the device to be a router. • CPU: Pentium III 733Mhz • Memory: 256 MB. • Motherboard: Asus CUSLC2-C AGP4X • NICS: Intel Etherpro 10/100. • Emulator Software: Nistnet 2.1.0

  16. Used to test H.323 • Verified Nistnet system prior to test. • Tested platform with SmartBits. • All parameters were met with in a +/- 1 msec (Actual resolution ~.5msec) • With SmartBits we could verify switches etc. to further validate our findings. Worst case is total accuracy within +/- 3msec.

  17. Experiment Setup NIC Client Switch VLAN 1 Appliance Client NISTnet Switch VLAN 2 MCU MCU Multiple Clients cascaded via Multiple MCUs

  18. Types of Tests • Point to point • One Armed MCU • MCU based ( Conference ) • Cascaded MCUs. • Encode Delay.

  19. End-to-end Delay Components SENDER SIDE NETWORK RECEIVER SIDE Compression Delay Transmission Delay Electronic Delay Propagation Delay Processing Delay Queuing Delay Resynchronization Delay Decompression Delay Presentation Delay

  20. Encode and Decode Latency SWITCH END POINT 1 END POINT 2 MIC I/P AUDIO O/P MCU MCU METRONOME (PULSE GENERATOR) A B OSCILLOSCOPE SCOPE I/P A: METRONOME I/P SCOPE I/P B: ENDPOINT 2 AUDIO O/P

  21. Oscilloscope Waveforms

  22. Experiment and Results • Dialing Speeds: 256K, 384K, 512K, 768K • Metronome setting: 113 • Propagation delay + Switch delay ~ 0 • Encode + Decode delay ~ 240ms (independent of dialing speed) • Delay through MCU ~120ms to ~200ms (delay increasing with dialing speed)

  23. Network Requirements • Latency – users may find annoying but the it does not break the protocol. • Loss – Can tolerate some loss, must be below 1% in p-2-p and 0.75% in MCU • Jitter – Very jitter intolerant. For 30 Fps must be lower than ~33 msec. Seems very intolerant in cascaded MCU scenario.

  24. Models • Any E-2-E solution has scalability problem in the sense that in packet switched networks the solution vector is more than number of hops and delay etc. • x-> <= Ax->+α-> • In other words it is also a function of topology. (More in DiffServ). .Source: Network Calculus: A Theory of Deterministic Queuing Systems for the Internet by Jean-Yeves Le Boudec & Patrick Thriran, Springer-Verlog, Berlin Heidelberg, 2001.

  25. Models • DiffServ lacks the per flow state necessary for tight performance bounds because….. • β*1(t) = [β(t)- α2(t)] Where β is the rate-latency function. βR,T(t) = R[t-T]+ i.e. Service Curve. • b*1 = b1 + r1T +r1(b2+r2T/R-r2) Where b is a component of the Affine function γ r,b(t) = b+rt if t>0. Source: Network Calculus: A Theory of Deterministic Queuing Systems for the Internet by Jean-Yeves Le Boudec & Patrick Thriran, Springer-Verlog, Berlin Heidelberg, 2001.

  26. Models • V ~ 0.564 for bounded delay so when v0 converges to V the latency bound explodes to infinity. For vl = ΣiЭm ri/Cl. Where v = link utilization, i=flow, r = rate and C = service rate. Source: Network Calculus: A Theory of Deterministic Queuing Systems for the Internet by Jean-Yeves Le Boudec & Patrick Thriran, Springer-Verlog, Berlin Heidelberg, 2001.

  27. Engineering to the need • What realistically can we do? • It depends on ones network. • Appropriate queuing for congested links for maybe a single to only a few flows. • ADEC may be ideal for this condition. • Packet shaping on receiver with a Greedy Packet Shaper. GPS will not increase latency or buffering requirements if and only if network was previously lossless.

  28. Program Design

  29. Megaconfernce III • International IP-based video conference • Sponsored by Internet2 / ITEC • Goals • push state-of-the-art Internet video conferencing • induce vendors to improve their products • bring new users and countries online • 200 universities & organizations • For more information about the conference: • http://www.mega-net.net/megaconference/

  30. ADEC Presentation • Digital Inclusion: Extending I2, ADEC and NSF • University of Nebraska, Lincoln • University of Maryland, College Park • University of Maryland, Eastern Shore • North Carolina A&T • NSF Access Center, Washington D.C.

  31. Lessons Learned • Hybrid networking works • Television techniques can be applied….and they positively impact program quality • Studio cameras • Studio lighting • Studio set • Microphones • Producer / director • Don’t limit your thinking….explore all possibilities

  32. H.323 Over Satellite

  33. Variables • Tachyon Network • Satellite IP, asynchronous, bandwidth settings, dedicated vs. non-dedicated service • Polycom • dialing speeds • Internet1 – Internet2 • Point-to-point, multi-point • Data flow: uplink > downlink, downlink > uplink • Network traffic - noise • H.323 • MCU

  34. Testing (April 2002) • Test tape • Internet1 • Tachyon bandwidth service • 2mb/256k non-dedicated • 2mb/512k non-dedicated • Goal: identify optimum Polycom speed per Tachyon bandwidth service • Video tape results

  35. Observations • Data rate • Frame rate • Packet loss • Pixellation • Latency • Jitter

  36. Preliminary results • Some fluctuations in quality • Experienced some packet loss • Were able to identify certain optimum Polycom settings • It worked!

  37. Next steps…. • Internet2 • Multi-point • Educational Effectiveness committee • Case studies

  38. Q & A

More Related