480 likes | 586 Views
Joint Optimization of Scheduling and Congestion Control in Communication Networks. Matthew Andrews Bell Labs. Congestion control and scheduling. Inj rate x2. S2. Scheduling: Decide which data should be served at each internal queue Congestion control
E N D
Joint Optimization of Scheduling and Congestion Control in Communication Networks Matthew Andrews Bell Labs
Congestion control and scheduling Inj rate x2 S2 • Scheduling: • Decide which data should be served at each internal queue • Congestion control • Decide how much data should be injected into each flow • i.e. choose x1, x2, x3 S1 Inj rate x1 Inj rate x3 S3 t2 t3 t1
Wireline networks Inj rate x2 • In wireline networks, scheduling and congestion control are typically only loosely coupled • Scheduling: • Simple FIFO is often used • No dependence on flow rates • Congestion control • TCP only uses coarse info from scheduler, e.g. RTTs, packet losses • TCP operates without knowledge of exact scheduling algorithm used S2 S1 Inj rate x1 Inj rate x3 S3 t2 t3 t1
Wireless networks • This talk: • Three benefits to a tighter coupling of scheduling and congestion control in wireless networks • Pointer to algorithm that achieves this coupling
Congestion Control • Does it make sense to talk about alternatives to TCP? • In wireless networks… maybe… • 3G networks employ proprietary congestion control over the wireless link • (e.g. www.venturiwireless.com) • Non-TCP based congestion control could be used in a self-contained ad-hoc network
Congestion Control • One well known issue with TCP that I won’t discuss… • In wireless networks, TCP interprets losses due to interference as congestion and backs off too much • Well-studied issue • Well-known solutions • Snoop protocol ( Balakrishnan, Seshan, Amir, Katz) • Loss prevention (FEC, HARQ, DARQ, link-level retransmissions etc.)
Joint Congestion Control + Scheduling • Three benefits of joint congestion control + scheduling in wireless networks • 1. Enables effective buffer sizing. Prevents excessive queue buildups. • 2. Prevents conflicts between rate allocation due to congestion control and rate allocation due to link scheduler • 3. Allows for network utility maximization, even in presence of complex queueing dynamics • (Applies to wireline as well as wireless networks)
1. Buffer sizing • Standard rule for buffer sizing in wireline networks • Buffer size = bandwidth delay product (BDP) • Enables full utilization of link rate • In wireless networks • BDP ill defined due to variable link bandwidth • Buffer sizing difficult • Buffer too small – don’t utilize bandwidth when link rate is high • Buffer too large – excessive delays when link rate is low link rate C(t) end2end prop delay d
1. Buffer sizing example • Two link rates, 1Mbps and 20kbps • 35KB buffer = 1Mbps x 280ms = 20kbps x 14s • Downlink packet latencies for download of CNN homepage 1s 10s 20kbps 1Mbps
1. Buffer sizing • Another example • Chakravorty and Pratt (2002) observed queues >30s in GPRS networks • Leads to unacceptable delays for other flows sharing same buffer • What would be better? • Have large buffers to deal with high bandwidth case • Recognize when link has low bandwidth • Make sure congestion control does not send too much data in this case
2. Scheduling vs congestion control ri (t) rj (t) service rate vector (r1(t),…,rn (t)) t • Opportunistic scheduling • At each time step, pick one user to serve • If user i chosen, serve at rate ri (t) • Ri (t) = ave service rate to user i
2. Scheduling vs congestion control ri (t) rj (t) service rate vector (r1(t),…,rn (t)) t • Proportional Fair wireless scheduling algorithm • At each time step, serve user argmax ri (t) / Ri (t) • Aim is to maximize i log Ri (t)
2. Scheduling vs congestion control • Conflict between scheduling and cong. control!! • Link scheduler tries to do optimal rate allocation among flows • E.g. Prop Fair aims to maximize i log Ri • TCP also tries to do rate allocation among flows • Whenever RTTs are low, TCP increases sending rate to try and get more bandwidth • But TCP can’t get more bandwidth than wireless link scheduler allows • All we get are bigger queues R3 R1 R2 Rates provided by Prop Fair
2. Scheduling vs congestion control • Better solution • Scheduling and congestion control work jointly to find optimal rate allocation
3. Network Utility Maximization • Wireline networks max Ui(xi) subject to . Q i xi cQ • xi = inj rate into path i • cQ = capacity of server Q • Ui(.) = utility function (e.g. log) • Kelly-Maulloo-Tan, Low-Lapsley, Low-Peterson-Wang… • “TCP is a primal dual algorithm for solving this problem” S2 S3 S1 t1 server A server B t2 t3
Example • Kelly, Maulloo, Tan • xi (t) = injection rate into flow i at time t • pQ = price for congestion at router Q
3. Network Utility Maximization • Wireless networks max Ui(xi) subject to . ( …, xi , … ) C • C = system capacity region (convex) • Depends on power assignments, interference etc. • Chiang • Joint power control and congestion control for solving problem
3: Convergence vs oscillations Inj rate x2 Inj rate x3 S2 S3 Inj rate x1 Server B S1 t1 Server A Cong at server A = x1 + x2 t2 t3 • Prior work: • Congestion of server Q = F(injection rates of flows that use Q) • For example, congestion is signaled before queues buildup (e.g. via ECN) • Arrival rate of flow at server = flow injection rate • Allows for convergence results
3: Convergence vs oscillations S2 S1 S3 t2 t3 • A-Slivkins (Infocom 06) • Suppose congestion causes queue buildups • Flow arrival rate at server not necessarily equal to flow injection rate • Do convergence results still hold? t1
t1 t2 t3 3: Sending rates vs arrival rates inji(t) • due to queues that are upstream,in general arrival rates arr1(t), arr2(t), arr3(t)are different from sending rates inj1(t), inj2(t), inj3(t) • Suppose we use the true arrival rates • i.e. cong =arr1(t) + arr2(t) + arr3(t) S1 S2 S3 arri(t) server
3: Convergence vs oscillations • Result: for any TCP-like congestion control mechanism,there exists a network of (wireline) servers and a set of flows such that starting from a certain initial state, system oscillates in a suboptimal state at all times, for each server, the total sending rate of all flows that use this server is less than its capacity
Joint scheduling + cong control xi xj • How should we do joint scheduling and congestion control? • Problem definition • Model queues explicitly • When data served by one server, passes to next server on flow route • Design scheduling + cong control max Ui(xi) subject to . All queues are stable
Joint scheduling + cong control xi xj • Greedy Primal Dual Algorithm (Stolyar) • Simple version • Flow Routes are given • Set of routes to destination d form rooted tree • At most 1 pckt into each flow per time step • Per destination queues • Qv,d = amount of dest d data at node i • nv,d = next hop for Qv,d data • rv,w(t) = data rate between nodes v,w
Joint scheduling + cong control xi xj • Greedy Primal Dual Algorithm (Stolyar) • Scheduling • Node v serves data from queue that maximizes (Qv,d – Qnv,d,d) rv,nv,d(t) • Scheduling • Flow i injects a packet whenever U’(xi(t)) – b.Qibegin < 0 b = small parameter Qibegin = first queue on path of flow i
Joint scheduling + cong control xi xj • Greedy Primal Dual Algorithm (Stolyar) • Solves the utility maximization problem max Ui(xi) subject to . All queues are stable • Works for wireless networks • Joint scheduling and cong control • Collaboration via queues sizes • Do not get excessive queue buildup • Scheduling creates “backpressure”
Conclusions • Three reasons why joint scheduling and congestion control make sense in wireless networks • Sketched one possible method for doing this (Stolyar) • Related work due to Eryilmaz-Srikant and Neely-Modiano-Li
Conclusions • Implementation issues? • Need communication between scheduler and cong control • E.g. in Greedy Primal Dual algorithm, need to exchange queue sizes between neighbors • For wireless networks, need to exchange channel state information for optimal throughput • Could piggyback queue state info on channel state info • Different channel models? • Optimality of Greedy Primal Dual proved for stationary channels • What about adversarial channels?
Backup slides • Oscillating example of A-Slivkins 2006.
?? • no congestion: all queues are empty S S t t • congestion: at least one queue is non-empty Parameterized congestion control • sender detects congestion using feedback from receiver • yes decrease sending rate; noincrease sending rate
start Q1 Q1 Q1 Q2 Q2 Q2 Q3 Q3 Q3 Q4 Q4 Q4 S S S t t t 1 finish 1 The basic gadget: high-level idea capacity 1 <1 <1 1
init rate S’ capacity 1 <1 <1 1 init rate 0 1 t’ The basic gadget: animation Q1 Q2 Q3 Q4 S t
capacity 1 <1 <1 1 Q1 Q2 Q3 Q4 S t The basic gadget: animation init rate S’ rate = 0 t’
capacity 1 <1 <1 1 Q1 Q2 Q3 Q4 S t rate The basic gadget: animation S’ rate = 0 t’
capacity 1 <1 <1 1 Q1 Q2 Q3 Q4 S t The basic gadget: animation rate = 0 S’ rate = 0 1 t’
rate capacity 1 <1 <1 1 Q1 Q2 Q3 Q4 S t The basic gadget: animation S’ rate = 0 t’
before 1 1 2 2 3 3 4 4 • after 1 2 3 1 2 3 4 Connect two gadgets identify Q4 from one gadget with Q1 from another
1 2 3 1 2 3 1 2 3 1 2 3 Row of gadgets S1 t1 fluid eventually reaches its destination, and the process stopsnot too exciting!
1 2 3 1 2 3 1 2 3 1 2 3 Row of gadgets S1 t1 a better process
refill 1 2 3 1 2 3 1 2 3 1 2 3 Row of gadgets and now a refill happens S1 t1 a better process
refill 1 2 3 1 2 3 1 2 3 1 2 3 Row of gadgets ... and so on S1 t1 a better process
S1 t1 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 S2 t2 S3 t3 Rows of gadgets each row is running the same process, shifted in time
refill S1 t1 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 refill S2 t2 refill S3 t3 Rows of gadgets now a refill happens each row is running the same process, shifted in time
refill S1 t1 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 1 1 1 2 2 2 3 3 3 S2 t2 S3 t3 Rows of gadgets ... and so on Wait a sec... how do the refills happen ???
S1 t1 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 S2 t2 S3 t3 S4 t4 Refills and vertical sessions rate >0
S1 t1 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 S2 t2 S3 t3 S4 t4 Refills and vertical sessions rate >0
S1 t1 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 S2 t2 S3 t3 S4 t4 Refills and vertical sessions rate >0
S1 t1 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 S2 t2 S3 t3 rate S4 t4 Refills and vertical sessions
S1 t1 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 1 1 1 1 2 2 2 2 3 3 3 3 S2 t2 S3 t3 S4 t4 Refills and vertical sessions refilled !!! rate = 0