A Research Framework for the Clean-Slate Design of Next-Generation Optical Access

A Research Framework for the Clean-Slate Design of

Next-Generation Optical Access

Dr Kyeong Soo (Joseph) Kim

College of Engineering

Swansea University

22 August 2011

Outline

I. Introduction

II. New Comparative Analysis Framework

III. Virtual Test Bed for Experiments

IV. Preliminary Results: Elasticity of Hybrid PON

V. Summary

2

Overview of Proposed Research Programme

Virtual Test Bed for Next-Generation Optical Access (NGOA)

Comparative Analysis Framework

Generating realistic traffic through a complete protocol stack

based on user behaviour models at application & session levels.

Quality of Experience

(QoE)

• A new comparative analysis framework for the user-

perceived performances (as measures of QoE) of candidate

NGOA systems.

• It is based on equivalent circuit rate (ECR) framework &

multivariate non-inferiority testing procedure and able to

take into account the statistical variability in experimental

data and a tolerance for the measure.

• The virtual test bed is implemented as simulation models for both systems under

test (SUT) &supporting environments (i.e., application server, intermediate

routers, user nodes) and run in a large-scale with the help of cloud computing (i.e.,

Amazon elastic compute cloud (Amazon EC2)*).

• It provides a common reference framework for experiments for researchers in

both Academia and Industry in order to properly benchmark candidate NGOA

systems and exchange their results.

Energy-Efficient and Elastic Components and Architectures

New Research Framework for Clean-Slate Design of NGOA

• Based on the proposed research framework,

we will investigate from scratch the

following major issues in components &

architectures:

• System capacity

• Elasticity

• Cost & energy efficiency

• We expect that the results from our study

will be quite different from conventional

ones and, therefore, have many implications

on traffic engineering as well as

architectural designs for the following

reasons:

• Realistic traffic models

• Measures for user-perceived

performances

User Behaviour-Based Traffic Modelling/Generation

* Supported by Amazon Web Services (AWS) in Education Research Grant.

I. Introduction

4

Changing Landscape for NGOA in 10-Plus-Year Time Frame

• Architectural requirements – Higher line rate (10+ Gbit/s)

and per-user capacity

– Lower power consumption

– Elasticity

– Access/metro integration • Higher split ratios (1:128~1024)

• Longer reaches (60~100 km)

– Support of hybrid optical/wireless

• Traffic characteristics – Higher bandwidth

– Higher burstiness

– Peer-to-peer

• Business aspects – Revenue model

– New services/applications • User demands

• Usage behaviour

5

Characteristics of Future Traffic: Higher bandwidth and burstiness!

Slow start

Congestion

avoidance

HTTP (TCP) Traffic

I B B P B B I B … frame

size MPEG-4 Part 2

(I/P/B=6721B/2234B/1186B)

H.264/AVC (I/P/B=5658B/1634B/348B)

Video Traffic*

Cannot fill the pipe

for most of the time

* G. van der Auwera et al., “Traffic characteristics of H.264/AVC variable bit rate video,”

IEEE Comm. Mag., vol. 46, no. 11, pp. 164-174, Nov. 2009. 6

Lessons from Cloud Computing* - 1

– Elasticity

• Ability to add or remove resources at a fine grain and with a small lead time

– Transference of risks of

• Overprovisioning (underutilization)

• Underprovisioning (saturation)

Max. (=peak)

Min.

Avg.

Time

Demand

* M. Armbrust et al., “Above the clouds: A Berkeley view of cloud computing,”

Dept. of EECS, UC Berkeley, Tech. Rep. UCB/EECS-2009-28, Feb. 2009. 7

Lessons from Cloud Computing - 2

– The illusion of infinite computing resources available on demand • Through the construction of large-scale, commodity-computer

datacenters at low cost locations, and virtualization technique

– The elimination of an up-front commitment by cloud users • Companies can start small and increase gradually

– The ability to pay for use of computing resources on a short-term basis as needed

8

Implications on NGOA Architectures - 1

9

Economy of scale through integration*

Network resource as utility

Maximisation of resource sharing

* M. Armbrust et al., “Above the clouds: A Berkeley view of cloud computing,”

