Bell Labs Advanced Technologies EMEAAT Proprietary Information © 2004 Lucent Technologies1 Overview contributions for D27 Lucent Netherlands Richa Malhotra

Proprietary Information © 2004 Lucent Technologies 1Bell LabsAdvanced Technologies EMEAATAT

Overview contributions for D27

Lucent Netherlands

Richa Malhotra

Ronald van Haalen

2Bell LabsAdvanced Technologies EMEAATAT

Overview of Lucent’s contribution to D27

Route management: Comparison of large Load-balanced networks with large Ethernet networks

Resilience: Protection for load-balanced networks and comparing it to Ethernet

QoS on Ethernet (most topics also hold for IP):

– Scheduling

– Policing, Marking and Queue management interaction and influence on achievable SLAs

– TCP performance with SLA based policing


Resilience contributions for D27

Lucent Technologies

Richa Malhotra, Ronald van Haalen


Resilience for load-balancing

Source

Destination

Link or node failure leads to loss of traffic

Traffic

Traffic

Traffic

Traffic

Traffic



Source

Destination

Use one or more parity streams for protection, if a link fails, the packets can be generated again at the destination by using the parity stream

Traffic

Traffic

Traffic

Traffic

Parity stream



Compare Ethernet and load-balancing resilience

Ethernet Spanning Tree:

– Loss of bandwidth because of protection

– Restoration time

Load-balancing parity:

– Loss of bandwidth because of protection

– No restoration time

Perform simulations to compare the two schemes


QoS contributions for D27

Lucent Technologies

Richa Malhotra, Ronald van Haalen


QoS topics addressed

Scheduling

Policing, Marking and Queue management interaction and influence on achievable SLAs

TCP performance with SLA based policing

Focus

– Metro Ethernet Networks

– Issues also apply to IP networks


Scheduling: Problem Background

Basically 2 types of traffic

– Stream (UDP), does not adapt to network resources, time-sensitive

– Elastic (TCP), adapts to network capacity available, time insensitive

Classes of service – stream inelastic, Elastic and Best Effort

SLA (service level agreement)s will exist both for inelastic(UDP) and elastic(TCP) traffic streams. Guarantees have to be met for both.


Problem Description

Due to time-sensitive nature of UDP-stream traffic has to be given strict priority over TCP-elastic traffic

If the load of the high priority UDP-stream traffic is not controlled it will starve the low priority TCP-elastic traffic and SLAs will not be met.

Thus the load of high priority UDP-stream traffic has to be controlled.

QUESTION: To what extent should this be controlled, and how will this influence the TCP-elastic traffic? Can we relate these two aspects with simple analytical expressions

The analytical expressions can then be used for QoS control, integrated into the CP/MP for admission control and resource management. Probably monitoring techniques can make the performance estimations more time-dependant and accurate over time.


Model

High priority queue with stream traffic (UDP), Blocking

Low priority queue with elastic traffic (TCP), No Blocking

Fixed server capacityProcessor sharing for low priority

Scheduling: Strict priority

