Lambda scheduling algorithm for file transfers

on high-speed optical circuits

Hojun LeePolytechnic Univ.

Hua Li and Edwin ChongColorado State Univ.

Malathi VeeraraghavanUniv. of Virginia

Contact: mv@cs.virginia.edu

2

Outline Background & Problem statement Varying-Bandwidth List Scheduling (V

BLS) Conclusions and future work

3

Background

Many optical network testbeds being created for eScience applications Canarie’s Ca*net 4 - Canada Translight – USA SURFnet – Netherlands UKLight – UK

Target applications: Terabyte/petabyte file transfers Remote visualization, computational

steering

4

Background These optical networks are circuit-switched Circuit-switched network operation:

Establish a circuit reserve capacity at each switch on end-to-end path

Dedicated resources implies “rate guarantee” Sounds great – but what’s the catch?

Cost, if network resources are not SHARED on some basis Answer: implement dynamic provisioning of circuits

User holds a “lambda” for some short duration and releases for others to use

How “dynamic?” The greater the sharing, the lower the costs Our proposed approach (NSF project called CHEETAH):

Hold “lambdas” only for the duration of file transfers

5

Background: Old theory says circuits unsuitable for file transfers

PS: Packet switch CS: Circuit switch

Fixed bandwidth scheme

Capacity C

PS

1

.

.N

2

3

Each transfer gets C/N capacity

1

23

NThe lone remaining transfer enjoys

full capacity C

Capacity C

CS

1

.

.N

2

3

Each transfer is allocated C/N capacity

1

23

N

The lone remaining transfer continueswith capacity allocation C/N

6

Our answer to this handicap

Instead of scheduling a “fixed capacity” for the duration of a file transfer -

To take advantage of bandwidth that becomes available subsequent to the start of the transfer -

Schedule varying capacities for different time ranges within the duration of a transfer

Provide sender this schedule at the start of the transfer (i.e., during circuit provisioning) – it adjusts sending rate

Announce schedule to all the circuit switches on the path for an automated reconfiguration of circuits at time range boundaries

How do we predict the time ranges in which more capacity will be available after the transfer starts at the time of circuit setup?

Require users to specify file sizes Scheduler keeps track of allocations already made to

ongoing transfers

7

Problem statement

Hence our problem is not how to schedule lambdas for fixed durations, but -

Rather it is how to schedule lambdas for file transfers

8

Scheduling requests Specify

File size Maximum rate

File transfers, unlike real-time audio/video, can be allocated “any” capacity; higher the rate, smaller the transfer delay

End host processing, network interface card and disk limitations place an upper bound on the rate allocated for the file transfer

Requested start time Allows users to specify a delayed start time Immediate-request vs. book-ahead calls (pricing)

9

VBLS: A Lambda-Scheduling Algorithm for File Transfers

End host applications request lambdas for file transfers by specifying a three-tuple

: file size : a maximum bandwidth limit for the request : the desired start time for the transfer

The scheduler assigns a Time-Range-Capacity (TRC) vector for each transfer

: the start of the kth time range : the end of the kth time range : the capacity allocated for the transfer in the kth time ra

nge.

),,( max reqTRF

F

maxR

reqT

},...,2,1),,,{( kCEB kkkkB

kE

kC

10

VBLS: an exampleAssume the available capacity of a 4-channel link is as shown below

F: 5GBRmax: 2 channelsTreq: 50

Per-channel rate: 10GbpsTime unit: 100ms

In 10 time units can transfer 1.25GB

TRC allocated: (50, 60, 1)(60, 70, 2)(70, 75, 2)

Availablecapacity

11

VBLS algorithm Identify change points (P1, P2, ..., Pn), in available

capacity function, (t) Find interval [Pi, P(i+1)] in which Treq lies Four cases are possible while allocating resources in

that interval: Remaining file can be fully transferred and (i) Rmax Remaining file can be fully transferred and (i) > Rmax Remaining file cannot be fully transferred and (i) Rmax Remaining file cannot be fully transferred and (i) > Rmax

In each case, we set parameters of a time range: Beginning of time range End of time range Capacity allocated in that time range

In last two cases, decrease remaining file size variable and continue to next interval between change points

12

Analysis and simulation

Traffic model: Call arrival process = file transfer

arrival process: Poisson with rate File size F: bounded Pareto distribution

pxk

pk

xkxfX

,

1

)(1

k: lower bound on file size; p: upper bound on file size; : shape parameter: 1.1

13

Validation of simulation program with analysis

Simple case: All calls specify same maximum rate,

which is set equal to link capacity C M/G/1 model with ‘G’ being bounded

Pareto Analytical result available

14

Result for validation case

File latency: mean waiting time – from Treq until first bit is transmitted

System load

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

System load

File

late

ncy

(sec

)

Analytical model (EQ(2))Simulation

CFE ][

15

Sensitivity analysis: Effect of maximum rate

All calls request same Rmax of 1, 5, 10, 100 channels on a link of capacity C=100 channels Mean latency smallest in the 1-

channel case Mean file transfer delay (which is

latency + service time) is smallest in 100-channel case

16

Sensitivity analysis: Effect of file size lower bound (k) and upper bound (p)

All calls request same Rmax of 1, 5, 10 channels on a link of capacity C=100 channels Case 1: k=500MB; p = 10GB Case 2: k= 10GB; p = 100GB

File latency is more in Case 2 because variance is higher in Case 2 (shape of bounded Pareto distribution)

Increasing upper bound p, increases variance and hence file latency increases

17

Simulation comparison of VBLS against FBLS (Fixed-Bandwidth LS) and PS

Normalized delay (D)

i

iF

i

idiF

D

Calls choose 1, 5 or 10 channels with probability 0.3, 0.3 and 0.4

18

Alternate view: throughput

File throughput (y-axis): long-term average of file size divided by transfer delay

System load (x-axis)

1 channel 5 channels 10 channels

19

Observation VBLS

Achieves close to idealized PS (infinite buffer) performance

Finite-buffer PS networks need something like TCP – reduces idealized PS throughput levels

Compare with current TCP enhancements under design

which are implementing run-time discovery of available bandwidth to ideally adjust sending rates to match available bandwidth

goal: avoid packet losses and consequent rate drops

20

Practical considerations

Extending VBLS scheme to multiple links Clock synchronization & Propagation delay

Staggered schedule Accounting for retransmissions Available capacity function

Cannot be continuous, has to be discrete Wasted resources because of discretization

Cost of achieving PS-like performance Circuit switches now more complex Need electronics to do timer-based reconfigurations

of circuits

21

Extensions

Add a second class of requests: Holding time Minimum rate Maximum rate Requested start time

Useful for remote visualization and other interactive applications

22

Conclusions and future work

VBLS overcomes a well-known drawback of using circuits for file transfers

fixed-bandwidth allocation fails to take advantage of bandwidth that becomes available subsequent to the start of a transfer

Simulations showed that VBLS can improve performance over fixed-bandwidth schemes significantly for file transfers

Cost: implementation complexity Future work: to include a second class of user requests for lambd

as, targeted at interactive applications such as remote visualization and simulation steering