Assigning rates on bottleneck links

We now consider how scheduling should assign rates in the face of inadmissible traffic.

For now, we will assume that the rate of traffic arriving in VOQs does not depend on the rates assigned to VOQs on the time scale at which scheduling occurs. Of course, the traffic produced by protocols such as TCP, which exist above the scheduling layer, will depend on the rate of traffic actually delivered but we will defer this discussion until section 4.5.1. With inadmissible traffic, we must decide how to divide the limited capacity on one or more bottleneck links. Given that the tenant has no way to express the priority among its flows, how should rates be assigned? Without making assumptions about the behavior of the application or protocols above the scheduling layer, there is no clear way to answer this question. Here we will propose two different ways in which rates could be assigned and in chapter 5 we will explore whether there may be advantages to one approach over the other.

Max-min fair share

The first approach is to assign rates on the link in max-min fair fashion. The simplest way to describe max-min fairness is that all flows not bottlenecked elsewhere in the network receive an equal share on a link. If a flow cannot use its full share on a link, the unused bandwidth will be distributed evenly among those flows that can use more. Under ideal conditions, TCP flows converge to their max-min fair share of bottleneck links and given that many applications use TCP, it is not unreasonable to assume that a tenant will expect max-min fairness among its flows.

Before we can show how to calculate a max-min fair rate assignment, we first show how to divide the capacity of a single link in max-min fair fashion. Because flows may be bottlenecked by the bandwidth they receive on other links, we use the term

“request” to describe the rate that a flow can use on a link.

• Let q_i,j,l denote the requested rate for flow f_i,j on link l.

• Let Q_l be the set of all requested rates on link l.

• Let s_i,j,l be the share given to flow f_i,j on link l.

• Let S_l be the set of all shares assigned on link l.

Since a flow only needs the rate needed to clear its backlog, if it is not bottlenecked elsewhere in the network then we can assume that its request simply matches its backlog, i.e., q_i,j,l = b_i,j.

Max-min rate assignment

Algorithm 1 Assign max-min fair share on link

1: procedure MaxMin(Ql, c_l)

2: S_l ← {} . The set of assigned shares

3: u_l ← c_l . Initialize the unused capacity

4: while Q_l 6= {} do . Terminate when no requests remain

5: q_i,j,l ← min(q_i,j,l ∈ Q_l) . Find the minimum request

6: s_i,j,l ← min(q_i,j,l,_|Q¹

l|u_l)

7: u_l← u_l− s_i,j,l

8: Q_l ← Q_l− {q_i,j,l} . Remove the request from consideration

9: S_l ← S_l∪ {s_i,j,l}

10: return S_l

The procedure that we present above for computing max-min shares on a link is based on one presented in [22]. It guarantees that at every iteration, any flow that remains will receive at least min(q_i,j,l,_|Q¹

l|u_l). That is a flow either receives the rate it requests or it receives an equal share of the the remaining capacity.

We follow the same principle to compute the max-min share assigned for all flows in the network, i.e., the max-min rate assignment. Just as the procedure above assigns to the smallest request first, the algorithm below assigns the rates in order from smallest to largest share. At every iteration, a flow is guaranteed to receive either its requested rate or the minimum share along its path. Note that while this algorithm is our own, we do not claim that it is original.

Algorithm 2 Assign max-min rates

1: procedure MaxMinRates(D = (VD, E_D), B)

2: R ← {}

3: Q ← {q_i,j = b_i,j : b_i,j ∈ B}

4: for all l ∈ E_D do . Initialize the state of all links

5: u_l← c_l

6: Q_l ← {q_i,j,l = b_i,j : f_i,j ∈ F_l}

7: while Q 6= {} do

8: S ← {}

9: for all q_i,j ∈ Q do

10: s_i,j ← min(q_i,j,_|Q¹

l|u_l: l ∈ P_i,j) . Minimum share along the path

11: S ← S ∪ {s_i,j}

12: s_i,j = min(s_i,j ∈ S) . Find the smallest share assigned

13: for all l ∈ Pi,j do . Remove the flow from consideration on links

14: u_l ← u_l− s_i,j

15: Q_l← Q_l− {q_i,j,l}

16: ri,j ← si,j

17: R ← R ∪ {r_i,j}

18: Q ← Q − {q_i,j}

19: return R

Backlog-proportional share

