TCP Alternative Backoff with ECN (ABE)
draft-khademi-alternativebackoff-ecn-00

Abstract

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 http://datatracker.ietf.org/drafts/current/.

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 (http://trustee.ietf.org/license-info) 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
• 2. Updating the Sender-side ECN Reaction
• 3. Acknowledgements
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

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

XX RFC ED - PLEASE REMOVE THIS SECTION XXX

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

6.2. Informative References

Authors' Addresses