Internet Congestion ControlM. Mathis
Research GroupPittsburgh Supercomputing Center
Internet-DraftDecember 9, 2008
Intended status: Informational 
Expires: June 12, 2009 


Rethinking TCP Friendly
draft-mathis-iccrg-unfriendly-pre00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 12, 2009.

Abstract

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 beginning with RFC 2001.

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.



1.  Parable

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 isn't working 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 ..... eventually raising the overall efficiency by lifting fear of being unfair to others so that the traffic can be less timid.



1.1.  Instructions to contributors

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 good, the bad and the ugly consequences of changing the TCP-friendly paradigm.

[[Text in double square brackets are notes to authors. Word counts are only advisory. 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.

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.

Additional author information will be posted on a document management page at http://staff.psc.edu/mathis/unfriendly/drafts/



2.  Introduction

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 congestion.....

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...

Section 3 (Reasons to Change the TCP-friendly paradigm) describes some of the problems with the current paradigm....

Section 4 (Difficulties to be Overcome) describes some of the problems that need to be overcome to implement the new paradigm....

(Future) Section 4.8 (A Plausable Path Forward) describes a plausible path forward....



3.  Reasons to Change the TCP-friendly paradigm

Problems with the current Internet fairness model fall into two broad categories....

The first category corresponds to situations where the Internet fails to attain a reasonable definition of fair...

The second category corresponds to problems with the AMID algorithm itself...



3.1.  TCP-friendly isn't fair enough

These are problems that stem from the assumption that fairness can be achieved by sending independent signals to different flows...

[[These are itemized here, but consider making them into separate short subsections.]]

[[Consider pulling additional examples and text from draft-briscoe-tsvwg-relax-fairness-01.txt..]]



3.2.  AIMD is not suitable for the entire Internet

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....



3.2.1.  AIMD requires excessivly small loss rates

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



3.2.2.  Long convergence times

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



3.2.3.  A new standard congestion control?

Note that we might pick a new reference congestion control algorithm to replace AIMD. This would require breaking multiple assumptions in during the transition, but would asymptotically reestablish the second principle. Among other problems this requires reestablishing a new standard one-size-fits-all congestion algorithm. Given the likely unbound debate to come to consensus on such a standard, we take different position, that the transition 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 reference congestion control might not emerge, but merely that it is a not a goal at this time.



3.2.4.  No provider input

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]]



4.  Difficulties to be Overcome

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



4.1.  The Transition

Must avoid new CC into old bottlenecks...



4.2.  Risk of Congestion Collapse

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....



4.3.  Loss of Appropriate Economic Incentives

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...



4.4.  Loss of Implicit Fairness

Even if it the existing models only provide weak fairness, there are many situations where this is extremely 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...



4.5.  Scale Limitations

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....



4.6.  Our Research May be off Base

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.....



4.7.  Many IETF Standards may need to be revised

Roughly a half dozen have definitional language about TCP-Friendly and TCP-Friendly Rate Control.

Roughly 60 RFC contain references to TCP-Friendly.



4.8.  A Plausable Path Forward

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



5.  Security Considerations

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



6. References

[1] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, “Recommendations on Queue Management and Congestion Avoidance in the Internet,” RFC 2309, April 1998 (TXT, HTML, XML).


Author's Address

  Matthew Mathis
  Pittsburgh Supercomputing Center


Full Copyright Statement

Intellectual Property