Rethinking TCP Friendly
draft-mathis-iccrg-unfriendly-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Matt Mathis | ||
| Last updated | 2009-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)