1. Solving bucket-based large flow allocation problems
Paolo Medagliani

2. Outline Introduction to the problem Two algorithms Results
Linear programming-based
Greedy
Results 2

3. French Mathematical and Algorithmic Sciences Lab
Located in Boulogne Billancourt
Started officially October 2014
57 researchers at PhD level + 11 PhDs
Merouane Debbah (scientific director)
Mid and Long Term research
2 departments:
Communication Science
Networking Science
Focus: 4.5G, 5G, SDN, Big Data for telecom
An active lab in a HUGE company (170k employees worldwide, +45% growth this year in Western Europe) 3

4. Our Vision, Projects and Expertise
Solve global and online optimization problems
into next-generation network controllers
Topics
Projects
Routing and Admission control
Rate control, network monitoring
Network virtualization (embedding, placement…)
SDN: Network optimization, Path computation, Monitoring, Learning
Tools and Skills
Optimization theory (combinatorial, stochastic), Online and approximation
algorithms , Game and auction theory, Control theory, Dynamic
Programming, Online algorithms, Machine learning 4

5. Why flow splitting? Flow splitting Use case Main problem
Helps to balance traffic or to accept more traffic
Increase scalability when traffic needs to be processed by middleboxes
Use case
Cloud or carrier provider hosting up to thousands of flow aggregates
Multi-path routing requires a switch to split aggregated flows
Main problem
Find a feasible solution that maximizes the throughput and minimize cost.
The problem is not linear, NP-hard and cannot be approximated to within constant factors unless P=NP. 5

6. MPLS-TE use case Split is considered only at the source S1
f1= 0.5 f1 f1 D
Flow f
Flow f S 3 f2 f2
f2= 0.5 2
Split is considered only at the source S
Simpler to manage
Helps to handle Jitter in the flow aggregate
A flow consists in a set of sub-paths from S to D
Intermediate nodes treat f1 and f2 as two different flows
Split could be uneven and unequal cost (vs. ECMP) 6

7. Extend ECMP by repeating entries
Hash-based splitting
Extend ECMP by repeating entries
Typical size of TCAM memory is 3k entries[1]
[1] K. Kannan, S. Banerjee, “Compact TCAM: Flow entry compaction in TCAM for power aware SDN”, Distributed Computing and Networking, 2013 7

8. Hash-based splitting
The larger the number of buckets the better the flow distribution accurately models a fractional ideal
The distribution of flow volume amongst the paths is constrained by the use of a limited number of TCAM entries
Page 8 8

9. Flow splitting problem
Problem: Find a feasible GLOBAL bucket configuration
Input parameters:
Network topology
Current network state (residual capacity on each link)
Demands to be allocated
Constraints
Max number of buckets at each node (TCAM size)
Max number of paths for each demand
Control: allocation of paths according to bucket structure
Objective: max bandwidth acceptance and cost minimization
SDN Controller s1 t1 s2 t2
Centralized control and management 9

10. MINLP formulation Large constant ratios nb buckets memory
Large constant
ratios
nb buckets
memory
MCF
By setting buv = 1 for all uv 2 E, Nk
p = dk = 1 for all
k 2 K, and giving large enough bucket capacity at each node
(e.g., K is sufficient), we see that the maximum edge-disjoint
paths (EDP) problem reduces to MCFS. For both directed and
undirected graphs, EDP is NP-hard to approximate to within
constant factors
x says if an edge is used (binary)
y tells how much bandwidth is allocated to an edge
z gives the number of buckets used (binary) 10

11. Results on execution time
ILP with CPLEX after linearization
Network with 6 nodes and 8 bidirectional links
K=1 commodity
Without flow splitting -> 0’1’’
With flow splitting -> 0’3’’
K=2 commodities
Without flow splitting -> 1’40’’
With flow splitting -> 24’
I want speed and optimality…
but HOW??
NO SCALABILITY 11

12. Outline Introduction to the problem Two algorithms Results
Linear programming-based
Greedy
Results 12

13. How to solve the flow splitting problem?
2 complementary approaches
A Linear programming-based heuristic
Very close to optimality (based on Column Generation)
Requires a succesive phase of rounding
Can be accelerated by parallelizing some steps of the algorithm
A greedy heuristic
Very fast even for massive number of demands
Based on sequential execution of shortest path algorithm
Can embed the computation of reliable pair of paths respecting given weight constraints 13