Dept. of EECS, UC Berkeley, Tech. Rep. UCB/EECS-2009-28, Feb. 2009.

Implications on NGOA Architectures - 2

Backbone/Core MAN

Access

Access

Residential

Users

Business

Users

Current edge of the OBS/MPLS network

New edge of the OBS/MPLS network (toward ONUs)

New framing &

switching schemes

at UNIs

…

…

Flexible PON Flexible PON with higher elasticity

See the next slides for examples.

10

Remotely Powered & Reconfigurable Remote Nodes*

11

JSDU PPC-9LW

Photovoltaic Power Converter

Fiberer 2x2 MEMS

Optical Latching Switch

* J. H. Lee et al., “A remotely reconfigurable remote node for next-generation access networks,”

IEEE Photon. Technol. Lett., vol. 20, pp. 915, Jun. 2008.

Scheduler

Downstream

Traffic

Queues

. . .

1:M

Passive Splitter

Upstream

Traffic

Queues

. . .

Burst-Mode Receiver

MAC Downstream

Traffic Queue

Upstream

Traffic Queue

Hybrid TDM/WDM-PON OLT

Hybrid TDM/WDM-PON ONU

1:N

AWG

. .

. .

. .

Circulator

Tunable Transmitter

Tunable Receiver

Tunable Receiver

Circulator

. . .

. . .

Tunable Transmitter

Modulator (e.g., RSOA)

Hybrid

TDM/WDM-PON

with Tuneable

Transceivers

1:2

Passive Splitter

12

Key Observations - 1

• Toward more energy-efficient & elastic NGOA

– Performance has long been a major issue in traditional network design, but energy efficiency becomes as important an issue as performance in design of NGOA.

– The elasticity of network is a key to achieving higher energy efficiency as well as lower operation & maintenance cost.

13

Key Observations - 2

• Lack of a comprehensive research framework

– Many candidate architectures and protocols have been proposed, but there is no comprehensive framework to compare their performances in a fair and objective way.

– A new research framework should be able to take into account the energy efficiency and elasticity of architectures and protocols as well as the performances perceived by users (i.e., reflecting QoE).

14

Key Observations - 3

• Importance of experiments in the study of NGOA systems

– Due to the complexity of protocols and the interaction among multiple traffic flows in the study of network architectures, researchers now heavily depend on experiments with simulation models or test beds implementing proposed architectures and protocols, rather than traditional mathematical analyses under simplifying assumptions.

15

Key Observations - 4

• Need of a powerful and flexible test bed for experiments

– To provide the whole protocol stack up to the application layer, measurement of user-perceived performances, and traffic generation based on user behavior.

– To enable researchers and network operators/service providers to test candidate NGOA systems under a realistic and long-term operating environment. • We are aiming to investigate the impact of (at least) daily usage

patterns of residential & business users on network performances.

16

What Should We Do Now?

• Because we are at an early stage of research for long-term NGOA solutions, we need to establish a comprehensive research framework for comparing candidate network architectures and protocols and implement a powerful and flexible test bed for actual experiments under a realistic operating environment.

• Then, we should carry out the investigation of both new (e.g., energy efficiency, elasticity) and old (e.g., performances, cost) issues for candidate network architectures and protocols based on the proposed research framework and test bed.

17

Clean-Slate Design of NGOA

Virtual Test Bed

NGOA Components & Architectures

18

Comparative Analysis

Framework

Revenue & User Behaviour Modelling

18

Need of Clean-Slate Design

• To take into account the fundamental changes of NOGA in 10-plus-year time frame, we need to revisit from scratch the following issues:

– Research framework • Comparative analysis

• Quantification of bandwidth and power consumption

• Traffic generation and performance measures

– Architectures • WDM-PON, hybrid PON, OFDMA-PON, ODSM-PON*.

– Protocols and algorithms • Switching/routing, scheduling, flow control, framing, link adaptation.

– Revenue models • Based on new consumer demands and usage behaviours.

19 * Opportunistic and dynamic spectrum management PON

Our Approaches

• We will design from scratch and investigate the issues of energy efficiency, elasticity, and cost based on user-perceived performances under a realistic & long-term operating condition.

