Internet Congestion Control M. Mathis
Research Group Pittsburgh Supercomputing Center
Internet-Draft March 1, 2009
Intended status: Informational
Expires: September 2, 2009
Rethinking TCP Friendly
draft-mathis-iccrg-unfriendly-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 2, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
Mathis Expires September 2, 2009 [Page 1]
Internet-Draft Rethinking TCP Friendly March 2009
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
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.
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.
Mathis Expires September 2, 2009 [Page 2]
Internet-Draft Rethinking TCP Friendly March 2009
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.
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 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/
]]
2. Introduction
The current Internet fairness model is based on separate
Mathis Expires September 2, 2009 [Page 3]
Internet-Draft Rethinking TCP Friendly March 2009
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...
Section 3 describes some of the problems with the current
paradigm....
Section 4 describes some of the problems that need to be overcome to
implement the new paradigm....
Section 5 describes a plausible path forward....
3. Reasons to Change the TCP-friendly paradigm
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
Section 3.1 and Section 3.2 respectively.
3.1. TCP-friendly isn't fair enough
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
Mathis Expires September 2, 2009 [Page 4]
Internet-Draft Rethinking TCP Friendly March 2009
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..]]
3.1.1. Multiple Connections
Applications that open many connections...
3.1.2. Non-standard protocols
Non-IETF protocols (typically UDP based) that don't try to be fair...
3.1.3. Drop-tail queues
Lockout and other problems with drop tail queues, as documented in
RFC 2309 [1]...
3.1.4. Wildy Different Round Trip Times
If the RTTs are very different then window fair becomes egregiously
rate unfair...
3.1.5. Instantaneous and Average Fairness
The distinction between instantaneous and average fairness...
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)
Mathis Expires September 2, 2009 [Page 5]
Internet-Draft Rethinking TCP Friendly March 2009
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 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 Section 4, 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.
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....
Mathis Expires September 2, 2009 [Page 6]
Internet-Draft Rethinking TCP Friendly March 2009
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 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.
Mathis Expires September 2, 2009 [Page 7]
Internet-Draft Rethinking TCP Friendly March 2009
5. A Plausable Path Forward
[[TBD. Don't start yet.]]
6. Security Considerations
Traffic controls in the network can only improve the overall
protection from DDoS.....
7. 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.
Appendix A. Acknowledgments
Thank you everyone...
Author's Address
Matthew Mathis
Pittsburgh Supercomputing Center
300 S. Craig St.
Pittsburgh, PA 15213
Email: mathis@psc.edu
Mathis Expires September 2, 2009 [Page 8]