draft-ietf-tcpm-ecnsyn-00.txt   draft-ietf-tcpm-ecnsyn-01.txt 
Internet Engineering Task Force A. Kuzmanovic Internet Engineering Task Force A. Kuzmanovic
INTERNET DRAFT Northwestern University INTERNET DRAFT Northwestern University
draft-ietf-tcpm-ecnsyn-00.txt S. Floyd draft-ietf-tcpm-ecnsyn-01.txt S. Floyd
ICIR ICIR
K.K. Ramakrishnan K.K. Ramakrishnan
AT&T AT&T
January, 2006 October, 2006
Adding Explicit Congestion Notification (ECN) Capability to TCP's Adding Explicit Congestion Notification (ECN) Capability to TCP's
SYN/ACK Packets SYN/ACK Packets
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to
the TCP connection, avoiding the severe penalty of a retransmit the TCP connection, avoiding the severe penalty of a retransmit
timeout for a connection that has not yet started placing a load on timeout for a connection that has not yet started placing a load on
the network. The sender of the SYN/ACK packet must respond to an ECN the network. The sender of the SYN/ACK packet must respond to an ECN
mark by reducing its initial congestion window from two, three, or mark by reducing its initial congestion window from two, three, or
four segments to one segment, reducing the subsequent load from that four segments to one segment, reducing the subsequent load from that
connection on the network. connection on the network.
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
Changes from draft-ietf-twvsg-ecnsyn: Changes from draft-ietf-tcpm-ecnsyn-00:
* Only updating the revision number.
Changes from draft-ietf-twvsg-ecnsyn-00:
* Changed name of draft to draft-ietf-tcpm-ecnsyn. * Changed name of draft to draft-ietf-tcpm-ecnsyn.
* Added a discussion in Section 3 of "Response to * Added a discussion in Section 3 of "Response to
ECN-marking of SYN/ACK packets". Based on ECN-marking of SYN/ACK packets". Based on
suggestions from Mark Allman. suggestions from Mark Allman.
* Added a discussion to the Conclusions about adding * Added a discussion to the Conclusions about adding
ECN-capability to relevant set-up packets in other ECN-capability to relevant set-up packets in other
protocols. From a suggestion from Wesley Eddy. protocols. From a suggestion from Wesley Eddy.
skipping to change at page 9, line 12 skipping to change at page 9, line 12
packets should generally be low. In this case, the benefit of making packets should generally be low. In this case, the benefit of making
SYN/ACK packets ECN-Capable should be similarly moderate. However, SYN/ACK packets ECN-Capable should be similarly moderate. However,
for a congested router with a Drop Tail queue in units of packets or for a congested router with a Drop Tail queue in units of packets or
with an AQM mechanism in packet mode, and with no priority queueing with an AQM mechanism in packet mode, and with no priority queueing
for smaller packets, small and large packets should have the same for smaller packets, small and large packets should have the same
probability of being dropped or marked. In such a case, making probability of being dropped or marked. In such a case, making
SYN/ACK packets ECN-Capable should be of significant benefit. SYN/ACK packets ECN-Capable should be of significant benefit.
We believe that there are a wide range of behaviors in the real world We believe that there are a wide range of behaviors in the real world
in terms of the drop or mark behavior at routers as a function of in terms of the drop or mark behavior at routers as a function of
packet size [Tools, Section 10]. We note that all of these packet size [Tools] (Section 10). We note that all of these
alternatives listed above are available in the NS simulator (Drop alternatives listed above are available in the NS simulator (Drop
Tail queues are by default in units of packets, while the default for Tail queues are by default in units of packets, while the default for
RED queue management has been changed from packet mode to byte mode). RED queue management has been changed from packet mode to byte mode).
Response to ECN-marking of SYN/ACK packets: Response to ECN-marking of SYN/ACK packets:
One question is why TCP SYN/ACK packets should be treated differently One question is why TCP SYN/ACK packets should be treated differently
from other packets in terms of the packet sender's response to an from other packets in terms of the packet sender's response to an
ECN-marked packet. Section 5 of RFC 3168 specifies the following: ECN-marked packet. Section 5 of RFC 3168 specifies the following:
"Upon the receipt by an ECN-Capable transport of a single CE packet, "Upon the receipt by an ECN-Capable transport of a single CE packet,
skipping to change at page 13, line 14 skipping to change at page 13, line 14
6. Security Considerations 6. Security Considerations
TCP packets carrying the ECT codepoint in IP headers can be marked TCP packets carrying the ECT codepoint in IP headers can be marked
rather than dropped by ECN-capable routers. This raises several rather than dropped by ECN-capable routers. This raises several
security concerns that we discuss below. security concerns that we discuss below.
"Bad" middleboxes: "Bad" middleboxes:
There is a small but decreasing number of middleboxes that drop or There is a small but decreasing number of middleboxes that drop or
reset SYN and SYN/ACK packets based on the ECN-related flags in the reset SYN and SYN/ACK packets based on the ECN-related flags in the
TCP header [MAF05,RFC3360]. While there is no evidence that any TCP header [MAF05], [RFC3360]. While there is no evidence that any
middleboxes drop SYN/ACK packets that contain an ECN-Capable middleboxes drop SYN/ACK packets that contain an ECN-Capable
codepoint in the *IP header*, such behavior cannot be excluded. codepoint in the *IP header*, such behavior cannot be excluded.
Thus, as specified in Section 2, if a SYN/ACK packet with the ECT Thus, as specified in Section 2, if a SYN/ACK packet with the ECT
codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet codepoint is dropped, the TCP node SHOULD resend the SYN/ACK packet
without the ECN-Capable codepoint. without the ECN-Capable codepoint.
Congestion collapse: Congestion collapse:
Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN- Because TCP SYN/ACK packets carrying an ECT codepoint could be ECN-
marked instead of dropped at an ECN-capable router, the concern is marked instead of dropped at an ECN-capable router, the concern is
whether this can either invoke congestion, or worsen performance in whether this can either invoke congestion, or worsen performance in
skipping to change at page 14, line 13 skipping to change at page 14, line 13
retransmission-based reliability in their setup phase (e.g., SCTP, retransmission-based reliability in their setup phase (e.g., SCTP,
DCCP, HIP, and the like). DCCP, HIP, and the like).
8. Acknowledgements 8. Acknowledgements
We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi We thank Mark Allman, Wesley Eddy, Janardhan Iyengar, and Pasi
Sarolahti for feedback on earlier versions of this draft. Sarolahti for feedback on earlier versions of this draft.
9. Normative References 9. Normative References
[RFC 2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119, March 1997.
[RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
Standard, September 2001. Standard, September 2001.
[RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's [RFC3390] M. Allman, S. Floyd, and C. Partridge, Increasing TCP's
Initial Window, RFC 3390, October 2002. Initial Window, RFC 3390, October 2002.
10. Informative References 10. Informative References
[ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification, [ECN+] A. Kuzmanovic, The Power of Explicit Congestion Notification,
skipping to change at page 15, line 16 skipping to change at page 15, line 18
3360, August 2002. 3360, August 2002.
[SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP} [SCJO01] F. Smith, F. Campos, K. Jeffay, D. Ott, What {TCP/IP}
Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001. Protocol Headers Can Tell us about the Web, SIGMETRICS, June 2001.
[SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also [SYN-COOK] Dan J. Bernstein, SYN cookies, 1997, see also
<http://cr.yp.to/syncookies.html> <http://cr.yp.to/syncookies.html>
[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of
Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg- Simulation and Testbed Scenarios, Internet-draft draft-irtf-tmrg-
tools-00, work in progress, September 2005. tools-02, work in progress, June 2006.
11. IANA Considerations 11. IANA Considerations
There are no IANA considerations regarding this document. There are no IANA considerations regarding this document.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Aleksandar Kuzmanovic Aleksandar Kuzmanovic
Phone: +1 (847) 467-5519 Phone: +1 (847) 467-5519
Northwestern University Northwestern University
 End of changes. 7 change blocks. 
6 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/