• Our approaches will give us new insights on critical issues in NGOA architectures and protocols including – Quantification of network capacity based on user-perceived performances.

– Evaluation of energy efficiency , elasticity, and cost of candidate systems based on the (statistically) equivalent user-level performances.

– Investigation of merits/demerits of shared & dynamic architectures with respect to dedicated & static architectures.

20

II. New Comparative Analysis Framework

21

Motivation

• Due to the complexity of protocols and the interactive nature of traffic involved in the study of network architectures, researchers now heavily depend on experiments with simulations or test beds.

• Due to the shift toward experiments, comparison procedures should be able to take into account the statistical variability in measured data from the experiments.

• Measures for the comparison should be user-oriented (i.e., QoE-based) and multiple measures should be compared together in an integrated way.

22

Issues in Comparison - 1

• The comparison between two delay curves shown in the figure seems straightforward at first glance.

• In fact, it is not straightforward when we consider the statistical variability in measured data. – A statistical approach is needed!

23

Load

Delay

System A

System B

x

24

Issues in Comparison - 2

• How can we compare multiple performance measures of two systems in an integrated way? – Can we say that the system A is

at least as good as the system B? • If so, on what basis?

• How can we relate network-level performances to user-perceived performance (i.e. QoE)?

25

Measure System A System B

Delay 10 ms 9.5 ms

Throughput 100 MB/s 97.6 MB/s

Packet Loss Rate

5 % 7 %

Existing Works on Comparison Framework

• Equivalence Testing1

– Frequently used in Medicine and Biology for the establishment of the equivalence (often called bioequivalence) between two different clinical trials or drugs through statistical hypothesis testing.

• Equivalent Circuit Rate (ECR)2

– A measure for shared packet access network, which specifies the rate of a dedicated connection that is equivalent to the shared system in terms of user-perceived performance (i.e., web page delay).

– Currently state-of-the-art in networking research.

26

1. R. L. Berger and J. C. Hsu, “Bioequivalence trails, intersection-union tests, and equivalence confidence sets,”

Statistical Science, vol. 11, no. 4, pp. 283-319, 1996.

2. N. K. Shankaranarayanan et al., “User-perceived performance of web-browsing and interactive data in HFC cable

access networks,” Proc. of ICC’01, vol. 4, Jun. 2001, pp. 1264-1268.

App.

Server

App.

Server

RB

RB

Reference Architecture

R = min(RF, RD) ( 1.0)

ONU 1 User 1

User n

…

RF

RD

RD

Candidate Architecture

ONU 1

ONU N

…

User 1

User n

…

User 1

User n

…

RU

RU

OLT

OLT

RU

Comparative Analysis Framework based on ECR

27

Original ECR Calculation Procedure

28

Simulation with reference model (Point-to-point)

Build a function f(R)=Dw

given the # of sessions

Simulation with candidate model

(TDM-PON, Hybrid PON, …)

Find Dw

given the # of sessions

Solve f(ECR)=Dw

* R: Access line rate

* DW: Web page delay

Issues in Original ECR Framework

• Use of a single performance metric

– HTTP traffic alone cannot provide enough load for the NGOA with 10+ Gbit/s capacity.

– A broad spectrum of applications/services for future NGOA needs to be covered.

• No systematic comparison procedure

– No procedure is provided for the comparison of simulation results.

29

New Comparative Analysis Framework

• Construct a new framework extending the original ECR framework as follows:

– What to compare • Multiple user-perceived performances covering broad spectrum of

applications/services for future NGOA

• Percentile (including average and maximum) of performance measures

– How to compare • Comparison of a single performance measure: Based on non-

inferiority testing (at least as good as; one-sided variant of the equivalence testing).

• Integration of multiple single-performance comparisons: Based on intersection-union testing (IUT).

30

Equivalence or Non-inferiority? - 1

• Equivalence test is based on “acceptable difference” limits as follows:

– 𝐻0: 𝜇𝑅 − 𝜇𝐶 ≤ 𝜃𝐿 or 𝜇𝑅 − 𝜇𝐶 ≥ 𝜃𝑈

– 𝐻𝐴: 𝜃𝐿 ≤ 𝜇𝑅 − 𝜇𝐶 ≤ 𝜃𝑈

