Network teleology Damon Wischik

What is teleology? Teleology (noun). The doctrine or study of ends or final causes, especially as related to the evidences of design or purpose in nature; also transf. such design as exhibited in natural objects or phenomena. –Greek  - from , end

Macroscopic description of TCP Let x be the mean bandwidth of a flow [pkts/sec] Let RTT be the flow’s round-trip time [sec] Let p be the packet loss probability The TCP algorithm increases x at rate 1/RTT 2 [pkts/sec] and reduces x by x/2 for every packet loss average increase in rate = average decrease in rate: 1/RTT 2 = (p x) x/2

Macroscopic description Let x be the mean bandwidth of a flow [pkts/sec] Let RTT be the flow’s round-trip time [sec] Let p be the packet loss probability The TCP algorithm increases x at rate 1/RTT 2 [pkts/sec] and reduces x by x/2 for every packet loss average increase in rate = average decrease in rate: 1/RTT 2 = (p x) x/2 Consider a link with N identical flows Let NC be the capacity of the link [pkts/sec] packet loss ratio = fraction of work that exceeds service rate: p = (Nx-NC) + /Nx = (x-C) + /x

Teleological description Consider several TCP flows sharing a single link Let x r be the mean bandwidth of flow r [pkts/sec] Let y be the total bandwidth of all flows [pkts/sec] Let C be the total available capacity [pkts/sec] TCP and the network act so as to solve maximise  r U(x r ) - P(y,C) over x r  0 where y=  r x r x U(x)U(x) y P(y,C) C

Teleological description little extra valued attached to high- bandwidth flows severe penalty for allocating too little bandwidth x U(x)U(x)

Teleological description x U(x)U(x) flows with large RTT are satisfied with little bandwidth flows with small RTT want more bandwidth

Teleological description y P(y,C) C no penalty unless links are overloaded

Teleological description The network distributes resources as if it’s solving an optimization problem Is this what we want the Internet to optimize? Does it make good use of the network? Can it deliver high bandwidth and good quality? Is it a fair allocation? Can we design a better allocation? x U(x)U(x) y C P(y,C)

Input-queued switches Every timestep, the switch 1.chooses a matching from inputs to outputs, then 2.offers service to those queues involved in the matching. output port 1input port 1 input port 2 queue X 32 matching

The MWM matching algorithm How does the switch decide which matching to use? Let the weight of a matching  be  ·X =  i,j X i j  i j Let the maximum weight be max   ·X The MWM (Maximum Weight Matching) algorithm chooses, at every time step, some matching which achieves the maximum weight.

Simulation trace queue lengths [0-50pkts] time [0-500]

Simulation trace Workload w 1. Sum of queue sizes at input port 1 Workload w. 2 Sum of queue sizes for output port 2

Simulation trace Inferred queue sizes, estimated from input and output workloads

Simulation trace Inferred queue sizes, estimated from input and output workloads Actual simulated queue sizes

Teleological description The switching algorithm distributes the workload among the input queues so as to solve an optimization problem Is this an optimization problem we want to solve? Would a different switching algorithm reduce the buffer overflow probability?

Routing choice in road networks A road network The delay on a road is a function of the flow f Drivers choose the quickest route How will traffic distribute itself? 10f 50+f Total delay 10*3+50+3=83 for all users

Braess’ example An extra road is built. How does the traffic flow change? 10f 50+f Total delay 10*3+50+3=83 for all users 10f 50+f 6f

Braess’ paradox Building an extra road makes delays worse for everyone! 10f 50+f Total delay 10*3+50+3=83 for all users 10f 50+f Total delay 10*4+50+2=10*4+6*2+10*4=92 for all users 6f

Wardrop equilibrium The allocation of flows satisfies an optimization problem The objective function is not the natural one (i.e. minimize average delay) How can we encourage drivers to choose socially optimal routes?

Conclusion A network algorithm is usually specified at the microscopic level (i.e. by code) The code may have an implicit teleology The teleological view can –give insight into the algorithm –suggest tweaks