v Telecommunications Industry AssociationTR-30.3/ Arlington, VA, March 30-31, 2009

Packet Delay Modeling From a network synchronization perspective TIA TR 30.3 Arlington, VA March 2009

Outline Introduction Status Need common test suites Issues Burst Definition Simple way to understand PDV Matlab approximation to help demystify Synthetic test cases Some example results Interesting 3D surface plots Recap

State of Sync Deployment of CES/TDMoIP/PTP has begun Strong financial incentive to do so Trials are ongoing with good success But is the technology really ready? Not yet. Examples: SLA metrics are insufficient to ensure success with Sync Need common conformance and interoperability test suites Allocate end-to-end PDV budget to individual NEs Drives future equipment development Anue Systems, Inc.

Need common test suites Three different approaches Collect real world traces from actual networks Good because it is realistic But no way to know if such traces are really worst case Service providers are sensitive about publishing such measurements G.8261 Appendix VI test bed Measure delays in a test bed under controlled conditions Realism and repeatability depends on many factors Synthetic test cases Create test cases that introduce controlled amounts of impairment Can be unrealistic but still very useful E.g: sinusoidal tolerance tests for SONET/SDH Can be realistic E.g: modem testsd Anue Systems, Inc.

Real world measurements Actual measurements are samples of network behavior. Good for research and initial development Not so good for ensuring interoperability or performance margin in a real network. What if conditions change? Network loads & characteristics increase Technologies change (e.g. DOCSIS3.0, WiMAX, xDSL, PON) And: Harder to control e.g. no control over results (e.g. minTDEV)

Real World Measurements Anue Systems, Inc. GEM RNC Capture CES or PTP and save to PDV Bidi & Multi stream PDV #1 PDV #2 1 2

Real world measurements Anue Systems, Inc.

G.8261 App VI Test case: Seems straightforward Anue Systems, Inc.

Build & Measure a G.8261 App VI Test bed Test case descriptions in Appendix VI are incomplete It probably seemed clear enough when written. And it wasn’t important enough to be normative anyway. Now, everyone is doing it. Differently. Top three issues 1.Load Definition 2.Burst Definition 3.Burst Definition Anue Systems, Inc.

A test bed Measure delay under G.8261 Appendix VI test conditions…..

Definition of Load Percentage Load percentage is A ratio: number of bits / max # bits possible Measured over a specified time interval Longest possible time is to measure over a whole test case (one value/average) Shortest possible time is to measure from one frame to the next (many values) Why does this matter? Because we need to know what 80% load means If 80% is the peak load Then 80% is max and applies only during the burst. During gap, assume that 64 and 576 byte generators stay same If 80% is an average over the whole test case (nominal), Then load measured during a single burst must be greater than 80%. The amount by which it exceeds 80% determines the burst duty cycle. Anue Systems, Inc.

Bursts not fully specified “Maximum size packets will occur in bursts lasting between 0.1s and 3s.” Two related questions: How long between bursts? What is the burst density? If “Load” means peak load Then there’s no guidance on the gaps between bursts Could pick fixed or random value, or just assume 50% duty cycle If “Load” means average load Then gap time will depend on burst density proportional to the amount by which the load during a burst exceeds the nominal load Anue Systems, Inc.

Burst Parameters Anue Systems, Inc. time Load Percentage Burst Length Burst Load Gap Length Nominal Load

Burst Examples (30 sec. each: 20%, 50%, 80%) Anue Systems, Inc.

Burst Examples (30 sec. each: 20%, 50%, 80%) Anue Systems, Inc.

Burst Examples (30 sec. each: 20%, 50%, 80%) Anue Systems, Inc.

Are there limits on Burst Density? Yes For two reasons TM1 has 64-byte disturbance packets at a constant rate (CBR). Bandwidth limit (1G) of the disturbance load generators. Though you could have separate generators for each packet size ($) Max BurstLoad = 100% - NomLoad*(F 64 +F 576 ) Anue Systems, Inc.