31

Equivalence or Non-inferiority? - 2

• However, do we really need the two-sided criterion in comparing network architectures based on performance measures (i.e., QoE)?

– “At least as good as (i.e., non-inferiority)” would be more appropriate criterion here.

– So the hypotheses in this case are:

• 𝐻0: 𝜇𝑅 − 𝜇𝐶 ≤ 𝜃 (or 𝜇𝑅 − 𝜇𝐶 ≥ 𝜃)

• 𝐻𝐴: 𝜇𝑅 − 𝜇𝐶 > 𝜃 (or 𝜇𝑅 − 𝜇𝐶 < 𝜃) – Direction of inequality depends on a measure (e.g., delay,

throughput).

32

Extended ECR Calculation Procedure - 1

• First, obtain measures of the user-perceived performances for applications/services (i.e., 𝑀1, ⋯ ,𝑀𝑁𝑀

) of the reference architecture for the

line rates of 𝑅1, ⋯ , 𝑅𝑁𝑅 where 𝑅1 = 𝑚𝑖𝑛 𝑅𝐹 , 𝑅𝐷 ,

𝑅𝑁𝑅> 0, and 𝑅𝑖 > 𝑅𝑗 for 𝑖 < 𝑗.

– 𝑁𝑀 and 𝑁𝑅 denote the number of performance measures adopted and the number of values for R (i.e., 𝑅𝑖’s) used for comparison, respectively.

33

Extended ECR Calculation Procedure - 2

• Second, using the procedures in the next slides, find a value for the line rate of the reference architecture for which the measures of the candidate architecture are statistically non-inferior to those of the reference architecture.

– The null and the alternative hypotheses of the non-inferiority testing for measure 𝑀𝑖 are given by

𝐻0: 𝜇𝑖,𝑅 − 𝜇𝑖,𝐶 ≤ 𝛿𝑖𝐻1: 𝜇𝑖,𝑅 − 𝜇𝑖,𝐶 > 𝛿𝑖

where 𝜇𝑖,𝑅 and 𝜇𝑖,𝐶 denote population means of 𝑀𝑖 for the reference and the candidate architectures, respectively, and 𝛿𝑖 represents the tolerance for the measure 𝑀𝑖.

34

ECR Calculation Procedure Based on Multivariate Non-inferiority Testing

Start

i = 0

Multivariate non-inferiority testing

(of candidate w.r.t. reference with the line

rate of Ri)

result = pass?(Non-inferior?)

i < NR?

No

i = i + 1

Yes

Failed

No

ECR = Ri

Yes

End

• NR: Number of values for R (i.e., Ri’s) used for comparison

35

See the next slide.

Multivariate Non-inferiority Testing Based on Intersection-Union Test (IUT)

Start

i = 0

Non-inferiority testing for measure i

(of candidate w.r.t. reference)

Reject H0?(Non-inferior?)

i < NM?

Yes

i = i + 1

Yes

result = pass

No

result = fail

No

End

• NM: Number of performance measures adopted

36

Benefits of a New Comparison Framework

• We can present the combined performance (i.e., ECR) of a system in a more compact way, given the configuration.

• We can compare non-traditional measures of systems (e.g., energy efficiency, cost, and the amount of resources) in a fairer way under the configurations (of systems) providing the same ECR.

37

Challenges of a New Comparison Framework

• Measurement of user-perceived performances under a realistic operating environment requires

– Traffic models based on user behaviours for applications/services.

– A test bed to carry out experiments under a realistic operating environment and obtain higher-level measures for user-perceived performances.

• We need massive computational power to compute a test statistic of measures for the ECR calculation.

38

III. Virtual Test Bed for Experiments

39

Why Not Real Test Bed?

• A real test bed is good for the R&D of systems already standardised, but not cost-efficient and flexible enough for the clean-slate design of NGOA with the following features: – Multiple candidate systems are tested and compared.

– A whole protocol stack (up to application layer), together with user behavior models, is used for the investigation of interaction among traffic flows as well as realistic traffic generation.

• We want a common reference framework for experiments to be available for researchers in both Academia and Industry (not physically confined to a certain lab/institution) in order to properly benchmark candidate systems and exchange their results. – Like ns in early days of the study of TCP protocols1,2.

