1 / 25

Flow Rate Fairness

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. Resource Sharing in the Internet. The Internet is based on a simple premise:

mahala
Télécharger la présentation

Flow Rate Fairness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related