< draft-mathis-conex-abstract-mech-00.txt   draft-ietf-conex-abstract-mech-00.txt >
Congestion Exposure (ConEx) M. Mathis Congestion Exposure (ConEx) Working M. Mathis
Working Group Google Group Google, Inc
Internet-Draft B. Briscoe Internet-Draft B. Briscoe
Intended status: Informational BT Intended status: Informational BT
Expires: April 22, 2011 October 19, 2010 Expires: September 8, 2011 March 7, 2011
Congestion Exposure (ConEx) Concepts and Abstract Mechanism Congestion Exposure (ConEx) Concepts and Abstract Mechanism
draft-mathis-conex-abstract-mech-00 draft-ietf-conex-abstract-mech-00
Abstract Abstract
This document describes an abstract mechanism by which senders inform This document describes an abstract mechanism by which senders inform
the network about the congestion encountered by packets earlier in the network about the congestion encountered by packets earlier in
the same flow. Today, the network may signal congestion to the the same flow. Today, the network may signal congestion to the
receiver by ECN markings or by dropping packets, and the receiver may receiver by ECN markings or by dropping packets, and the receiver may
pass this information back to the sender in transport-layer feedback. pass this information back to the sender in transport-layer feedback.
The mechanism to be developed by the ConEx WG will enable the sender The mechanism to be developed by the ConEx WG will enable the sender
to also relay this congestion information back into the network in- to also relay this congestion information back into the network in-
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2011. This Internet-Draft will expire on September 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements for the ConEx Signal . . . . . . . . . . . . . . 5 2. Requirements for the ConEx Signal . . . . . . . . . . . . . . 4
3. Representing Congestion Exposure . . . . . . . . . . . . . . . 7 3. Representing Congestion Exposure . . . . . . . . . . . . . . . 6
3.1. Strawman Encoding . . . . . . . . . . . . . . . . . . . . 7 3.1. Strawman Encoding . . . . . . . . . . . . . . . . . . . . 7
3.2. ECN Based Encoding . . . . . . . . . . . . . . . . . . . . 8 3.2. ECN Based Encoding . . . . . . . . . . . . . . . . . . . . 7
3.2.1. ECN Changes . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. ECN Changes . . . . . . . . . . . . . . . . . . . . . 8
3.3. Abstract Encoding . . . . . . . . . . . . . . . . . . . . 9 3.3. Abstract Encoding . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Independent Bits . . . . . . . . . . . . . . . . . . . 9 3.3.1. Independent Bits . . . . . . . . . . . . . . . . . . . 9
3.3.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . 9 3.3.2. Codepoint Encoding . . . . . . . . . . . . . . . . . . 9
4. Congestion Exposure Components . . . . . . . . . . . . . . . . 10 4. Congestion Exposure Components . . . . . . . . . . . . . . . . 9
4.1. Modified Senders . . . . . . . . . . . . . . . . . . . . . 10 4.1. Modified Senders . . . . . . . . . . . . . . . . . . . . . 9
4.2. Receivers (Optionally Modified) . . . . . . . . . . . . . 10 4.2. Receivers (Optionally Modified) . . . . . . . . . . . . . 10
4.3. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Policy Devices . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Congestion Policers . . . . . . . . . . . . . . . . . 12 4.4.1. Congestion Policers . . . . . . . . . . . . . . . . . 11
4.4.2. Other Policy Devices . . . . . . . . . . . . . . . . . 12 4.4.2. Other Policy Devices . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
One of the required functions of a transport protocol is controlling One of the required functions of a transport protocol is controlling
congestion in the network. There are three techniques in use today congestion in the network. There are three techniques in use today
for the network to signal congestion to a transport: for the network to signal congestion to a transport:
o The most common congestion signal is packet loss. When congested, o The most common congestion signal is packet loss. When congested,
the network simply discards some packets either as part of an the network simply discards some packets either as part of an
explicit control function [RFC2309] or as the consequence of a explicit control function [RFC2309] or as the consequence of a
queue overflow or other resource starvation. The transport queue overflow or other resource starvation. The transport
receiver detects that some data is missing and signals such receiver detects that some data is missing and signals such
through transport acknowledgments to the transport sender (e.g. through transport acknowledgments to the transport sender (e.g.
TCP SACK options). The sender performs the appropriate congestion TCP SACK options). The sender performs the appropriate congestion
control rate reduction (e.g. [RFC5681] for TCP) and, if it is a control rate reduction (e.g. [RFC5681] for TCP) and, if it is a
reliable transport, it retransmits the missing data. reliable transport, it retransmits the missing data.
o If the transport supports explicit congestion notification (ECN) o If the transport supports explicit congestion notification (ECN)
[RFC3168] or pre-congestion notification (PCN) [RFC5670] , the [RFC3168] or pre-congestion notification (PCN) [RFC5670] , the
transport sender indicates this by setting an ECN-capable transport sender indicates this by setting an ECN-capable
transport (ECT) codepoint in every packet. Network devices can transport (ECT) codepoint in every packet. Network devices can
then explicitly signal congestion to the receiver by setting ECN then explicitly signal congestion to the receiver by setting ECN
bits in the IP header of such packets. The transport receiver bits in the IP header of such packets. The transport receiver
communicates these ECN signals back to the sender, which then communicates these ECN signals back to the sender, which then
performs the appropriate congestion control rate reduction. performs the appropriate congestion control rate reduction.
o Some experimental transport protocols and TCP variants [Vegas] o Some experimental transport protocols and TCP variants [Vegas]
sense queuing delays in the network and reduce their rate before sense queuing delays in the network and reduce their rate before
the network has to signal congestion using loss or ECN. A purely the network has to signal congestion using loss or ECN. A purely
delay-sensing transport will tend to be pushed out by other delay-sensing transport will tend to be pushed out by other
competing transports that do not back off until they have driven competing transports that do not back off until they have driven
the queue into loss. Therefore, modern delay-sensing algorithms the queue into loss. Therefore, modern delay-sensing algorithms
use delay in some combination with loss to signal congestion (e.g. use delay in some combination with loss to signal congestion (e.g.
LEDBAT [I-D.ietf-ledbat-congestion], Compound LEDBAT [I-D.ietf-ledbat-congestion], Compound
[I-D.sridharan-tcpm-ctcp]). In the rest of this document, we will [I-D.sridharan-tcpm-ctcp]). In the rest of this document, we will
confine the discussion to concrete signals of congestion such as confine the discussion to concrete signals of congestion such as
skipping to change at page 14, line 9 skipping to change at page 13, line 24
ECN: A Framework for adding ECN: A Framework for adding
Congestion Accountability to Congestion Accountability to
TCP/IP", draft-briscoe-tsvwg-re- TCP/IP", draft-briscoe-tsvwg-re-
ecn-tcp-motivation-01 (work in ecn-tcp-motivation-01 (work in
progress), September 2009. progress), September 2009.
[I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., Jacquet, A., [I-D.briscoe-tsvwg-re-ecn-tcp] Briscoe, B., Jacquet, A.,
Moncaster, T., and A. Smith, "Re- Moncaster, T., and A. Smith, "Re-
ECN: Adding Accountability for ECN: Adding Accountability for
Causing Congestion to TCP/IP", Causing Congestion to TCP/IP",
draft-briscoe-tsvwg-re-ecn-tcp-08 draft-briscoe-tsvwg-re-ecn-tcp-09
(work in progress), September 2009. (work in progress), October 2010.
[I-D.conex-concepts-uses] Briscoe, B., Woundy, R., Moncaster, [I-D.conex-concepts-uses] Briscoe, B., Woundy, R., Moncaster,
T., and J. Leslie, "ConEx Concepts T., and J. Leslie, "ConEx Concepts
and Use Cases", draft-moncaster- and Use Cases", draft-moncaster-
conex-concepts-uses-01 (work in conex-concepts-uses-01 (work in
progress), July 2010. progress), July 2010.
[I-D.ietf-ledbat-congestion] Shalunov, S. and G. Hazel, "Low [I-D.ietf-ledbat-congestion] Shalunov, S., Hazel, G., and J.
Extra Delay Background Transport Iyengar, "Low Extra Delay
(LEDBAT)", Background Transport (LEDBAT)",
draft-ietf-ledbat-congestion-02 draft-ietf-ledbat-congestion-03
(work in progress), July 2010. (work in progress), October 2010.
[I-D.sridharan-tcpm-ctcp] Sridharan, M., Tan, K., Bansal, D., [I-D.sridharan-tcpm-ctcp] Sridharan, M., Tan, K., Bansal, D.,
and D. Thaler, "Compound TCP: A New and D. Thaler, "Compound TCP: A New
TCP Congestion Control for High- TCP Congestion Control for High-
Speed and Long Distance Networks", Speed and Long Distance Networks",
draft-sridharan-tcpm-ctcp-02 (work draft-sridharan-tcpm-ctcp-02 (work
in progress), November 2008. in progress), November 2008.
[RFC0791] Postel, J., "Internet Protocol", [RFC0791] Postel, J., "Internet Protocol",
STD 5, RFC 791, September 1981. STD 5, RFC 791, September 1981.
skipping to change at page 14, line 51 skipping to change at page 14, line 17
Management and Congestion Avoidance Management and Congestion Avoidance
in the Internet", RFC 2309, in the Internet", RFC 2309,
April 1998. April 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. [RFC3168] Ramakrishnan, K., Floyd, S., and D.
Black, "The Addition of Explicit Black, "The Addition of Explicit
Congestion Notification (ECN) to Congestion Notification (ECN) to
IP", RFC 3168, September 2001. IP", RFC 3168, September 2001.
[RFC3514] Bellovin, S., "The Security Flag in [RFC3514] Bellovin, S., "The Security Flag in
the IPv4 Header", RFC 3514, the IPv4 Header", RFC 3514, April 1
April 2003. 2003.
[RFC3540] Spring, N., Wetherall, D., and D. [RFC3540] Spring, N., Wetherall, D., and D.
Ely, "Robust Explicit Congestion Ely, "Robust Explicit Congestion
Notification (ECN) Signaling with Notification (ECN) Signaling with
Nonces", RFC 3540, June 2003. Nonces", RFC 3540, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., [RFC3550] Schulzrinne, H., Casner, S.,
Frederick, R., and V. Jacobson, Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for "RTP: A Transport Protocol for
Real-Time Applications", STD 64, Real-Time Applications", STD 64,
skipping to change at page 16, line 8 skipping to change at page 15, line 21
Avoidance on a Global Internet", Avoidance on a Global Internet",
IEEE Journal on Selected Areas in IEEE Journal on Selected Areas in
Communications 13(8)1465--80, Communications 13(8)1465--80,
October 1995, <http:// October 1995, <http://
ieeexplore.ieee.org/iel1/49/9740/ ieeexplore.ieee.org/iel1/49/9740/
00464716.pdf?arnumber=464716>. 00464716.pdf?arnumber=464716>.
Authors' Addresses Authors' Addresses
Matt Mathis Matt Mathis
Google Google, Inc
1600 Amphitheater Parkway
Mountain View, California 93117
USA
Phone:
Fax:
EMail: mattmathis at google.com EMail: mattmathis at google.com
URI:
Bob Briscoe Bob Briscoe
BT BT
B54/77, Adastral Park B54/77, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
Phone: +44 1473 645196 Phone: +44 1473 645196
EMail: bob.briscoe@bt.com EMail: bob.briscoe@bt.com
 End of changes. 20 change blocks. 
36 lines changed or deleted 33 lines changed or added

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