One document matched: draft-ietf-tcpm-accecn-reqs-04.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 RFC2018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2018.xml">
<!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">
<!ENTITY RFC6789 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6789.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="info" docName="draft-ietf-tcpm-accecn-reqs-04" 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 abbrev="Requirements for More Accurate ECN">Problem Statement and Requirements for a More Accurate ECN Feedback</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="2013" />
<area>Transport</area>
<workgroup>TCP Maintenance and Minor Extensions (tcpm)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>Explicit Congestion Notification (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 ECN feedback information
in the case where more than one marking is received in one RTT.
This document specifies requirements for an update to the TCP protocol
to provide more accurate ECN feedback than one signal per RTT.
</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). This is sufficient for pre-existing
congestion control mechanisms that perform only one reduction in sending
rate per RTT, independent of the number of ECN congestion marks. But
recently proposed/deployed mechanisms like Congestion Exposure (ConEx)
<xref target="RFC6789"/> or DCTCP <xref target="Ali10"/> need more
fine-grained ECN feedback information to work correctly in the case
where more than one marking is received in any one RTT.</t>
<t>This document lists requirements for a robust and interoperable more accurate TCP/ECN
feedback protocol that all implementations of new TCP extension like ConEx and/or
DCTCP can use. While a new feedback scheme should still deliver identical performance
as classic ECN, this document also clarifies what has to be taken into consideration
in addition. Thus the listed requirements should be addressed in the specification of
a more accurate ECN feedback scheme. Moreover, as a large set of proposals already exists,
a few high level design choices are sketched and briefly discussed, to demonstrate some
of the benefits and drawbacks of each of these potential schemes.
A few solutions have already been proposed, so <xref target="accecn_designs"/>
demonstrates how to use the requirements to
compare them, by briefly sketching their high level design choices and
discussing the benefits and drawbacks of each.
</t>
<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>
<list hangIndent="9" style="hanging">
<t hangText="CE:">the Congestion Experienced codepoint,</t>
<t hangText="ECT(0):">the first ECN-capable Transport codepoint, and</t>
<t hangText="ECT(1):">the second ECN-capable Transport codepoint.</t>
</list>
</t></list>
The ECN flags in the TCP header:
<list hangIndent="10" style="empty"><t>
<list hangIndent="9" style="hanging">
<t hangText="CWR:">the Congestion Window Reduced flag,</t>
<t hangText="ECE:">the ECN-Echo flag, and</t>
<t hangText="NS:">ECN Nonce Sum.</t>
</list>
</t></list>
</t>
<t> In this document, the ECN feedback scheme as specified
in <xref target="RFC3168"/> is called the 'classic ECN'
and any new proposal the 'more accurate ECN feedback' scheme.
A 'congestion mark' is defined as an IP packet where the CE codepoint is set.
A 'congestion episode' refers to one or more congestion marks belonging to the same
overload situation in the network (usually during one RTT). A TCP segment with the
acknowledgment flag set is simply called ACK.
</t>
</section>
</section>
<section anchor="accecn_recap"
title="Recap of Classic ECN and ECN Nonce in IP/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
(ECT) which results in two signals, ECT(0) and ECT(1). A network node
can set both bits simultaneously when it experiences congestion. When
both bits are set the packet is regarded as "Congestion Experienced"
(CE).</t>
<t>In the TCP header the first two bits in byte 14 are defined as ECN
feedback for each half-connection. A TCP receiver signals the reception
of a congestion mark using the ECN-Echo (ECE) flag in the TCP header.
For reliability, the receiver continues to set the ECE flag on every
ACK. To enable the TCP receiver to determine when to stop setting the
ECN-Echo flag, the sender sets the CWR flag upon reception of an ECE
feedback signal. This always leads to a full RTT of ACKs with ECE set.
Thus the receiver cannot signal back any additional CE markings arriving
within the same RTT.</t>
<t>The ECN Nonce <xref target="RFC3540"/> is an experimental addition to
ECN that the TCP sender can use to protect itself against accidental or
malicious concealment of marked or dropped packets. This addition
defines the last bit of byte 13 in the TCP header as the Nonce Sum (NS)
flag. The receiver maintains a nonce sum that counts the occurrence of
ECT(1) packets, and signals the least significant bit of this sum on the
NS flag.</t>
<figure anchor="TCPHdr" align="center" title="The (post-ECN Nonce) definition of the TCP header flags">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Header Length | Reserved | S | W | C | R | C | S | S | Y | I |
| | | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
<t>However, as ECN is a separate extension to ECN, even if a sender tries to protect
itself with the ECN Nonce, any receiver wishing to conceal marked or dropped packets only has to
pretend not supporting ECN Nonce and simply not provide any Nonce sum feedback.
An alternative for a sender to assure feedback integrity has been proposed
where the sender occasionally inserts a CE mark, reordering or loss itself, and checks that the
receiver feeds it back faithfully <xref target="I-D.moncaster-tcpm-rcv-cheat"/>.
This alternative requires no standardization and consumes no header bits
or codepoints, as well as releasing the ECT(1) codepoint in the IP header
and the NS flag in the TCP header for other uses.
<vspace blankLines="2"/>
</t>
</section>
<section title="Use Cases">
<t>ConEx is an experimental approach that allows the sender to re-insert
the congestion feedback it sees into the forward data path. This is
primarily so that any traffic management can be proportionate to actual
congestion caused by traffic, rather than limiting traffic based on rate
or volume in case it might cause congestion <xref target="RFC6789"/>. A
ConEx sender uses selective acknowledgements (SACK <xref target="RFC2018"/>)
for fine-grained feedback of loss signals, but
currently TCP offers no equivalent fine-grained feedback for ECN.</t>
<t>DCTCP offers very low and predictable queueing delay. DCTCP requires
switches/routers to have ECN enabled and configured with no signal
smoothing, so it is currently only used in private networks, e.g.
internal to data centers. DCTCP was released in Microsoft Windows 8, and
implementations exist for Linux and FreeBSD.</t>
<t>The changes DCTCP makes to TCP are not currently the subject of any
IETF standardization activity. The different DCTCP implementations alter
TCP's ECN feedback protocol <xref target="RFC3168"/> in unspecified
proprietary ways, and they either omit capability negotiation, or they
use non-interoperable negotiation. A primary motivation for this
document is to prevent each proprietary implementation from inventing
its own handshake, which could lead to <spanx style="emph">de facto</spanx>
consumption of the few flags that remain available for standardizing
capability negotiation. Also, those variants that use the feedback
protocol proposed in <xref target="Ali10"/> only work if there are no
losses at all, and otherwise they become confused.</t>
<t> The following scenarios should briefly show where the accurate feedback
is needed or adds value:
<list hangIndent="8" style="hanging">
<t hangText="An RFC5681 TCP sender that supports ConEx:"><vspace/>In
this case the ConEx mechanism uses the extra information per RTT to
re-echo the precise congestion information, but the congestion
control algorithm still ignores multiple marks per RTT <xref
target="RFC5681"/>.</t>
<t hangText="A sender using DCTCP congestion control without ConEx:"><vspace/>
The congestion control algorithm uses the extra info per RTT to
perform its decrease depending on the number of congestion marks.</t>
<t hangText="A sender using DCTCP congestion control and supports ConEx:"><vspace/>Both
the congestion control algorithm and ConEx use the fine-grained ECN
feedback mechanism.</t>
<t hangText="A RFC5681 TCP sender without ConEx:"><vspace/>
No accurate feedback is necessary here. The congestion control
algorithm still reacts on only one signal per RTT. But it is best
to have one generic feedback mechanism, whether it is used or not.</t>
<t hangText="Using CE for checking integrity:"><vspace/>
If a more accurate ECN feedback scheme would feed all occurrences of CE
marks back, a sender could perform integrity checking based in the
injection of CE marks. Thereby, a sender will send packets which are
deterministically marked with CE (at a low frequency) and keep track
if feedback is received for these packets. Of course, the congestion
notification feedback for these self-injected markings,
does not cause a congestion control react.</t>
</list>
</t>
</section>
<section title="Requirements" anchor="accecn_reqs">
<t>The requirements of the accurate ECN feedback protocol, for the use of
e.g. Conex or DCTCP, are to have a fairly accurate (not necessarily
perfect), timely and protected signaling. This leads to the following
requirements, which should be discussed for any proposed more accurate
ECN feedback scheme:</t>
<t><list hangIndent="8" style="hanging">
<t hangText="Resilience"><vspace/>The ECN feedback signal is carried within the
ACK. TCP ACKs can get lost. Moreover, delayed ACKs are commonly used
with TCP. That means in most cases only every second data packet triggers an ACK.
In a high congestion situation where most of the packets are marked with CE, an
accurate feedback mechanism must still be able to signal sufficient congestion
information. Thus the accurate ECN feedback extension has to take delayed ACK and
ACK loss into account. Also, a more accurate
feedback protocol would still work if delayed ACKs covered more than two packets.</t>
<t hangText="Timeliness"><vspace/>a CE mark can be induced by a network node on the
transmission path and is then echoed by the receiver in the TCP ACK. Thus when
this information arrives at the sender, it is naturally already about one RTT old.
With a sufficient ACK rate a further delay of a small number of ACKs can be
tolerated. However, this information will become stale with large delays, given the
dynamic nature of networks. TCP congestion control (which itself partly introduces these
dynamics) operates on a time scale of one RTT. Thus, to be timely, congestion feedback
information should be delivered within about one RTT.</t>
<t hangText="Integrity"><vspace/>
<!-- With ECN Nonce, a misbehaving receiver or network node
can be detected with good probability. If the accurate ECN feedback is
reusing the NS bit, it is encouraged to ensure integrity at least as good as
ECN Nonce. If this is not possible, alternative approaches should be provided
how a mechanism using the accurate ECN feedback extension can re-ensure
integrity or give strong incentives for the receiver and network node to
cooperate honestly.-->
A more accurate ECN feedback scheme should
assure the integrity of the feedback at least as well as the ECN Nonce or
gives strong incentives for the receiver and network nodes to cooperate
honestly.
<vspace blankLines="1"/>Given there are known problems with the ECN nonce (as identified above),
this document only requires that the integrity of the more accurate ECN feedback
can be assured; it does not require that the ECN Nonce mechanism is employed to achieve
this. Indeed, if integrity could be provided else-wise, a more accurate ECN
feedback protocol might re-use the nonce sum (NS) flag in the TCP
header.
<vspace blankLines="1"/>If the accurate ECN feedback scheme provides sufficient information,
the integrity check could e.g. be performed by deterministically setting the CE in the sender
and monitoring the respective feedback (similar to ECT(1) and the ECN Nonce sum).
If and what kind of enforcements a sender should do, when detecting wrong feedback
information, is not part of this document.</t>
<t hangText="Accuracy"><vspace/><!--In TCP usually delayed ACKs are used. Thats means in
most cases only for every second data packets an acknowledgment is sent. Moreover,
an ACK can get lost.-->Classic ECN feeds back one congestion notification per RTT, which
is sufficient for classic TCP congestion control which reduces the sending
rate at most once per RTT. The more accurate ECN feedback scheme has to ensure that
if a congestion episode occurs, at least one congestion notification is echoed and
received per RTT as classic ECN would do. Of course, the goal of a more accurate ECN extension is to
reconstruct the number of CE markings more accurately and in the best case even to reconstruct
the exact number of payload bytes that a CE marked packet was carrying. However, a sender should
not assume to get the exact number of congestion markings or marked bytes in all situations.
Moreover, the feedback scheme should preserve the order at which any ECN signal was
received. And ideally, it would even be possible for the sender to determine which
of the packets (covered by one delayed ACK) were congestion marked, e.g. if the flow consists
of packets of different sizes, or to allow for future protocols
where the order of the markings may be important.
<vspace blankLines="1"/>In fact, the ECN field in the IP header provides four code points.
In the best case, a sender that has the more accurate ECN feedback information, would be able
to reconstruct the occurrence of any of the four code points. Assuming the sender marks all
data packets will at least as ECN-capable and ETC(0) will be the default setting, feeding the
occurrence of CE and ECT(1) back might be sufficient.</t>
<t hangText="Complexity"><vspace/>The implementation should be as simple as possible and
only a minimum of additional state information should be needed.
This will enable the more accurate ECN feedback to be used as the default feedback mechanism,
even if only one ECN feedback signal per RTT is needed. Furthermore, the receiver should not take
assumptions about the mechanism that was used to set the markings nor about any interpretation or
reaction to the congestion signal. The receiver should only feed the information back as accurate
as possible.<!--A proposal fulfilling this for a more
accurate ECN feedback can then also be the standard ECN feedback mechanism.--></t>
<t hangText="Overhead"><vspace/>A more accurate ECN feedback signal should limit the additional network
load, because ECN feedback is ultimately not critical information (in the worst case, loss will
still be available as a congestion signal of last resort). As feedback information has to be
provided frequently and in a timely fashion, potentially all or a large fraction of TCP
acknowledgments might carry this information. Ideally, no additional segments should
be exchanged compared to an RFC3168 TCP session, and the overhead in
each segment should be minimized.
</t>
<t hangText="Backward and forward compatibility"><vspace/>
Given more accurate ECN feedback will involve a
change to the TCP protocol, it will need to be negotiated between
the two TCP endpoints. If either end does not support the more accurate
feedback, they should both be able to fall-back to classic ECN
feedback.
<vspace blankLines="1"/>A more accurate ECN feedback
extension should aim to be able to traverse most existing
middleboxes. Further, a feedback mechanism should provide a method
to fall-back to classic RFC3168 signaling if the new signal is
suppressed by certain middleboxes.
<vspace blankLines="1"/>In order
to avoid a fork in the TCP protocol specifications, if experiments
with the new ECN feedback protocol are successful, it
is intended to eventually update RFC3168 for any TCP/ECN sender, not
just for ConEx or DCTCP senders. Therefore, even if only one ECN
feedback signal per RTT is needed, it should be possible to use
the more accurate ECN feedback.</t>
</list></t>
</section>
<section title="Design Approaches" anchor="accecn_designs">
<t>All approaches presented below (and proposed so far) are able to provide accurate
ECN feedback information as long as no ACK loss occurs and the congestion rate
is reasonable. In case of high a high ACK loss rate or very high congestion (CE
marking) rate, the proposed schemes have different resilience characteristics
depending on the number of used bits for the encoding. While classic ECN provides
a reliable (inaccurate) feedback of a maximum of one congestion signal per RTT,
the proposed schemes do not implement an explicit acknowledgement mechanism.
</t>
<section title="Re-use of ECN/NS Header Bits">
<t>The three ECN/NS header, ECE, CWR and NS are re-used (not only for additional
capability negotiation during the TCP handshake exchange but) to signal the current value of
an CE counter at the receiver. This approach only provides a limited resilience against ACK lost
depending of the number of used bits.
</t>
<t>Several codings have been proposed so far:
<list style="symbols">
<t>A one bit scheme sends one ECE for each CE received (to
increase the robustness against ACK loss CWR could be used to
introduce redundant information on the next ACK);</t>
<t>A 3-bit counter scheme continuously feeds back the three least
significant bits of a CE counter;</t>
<t>A 3-bit codepoint scheme encodes either a CE counter or an
ECT(1) counter in 8 codepoints.</t>
</list>
</t>
<t>The proposed schemes provide accumulated information on ECN-CE-marking feedback,
similar to the number
of acknowledged bytes in the TCP header. Due to the limited number of bits the
ECN feedback information will wrap much more often than the acknowledgement field.
Thus feedback information could be lost due to a relatively small sequence of pure-ACK losses.
Resilience could be
increased by introducing redundancy, e.g. send each counter increase two or
more times. Of course any of these additional mechanisms will increase the complexity.
If the congestion rate is larger that the ACK rate (multiplied by the number of congestion
marks that can be signaled per ACK), the congestion information cannot correctly
fed back.
Thus an accurate ECN feedback mechanism needs to be able to also cover the worst case situation
where every packet is CE marked. This can potentially be realized by dynamically adapting the
ACK rate and redundancy, which again increases complexity and perhaps the signaling
overhead as well. Scheme that do not re-use the ECN NS bit, can still support ECN Nonce.
</t>
</section>
<section title="Using Other Header Bits ">
<t>As seen in <xref target="TCPHdr"/>, there are currently three unused flag bits
in the TCP header. The proposed 3 bit or codepoint schemes could be extended by one or
more bits, to add higher resilience against ACK loss. The relative gain
would be proportionally higher resilience against ACK loss, while the respective
drawbacks would remain identical.
</t>
<t>Alternatively, the receiver could use bits in the Urgent Pointer
field to signal more bits of its congestion signal counter, but only
whenever it does not set the Urgent Flag. As this is often the case,
resilience could be increased without additional header overhead.</t>
<t>Any proposal to use such bits would need to check the likelihood
that some middleboxes might discard or 'normalize' the currently
unused flag bits or a non-zero Urgent Pointer when the Urgent Flag is
cleared.</t>
</section>
<section title="Using a TCP Option">
<t>Alternatively, a new TCP option could be introduced, to help maintaining the
accuracy and integrity of the ECN feedback between receiver and sender.
Such an option could provide higher resilience and even more information.
E.g. ECN for RTP/UDP provides
explicit the number of ECT(0), ECT(1), CE, non-ECT marked and lost packets.
However, deploying new TCP options has its own challenges. Moreover, to actually
achieve a high resilience, this option would need to be carried by either all or a large number
ACKs. Thus this approach would introduce considerable signaling overhead while ECN feedback is not
such a critical information (as in the worst case, loss will still be available to provide a strong
congestion feedback signal).
Anyway, such a TCP option
could also be used in addition to a more accurate ECN feedback scheme in the TCP header or in addition to classic ECN, only when available and needed.
</t>
</section>
<!--<t>Combining the idea of <xref target="eci_mode"/> and <xref target="cp_mode"/>,
further extending it to a one-octet option, would allow the signaling of two
values, each with 4 bit. The gains in worst case ACK loss, delayed ACK ratios
and maintaining ECN Nonce would scale accordingly.
</t>
<t>Alternatively, if timestamp capability negotiation is supported, a few
bits could be extracted from the timestamp value, to provide extended
signaling. However, processing TCP options (or overloaded TCP options) is
more complex than processing of header flags.
</t>-->
</section>
<section title="Acknowledgements">
<t>Thanks to Bob Briscoe for reviewing and providing valuable additions on DCTCP and ConEx.
Moreover, thanks to Gorry Fairhurst as well as Bob Briscoe for ideas on CE-based integrity checking.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</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>Given ECN feedback is used as input for congestion control, the
respective algorithm would not react appropriately if ECN
feedback were lost and the resilience mechanism to recover it was
inadequate. This resilience requirement is articulated in <xref
target="accecn_reqs"/>. However, it should be noted that
ECN feedback is not the last resort against congestion collapse, because
if there is insufficient response to ECN, loss will ensue, and TCP will
still react appropriately to loss.</t>
<t>A receiver could suppress ECN feedback information leading to its
connections consuming excess sender or network resources.
<!--Or an attacker
could providing wrong congestion information which then easily leads to
throttling of certain connections. These problems
are --> This problem is
similar to that seen with the classic ECN feedback scheme and should
be addressed by integrity checking as required in <xref
target="accecn_reqs"/>.</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.kuehlewind-tcpm-accurate-ecn-option.xml"?>
<?rfc include="reference.I-D.moncaster-tcpm-rcv-cheat.xml"?>
&RFC2018;
&RFC5562;
&RFC5681;
&RFC5690;
&RFC6789;
<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 16:23:58 |