Exponential arrivals with requests service length (file length or session length following a generic distribution

Low priority traffic sees varying server capacity available for itself

Capacity left over for low priority is shared over all low priority elastic flows

Typical of TCP traffic: Within a SLA/customer flow the number of TCP flows are not controlled.

TCP adapts to the network capacity available and reduces its rate. (We use flow level model)


Results: Exponential Service requirements

beta_high beta_low lambda_h lambda_low Capacity_total Capacity_h Simulation THEORYlow_sojournloss prob high low_Sojourn loss prob high %error

0.25 1 0.8 1 2 1 1.52957 0.167082 1.5373 0.1667 -0.502831.6 1.71022 0.286378 1.7547 0.2857 -2.534912.4 1.90147 0.0376 1.9803 0.375 -3.980713.2 2.10586 0.444238 2.2115 0.4444 -4.77685

0.25 1 0.8 1 2 2 1.58307 0.01657 1.5851 0.0164 -0.128071.6 1.97133 0.0541908 1.9903 0.0541 -0.953122.4 2.56324 0.100812/1.00914 2.6492 0.1011 -3.244753.2 3.58625 0.150338 3.7952 0.1509 -5.50564

0.25 1 1.6 2 4 2 1.17714 0.0542394 1.181 0.0541 -0.326843.2 1.29784 0.150307 1.3146 0.1509 -1.274914.8 1.43198 0.246469 1.4772 0.2466 -3.06126.4 1.61277 0.330352 1.6602 0.3299 -2.85688

0.25 1 1.6 2 4 4 1.18728 0.000780832 1.1883 0.000715 -0.085843.2 1.3904 0.00770018 1.3885 0.0077 0.1368384.8 1.80713 0.0260174 1.8027 0.0262 0.2457426.4 2.74784 0.0569914 2.8003 0.0565 -1.87337

2.66485 2.8003 -4.83698

0.25 1 4 5 10 7 1.02517 6.75E-05 1.0266 7.30E-05 -0.139298 1.08408 0.00344792 1.0807 0.0034 0.311785

12 1.21386 0.0214821 1.2191 0.0219 -0.4316816 1.54415 0.0628882 1.5664 0.0627 -1.44092

0.25 1 4 5 10 10 1.0256 0 1.0266 0 -0.09758 1.08856 4.87E-05 1.0813 3.82E-05 0.666936

12 1.2578 0.000835854 1.2347 8.10E-04 1.8365416 1.76232 0.00536423 1.777 0.0053 -0.83299

0.25 1 4 5 10 2 1.01592 0.200317 1.0209 0.2 -0.49028 1.02712 0.400597 1.0336 0.4 -0.63089

12 1.03058 0.528957 1.0428 0.5294 -1.1857416 1.03446 0.615481 1.0493 0.6154 -1.43456

4 1 0.25 5 10 2 1.0204 0.203565 1.0329 0.2 -1.225010.5 5 1.02889 0.403606 1.0621 0.4 -3.22775

0.75 5 1.03556 0.529196 1.0851 0.5294 -4.783891 5 1.03889 0.616264 1.1021 0.6154 -6.08438


Achievable Service Level Agreements in

Metro Ethernet Networks


Problem Background

Metro Ethernet Bridge



Access Network 1

Access Network 2

Metropolitan Area Network

Service Level AgreementsBetween Access networks (customers) and

the public Metro networkBandwidth profile--CIR and PIR

SLA enforced using policing (token bucket)

Packet marking: used to distinguish betweenIN-profile and OUT-of-profile or OUT-of-profile but within excess rate

Further on in the network packets might experience congestion in the queues (Queue management techniques)


Achievement of SLAs influenced by 3 essential elements

dropped

PIR CIR

Policingtoken bucket

Marking3 color

Queue ManagementDropping techniques at

queue at time of congestionThreshold based


Metro Ethernet Network(MEN) Simulator

MEN simulator

– Dual token bucket

– Marking: red packets dropped immediately, packets green if conformant to CIR, yellow if not conformant to CIR but conformant to PIR

– Queue manager: Soft hol based dropping

If threshold is exceeded, further incoming yellow packets are dropped

Ns2 TCP stack used to generate TCP traffic


UDP (Poisson) traffic only

Given traffic is Poisson with average arrival rate

Part of this traffic is conformant to CIR (green), part of this not-conformant to CIR but conformant to PIR (yellow)

RESULT: Achieved throughput in proportion to the of each customer.


TCP traffic

With the given constraint

MAIN RESULT:

It is possible that one customer does not get its CIR while another customer gets more than its CIR

Capacity Link Congested

Capacity Link Congested

CustomersTotal

ii

CustomersTotal

ii

CIR

PIR

1

1


TCP traffic example configuration & results

Congested Link capacity =145, no dropping at token bucket

When CIRs and PIRs of all customers are equal RESULTS are as good.

Configured CIR Configured PIR

Achieved

Throughput

Customer 1 20 150 32.49

Customer 2 20 150 33.52

Customer 3 20 150 31.47

Customer 4 20 150 36.55



Congested Link capacity =145, with queuing at hosts, no dropping at token bucket

Configured CIR Configured PIR

Achieved

Throughput

Customer 1 80 150 62.55

Customer 2 20 150 28.15

Customer 3 20 150 26.81

Customer 4 10 150 19.96



Congested Link capacity =145, no queuing at hosts, no dropping at token bucket

Configured

CIR

Configured

PIR

Achieved

Throughput

Customer 1 80 150 36.17

Customer 2 20 150 36.19

Customer 3 20 150 36.25

Customer 4 10 150 36.22


Conclusion

For UDP traffic only SLAs differentiation can be achieved

For TCP traffic it is difficult to achieve SLAs and even assured rate (CIR) might not be guaranteed

Next Steps

– Investigate possible solutions for TCP

– Integrate with TCP+token-bucket study


TCP performance problems with SLA based policing


Problem Background


(over SDH/SONET)


(over SDH/SONET)


(over SDH/SONET)

Access Network 1

Access Network 2

Metropolitan Area Network

Service Level AgreementsBetween Access networks (customers) and the public Metro network

Charac: Bandwidth profile--CIR and/or PIRThe bandwidth profile of the SLA enforced by policing methods like token bucket

TCP performance is considerably hampered with token bucket based enforcement of the SLA.(problem is generic and not specific to Ethernet based networks)


Problem overview Scenario:

• One TCP flow• Token bucket limits rate of sender• Packets are dropped at tokenbucket

if rate is exceeded

With one TCP connection, the throughput is only a fraction of the provisioned rate!

Simulator and initial insight: already developed in a different project

max. PBS tokens in token bucket

1 token = credit for 1 byte

PIR tokens per second

PIR

1 TCP connectionSender Receiver


TCP problem with policing

First step to achieving SLAs: problem exists irrespective of any congestion in the network

In Nobel:

– Work out possible solutions

Documents

Bell Labs Advanced Technologies EMEAAT Proprietary Information © 2004 Lucent Technologies1 Overview contributions for D27 Lucent Netherlands Richa Malhotra