draft-ietf-tsvwg-ecn-02.txt   draft-ietf-tsvwg-ecn-03.txt 
Internet Engineering Task Force K. K. Ramakrishnan Internet Engineering Task Force K. K. Ramakrishnan
INTERNET DRAFT TeraOptic Networks INTERNET DRAFT TeraOptic Networks
draft-ietf-tsvwg-ecn-02.txt Sally Floyd draft-ietf-tsvwg-ecn-03.txt Sally Floyd
ACIRI ACIRI
D. Black D. Black
EMC EMC
February, 2001 March, 2001
Expires: August, 2001 Expires: September, 2001
The Addition of Explicit Congestion Notification (ECN) to IP The Addition of Explicit Congestion Notification (ECN) to IP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 4, line 19 skipping to change at page 4, line 19
19.2. Implications for the Subverted Flow 19.2. Implications for the Subverted Flow
19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion Control 19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion Control
20. The Motivation for the ECT Codepoints. 20. The Motivation for the ECT Codepoints.
20.1. The Motivation for an ECT Codepoint. 20.1. The Motivation for an ECT Codepoint.
20.2. The Motivation for two ECT Codepoints. 20.2. The Motivation for two ECT Codepoints.
21. Why use Two Bits in the IP Header? 21. Why use Two Bits in the IP Header?
22. Historical Definitions for the IPv4 TOS Octet 22. Historical Definitions for the IPv4 TOS Octet
23. IANA Considerations 23. IANA Considerations
RFC EDITOR - REMOVE THE FOLLOWING PARAGRAPH ON PUBLICATION - To compare RFC EDITOR - REMOVE THE FOLLOWING PARAGRAPH ON PUBLICATION - To compare
this with draft-ietf-tsvwg-ecn-01, compare the following: this with draft-ietf-tsvwg-ecn-02, compare the following:
"http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-01.troff"
"http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-02.troff" "http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-02.troff"
"http://www.aciri.org/floyd/papers/draft-ietf-tsvwg-ecn-03.troff"
Changes from draft-ietf-tsvwg-ecn-02:
Revised Section 5.3 on fragmentation.
Changes from draft-ietf-tsvwg-ecn-01: Changes from draft-ietf-tsvwg-ecn-01:
Added the ECT(1) codepoint, and changed references about bits to Added the ECT(1) codepoint, and changed references about bits to
references about codepoints in many places. Also added Section 11.2 on references about codepoints in many places. Also added Section 11.2 on
"A Discussion of the ECN nonce", and Section 20.2 on "The Motivation for "A Discussion of the ECN nonce", and Section 20.2 on "The Motivation for
two ECT Codepoints". two ECT Codepoints".
Added a paragraph saying that by default, the discussion of setting Added a paragraph saying that by default, the discussion of setting
the CE codepoint applies to all Differentiated Services Per-Hop the CE codepoint applies to all Differentiated Services Per-Hop
Behaviors. Behaviors.
Added Section 5.3 on fragmentation. Added Section 5.3 on fragmentation.
Added "A host MUST NOT set ECT on SYN or SYN-ACK packets." to the end Added "A host MUST NOT set ECT on SYN or SYN-ACK packets." to the end
skipping to change at page 12, line 40 skipping to change at page 12, line 40
packet. This issue of corrupted CE packets would have to be packet. This issue of corrupted CE packets would have to be
considered in any proposal for the network to distinguish between considered in any proposal for the network to distinguish between
packets dropped due to corruption, and packets dropped due to packets dropped due to corruption, and packets dropped due to
congestion or buffer overflow. In particular, the ubiquitous congestion or buffer overflow. In particular, the ubiquitous
deployment of ECN would not, in and of itself, be a sufficient deployment of ECN would not, in and of itself, be a sufficient
development to allow end-nodes to interpret packet drops as development to allow end-nodes to interpret packet drops as
indications of corruption rather than congestion. indications of corruption rather than congestion.
5.3. Fragmentation 5.3. Fragmentation
All ECN-capable packets SHOULD have the DF (Don't Fragment) bit set. ECN-capable packets MAY have the DF (Don't Fragment) bit set.
Reassembly of a fragmented packet MUST NOT lose indications of Reassembly of a fragmented packet MUST NOT lose indications of
congestion. In other words, if any fragment of an IP packet to be congestion. In other words, if any fragment of an IP packet to be
reassembled has the CE codepoint set, then one of two actions MUST be reassembled has the CE codepoint set, then one of two actions MUST be
taken: taken:
* The reassembled packet has the CE codepoint set. This MUST NOT * Set the CE codepoint on the reassembled packet. However, this
occur if any of the other fragments contributing to this MUST NOT occur if any of the other fragments contributing to this
reassembly carries the Not-ECT codepoint. reassembly carries the Not-ECT codepoint.
* The packet is dropped instead of being reassmembled. * The packet is dropped, instead of being reassmembled, for any
other reason.
If both actions are applicable, either MAY be chosen. Reassembly of If both actions are applicable, either MAY be chosen. Reassembly of
a fragmented packet MUST NOT change the ECN codepoint when all of the a fragmented packet MUST NOT change the ECN codepoint when all of the
fragments carry the same codepoint. fragments carry the same codepoint.
Situations may arise in which the above specification is We would note that because RFC 2481 did not specify reassembly
insufficiently precise. For example, it does not place requirements behavior, older ECN implementations conformant with that Experimental
on reassembly of fragments that carry a mixture of ECT(0), ECT(1) RFC do not necessarily perform reassembly correctly, in terms of
and/or Not-ECT. In situations where more precise reassembly behavior preserving the CE codepoint in a fragment. The sender could avoid
would be required, protocol specifications SHOULD instead specify the consequences of this behavior by setting the DF bit in ECN-
that DF MUST be set in all packets sent by the protocol. Capable packets.
Situations may arise in which the above reassembly specification is
insufficiently precise. For example, if there is a malicious or
broken entity in the path at or after the fragmentation point, packet
fragments could carry a mixture of ECT(0), ECT(1), and/or Not-ECT
codepoints. The reassembly specification above does not place
requirements on reassembly of fragments in this case. In situations
where more precise reassembly behavior would be required, protocol
specifications SHOULD instead specify that DF MUST be set in all ECN-
capable packets sent by the protocol.
6. Support from the Transport Protocol 6. Support from the Transport Protocol
ECN requires support from the transport protocol, in addition to the ECN requires support from the transport protocol, in addition to the
functionality given by the ECN field in the IP packet header. The functionality given by the ECN field in the IP packet header. The
transport protocol might require negotiation between the endpoints transport protocol might require negotiation between the endpoints
during setup to determine that all of the endpoints are ECN-capable, during setup to determine that all of the endpoints are ECN-capable,
so that the sender can set the ECT codepoint in transmitted packets. so that the sender can set the ECT codepoint in transmitted packets.
Second, the transport protocol must be capable of reacting Second, the transport protocol must be capable of reacting
appropriately to the receipt of CE packets. This reaction could be appropriately to the receipt of CE packets. This reaction could be
skipping to change at page 59, line 7 skipping to change at page 59, line 25
Email: floyd@aciri.org Email: floyd@aciri.org
URL: http://www.aciri.org/floyd/ URL: http://www.aciri.org/floyd/
David L. Black David L. Black
EMC Corporation EMC Corporation
42 South St. 42 South St.
Hopkinton, MA 01748 Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140 Phone: +1 (508) 435-1000 x75140
Email: black_david@emc.com Email: black_david@emc.com
This draft was created in February 2001. This draft was created in March 2001.
It expires August 2001. It expires September 2001.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/