The Reality and Mythology of QoS and H.323

1. The Reality and Mythology of QoS and H.323 pschopis@itecohio.org pcalyam@oar.net

2. Overview • H. 323 bounds testing • QoS models • Implications of applying models • Engineering to need.

3. Test Motivation • Abilene is trying to provide DiffServ EF • Is H.323 suitable candidate for APS? • DiffServ lacks hard bounds, it is totally probabilistic. • What really would help? What are the performance bounds?

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

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

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

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

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

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

10. Point-to-Point tests • Latency does not matter. (holds true for all scenarios)

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 Presentation Delay

22. Delay Values • Transmission Delay + Electronic Delay: Modem delay = 40ms Transmission delay = 10 chars over 56Kbps = 80/56000bps = 1.4ms • Switch Propagation Delay: <2ms • Presentation Delay = 17ms

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

24. Oscilloscope Waveforms

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

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

27. Network Calculus 101 • All functions are cumulative distribution functions, i.e. wide-sense increasing. • Uses min-plus Algebra. • Uses classes of primitive functions to describe various network behaviors • Employs convolution and deconvolution with primitives to arrive at meaningful conclusions.

28. Models • IntServ – Has the necessary per flow state but is not here yet. • It also probably has many unforeseen maintenance and administrative issues. (see next section). • Experience from ATM SVCs suggests many scalability issues. Possible solutions include MPLS or Policy routing.

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

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

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

32. 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. • 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.