14. LP-based algorithm Iterate Scale edge capacities by (1 - α)
Artificially reduce link capacity to reserve space for rounding. Different values of α have to be used.
Solve the relaxed multicommodity flow (i.e., using column generation)
Remove path number and bucket constraints, relax integer variables and solve.
Allocate a proportional fair amount of bucket budget to each demand at each source node
Randomly round up the fractional solution
Reduce the number of paths if above N
Find a feasible configuration which minimizes the error
Iterate if demands can still be allocated
Scale
LP solver
Oracle
Rounding LP
Rounding
Iterate 14

15. CG-based methauristic (1/5)
Original network
Residual capacity d2 d3
demands d1 dK 15

16. CG-based methauristic (2/5)
Scaled network by a factor α
Given c(e) the capacity of a link, c’(e)=c(e)*(1- α)
Solve CG on this network
Scaling network capacity
allows to find feasible paths during
rounding session d2 d3
demands d1 dK 16

17. CG-based methauristic (3/5)
In red, the link occupation after the CG on scaled network d1 p1 p2
Solution for d1 as provided by CG
p1=0.43
p2=0.57 d3 d2
Solution may not be feasible in terms of buckets => ROUNDING d1
Randomly move bw from one path to another
d1, d2 d1 d3 d1 d2 d3
demands d1 dK 17

18. CG-based methauristic (4/5)
ROUNDING carried out on original network d1
Randomly assign buckets to paths computed by LP
Priority to paths with higher bw to be allocated
Residual capacity p1 p2
Solution before rounding for d1 and after rounding
p1=0.4
p2=0.6
Allocated demands
No knowledge of the network => test of all bucket profiles
The feasible configuration with the smallest error compared to LP is applied to the network
New attempt on residual network d4 dK
Residual
demands 18

19. Greedy algorithm Iterate
Allocate a proportional fair bucket budget to each demand at each source node
Divide each flow into chunks knowing the bucket number
Allocate as many chunks as possible on the shortest path between source and destination
Once the path is saturated, update network utilization and compute a new shortest path to allocate residual bandwidth
Repeat previous steps until either the whole demand is allocated or the demand is rejected
Repeat path allocation different chunk sizes in order to find the best bucket configuration in term of routing cost
Iterate if demands can still be allocated
Oracle
Greedy
Best solution
Iterate 19

20. Packing buckets into a path}
32 buckets
100 units flow
Chunk size = 100/32 = 3.125 15 25 60
Bottleneck is 15…
Q) How many chunks can we fit?
15/chunk size=15/(100/32)= 4.8, so we can fit 4 chunks of flow
----> assign 4 buckets 20

21. Packing buckets into a path}
32 buckets
100 units flow
Chunk size = 100/32 = 3.125
15-(4*chunk size)=2.5
25-(4*chunk size)=12.5
60-(4*chunk size)=57.5
Chunk size=3.125 < 2.5…we can’t fit any more chunks in this link, may as well delete it
We need to find other paths to service the remaining
32 – 4 = 28 chunks of flow, i.e., assign the remaining 28 buckets 21

22. Outline Introduction to the problem Two algorithms Results
Linear programming-based
Greedy
Results 22

23. Simulation setup Fat Tree topology with 125 nodes 250 demands
Average node degree of 4
Link capacity in [100M : 1G]
Exponential distribution of edge costs
TCAM Size in {20; 50; 100; 150; 200}
250 demands
Random source destination pairs
Max size in [1G]
Zipf distribution (exponent 0.8)
Matlab implementation 23

24. Accepted thoughput and running time24

25. CDF of bucket distribution
TCAM size: 20 buckets
TCAM size: 200 buckets 25

26. Performance comparison – Scalability
C++ implementation
500 nodes
4900 links
5000 to demands
10% of elephant flows
Due to bottlenecks, performance loss compared to unconstrained LP
Despite worse bw allocation performance, greedy approaches are really fast at computing a solution for large demand sets 26

27. Concluding remarks
MINLP NP-hard even to approximate within any constant factor
Flow splitting is a problem that is very hard (see impossible) to be optimally solved.
Two approaches to solve the flow splitting with buckets problem
LP-based rounding approach which is close to optimality but may be slow for large network instances
Greedy approach which is very fast but inaccurate for large demand sets
There is still room for improvement through algorithm faster LP resolution and parallel computing implementation
Online version of the problem is interesting 27