40

1. K. Fall and S. Floyd, “Simulation-based comparisons of Tahoe, Reno and SACK TCP,”

SIGCOMM Comput. Commun. Rev., vol. 26, pp. 5–21, Jul. 1996.

2. L. Breslau et al., “Advanced in network simulation,” IEEE Computer, vol. 33, no. 5, pp. 59-67, May 2000.

Our Solution

• A virtual test bed which will be implemented as simulation models for both systems under test (SUT) and supporting environments (e.g., application server, user nodes) and run in a large-scale with the help of cloud computing.

• Features:

– Simulation models based on OMNeT++/INET framework1.

– Message passing interface (MPI)2 for parallel extension of large-scale simulation.

– Hybrid cloud based on local private cloud and remote public cloud for scalable & cost-efficient computing.

41 1. http://www.omnetpp.org

2. http://www.mpi-forum.org

App.

Server

RB RF

RD

RD

ONU 1

ONU N

…

RTT

User 1

User n

…

User 1

User n

…

RU

OLT ODN

RU

Router Router RB

SNI UNI System Under Test

ODN: Optical Distribution Network

SNI: Service Node Interface

UNI: User Node Interface

RTT: Round-Trip Time

Overview of Virtual NGOA Test Bed

42

Traffic Generation in Existing Work

• Traffic is usually generated at the data link/network layer based on a frame/packet-level traffic models. – Due to the computational

complexity involved with implementation of higher layers and protocols.

– This approach, however, cannot capture the interactive nature of real traffic in actual networks.

43

Application/ Session

Transport

Network

Data Link

Physical

or

Traffic Generation in Our Work

• Traffic will be controlled and initiated by the user (via its behaviour model) and generated through the whole protocol layers (including application/session and transport). – In this way, we can capture the

interactive nature of real traffic in actual networks in the virtual test bed.

– Also, we can take into account traffic patterns for different types of users. • e.g., business vs. residential users

44

Application/ Session

Transport

Network

Data Link

Physical

User

Overview of User (Host) Node

TCP

UDP

Network and Lower

Layers

…

…

…

UNI

HTTP 1

FTP 1

HTTP nh

FTP nf

Video nv

Video 1

User Behaviour

Model

45

User Behaviour-Based Traffic Modelling and Generation

User Behaviour Model

Session-Level Traffic Model

Packet/Frame-Level Traffic Generation

X1 X2 Xn

Y1 Y2 Ym

46

Measurement of User-Perceived Performances

• Capturing user-perceived performances as objective measures of QoE

• Use of session- or video-frame-level metric – Session delay; web page delay for HTTP and file downloading delay for

FTP.

– Decodable frame rate (DFR) for video stream.

• Measurement of percentiles – Mean and maximum as special cases.

47

Session-Level HTTP Traffic Model • A behavioural model for user(s) web browsing* with the

following simplification: – No caching and pipelining

– Adapted for traffic generation at the client side

48 * J. J. Lee and M. Gupta, “A new traffic model for current user web browsing behavior,”

Research@Intel, 2007.

Server

Client

Request for

HTTP object

Request

for embedded

object 1

Response

Parsing Time Reading Time

…

Request

for embedded

object 2

Response to the last

embedded object Request

for HTTP

object

Web page delay (= session delay)

Session-Level FTP Traffic Model • A simple model for user(s) file downloading*:

– Could be considered as HTTP sessions just downloading files.

– The model is for a data transfer connection only. • A connection for control information is ignored.

– Adapted for traffic generation at the client side

49

Server

Client

Request for

a file to download

Reading Time

Response to the

file Request for

a file to download

File download delay (= session delay)

* cdma2000 Evaluation Methodology, 3GPP2 C.R1002-B, 3GPP2 Std., Rev. B, Dec. 2009 .

Streaming Video Traffic Model

• Interface with OMNeT++/INET framework

– Through “UDPVideoStream{Svr,Cli}WithTrace” modules:

• UDP server can handle multiple client requests simultaneously

• Random starting phase for each request

• Wrap around to generate infinite streams

• UDP client records the following performance metrics: – Packet end-to-end delay (vector)

