Internet DRAFT - draft-kuehlewind-tcpm-accurate-ecn-option
draft-kuehlewind-tcpm-accurate-ecn-option
tcpm M. Kuehlewind, Ed.
Internet-Draft University of Stuttgart
Intended status: Experimental R. Scheffenegger
Expires: January 14, 2013 NetApp, Inc.
July 13, 2012
Accurate ECN Feedback Option in TCP
draft-kuehlewind-tcpm-accurate-ecn-option-01
Abstract
This document specifies an TCP option to get accurate Explicit
Congestion Notification (ECN) feedback from the receiver. ECN is an
IP/TCP mechanism where network nodes can mark IP packets instead of
dropping them to indicate congestion to the end-points. An ECN-
capable receiver will feedback this information to the sender. ECN
is specified for TCP in such a way that only one feedback signal can
be transmitted per Round-Trip Time (RTT). Recently new TCP
mechanisms like ConEx or DCTCP need more accurate feedback
information in the case where more than one marking is received in
one RTT. This TCP extension can be used in addition to the classic
ECN as well as with a more accurate ECN scheme recently proposed
which reuses the ECN bit in the TCP header.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 14, 2013.
Copyright Notice
Copyright (c) 2012 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
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 1]
Internet-Draft Accurate ECN Feedback Option in TCP July 2012
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview ECN and ECN Nonce in IP . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Negotiation of Accurate ECN feedback . . . . . . . . . . . . . 4
3. Accurate ECN (AccECN) feedback Option Specification . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 2]
Internet-Draft Accurate ECN Feedback Option in TCP July 2012
1. Introduction
Explicit Congestion Notification (ECN) [RFC3168] is an IP/TCP
mechanism where network nodes can mark IP packets instead of dropping
them to indicate congestion to the end-points. An ECN-capable
receiver will feedback this information to the sender. ECN is
specified for TCP in such a way that only one feedback signal can be
transmitted per Round-Trip Time (RTT). Recently proposed mechanisms
like Congestion Exposure (ConEx) or DCTCP [Ali10] need more accurate
feedback information in case when more than one marking is received
in one RTT.
This documents specifies an TCP option to provide more than one ECN
feedback signal per RTT. This modification does not obsolete
[RFC3168]. This TCP extension can be used in addition to the classic
ECN as well as in addition to more accurate ECN scheme recently
proposed which reuses the ECN bits in the TCP header for the same
purpose than this extension --- more accurate ECN feedback (see
[I-D.kuehlewind-conex-accurate-ecn]). Note that a new TCP extension
can experience deployment problems by middleboxes dropping unknown
options. Thus the ECN feedback in the TCP header is still needed to
ensure ECN feedback. Moreover, this option will increase the header
length for all kind of TCP packets which can cause additional load in
case of severe congestion (on the feedback channel).
1.1. Overview ECN and ECN Nonce in IP
ECN requires two bits in the IP header. The ECN capability of a
packet is indicated, when either one of the two bits is set. An ECN
sender can set one or the other bit to indicate an ECN-capable
transport (ETC) which results in two signals --- ECT(0) and
respectively ECT(1). A network node can set both bits simultaneously
when it experiences congestion. When both bits are set the packets
is regarded as "Congestion Experienced" (CE).
ECN-Nonce [RFC3540] is an optional addition to ECN that is used to
protects the TCP sender against accidental or malicious concealment
of marked or dropped packets. With ECN-Nonce a nonce sum is maintain
that counts the occurrence of ECT(1) packets.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
We use the following terminology from [RFC3168] and [RFC3540]:
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 3]
Internet-Draft Accurate ECN Feedback Option in TCP July 2012
The ECN field in the IP header:
CE: the Congestion Experienced codepoint; and
ECT(0)/ECT(1): either one of the two ECN-Capable Transport
codepoints.
In this document, we will call the ECN feedback scheme as specified
in [RFC3168] the 'classic ECN'. A 'congestion mark' is defined as an
IP packet where the CE codepoint is set.
2. Negotiation of Accurate ECN feedback
As there is only limited space in the TCP Options, particularly
during the initial three-way handshake, an abbreviated Option is used
to negotiate for Accurate ECN feedback. This option also initiates
all counters to an initial value of zero at the receiving side.
TCP Accurate ECN Option Negotiation:
Kind: TBD
Length: 2 bytes
+------+-----+
| Kind | 2 |
+------+-----+
1 1
Figure 1: Accurate ECN feedback TCP option negotiation
This abbreviated option is only valid in a <SYN> or <SYN,ACK>
segment, during a three way handshake. The negotiation follows the
same procedure as with other TCP options, i.e. SACK. A TCP sender
MAY send the accurate ECN feedback negotiation option in an initial
SYN segment and MAY send a more accurate ECN option (see Section 3)
in other segments only if it received this option negotiation in the
initial <SYN> segment or <SYN,ACK> for the connection. A TCP
receiver MAY send an <SYN,ACK> segment with the accurate ECN feedback
negotiation option in response to a received accurate ECN feedback
negotiation option in the <SYN>. If both ends indicate that they
support Accurate ECN (AccECN) feedback, the AccECN option SHOULD be
used in any subsequent TCP segment. A TCP sender or receiver MUST
only negotiate for the AccECN option if ECN is negotiated as well.
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 4]
Internet-Draft Accurate ECN Feedback Option in TCP July 2012
3. Accurate ECN (AccECN) feedback Option Specification
A TCP receiver, that provides Accurate ECN feedback, will maintain a
counter for the number of ECT(0), ECT(1), CE, non-ECT marked and lost
packets as well as the cumulative number of bytes of CE marked
packets. The TCP option to provide the Accurate ECN (AccECN)
feedback to the sender will echo these counters.
TCP Accurate ECN Option:
Kind: TBD (same as above)
Length: 12 bytes
+------+------+---------+---------+-------+-------+-------+-----------+
| Kind | 12 | ECT(0) | ECT(1) | CE |non-ECT| loss |CE in bytes|
+------+------+---------+---------+-------+-------+-------+-----------+
1 1 2 2 1 1 1 3
Figure 2: Accurate ECN feedback TCP option
TCP anyway provides a mechanism to detect loss as loss should always
be assumes as a strong signal for congestion and TCP congestion
control reacts on loss. If TCP SACK is not available, the exact
number of losses is not known. Moreover, the TCP loss detection
(incl. SACK) is done in bytes and not in number of packets. The
number of lost packets can be used by the sender to calculate the ECN
Nonce sum more exactly.
The same feedback information are proposed for the (ECN) feedback in
RTP (see [I-D.ietf-avtcore-ecn-for-rtp].
As TCP is a bi-directional protocol, this option can be used in both
directions. With the reception of every data segment at least one of
the counters changes (ETC(0) or ETC(1)). The AccECN option SHOULD be
included in every ACK to ensure the reception of the ECN feedback at
the sender in case of ACK loss. To reduce network load the AccECN
option MAY not be send in every ACK, e.g. only in very second ACK (if
ACKs are sent very frequently).
In general it is possible that any of the counters wraps around. In
this case the information might get corrupted if e.g. for any reason
only one ACK per RTT is sent and more than 256 CE marks occur in one
RTT. For this case it MUST be ensured, that at least three ACKs/
segments with the AccECN option have been sent prior to the counter
experiencing an wrap around. Whenever an AccECN Option is received
with smaller counter value than in the previous one and the
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 5]
Internet-Draft Accurate ECN Feedback Option in TCP July 2012
respective ACK acknowledges new data, a wrap around MUST be assumed.
4. Acknowledgements
5. IANA Considerations
TBD
6. Security Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
7.2. Informative References
[Ali10] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel,
P., Prabhakar, B., Sengupta, S., and M. Sridharan, "DCTCP:
Efficient Packet Transport for the Commoditized Data
Center", Jan 2010.
[I-D.briscoe-tsvwg-re-ecn-tcp]
Briscoe, B., Jacquet, A., Moncaster, T., and A. Smith,
"Re-ECN: Adding Accountability for Causing Congestion to
TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-09 (work in
progress), October 2010.
[I-D.ietf-avtcore-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 6]
Internet-Draft Accurate ECN Feedback Option in TCP July 2012
in progress), May 2012.
[I-D.kuehlewind-conex-accurate-ecn]
Kuehlewind, M. and R. Scheffenegger, "Accurate ECN
Feedback in TCP", draft-kuehlewind-conex-accurate-ecn-01
(work in progress), October 2011.
Authors' Addresses
Mirja Kuehlewind (editor)
University of Stuttgart
Pfaffenwaldring 47
Stuttgart 70569
Germany
Email: mirja.kuehlewind@ikr.uni-stuttgart.de
Richard Scheffenegger
NetApp, Inc.
Am Euro Platz 2
Vienna, 1120
Austria
Phone: +43 1 3676811 3146
Email: rs@netapp.com
Kuehlewind & Scheffenegger Expires January 14, 2013 [Page 7]
