< draft-floyd-cong-03.txt   draft-floyd-cong-04.txt >
Internet Engineering Task Force Sally Floyd, Editor Internet Engineering Task Force Sally Floyd, Editor
INTERNET DRAFT ACIRI INTERNET DRAFT ACIRI
draft-floyd-cong-03.txt April 2000 draft-floyd-cong-04.txt June 2000
Expires: October 2000 Expires: December 2000
Congestion Control Principles Congestion Control Principles
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 7, line 23 skipping to change at page 7, line 23
4.3. New developments in the standards process 4.3. New developments in the standards process
The most obvious developments in the IETF that could affect the The most obvious developments in the IETF that could affect the
evolution of congestion control are the development of integrated and evolution of congestion control are the development of integrated and
differentiated services [RFC2212, RFC2475] and of Explicit Congestion differentiated services [RFC2212, RFC2475] and of Explicit Congestion
Notification (ECN) [RFC2481]. However, other less dramatic Notification (ECN) [RFC2481]. However, other less dramatic
developments are likely to affect congestion control as well. developments are likely to affect congestion control as well.
One such effort is that to construct Endpoint Congestion Management One such effort is that to construct Endpoint Congestion Management
[HS99], to enable multiple concurrent flows from a sender to the same [BS00], to enable multiple concurrent flows from a sender to the same
receiver to share congestion control state. By allowing multiple receiver to share congestion control state. By allowing multiple
connections to the same destination to act as one flow in terms of connections to the same destination to act as one flow in terms of
end-to-end congestion control, a Congestion Manager could allow end-to-end congestion control, a Congestion Manager could allow
individual connections slow-starting to take advantage of previous individual connections slow-starting to take advantage of previous
information about the congestion state of the end-to-end path. information about the congestion state of the end-to-end path.
Further, the use of a Congestion Manager could remove the congestion Further, the use of a Congestion Manager could remove the congestion
control dangers of multiple flows being opened between the same control dangers of multiple flows being opened between the same
source/destination pair, and could perhaps be used to allow a browser source/destination pair, and could perhaps be used to allow a browser
to open many simultaneous connections to the same destination. to open many simultaneous connections to the same destination.
skipping to change at page 11, line 38 skipping to change at page 11, line 38
that have been discussed for many years, and by many people. In that have been discussed for many years, and by many people. In
particular, acknowledgement is due to the members of the End-to-End particular, acknowledgement is due to the members of the End-to-End
Research Group, the Reliable Multicast Research Group, and the Research Group, the Reliable Multicast Research Group, and the
Transport Area Directorate. This document has also benefited from Transport Area Directorate. This document has also benefited from
discussion and feedback from the Transport Area Working Group. discussion and feedback from the Transport Area Working Group.
Particular thanks are due to Mark Allman for feedback on an earlier Particular thanks are due to Mark Allman for feedback on an earlier
version of this document. version of this document.
8. References 8. References
[BS99] Hari Balakrishnan and Srinivasan Seshan, The Congestion [BS00] Hari Balakrishnan and Srinivasan Seshan, The Congestion
Manager, draft-balakrishnan-cm-01.txt, internet draft, work in Manager, draft-balakrishnan-cm-02.txt, internet draft, work in
progress, October 1999. progress, March 2000.
[DMKM99] S. Dawkins, G. Montenegro, M. Kojo, and V. Magret, End-to- [DMKM00] S. Dawkins, G. Montenegro, M. Kojo, and V. Magret, End-to-
end Performance Implications of Slow Links, draft-ietf-pilc- end Performance Implications of Slow Links, draft-ietf-pilc-
error-02.txt, internet draft, work in progress, October 1999. slow-03.txt, internet draft, work in progress, March 2000.
[FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End
Congestion Control in the Internet. IEEE/ACM Transactions on Congestion Control in the Internet. IEEE/ACM Transactions on
Networking, August 1999. URL http://www- Networking, August 1999. URL http://www-
nrg.ee.lbl.gov/floyd/end2end-paper.html". nrg.ee.lbl.gov/floyd/end2end-paper.html".
[HPF99] Handley, M., Padhye, J., and Floyd, S., TCP Congestion Window [HPF00] Handley, M., Padhye, J., and Floyd, S., TCP Congestion Window
Validation, draft-handley-tcp-cwv-01.txt, internet draft, work in Validation, draft-handley-tcp-cwv-02.txt, internet draft, work in
progress, December 1999. progress, March 2000.
[HS99] Hari Balakrishnan and Srinivasan Seshan, The Congestion
Manager, draft-balakrishnan-cm-01.txt, internet draft, work in
progress, October 1999.
[Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM [Jacobson88] V. Jacobson, Congestion Avoidance and Control, ACM
SIGCOMM '88, August 1988. SIGCOMM '88, August 1988.
[RFC793] J. Postel, Transmission Control Protocol, RFC 793, September [RFC793] J. Postel, Transmission Control Protocol, RFC 793, September
1981. 1981.
[RFC896] Nagle, J., Congestion Control in IP/TCP, RFC 896, January [RFC896] Nagle, J., Congestion Control in IP/TCP, RFC 896, January
1984. 1984.
skipping to change at page 13, line 19 skipping to change at page 13, line 15
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, April 1999. Control, RFC 2581, April 1999.
[RFC2582] Floyd, S., and Henderson, T., The NewReno Modification to [RFC2582] Floyd, S., and Henderson, T., The NewReno Modification to
TCP's Fast Recovery Algorithm, RFC 2582, April 1999. TCP's Fast Recovery Algorithm, RFC 2582, April 1999.
[RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach, and T. Berners-Lee, Hypertext Transfer Protocol -- P. Leach, and T. Berners-Lee, Hypertext Transfer Protocol --
HTTP/1.1, RFC 2616, June 1999. HTTP/1.1, RFC 2616, June 1999.
[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP
Congestion Control with a Misbehaving Receiver, ACM Computer
Communications Review, October 1999.
[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan [TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan
Seshan, Mark Stemm, and Randy H. Katz, TCP Behavior of a Busy Seshan, Mark Stemm, and Randy H. Katz, TCP Behavior of a Busy
Internet Server: Analysis and Improvements, IEEE Infocom, March 1998. Internet Server: Analysis and Improvements, IEEE Infocom, March 1998.
Available from: Available from:
"http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz". "http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz".
[TCPF98] Dong Lin and H.T. Kung, TCP Fast Recovery Strategies: [TCPF98] Dong Lin and H.T. Kung, TCP Fast Recovery Strategies:
Analysis and Improvements, IEEE Infocom, March 1998. Available from: Analysis and Improvements, IEEE Infocom, March 1998. Available from:
"http://www.eecs.harvard.edu/networking/papers/ infocom-tcp- "http://www.eecs.harvard.edu/networking/papers/ infocom-tcp-
final-198.pdf". final-198.pdf".
skipping to change at page 15, line 37 skipping to change at page 15, line 37
would not be expected to require standardization, would be a proposal would not be expected to require standardization, would be a proposal
to send a "new" or presumed-lost packet in response to a duplicate or to send a "new" or presumed-lost packet in response to a duplicate or
partial acknowledgement, if allowed by the congestion window. An partial acknowledgement, if allowed by the congestion window. An
example of this would be sending a new packet in response to a single example of this would be sending a new packet in response to a single
duplicate acknowledgement, to keep the `ack clock' going in case no duplicate acknowledgement, to keep the `ack clock' going in case no
further acknowledgements would have arrived. Such a proposal is an further acknowledgements would have arrived. Such a proposal is an
example of a beneficial change that does not involve interoperability example of a beneficial change that does not involve interoperability
and does not affect global congestion control, and that therefore and does not affect global congestion control, and that therefore
could be implemented by vendors without requiring the intervention of could be implemented by vendors without requiring the intervention of
the IETF standards process. (This issue has in fact been addressed the IETF standards process. (This issue has in fact been addressed
in [DMKM99], which suggests that "researchers may wish to experiment in [DMKM00], which suggests that "researchers may wish to experiment
with injecting new traffic into the network when duplicate with injecting new traffic into the network when duplicate
acknowledgements are being received, as described in [TCPB98] and acknowledgements are being received, as described in [TCPB98] and
[TCPF98]." [TCPF98]."
9.5. Other aspects of TCP congestion control. 9.5. Other aspects of TCP congestion control.
Other aspects of TCP congestion control that have not been discussed Other aspects of TCP congestion control that have not been discussed
in any of the sections above include TCP's recovery from an idle or in any of the sections above include TCP's recovery from an idle or
application-limited period [HPF99]. application-limited period [HPF00].
10. Security Considerations 10. Security Considerations
This document has been about the risks associated with congestion
control, or with the absence of congestion control. Section 3.2
discusses the potentials for unfairness if competing flows don't use
compatible congestion control mechanisms, and Section 5 considers the
dangers of congestion collapse if flows don't use end-to-end
congestion control.
Because this document does not propose any specific congestion
control mechanisms, it is also not necessary to present specific
security measures associated with congestion control. However, we
would note that there are a range of security considerations
associated with congestion control that should be considered in IETF
documents.
For example, individual congestion control mechanisms should be as
robust as possible to the attempts of individual end-nodes to subvert
end-to-end congestion control [SCWA99]. This is a particular concern
in multicast congestion control, because of the far-reaching
distribution of the traffic and the greater opportunities for
individual receivers to fail to report congestion.
RFC 2309 also discussed the potential dangers to the Internet of
unresponsive flows, that is, flows that don't reduce their sending
rate in the presence of congestion, and describes the need for
mechanisms in the network to deal with flows that are unresponsive to
congestion notification. We would note that there is still a need
for research, engineering, measurement, and deployment in these
areas.
Because the Internet aggregates very large numbers of flows, the risk
to the whole infrastructure of subverting the congestion control of a
few individual flows is limited. Rather, the risk to the
infrastructure would come from the widespread deployment of many end-
nodes subverting end-to-end congestion control.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Sally Floyd Sally Floyd
AT&T Center for Internet Research at ICSI (ACIRI) AT&T Center for Internet Research at ICSI (ACIRI)
Phone: +1 (510) 642-4274 x189 Phone: +1 (510) 642-4274 x189
Email: floyd@aciri.org Email: floyd@aciri.org
URL: http://www.aciri.org/floyd/ URL: http://www.aciri.org/floyd/
This draft was created in April 2000. This draft was created in June 2000.
It expires October 2000. It expires December 2000.
 End of changes. 12 change blocks. 
18 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/