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

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


  • 257 Views
  • Uploaded on

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

PowerPoint Slideshow about 'Paving the Road to Collaboration Using H.323' - andrew


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 l.jpg

Paving the Road to Collaboration Using H.323

Dan Cotton, University of Nebraska

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


Aisep l.jpg
AISEP

Goal:

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


Aisep3 l.jpg
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 l.jpg
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 l.jpg
H.323

  • Presentation

    • Physical characteristics

    • Program design

    • Application testing


Network emulation l.jpg

Network Emulation

Understanding H.323 Performance Bounds

Paul Schopis

[email protected]


Overview l.jpg
Overview

  • Protocol Description

  • H. 323 bounds testing

  • QoS models

  • Implications of applying models

  • Engineering to need.


Protocol description l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Experiment Setup

NIC Client

Switch

VLAN 1

Appliance

Client

NISTnet

Switch

VLAN 2

MCU

MCU

Multiple Clients cascaded via Multiple MCUs


Types of tests l.jpg
Types of Tests

  • Point to point

  • One Armed MCU

  • MCU based ( Conference )

  • Cascaded MCUs.

  • Encode Delay.


End to end delay components l.jpg
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 l.jpg
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



Experiment and results l.jpg
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 l.jpg
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 l.jpg
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.


Models26 l.jpg
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.


Models27 l.jpg
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 l.jpg
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.



Megaconfernce iii l.jpg
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 l.jpg
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 l.jpg
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



  • Variables l.jpg
    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 l.jpg
    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 l.jpg
    Observations

    • Data rate

    • Frame rate

    • Packet loss

    • Pixellation

    • Latency

    • Jitter


    Preliminary results l.jpg
    Preliminary results

    • Some fluctuations in quality

    • Experienced some packet loss

    • Were able to identify certain optimum Polycom settings

    • It worked!


    Next steps l.jpg
    Next steps….

    • Internet2

    • Multi-point

    • Educational Effectiveness committee

      • Case studies



    ad