Network Working Group N. Khademi
Internet-Draft M. Welzl
Updates: 3168 (if approved) University of Oslo
Intended status: Experimental G. Armitage
Expires: January 1, 2016 Swinburne University of Technology
G. Fairhurst
University of Aberdeen
June 30, 2015

TCP Alternative Backoff with ECN (ABE)


This memo updates the TCP sender-side reaction to a congestion notification received via Explicit Congestion Notification (ECN). The updated method is less conservative than the TCP reaction in response to loss. The intention is to achieve good throughput when the queue at the bottleneck is smaller than the bandwidth-delay-product of the connection. This is more likely when an Active Queue Management (AQM) mechanism has ECN-marked a packet than when a packet was lost. Future versions of this document will discuss SCTP as well as other transports using ECN.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 1, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Explicit Congestion Notification (ECN) is specified in [RFC3168]. This allows a network device that uses Active Queue Management (AQM) to CE-mark rather than drop ECN-capable packets when incipient congestion is detected.

When an ECN-capable transport is used over a path that supports ECN, it provides the opportunity for flows to improves their performance in the presence of incipient congestion [I-D.AQM-ECN-benefits].

[RFC3168] not only specifies the router use of the ECN field, it also specifies a TCP procedure for using ECN. This states that a TCP sender should treat the ECN indication of congestion in the same way as that of a non-ECN-Capable TCP flow experiencing loss, by halving the congestion window "cwnd" and by reducing the slow start threshold "ssthresh". [RFC5681] stipulates that TCP congestion control sets "ssthresh" to max(FlightSize / 2, 2*SMSS) in response to packet loss. Consequently, a non-ECN enabled standard TCP flow using this reaction needs significant queue space: it can only fully utilize a bottleneck when the length of the link queue (or the AQM dropping threshold) is at least the bandwidth-delay product of the flow. CUBIC can fully utilize a link with a smaller queue because it multiplies the current cwnd with 0.8 in response to packet loss [ID.CUBIC] (since kernel version 2.6.25 (2008), the Linux implementation uses a value of 0.7). In case of a DropTail (FIFO) queue without AQM, this increases the risk of creating a standing queue [CODEL2012].

Devices implementing AQM should be the only source of marking for packets from ECN-capable senders. AQM mechanisms typically strive to maintain a small queue length, regardless of the bandwidth-delay product of a flows passing through them. Receipt of a CE-mark therefore indicates that reacting less conservatively would be appropriate.

Results reported in [ABE-paper] show significant benefits (improved throughput, resulting in reduced completion times for short flows) when reacting to ECN-Echo by multiplying cwnd and sstthresh with a value in the range [0.7..0.85] rather than 0.5.

2. Updating the Sender-side ECN Reaction

This document specifies an updated TCP reaction to the receipt of CE-marked packets.

The first paragraph of Section 6.1.2, "The TCP Sender", in [RFC3168] contains the following text:

"If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non- ECN-Capable TCP. That is, the TCP source halves the congestion window 'cwnd' and reduces the slow start threshold 'ssthresh'."

This memo updates this text to:

"If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should induce a less conservative reaction than loss: the TCP source multiplies the congestion window 'cwnd' with 0.8 and reduces the slow start threshold 'ssthresh'."

3. Acknowledgements

The authors were part-funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the authors.

The authors would like to thank the following people for their contributions to [ABE-paper]: Chamil Kulatunga, David Ros, Stein Gjessing, Sebastian Zander.

4. IANA Considerations


This memo includes no request to IANA.

5. Security Considerations

This document describes a change to TCP congestion control that can make a TCP sender more aggressive than flows using RFC 3819. This could lead to an unfair allocation in rates at a bottleneck. Similar unfairness is also exhibited by other congestion control mechanisms that have been in use in the Internet for many years (e.g. Cubic [ID.CUBIC]).

XXX This section to be completed XXX.

6. References

6.1. Normative References

[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.

6.2. Informative References

[ABE-paper] Khademi, N., Welzl, M., Armitage, G., Kulatunga, C., Ros, D., Fairhurst, G., Gjessing, S. and S. Zander, "Alternative Backoff: Achieving Low Latency and High Throughput with ECN and AQM", CAIA technical report CAIA-TR-150710A, July 2015, NOTE: this document may not be available at draft submission date. We will do our best to make it available as soon as possible, and definitely before IETF-93
[CODEL2012] Nichols, K. and V. Jacobson, "Controlling Queue Delay", July 2012.
[I-D.AQM-ECN-benefits] Fairhurst, G. and M. Welzl, "The Benefits of using Explicit Congestion Notification (ECN)", Internet-draft, IETF work-in-progress draft-ietf-aqm-ecn-benefits-05, June 2015.
[ID.CUBIC] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L. and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", Internet-draft, IETF work-in-progress draft-ietf-tcpm-cubic-00, June 2015.

Authors' Addresses

Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo, N-0316 Norway EMail:
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo, N-0316 Norway EMail:
Grenville Armitage Centre for Advanced Internet Architectures Swinburne University of Technology PO Box 218 John Street, Hawthorn Victoria, 3122 Australia EMail:
Godred Fairhurst University of Aberdeen School of Engineering, Fraser Noble Building Aberdeen, AB24 3UE UK EMail: