One document matched: draft-kuehlewind-tcpm-accurate-ecn-option-00.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-00" 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="2011" />
<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 causes additional load in case of
severe congestion.
</t>
<section title="Overview ECN and ECN Nonce in TCP">
<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 (same as above)
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 feedback, the option
MUST be used in any subsequent TCP segment.
</t>
</section>
<section title="Accurate ECN 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. The TCP option to provide the accurate ECN feedback to the sender will echo these counters (modulo 16) in five 2 byte fields. This option should be included in every ACK (and not only when a counter value changes) to ensure the reception of the ECN feedback at the sender in case of ACK loss.
<figure anchor="TCPOpt" align="center" title="Accurate ECN feedback TCP option">
<artwork align="left"><![CDATA[
TCP Accurate ECN Option:
Kind: TBD
Length: 12 bytes
+------+------+---------+---------+--------+---------+---------+
| Kind | 12 | ECT(0) | ECT(1) | CE | non-ECT | loss |
+------+------+---------+---------+--------+---------+---------+
1 1 2 2 2 2 2
]]></artwork>
</figure>
</t>
<t>
The number of lost packet would be needed to calculate
the ECN Nonce sum more exactly. TCP provides anyway a mechanism to detect loss and lost
needs to be assumes as a string signal for congestion anyway. Thus a TCP congestion control
algorithm muss react on loss. Moreover, if TCP SACK is not available the exact number of lost packets
is not known.
</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 bitdirectional protocol this option can be used in both directions.
</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-24 01:25:45 |