– Packet loss rate

– Frame loss rate

– Decodable frame rate (perceived quality metric)

50

Implementation of Virtual Test Bed

GPON Test Bed

Private Cloud

Cloud Computing 51

Hybrid Cloud for Seamless Development and Running of Programs

• We will build a hybrid cloud integrating a small-scale, private cloud and a large-scale public cloud (Amazon EC21)

– An identical environment for both the development of programs at a local private cloud and the run of them at a remote public cloud without change of code

– Based on open-source solutions

• OpenNebula (distributed VM management)

• StarCluster (clustering and load balancing)

1. Currently supported by Amazon Web Services (AWS) in Education Research Grant.

2. R. S. Montero, “Scaling out computing cluster with Amazon EC2: Hands on!,”

ESAC Grid Workshop, Madrid, Spain, Dec. 2008.

2

52

IV. Preliminary Results: Elasticity of Hybrid PON

53

System Model – Dedicated Reference • Number of ONUs (N): 1

• Number of hosts per ONU (n): 1, 2, …

• Access rate (RD = RF): 1, 10 Gbit/s

• UNI rate (RU): 10 Gbit/s

• Backbone rate (RB): 1 Tbit/s (future standard or MUX of 100-Gbit/s links)

• Round-trip time (RTT): 10 ms (including 600 µs RTT in 60-km PON)

54

App. Server

ONU 1 RD = RF

Host 1

Host n

… Backbone

RTT

RB

RU

System Model – Hybrid PON • Number of ONUs (N): 16

• Number of Hosts per ONU (n): 1, 2, …

• Distribution/Feeder Rates (RD, RF): 10 Gbit/s

• UNI Rate (RU): 10 Gbit/s

• Number of Transceivers (NTX, NRX): 1, 2, …

• Backbone Rate (RB): 1 Tbit/s

• Round-Trip Time (RTT): 10 ms

55

RF App. Server

ONU 1

ONU N

…

RD

RD

Host 1

Host n

…

Host 1

Host n

…

RTT

RB

OLT

RU

TX, RX

Number of Sessions per Each Traffic

• nh = nv = 1

– Assume that a user can watch and interact with at most one video channel and one web session simultaneously at any given time. • As far as user perceived (interactive) performance is concerned.

• nf should be kept large to load the high-speed access link

– FTP is usually background process. • This could be HTTP sessions just downloading files!

– Suggest 10 as a starting point. • Cannot find FTP model for 10 Gbit/s link at this time!

56

HTTP Traffic Model -1 Parameters / Measurements Best Fit (Parameters)

HTML Object Size [Byte] / Mean=11872, SD=38036, Max=2 M

Truncated lognormal (=7.90272, =1.7643, max=2 M) Mean=12538.25, SD=45232.98*

Embedded Object Size [Byte] / Mean =12460, SD=116050, Max=6 M

Truncated lognormal (=7.51384, =2.17454, max=6 M) Mean=18364.43, SD=105251.3

Number of Embedded Objects / Mean=5.07, Max=300

Gamma (=0.141385, =40.3257) Mean=5.70, SD=15.16

Parsing Time [sec] / Mean=3.12, SD=14.21, Max=300

Truncated lognormal (=-1.24892, =2.08427, max=300) Mean=2.252969, SD=9.68527

Reading Time [sec] / Mean=39.70, SD=324.92, Max=10000

Lognormal (=-0.495204, =2.7731) Mean=28.50, SD=1332.285

Request Size [Byte] / Mean=318.59, SD=179.46

Uniform (a=0, b=700) Mean=350, SD=202.07

57 * Assuming MB = MiB (Mebibyte; 230)

HTTP Traffic Model - 2

• With RTT=10ms & synthetic traffic statistics:

– Avg. web page (session) delay: 2.3s

• = RTT*(1+E[Nembedded_object])+E[TParsing]

• Ignoring transmission delay

– Avg. session period (including reading time): 30.8s

