http://www.cs.ucl.ac.uk/research/nrs/

Edge-to-Edge Dynamic QoS Reservations on SuperJANET4 Development Network

Richard Smith

Saleem Bhatti

Networks Research Group, Computer Science, UCL

http://nrg.cs.ucl.ac.uk/

Acknowledgements

Nicola Pezzi

Javier Orellana

Frank Saka

Peter Clarke

Manchester folk

RAL folk

UKERNA

Cisco

... and anyone else I have missed.

The Experiment

Is it possible to dynamically provision protected capacity on a high-speed network?

Bandwidth to be allocated in real-time, on demand

Accurate provisioning

Micro-mangement of flows by individual users/applications

Edge-to-edge signalling only – no state stored in core of network

(Is IP-based QoS control a good idea? discussion for another time …)

The Network

SuperJANET4 Development Network

MB-NG project - http://www.mb-ng.net/

DIFFSERV EF service

2.5 Gb/s in core links:

1Gb/s allocated to EF

Packet scheduling / policing:

Cisco router 7609 - MDRR / drop

Admission control / signalling:

GRS Project - NRS software
http://www.cs.ucl.ac.uk/research/nrs/

SuperJANET4 Development Network

RAL

ULCC

Warrington

UCL

Manchester

core router - Cisco 12xxx

edge router - Cisco 7609

2.5Gb/s POS

SuperJANET4 development network (simplified)

Project links

GRS

(edge)

MB-NG

(core, UK)

UKLIGHT (TBA)
(international)

EGEE/GEANT (TBA)
(international)

MB-NG - http://www.mb-ng.net/

GRS - http://www.cs.ucl.ac.uk/research/grs/

UKLIGHT - http://www.ja.net/development/UKLight/

EGEE - http://public.eu-egee.org/

GEANT - http://www.dante.net/geant/

Setup

Each PC can generate 1 Gb/s data

We transmit and monitor:

Background (UDP) traffic

A single UDP flow

A single TCP flow

One NRSE at London, one at Manchester:

Application signals local NRSE (London) which then signals Manchester NRSE (peer-to-peer)

NRSEs configure local edge routers

Routers drop packets when overloaded, but give priority to EF marked packets

Network Configuration

NRSE

application

requests

configure routers

Outline architecture

data

packets

NRSE

application

“scheduling harmonisation middleware”

(to CPU scheduling)

requests

NRSE Design

NRS-A

scheduling control

(schedule management)

(reservation invocation)

NRS-P

NRS-L

NRS-M

RD

user (human or application)

other

NRSEs

local

management

network elements

(e.g. routers, switches, etc.)

NRSE

Demo

Flows

TCP flow (stuck in slow start)

UDP flow (1 Gbps)

Background traffic (2 X 1 Gbps)

Total > 2.5 Gbps, so congestion!

TCP reservation (100 Mbps, 3 mins)

UDP reservation (950 900 Mbps, 2 mins)

UDP modified (500 Mbps)

TCP modified (500 Mbps)

TCP saw-tooth (aliasing/congestion control)

Demo - movie

Results

Dynamic edge-to-edge reservations successfully provide QoS guarantees for this environment

Protected bandwidth for both EF and BE

Users easily able to add, modify-in-progress and delete reservations for immediate use or in advance

Accurate timing of reservation activation

Would not be successful if core was not over-provisoned with respect to DIFFSERV EF

Discussion [1]

EF (re-)defined in RFC3246:

EF PHB defined for single hop only, not edge-to-edge

Intuitive definition (RFC3246, section 2.1):

“... the rate at which EF traffic is served at a given output interface should be at least the configured rate R, over a suitably defined interval, independent of the offered load of non-EF traffic to that interface.”

R averaged over a period of a few seconds

Observation of end-to-end rate ~1Gb/s

No loss observed for EF traffic

Discussion [2]

Formal definition (RFC3246, section 2.2/2.3/2.4):

scheduling - packet departure times

delay and jitter constraints

E_a, E_p error terms

MDRR details not available:

Work-conserving (so jitter likely)

No exhaustive delay measurements (yet)

so no estimates of E_a, E_p

but ad hoc observations suggest upper bound on delay

Do we care if it strictly conforms to the EF formal definition if an edge-to-edge, protected, loss-less, bounded-delay service is possible to implement?

Questions?

Only thank Nicola by name

SKIP THIS SLIDE unless we have too much time

We have implemented a protected capacity edge to edge service, and we can define that service how we like. We antipate most users will be doing file transfers, which doesn't care about jitter. However, we are not conformant to EF definition of per hop behaviour. Jitter sensitive applications will need to use buffering, as they already do.

Edge to Edge Dynamic QoS Reservations on SuperJANET4 Developmen

2004-07-05T04:06:31