Internet Congestion Control M. Mathis
Research Group Pittsburgh Supercomputing Center
Internet-Draft December 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
Mathis Expires June 12, 2009 [Page 1]
Internet-Draft Rethinking TCP Friendly December 2008
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
Mathis Expires June 12, 2009 [Page 2]
Internet-Draft Rethinking TCP Friendly December 2008
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 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....
Mathis Expires June 12, 2009 [Page 3]
Internet-Draft Rethinking TCP Friendly December 2008
(Future) Section 4.8 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.]]
o Applications that open many connections...
o Non-IETF protocols (typically UDP based) that don't try to be
fair...
o Lockout and other problems with drop tail queues, as documented in
RFC 2309 [1]...
o If the RTTs are very different then window fair becomes
egregiously rate unfair...
o The distinction between instantaneous and average fairness...
[[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)
Mathis Expires June 12, 2009 [Page 4]
Internet-Draft Rethinking TCP Friendly December 2008
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....
Mathis Expires June 12, 2009 [Page 5]
Internet-Draft Rethinking TCP Friendly December 2008
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.
Mathis Expires June 12, 2009 [Page 6]
Internet-Draft Rethinking TCP Friendly December 2008
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.
Author's Address
Matthew Mathis
Pittsburgh Supercomputing Center
Mathis Expires June 12, 2009 [Page 7]
Internet-Draft Rethinking TCP Friendly December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Mathis Expires June 12, 2009 [Page 8]