Quality of Service for Remote Control in the High Energy Physics Experiments: a Case Study

Tiziana Ferrari Quality of Service for Remote Control in the High Energy Physics ExperimentsCHEP, 07 Feb 2000

1

Quality of Service for Remote Control in the High Energy Physics Experiments:

a Case Study

Tiziana Ferrari

[email protected]

INFN - CNAF


2

Overview

• Quality of Service

• differentiated services architecture

• application characterization

• service definition and implementation

• future work


3

Quality of Service: problem statement

• today: single service, best-effort• Service: type of “data” treatment during transmission across

the network - qualitative- quantitative (delay, instantaneous delay variation, packet loss,

throughput, MTU, congestion treatment)

• Class: set of packets to which a given service applies• Benefits:

- congestion management- differentiated allocation of expensive network resources (ISP)- application: differentiated treatment of streams according to their

requirements and priority- guarantees of congestion independent parameters (e.g. delay variation)


4

Differentiated services

• Why the differentiated services (diffserv)?

- independent of layer 2 technologies

- interoperability between independent national research networks (different requirements, infrastructures, policies and management)

- traffic aggregation

- scalability

- no signalling

- QoS for networks not ATM based


5

Diffserv architecture components

• DS field (1 byte) - IP header -

• packet classification

• packet scheduling

• traffic conditioning: - metering- marking- policing- shaping

DS field CU0 6 7


6

Diffserv architecture: PHBs

• Per Hop Behaviours: description of the packet treatment into the network

• Standardised PHBs:

- Expedited Forwarding (low delay, low delay variation,

guaranteed bandwidth)

- Assured Forwarding (Behaviour Aggregate, 4 classes,

3 drop priorities per class)

• Experimental PHBs

• PHB class selectors: XXX000 (backward compatibility with TOS precedence)


7

Diffserv architecture: network model

DS domain

DS domain

DS domainDS domain

Non-DS capabledomain

MPLS

Core domain

marking

Markingpolicing scheduling

shaping

DS domainATM

DS region


8

Application characterization

Goal:

identification of the application requirements for

service definition

1 Trigger hardware remote control

2 Monitoring: quality and correctness of analysis results


9

Application 1: trigger hardware remote control

VMEServer 1

...

Client 1

Client 2

Client 3

Client n

...

bottlenecks

VME

VME

Server 2

Server m

R1 R2 R3

• ROBIN • client - server, duplex exchange of data, interactive• few transactions (low bandwidth) • TCP ports and IP address of the server known• one-way delay sensitiveness• high reliability (packet loss probability, bandwidth)• burst tolerance


10

Application 2: Analysis monitoring

server

...

bottleneck

• exchange of analysis results (root object)• duplex, asymmetric traffic volume• low bandwidth consumption• client - server, • TCP, IP address of server and clients known• packet loss tolerant• minimum bandwidth guarantee per client• dynamic allocation of the maximum overall capacity allocated


11

Service Level Specification (SLS) - 1

• Hardware remote control:

- packet classification and marking (at the edge): if (pack(src) = (s1 || s2 || … || sm) &&

pack(dst) = (d1 || d2 || … || dn) &&

protocol = TCP && pack(port)[x, y] ) then label(pack) = max precedence

- bandwidth guarantee (through policing):max service rate = 64 Kbps * Nsrc 64 kbps: estimated rate consumed by 1 server/client

Nsrc: number of servers (upstream) of clients (downstream)if (traffic <= max && burst <= 64 kby) then

label = Expedited Forwardingelse label = best-effort

- one-way delay (through scheduling): priority queuing


12

Service Level - 1: implementation

scheduling

VME

Server 1

VME

Server 2

VME...

Client 1

Client 2

Client 3

Client 4

rR

Server 8

marking

R

Rr

r

traffic, max rate R

scheduling marking

Server client:

traffic, max rate r policing

PQ

PQ

PQ

PQ

PQ

PQ

PQ

PQ PQ

PQ

PQ

PQ

PQ

Client server:


13

Service Level Specification -2

• Analysis monitoring:

- server client:

* packet classification and marking (at the edge): if (pack(src) = s && pack(dst)=(d1 || d2 || … || dn) &&

protocol = TCP)

then label(pack) = PHB Assured Forwarding(AF)class

* bandwidth guarantee (through policing):max service rate per client = 256 Mbps min rate per client: 64 kbps

for each client: if (traffic <= min && burst <= 16 Kby) then label =

AF11; else if (traffic <= max) then label = AF12;

else drop(packet)

* scheduling: Weighted Fair Queuing * traffic differentiation: Weighted Random Early Discard


14

Service Level Specification -2 (cont)

- Client server:

* packet classification and marking (at the edge): if (pack(src) = di && pack(dst) = s && protocol =

TCP)

then label(pack) = PHB Assured Forwarding(AF)class

* bandwidth guarantee (through policing):max service rate = 5 Mbps min rate per client: 64 kbps

for each client: if (traffic <= min && burst <= 16 Kby) then

label = AF11; else label = AF12;

if (traffic(Af12) <= max) then OK else drop(packet);

* scheduling: Weighted Fair Queuing * traffic differentiation: Weighted Random Early Discard


15

Service Level -2: implementation

scheduling

Server

Client 1

Client 2

Client 3

Client 4

r

marking

R

r

r

r

traffic, max rate R

scheduling markingServer client: traffic, max rate r policing

WFQ

WFQ

WFQ

WFQ

WFQ

WFQ WFQ

WFQ

WFQ

WFQ

WFQ

Client server:


16

Scheduling: PQ vs WFQPriority Queuing:

absolute precedence over any other queueone-way delay minimization

WFQ: distribution of bandwidth between queues according to the weight associated to each of them


17

Future work

Fermilab

ESnetdiffserv Testbed

European diffserv testbedor ATM p-2-p link

Test site 1

Test site 1

Test site 1

...

•Testbed configuration •tuning of router configuration•validation of the EF : priority queuing, burstiness and scheduling•validation of the AF implementation: WRED configuration

Quality of Service for Remote Control in the High Energy Physics Experiments: a Case Study

Documents

Transcript of Quality of Service for Remote Control in the High Energy Physics Experiments: a Case Study