]> Pittsburgh Supercomputing Center

300 S. Craig St. PittsburghPA15213 mathis@psc.edu

Internet Congestion Control Research Group The current Internet fairness paradigm mandates that all protocols have equivalent response to packet loss, such that relatively simple network devices can attain a weak form of fairness by sending uniform signals to all flows. This "TCP-friendly" paradigm has been the policy of the IETF for nearly two decades. Although it was only an informal policy in the beginning, it progressively became more formal following the publication of RFC 2001 in 1997. However we observe two trends that differ from this policy: an increasing number of environments where applications and other circumstances create situations that are "unfair", and ISPs that are responding to these situation by imposing traffic control in the network itself. This note explores the question of whether TCP-friendly paradigm is still appropriate for the huge breadth of technology and scale encompassed by today's global Internet. It considers the merits and difficulties of changing IETF policy to embrace these changes by progressively moving the responsibility for capacity allocation from the end-system to the network. Ultimately this policy change might eliminate or redefine the requirement that all protocols be "TCP-Friendly". This note is intended foster discussion in the community and eventually become input to the IESG and IAB, where it might evolve into a future architecture statement.

We have built a global village, with no explicit traffic control, no stop lights or stop signs, only implicit yield signs at every intersection. This works, because for the most part we have carefully trained the traffic to have a calibrated sense of fairness, and to take turns at all bottlenecks. This approach was optimal when the Internet was a club of friends, who believed in serving the common good. Now that the Internet has become truly global, encompassing all of the best and worst of mankind, it is not too surprising that we are finding that we need traffic control. Furthermore, there are more and more situations where the "one-size-fits-all" approach to congestion control doesn't work well enough. In some parts of the world the infrastructure is under utilized because the prescribed fairness makes the traffic too timid to effectively fill the available capacity, either due to adverse conditions along the path or due to the scale of the available capacity. In addition, in some contexts the users or applications are simply being greedy, without regard to their impact on others. If we embrace traffic controls, then we can permit traffic to be less timid, which will eventually raise overall network utilization and efficiency.

Everyone is welcome to contribute! Be especially careful to note any issues that I may have overlooked. Our goal is to be complete as possible, covering the potential good, bad and ugly consequences of changing the TCP-friendly paradigm. Please use the ICCRG list for discussion: iccrg@cs.ucl.ac.uk. If you have simple document additions or fixes you can send them directly to me at mathis@psc.edu. Word counts are only advisory (none yet). An RFC page is about 400 words. Ellipsis (...) indicate text still needing to be written. Generally a sentience fragment ending with ellipsis is likely to become a full paragraph, if not more. Text in double square brackets, such as this entire section, are notes to authors and will be removed prior to being submitted for RFC publication. Additional author information and document revision history will be posted on a document management page at http://staff.psc.edu/mathis/unfriendly/drafts/ ]]

The current Internet fairness model is based on separate principles..... First, that bottlenecks can send "independent signals" (drops or marks) to all flows.... Second, that all protocols and application have "uniform response" to these ..... Third, that the congestion response has to be "AIMD like"..... This paradigm approximates "window fairness" [CJ89 - Chiu and Jain, Analysis of AIMD for Congestion Control...] Our position is that we should consider explicitly inverting the first principle: require that the network be able to isolate flows and send different congestion signals to each, according to some explicit capacity allocation mechanism. As the network progressively takes on more responsibility for capacity allocation, we can progressively relax both of the other assumptions.... which can solve a number of other long standing problems... describes some of the problems with the current paradigm.... describes some of the problems that need to be overcome to implement the new paradigm.... describes a plausible path forward....

The motivation to change the Internet fairness model comes from a number problems with the current model. They fall into two broad categories: situations where the Internet fails to attain a reasonable definition of fair, and scaling problems associated with the AIMD algorithm itself. These are discussed seperatly in sections and respectively.

The current Internet fairness model is based on the assumption that fairness can be achieved by sending independent signals to different flows. This assumption fails in a number of very common situations in todays internet. Part of the difficulty is that "fairness" itself is sometimes subjective in the sense that what is fair from one point of view may be quite unfair from other points of view. However, in many situations the Internet fairness model fails to attain fairness by any definition of fairness. [[Consider pulling additional examples and text from draft-briscoe-tsvwg-relax-fairness-01.txt..]]

Applications that open many connections...

Non-IETF protocols (typically UDP based) that don't try to be fair...

Lockout and other problems with drop tail queues, as documented in RFC 2309...

If the RTTs are very different then window fair becomes egregiously rate unfair...

The distinction between instantaneous and average fairness...

The current TCP-friendly model assumes that the AIMD algorithm is suitable for all parts of the Internet..... AMID performance goes as 1/sqrt(p) [[Review math, including E(loss), E(period)]]..... These are problems that follow from AIMD....

Wireless and LFNs requires excessively small loss....... (cite work)

LFNs require extremely long convergence time...... (Mention S. Low scalability work)

Note that we might pick a new reference congestion control algorithm to replace AIMD. This would require breaking all three fairness principles during a transition, but would asymptotically reestablish the second principle that protocols have uniform response to congestion signals. Such an approach would mitigate a number of the problems discussed int , however it requires reestablishing a new standard one-size-fits-all congestion algorithm. Given the likely extended debate to come to consensus on such a standard and the very long deployment cycle, we take the position that the transition itself should be viewed as the long term steady state, with diverse congestion control algorithms co-existing in the operational Internet. This in not to say that a new, better standard congestion control might not emerge in the future, but it is a not a goal at this time.

Providers want to be able to make business policy re-traffic.... Are moving away from "independent signals" anyhow... We are not proposing to break net neutrality... [[This entire section may belong elsewhere]]

Reasons not to change and/or problems we must solve first....

Must avoid new CC into old bottlenecks...

TCP-friendly was used as a proxy for preventing congestion collapse. We need new methods for assuring that protocols are not subject to congestion collapse....

Current TCP provides window fair.... Current network based techniques are likely enforce rate fair.... ...causes loss of incentive for traffic locality.... No incentive for CDN and other techniques for content providers to move data closer to clients ... No incentives for clients to choose close data.... No incentives for ALTO...

Even if it the existing models only provide weak fairness, there are many situations where this is important... In particular the independent congestion signal assumption does not depend on flow classification. The new paradigm requires explicit flow classification. If the flow granularity is too large (more than one concurrent micro-flow), then we would like to have implicit fairness within the large flow. This requires uniform congestion response within the larger flow, but does not require that the individual micro-flows have AIMD like response...

We do not know if the Internet core will be protected well enough from congestion.... It has been observed that congestion at the edges tends to protect the core... AFD works at very large scale, but is it large enough....

Much CC research has been influenced by one of more of the assumptions underlying TCP-Friendly. If we abandon TCP-Friendly, then some large portion of past research may no longer be relevant.....

Roughly a half dozen have definitional language about TCP-Friendly and TCP-Friendly Rate Control. Roughly 60 RFC contain references to TCP-Friendly.

[[TBD. Don't start yet.]]

Traffic controls in the network can only improve the overall protection from DDoS.....

&rfc2309;

Thank you everyone...