170 likes | 195 Views
Weighted Proportional Fairness and Differential End-to-End Services. Fairness. in general: every flow should get a fair share of the bottlenecks types of fairness: max-min fairness proportional fairness weighed fairness: a flow of weight 2 is treated like two flows of weight 1.
E N D
Weighted Proportional Fairness and Differential End-to-End Services Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Fairness • in general: every flow should get a fair share of the bottlenecks • types of fairness: • max-min fairness • proportional fairness • weighed fairness: a flow of weight 2 is treated like two flows of weight 1 Philippe Oechslin p.oechslin@cs.ucl.ac.uk
TCP Congestion Control • throughput of TCP is limited by the smaller of maximum window and congestion window • upon loss TCP halves the congestion window (multiplicative decrease) • in absence of losses TCP increases congestion window by 1 packet per RTT (linear increase) Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Work by F. Kelly: • weighted proportional fairness where weight is price per time unit: • maximises the utility perceived by each user • maximises total utility provided by network. http://www.statslab.cam.ac.uk/~frank/rate.html • linear decrease/multiplicative increase leads to proportional fairness Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Our goal and study case: • modify TCP to achieve weighted proportional fairness • e.g. for the UK academic Web cache servers • two solutions: • control TCP receive buffers (prototype) • modify TCP congestion control (simulation results) Philippe Oechslin p.oechslin@cs.ucl.ac.uk
The UK academic cache servers US UK 8 mb/s web traffic cacheserver 34 mb/s non-web traffic Philippe Oechslin p.oechslin@cs.ucl.ac.uk
1 Modifying the receive window • receive window limits maximum throughput Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Results • prototype: cgi-script on the web cache allows users to modify receive buffer size and thus speed/cost of surfing. • limitations: receive buffer limits absolute rate, not proportional • given price ki that a user wants to pay, she should get of total receive buffer • only works if all connections share the same bottleneck Philippe Oechslin p.oechslin@cs.ucl.ac.uk
2 Modifying Congestion Control • MulTCP, behaves like N TCPs in all phases of TCP: • linear increase: N TCPs increase their window by one packet per window, MulTCP increases it by N packets • multiplicative decrease: Uppon loss, one of N TCPs reduces its window by half, MulTCP reduces it by 1/2N Philippe Oechslin p.oechslin@cs.ucl.ac.uk
MulTCP congestion control (cont’d) • slow start: N TCPs all start with one packet, then send two packets per ack • MulTCP can’t start with N packets, too bursty! • MulTCP start with one packet, then sends three packets per ack until same window as N TCPs Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Simulations • The simulated network: Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Results gain in throughput as function of N Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Problem: Billing and Policing • how do we find out how much a user owes to the network or one network to another? • how do we find if a TCP is not more aggressive than it should? • how do we aggregate this information? Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Receive window based • billing can be done as by-product of receive window allocation • hierarchical caches allow for aggregation • policing is not necessary! Philippe Oechslin p.oechslin@cs.ucl.ac.uk
MulTCP Billing • to bill user: need to know amount of data from user and average N during sampling period • network-network: need to know amount of data from network and average N • ask users to periodically declare average N per destination network, measure amount of data Philippe Oechslin p.oechslin@cs.ucl.ac.uk
MulTCP Policing • ask user to explicitly mark packets with N being used: • put N in TOS bits, or • put N in first packet of TCP connection (TCP option) • randomly analyse traffic traces Philippe Oechslin p.oechslin@cs.ucl.ac.uk
Conclusions • weighted proportional fairness: • achieves optimal utility and utilisation • is easy to implement in a distributed end-to-end manner • no modifications needed in routers! • however, billing and policing can not be done in distributed, aggregated manner Philippe Oechslin p.oechslin@cs.ucl.ac.uk