Paving the road to collaboration using h 323
Download
1 / 42

Paving the Road to Collaboration Using H.323 - PowerPoint PPT Presentation

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Paving the Road to Collaboration Using H.323

Dan Cotton, University of Nebraska

Paul, Schopis, Internet2 Technology Evaluation Center (ITEC-Ohio)


AISEP

Goal:

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


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


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


H.323

  • Presentation

    • Physical characteristics

    • Program design

    • Application testing


Network Emulation

Understanding H.323 Performance Bounds

Paul Schopis

pschopis@itecohio.org


Overview

  • Protocol Description

  • H. 323 bounds testing

  • QoS models

  • Implications of applying models

  • Engineering to need.


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


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.


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.


Audio Artifacts

  • Audio Augmentation – Audio artifacts added to audio stream such as pops, clicks and hiss.

  • Audio Depreciation – Parts of the audio are missing.


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.


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


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


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


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.


Experiment Setup

NIC Client

Switch

VLAN 1

Appliance

Client

NISTnet

Switch

VLAN 2

MCU

MCU

Multiple Clients cascaded via Multiple MCUs


Types of Tests

  • Point to point

  • One Armed MCU

  • MCU based ( Conference )

  • Cascaded MCUs.

  • Encode Delay.


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


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


Oscilloscope Waveforms


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)


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.


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.


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.


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.


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.


Program Design


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/


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.


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


  • H.323 Over Satellite


    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


    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


    Observations

    • Data rate

    • Frame rate

    • Packet loss

    • Pixellation

    • Latency

    • Jitter


    Preliminary results

    • Some fluctuations in quality

    • Experienced some packet loss

    • Were able to identify certain optimum Polycom settings

    • It worked!


    Next steps….

    • Internet2

    • Multi-point

    • Educational Effectiveness committee

      • Case studies


    Q & A


    ad
  • Login