The IESG has approved the Internet-Draft 'The Addition of Explicit
Congestion Notification (ECN) to IP' <draft-ietf-tsvwg-ecn-04.txt> as a
Proposed Standard. This document is the product of the Transport Area
Working Group Working Group. The IESG contact persons are Allison
Mankin and Scott Bradner.
Technical Summary
This protocol specifies the incorporation of ECN (Explicit Congestion
Notification) into TCP and IP, including ECN's use of two bits in the
IP header. It describes TCP's standard use (RFC 2581) of packet
drops as the indication of congestion. With the addition of
active queue management (e.g., RED) to the Internet infrastructure,
where routers detect congestion before the queue overflows, routers are
no longer limited to packet drops as the only indication of congestion.
Routers can instead set the Congestion Experienced (CE) codepoint in
the IP header of packets from ECN-capable transports. We describe
when the CE codepoint is to be set in routers, and describe
modifications needed to TCP to make it ECN-capable. Among other
transports than TCP, the SCTP Proposed Standard (RFC 2960) has
reserved bits for future support of ECN, and support of ECN in
other transports (unreliable unicast or multicast, reliable multicast)
is under consideration, as congestion control is developed for them.
The protocol also describes how to use ECN within IP tunnels,
and within IPSec tunnels in particular. The use of ECN in the
outer header of an IPSec tunnel might raise security concerns,
because an adversary could tamper with the outer header congestion
information and degrade performance. The approach determined on is
to make support for ECN an option for any IP tunnel, and recommend
tradeoff analysis between limited-functionality ECN, which is
compatible with IPSec tunnels but results in congestion signaled
only when packets are lost, or full-functionality ECN with IPSec.
One of the guiding principles for this document is that all the
mechanisms specified here are incrementally deployable, both on
the transport side and in router installations.
Working Group Summary
The working group strongly favored moving ECN from Experimental
(RFC 2481) to Proposed Standard. Among the developments between
the Experimental publication and this one were:
The protocol support for use of ECN in IPSec packets was developed
and the draft was approved for Informational by the IPSec WG and
the IESG. Rather than publish the IPSec draft standalone, it was
incorporated (Section 9.2).
The Transport Area WG reviewed additional enhancements, including
clarification of the interaction of TCP retransmissions and ECN.
Linux community members identified firewalls and IDS devices that
drop or reset TCP SYN packets with bits set for ECN capability.
The evaluation of the community was that these are broken devices,
and vendors of each of the identified devices issued fixes.
Further information (including experiment results and pointers to
implementations) is available at http://www.aciri.org/floyd/ecn.html.
Protocol Quality
There are numerous implementations of ECN. The authors and Area
Directors received communications from two of the major router
vendors expressing the goal to ship implementations of ECN as
specified in this new draft in the near future.
The protocol was reviewed for the IESG by Allison Mankin.
During Last Call on draft-ietf-tsvwg-ecn-02.txt, an effective
design, using nonces, for preventing receiver cheating with ECN
was brought to the TSVWG. This work was adopted into the TSVWG
charter by strong WG consensus and the WG had consensus to adjust
the definition of ECN codepoints so that they would be compatible
with eventual standardization of nonce protection. A new Last Call
was issued. No negative comments were received during either Last
Call.
