One document matched: draft-kuehlewind-tcpm-accurate-ecn-option-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3540.xml">
<!ENTITY RFC5562 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5562.xml">
<!ENTITY RFC5681 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC5690 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5690.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-kuehlewind-tcpm-accurate-ecn-option-01" ipr="trust200902">
<!-- updates="3186" -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>Accurate ECN Feedback Option in TCP</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Mirja Kühlewind" initials="M." role="editor"
surname="Kühlewind">
<organization>University of Stuttgart</organization>
<address>
<postal>
<street>Pfaffenwaldring 47</street>
<code>70569</code>
<city>Stuttgart</city>
<country>Germany</country>
</postal>
<email>mirja.kuehlewind@ikr.uni-stuttgart.de</email>
</address>
</author>
<author fullname="Richard Scheffenegger" initials="R."
surname="Scheffenegger">
<organization>NetApp, Inc.</organization>
<address>
<postal>
<street>Am Euro Platz 2</street>
<code>1120</code>
<city>Vienna</city>
<region></region>
<country>Austria</country>
</postal>
<phone>+43 1 3676811 3146</phone>
<email>rs@netapp.com</email>
</address>
</author>
<date year="2012" />
<area>Transport</area>
<workgroup>tcpm</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Explicit Congestion Notification (ECN) <xref target="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
<xref target="Ali10"/> need more accurate feedback information
in case when more than one marking is received in one RTT.
</t>
<t>This documents specifies an TCP option to provide more than one ECN feedback signal per RTT.
This modification does not obsolete <xref target="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 <xref target="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).
</t>
<section title="Overview ECN and ECN Nonce in IP">
<t>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).
</t>
<t>
ECN-Nonce <xref target="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.
</t>
</section>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>We use the following terminology from <xref target="RFC3168"/> and <xref target="RFC3540"/>:</t>
<t>The ECN field in the IP header:
<list hangIndent="10" style="empty">
<t>CE: the Congestion Experienced codepoint; and</t>
<t>ECT(0)/ECT(1): either one of the two ECN-Capable Transport codepoints.</t>
</list></t>
<t> In this document, we will call the ECN feedback scheme as specified
in <xref target="RFC3168"/> the 'classic ECN'.
A 'congestion mark' is defined as an IP packet where the CE codepoint is set.
</t>
</section>
</section>
<section title="Negotiation of Accurate ECN feedback" anchor="TCPSYN">
<t>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.</t>
<t>
<figure anchor="TCP_syn" align="center" title="Accurate ECN feedback TCP option negotiation">
<artwork align="left"><![CDATA[
TCP Accurate ECN Option Negotiation:
Kind: TBD
Length: 2 bytes
+------+-----+
| Kind | 2 |
+------+-----+
1 1
]]></artwork>
</figure>
</t>
<t>
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 <xref target="Option"/>) 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.
</t>
</section>
<section title="Accurate ECN (AccECN) feedback Option Specification" anchor="Option">
<t> 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.
<figure anchor="TCPOpt" align="center" title="Accurate ECN feedback TCP option">
<artwork align="left"><![CDATA[
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
]]></artwork>
</figure>
</t>
<t>
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.
</t>
<t>
The same feedback information are proposed for the (ECN) feedback in RTP
(see <xref target="I-D.ietf-avtcore-ecn-for-rtp"/>.
</t>
<t>
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). <!--Still whenever the CE counter changes the AccECN Option MUST be send in the next ACK.-->
</t>
<t>
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 respective ACK acknowledges new data, a wrap around MUST be assumed.
</t>
</section>
<section title="Acknowledgements">
<t>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD</t>
<!--<t> If this memo was to progress to standards track, it would update RFC3168
and RFC3540, to add new combinations of flags in the TCP header for capability
negotiation (see <xref target="TCPNeg"/>) and a change in TCP ECN semantics
(see <xref target="TCPSig"/>).</t>-->
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3168;
&RFC3540;
</references>
<references title="Informative References">
<?rfc include="reference.I-D.briscoe-tsvwg-re-ecn-tcp.xml"?>
<?rfc include="reference.I-D.ietf-avtcore-ecn-for-rtp"?>
<?rfc include="reference.I-D.kuehlewind-conex-accurate-ecn.xml"?>
<reference anchor="Ali10">
<front>
<title>DCTCP: Efficient Packet Transport for the Commoditized Data Center</title>
<author initials="M" surname="Alizadeh">
<organization></organization></author>
<author initials="A" surname="Greenberg">
<organization></organization></author>
<author initials="D" surname="Maltz">
<organization></organization></author>
<author initials="J" surname="Padhye">
<organization></organization></author>
<author initials="P" surname="Patel">
<organization></organization></author>
<author initials="B" surname="Prabhakar">
<organization></organization></author>
<author initials="S" surname="Sengupta">
<organization></organization></author>
<author initials="M" surname="Sridharan">
<organization></organization></author>
<date month="Jan" year="2010"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:12:14 |