G.8261 App VI Test cases: What matters most? Primary factor: Configuration of disturbance load generator Bursts (and gaps) Disturbance packet size(s) Secondary factors Type of switch (L2 or L2/L3) CBR (almost or exactly … or not) Other important factors Non-ethernet links (especially asymmetric access technologies) DSL, Cable Modem, PON (beating effects w.r.t. packet schedulers) Uplink versus downlink Store & Forward (traditional ethernet) vs. cut-through (MPLS) Anue Systems, Inc.

What to expect PDV to look like? Why? function V = PDV(NumPkt, PktSz, DistLd, TM, NumSw, MinDelSw, UncDelSw) MinDly = NumSw * (PktSz + MinDelSw); % Store-fwd delay MaxLen = max(TM(:,1)); X = zeros(1,MaxLen); % X is PDV for one switch for d=1:size(TM,1) len = TM(d,1); frac = TM(d,2); X = X + (frac/len)*[ones(1,len), zeros(1,MaxLen-len)]; end V = zeros(1,MaxLen*(NumSw-1)); % V is end-to end PDV V(1) = binopdf(0,NumSw-1,max(1e-4,DistLd)); for j=1:NumSw-1 tmp = X; for k=2:j tmp = conv(tmp,X); end weight = binopdf(j,NumSw-1,max(1e-4,DistLd)); V = V + weight*[tmp,zeros(1,MaxLen*(NumSw-1)-size(tmp,2))]; end V = [zeros(1,MinDly) NumPkt*V]; V = conv(V,ClkUncer(NumSw,UncDelSw)); Anue Systems, Inc.

What to expect PDV to look like? Anue Systems, Inc.

Model-based impairment profiles Build a bottom-up model of each network element Construct test scenarios by connecting together various model elements and run a simulation Validate end-to-end results Challenges As network changes, model params must also change New technologies may require new model elements Harder to make a general model than to measure one sample

Discrete event simulation of test bed.. One way to model is to use a discrete event simulator Develop models for the switches and dummy traffic generators. Anue has developed one such model This is just the beginning of modeling Further refinements are possible Plots shown are for G.8261 test beds configured per Appendix VI TM2 bursts assume Bursts that have constant load (70%-60%) 10 store/fwd GigE switches, 20 disturbance load generators (fwd/rev) Clock uncertainty (each switch is asynchronous) No priority or congestion avoidance (QoS, RED/WFQ, VOQ)

Example model results (20% load TM2) Reference (test bed) S/W Model Results

G.8261 Test Case 2 (TM2) Load Steps Anue Systems, Inc.

G.8261 Test Case 3 (TM2) Slow Load Ramp 24hr Anue Systems, Inc.

G.8261 TC3: variations showing 3D PDV Anue Systems, Inc. Delay 50us 150us 20% 80% Load

G.8261 TC3: variations showing 3D PDV Anue Systems, Inc. Delay 50us 150us 20% 80% Load

G.8261 TC7 (TM2 E1 16ppb) - Beating Anue Systems, Inc.

G.8261 TC8 partA (Blocking) Anue Systems, Inc. Bursts of max len pkts: (this dimension is governed by the burst density and max packet size) Gap between bursts: (this dimension is governed by the min and medium size packets)

3D Surface plot for TC8 ( blocking ) Anue Systems, Inc. Delay 50us 150us 0% 50% Load

3D Surface plot for TC8 ( blocking ) Anue Systems, Inc. Delay 50us 150us 0% 50% Load

G.8261 TC13 TM2 (fwd/rev steps) Anue Systems, Inc.

Recap Deployment has started Need metrics for measuring PDV Need common, repeatable test cases Focus on conformance and interoperability Burst parameters need better specification Simple matlab code can predict first order PDV behavior Helps understand measurements from lab Synthetic model Results are quite realistic

Thank You!

Questions? Contact me! Chip Webb Anue Systems 9111 Jollyville Rd Suite 100 ( preferred ) +1 (512) x102

Backup Slides Anue Systems, Inc.

Effect of reverse traffic: For L2/L3 enterprise switch DUMMY LOAD DUMMY LOAD Capture Packets Capture Packets DUT

Effect of reverse traffic: For L2/L3 enterprise switch Anue Systems, Inc.

Effect of reverse traffic: minTDEV Anue Systems, Inc.