Paving the Road to Collaboration Using H.323

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

• The project will
• enable unreachable campuses, remote learning
  centers, extension offices to share in advanced
  networking research and applications
• create access for the research university
  community to scientific, cultural and human
  resources otherwise inaccessible

4
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

5
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

6
H.323

• Presentation
• Physical characteristics
• Program design
• Application testing

7
Network Emulation

• Understanding H.323 Performance Bounds
• Paul Schopis
• pschopis_at_itecohio.org

8
Overview

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

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

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

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

12
Audio Artifacts

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

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

14
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

15
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

16
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

17
(No Transcript)
18
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.

19
Experiment Setup
NIC Client
Switch VLAN 1
Appliance Client
NISTnet
Switch VLAN 2
MCU
MCU
Multiple Clients cascaded via Multiple MCUs
20
Types of Tests

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

21
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 Pre
sentation Delay
22
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
23
Oscilloscope Waveforms
24
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)

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

26
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- a-
• 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.

27
Models

• DiffServ lacks the per flow state necessary for
  tight performance bounds because..
• ß1(t) ß(t)- a2(t) Where ß is the
  rate-latency function. ßR,T(t) Rt-T i.e.
  Service Curve.
• b1 b1 r1T r1(b2r2T/R-r2) Where b is a
  component of the Affine function ? r,b(t) brt
  if t0.
• Source Network Calculus A Theory of
  Deterministic Queuing Systems for the Internet
• by Jean-Yeves Le Boudec Patrick Thriran,
  Springer-Verlog, Berlin Heidelberg, 2001.

28
Models

• V 0.564 for bounded delay so when v0
• converges to V the latency bound explodes to
  infinity. For vl Si?m ri/Cl. Where
• v link utilization, iflow, 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.

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

30
Program Design
31
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/

32
(No Transcript)
33
(No Transcript)
34
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 AT
• NSF Access Center, Washington D.C.

35
(No Transcript)
36
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
• Dont limit your thinking.explore all
  possibilities

37
H.323 Over Satellite
38
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

39
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

40
Observations

• Data rate
• Frame rate
• Packet loss
• Pixellation
• Latency
• Jitter

41
Preliminary results

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

42
Next steps.

• Internet2
• Multi-point
• Educational Effectiveness committee
• Case studies

43
Q A