– Avg. load (# of bits/session period): 30.4 kbit/s

• = 3803.2 B/sec

• 328670+ sessions needed to fully load 10 Gbit/s line! (328+ for 10 Mbit/s line)

58

Streaming Video Traffic Model • HDTV quality, realistic, high bit-rate video traffic models

are needed for NGOA

– Use H.264/AVC video traces

– “Terminator 2” VBR clip from ASU Video Trace Library • Duration: ~10 min

• Encoder: H.264 FRExt

• Frame Size: HD 1280x720p

• GoP Size: 12

• No. B Frames: 2

• Quantizer: 10

• Mean frame bit rate: 28.6 Mbit/s

– ~334 streams needed to fill 10 Gbit/s line with the following assumption:

» Total overhead: 66 Bytes

• RTP(12), UDP(8), IP(20), and Ethernet (26)

» RTP payload: 1460 Bytes

• In case of 1500-byte MTU 59

FTP Traffic Model - 1

Parameters Probability Distribution Function (PDF)

File Size [Byte] / Mean=2 M, SD=0.722 M, Max=5 M

Truncated lognormal (=14.45, =0.35, max=5 M) Mean=1995616(~2 M), SD=700089.8(~ 0.70M)

Reading Time [sec] / Mean=180

Exponential (l=0.006) Mean=166.667, SD=166.667

Request Size [Byte] / Mean=318.59, SD=179.46

Uniform (a=0, b=700) Mean=350, SD=202.07

60

FTP Traffic Model - 2

• With RTT=10ms & synthetic traffic statistics:

– Avg. session delay: 10 ms

• = RTT

• Ignoring transmission delay

– Avg. session period (including reading time): 166. 68 s

– Avg. load (# of bits/session period): 95.8 kbit/s

• = 11972.7 B/sec

• 104384+ sessions needed to fully load 10 Gbit/s line! (104+ for 10 Mbit/s line)

61

TCP Parameters

• Protocol: Reno

– New Reno, SACK?

• MSS: 1460

– Default: 536

– Optimized for Ethernet interface

• 1452 for PPP

• Advertised window:

– Default: 14*MSS

62

Network Parameters

• Queueing policy: Drop Tail

• Ethernet NIC frame buffer size: 10k frames

– Based on RTT(10ms) * BW(10Gbit/s)

• (10ms * 10 Gbit/s) / 1518*8 bits/frame

• OLT VoQ and ONU FIFO queue sizes: 121,440,000 bits

– Corresponding to 10k maximum size (1518 bytes) Ethernet frames

63

Simulation Runs

• 30 hours with 20-min warmup-period

• 10 replications

– Corresponding to about 3000+ HTTP/500+ FTP sessions

• Rule of thumb (e.g., SMPL text book) recommends at lest 2500 samples with 5 replications.

– 20+ replications for normal distribution assumption in t-test in the future

64

Post-Processing

• Statistical analysis: R

• General scripting: Perl, Python, Shell (bash)

• Plotting: SciPy with matplotlib

65

Initial Results: Elasticity of Hybrid TDM/WDM-PON

• The figure shows the min. number of tuneable transceivers (min(Ntx)) of hybrid PON to achieve the ECR of Rtarget Gbit/s. – For the reference architecture,

the number of transceivers is fixed to the number of ONUs (subscribers), independent of the network load.

– The hybrid PON, on the other hand, can adjust the number of transceivers depending on the network load.

66

V. Summary

67

Summary • We have been investigating the issues of quality of experience (QoE), elasticity*, and

energy efficiency in NGOA with a focus on the solutions beyond 10G-EPON/XG-PON (i.e., NG-PON2 by ITU-T) and found out that the progress in the clean-slate design of NGOA has been impeded by the absence of a comprehensive research framework for a comparative analysis of candidate network architectures and protocols.

• We propose, therefore, a research programme for the clean-slate design of NGOA with the following major objectives:

– A new comparative analysis framework based on statistical hypothesis testing and user-perceived performances;

– User behaviour modelling for future services and applications;

– Virtual test bed for experiments under a realistic operating environment;

– Energy-efficient and elastic components and architectures.

• The results of the proposed research programme will not only enable researchers to carry out a fair and objective comparison of various candidate architectures and protocols, but also allow network operators & service providers to dimension their future NGOA under a realistic environment through the virtual test bed.

68 * The elasticity in the context of networking means the ability to manage overall

performances by fast provisioning of network resources based on user demands.