TCP Low Latency Option

Document Type Active Internet-Draft (individual)
Last updated 2017-06-08
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
TCP Maintenance Working Group                                    W. Wang
Internet-Draft                                               N. Cardwell
Intended status: Experimental                                   Y. Cheng
Expires: December 10, 2017                                    E. Dumazet
                                                             Google, Inc
                                                            June 8, 2017

                         TCP Low Latency Option


   This document specifies the TCP Low Latency option, which TCP
   connections can use during the connection establishment handshake to
   communicate extra parameters that can improve performance in low-
   latency environments.  With the first such parameter, a TCP data
   receiver can advertise a hint about the Maximum ACK Delay (MAD) it
   will schedule for its own delayed ACK mechanism.  This enables the
   TCP data sender to achieve lower latencies during loss recovery by
   using the Maximum ACK Delay advertised by the remote receiver to help
   compute retransmission timeouts that are potentially much lower than
   would otherwise be feasible.  The Low Latency option is extensible,
   and later versions of this draft will introduce other mechanisms,
   including TCP timestamps with a finer granularity than those
   supported by RFC 7323.

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 December 10, 2017.

Wang, et al.            Expires December 10, 2017               [Page 1]
Internet-Draft                     LL                          June 2017

Copyright Notice

   Copyright (c) 2017 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.

1.  Introduction

   TCP receivers typically implement a delayed ACK algorithm, as
   specified in [RFC1122] Sec; as summarized in [RFC5681] sec
   4.2, "an ACK SHOULD be generated for at least every second full-sized
   segment, and MUST be generated within 500 ms of the arrival of the
   first unacknowledged packet."  In practice, many widely-deployed
   implementations have tended to delay ACKs by up to roughly 200ms.
   This is probably a historical artifact inherited from the 200ms "fast
   timeout" mechanism in the BSD TCP implementation from the late 1980s

   As a result, to avoid spurious timeouts due to delayed ACKs, widely-
   deployed TCP sender implementations have adapted to this delayed ACK
   behavior by constraining retransmission timeout (RTO) values to be at
   least 200ms.

   Unfortunately, this 200ms value is 2000x the typical RTT of today's
   commodity datacenter networks (which are typically below 100
   microseconds).  So senders constraining RTOs to be at least 200ms are
   paying a latency penalty much higher than the RTT in such

   The TCP Low Latency option enables a TCP data receiver to advertise a
   hint about the Maximum ACK Delay (MAD) it will schedule for its own
   delayed ACK mechanism.  The receiver specifies the MAD value in the
   Low Latency option because the value that is feasible can be quite
   different for different receivers, based on the CPU's speed, CPU and
   network workloads, and OS-specific constraints on minimum supported
   timer granularity.

   This Low Latency option enables the TCP data sender to achieve lower
   latencies during loss recovery by using the Maximum ACK Delay

Wang, et al.            Expires December 10, 2017               [Page 2]
Internet-Draft                     LL                          June 2017
Show full document text