Flow Rate Fairness

1. Flow Rate Fairness Many slides are borrowed from Bob Briscoe http://www.bobbriscoe.net/projects/refb/ Presented by: Yang Guan March 25, 2010 CISC 856: TCP/IP & Upper Layer Protocols

2. Resource Sharing in the Internet • The Internet is based on a simple premise: • Sharing communication links are more efficient than dedicated channels • The primary sharing algorithm is built into Transmission Control Protocol (TCP) • TCP provides mechanisms to guard people how to share Internet capacity politely

3. How TCP shares the Internet • The protocol allows you to seem to be polite • TCP constantly increases transmission rate if it can • Until it sees some sign of congestion, TCP politely reduces bit rate

4. TCP-Friendliness • TCP is even used as a standard • For applications that do not utilize TCP in transport layer, they are called TCP-friendly if they consume about the same data rate as TCP does.

5. Does TCP make the world perfect? • The answer is of course NO! • Methods to circumvent TCP-friendliness rules: • Running multiple TCP sessions • Running each TCP session for long time • It is really the application software that determines how to share the Internet fairly

6. What does TCP overlook? Fig 1. TCP overlooks users’ activity over time [4]

7. What does TCP overlook? (cont’d) Fig 2. TCP overlooks multiple TCP instances [4]

8. Rethink: What is fair? • Equal flow rate? • It is not about how much a TCP consumes • It is about how much a TCP can affect others

9. Rethink: What is fair? (cont’d) • How to measure the effect on others? • Congestion volume: the amount of data that is sent during network congestion

10. Rethink: What is fair? (cont’d) Fig 3. Different TCP sharing schemes [4]

11. Rethink: What is fair? (cont’d) • Fair is faster: • Light browsing goes blisteringly faster • Heavy downloading is not obviously prolonged

12. Problems with TCP • Congestion is only detected and managed solely by computers at the edge • ISPs cannot set congestion limits • The few ruin the life of the many • Massive capacity is required • But poor incentive to invest in capacity

13. A New TCP Routine • Parameterize TCP with weight • Behave like 12 TCP flows, or • Behave like 0.25 of a TCP flow • The key is • High weights for light interactive usage (web surfing) • Low weights for heavy usage (movie downloads)

14. A New TCP Routine (cont’d) • Whenever congestion happens • Higher weighted TCP goes much faster • Lower weighted TCP expands back to fast rate afterwards

15. A New TCP Routine (cont’d) • On today’s Internet, the balance of weights is the wrong way around • How to persuade people to reasonably choose weights? • We should limit people by the effects they have on others—the incremental cost of their usage • Congestion volume: the volume of data sent during congestion

16. A New TCP Routine (cont’d) • Solution: • ISPs provide a monthly congestion-volume allowance (CVA) • High weights TCPs consumes CVA while low weights ones doesn’t • Heavy usage does not consume CVA since weights are set to be low • Light intensive usage does not consume too much CVA due to short lifetime

17. congestion policer – one example: per-user policer NB NA R1 S1 overdraft non-interactive long flows(e.g. P2P, ftp) congestionvolumeallowance interactive short flows(e.g. Web, IM)

18. 6 3 5 7 9 8 Making Congestion Visible to Network Layer • Why? • Healthy supply of bandwidth • Reroute data around congested links • Costumers draw down the limited allowances if congestion can not be avoided. • Currently, only the router that drops a packet knows the drop

19. First Step: ECN • Explicit Congestion Notification • Standardized into TCP/IP in 2001 • ECN allows end-to-end notification of network congestion without dropping packets[3] • Routers set CE (Congestion Experience) bit when the average queue length exceeds configured threshold levels. • Receivers feedback congestion information back to senders

20. First Step: ECN (cont’d) VER HLEN Service Type Total length Identification Flag Fragmentation offset TTL Protocol Header checksum Source IP address Destination IP address Fig 4. IPv4 header format

21. 5 7 3 2 6 8 4 First Step: ECN (cont’d) feedback 2 3 4 5 6 7 8 9 NB NA R S Fig 5. ECN mechanism [5]

22. Second Step: re-feedback Fig 6. Re-feedback mechanism [4]

23. Conclusion • Ready to be implemented as ECN has been included into TCP/IP • Sticks to the Internet e2e principle • Makes congestion visible to the networks in the middle

24. References [1]Bob Briscoe (BT), Illustrations by QuickHoney, A Fairer, Faster Internet Protocol, IEEE Spectrum, Dec 2008 pp38-43 [2] B. Briscoe. Flow rate fairness: Dismantling a religion. Computer Communications Review, 37(2):63–74, Apr. 2007. [3] Explicit Congestion Notification, http://en.wikipedia.org/wiki/Explicit_Congestion_Notification [4] Bob Briscoe, Internet: Fairer is Faster, BT White Paper [5] Bob Briscoe, et al, Policing congestion response in an internetwork usingre-feedback, Sigcomm 2005

25. Questions • Thanks