While max-min is desirable in many contexts because it provides fairness among flows, the traffic that we schedule belongs to a single tenant. For this reason it may be sensible to assign rates to flows in proportion to their backlog instead. Conceptually, the process of assigning backlog-proportional rates is similar to that of max-min. At every iteration, any remaining flow fi,j will be receive at least min(qi,j,l,^b_b^i,j

l u_l) where bl

represents the sum of the backlogs of the remaining flows. The procedure we present for computing backlog-proportional shares on a link is slightly different, however.

This procedure first finds those flows whose backlog-proportional share exceeds their request. These flows are added to the set of “unbottlenecked” flows U , and are simply assigned the share they request. The while loop exits when no such flows remain at which point all remaining flows belong to the set L. The set L represents the flows that are “bottlenecked” by the backlog-proportional share they receive at this link.

Since the flows in U cannot use their share of the link, they must be removed from

1: procedure BklgProp(Ql, B_l, c_l)

2: S_l ← {}

3: u_l ← c_l

4: b_l← X

∀bi,j∈B_l

b_i,j . Compute the backlog of all flows on l

5: L ← {} . Locally bottlenecked flows

6: U ← {} . Unbottlenecked flows (bottlenecked upstream)

7: while L 6= F_l− U do

8: L = Fl− U

9: for all f_i,j ∈ L do

10: s_i,j,l ← ^b_b^i,j

l u_l

11: if q_i,j,l < s_i,j,l then

12: si,j,l ← q_i,j,l

13: S_l ← S_l∪ {s_i,j,l}

14: U ← U ∪ {f_i,j}

15: bl← bl− si,j,l

16: u_l ← u_l− s_i,j,l

17: for all f_i,j ∈ L do

18: Sl ← Sl∪ {si,j,l}

consideration before we can determine the final shares that we assign to the flows in L. Note that if we set all backlogs equal to 1, i.e., b_i,j ← 1, ∀b_i,j ∈ B_l then the procedure above will produce the max-min shares on the link since the flows in L always have equal backlogs and therefore an equal share of the remaining capacity.

This observation will come in handy in section 4.3 when we present our distributed algorithm for solving max-min and backlog-proportional rates.

Backlog-proportional rate assignment

The centralized algorithm we present for computing backlog-proportional rates differs slightly from the algorithm used for max-min. At each iteration, the algorithm below finds the link with the smallest ratio of remaining capacity to backlog and assigns rates using the shares that it computes. The intuition behind this choice is that the share computed by the link for any of its remaining flows must be the smallest share along the flow’s path.

Algorithm 3 Assign backlog-proportional rates

1: procedure Backlog-proportional(D = (VD, E_D), B)

2: R ← {}

3: for all l ∈ E_D do . Initialize the state of all links

4: u_l← c_l

5: Ql ← {qi,j,l = bi,j : fi,j ∈ Fl}

6: B_l ← {b_i,j : f_i,j ∈ F_l}

7: bl ← X

∀b_i,j∈B_l

bi,j

8: while E_D 6= {} do

9: l ← l ∈ E_D, where ^u_b^l

l is minimum

10: Sl ← BklgP rop(B) . Link is the bottleneck for all its flows

11: for all s_i,j,l ∈ S_l do

12: r_i,j ← s_i,j,l . Assign rates using the shares it computes

13: R ← R ∪ {ri,j}

14: for all o ∈ P_i,j, o 6= l do . Remove flow from other links on path

15: Q_o ← Q_o− {q_i,j,o}

16: Bo← Bo− {bi,j,o}

17: b_o ← b_o− b_i,j

18: u_o ← u_o− r_i,j

19: ED ← ED− {l} . Remove link from consideration

20: return R

Since a link is removed from consideration after each iteration, the algorithm must terminate after no than |E_D| iterations. To prove the correctness of the algorithm, we claim that at every iteration, the rate assigned to a flow represents the mini-mum of its backlog proportional share on all links. This claim can be proven by contradiction. Suppose that in some iteration link l was chosen but a rate r_i,j was assigned which is greater than the flow’s backlog proportional share on some other link u. That is, s_i,j,l > s_i,j,u, which by their definitions is equivalent to min(qi,j,l,^b_b^i,j

l ul) > min(qi,j,u,^b_b^i,j

uuu). Because the algorithm does not modify the requests once they are initialized, we know qi,j,u = qi,j,l = bi,j and since bi,j is con-stant, we are left with ^u_b^l

l > ^u_b^u

l which contradicts the selection made by the algorithm since l was the link with minimum ratio ^u_b^l

l.

In document Delivering Consistent Network Performance in Multi-tenant Data Centers (Page 82-87)