[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

TSVWG Working Group                                               L. Han
Internet-Draft                                                     Y. Qu
Intended status: Experimental                                     Huawei
Expires: September 4, 2018                                     T. Nadeau
                                                            Lucid Vision
                                                           March 3, 2018


        A New Congestion Control in Bandwidth Guaranteed Network
                         draft-han-tsvwg-cc-00

Abstract

   In bandwidth guaranteed networks, network resources are reserved
   before a TCP session starts transmitting data.  This draft proposes a
   new TCP congestion control algorithm used in bandwidth guaranteed
   networks.  It is an extension to the current TCP standards.

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 https://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 September 4, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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




Han, et al.             Expires September 4, 2018               [Page 1]


Internet-Draft           New Congestion Control               March 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   3
   3.  Bandwidth Guaranteed Network  . . . . . . . . . . . . . . . .   4
   4.  New Congestion Control  . . . . . . . . . . . . . . . . . . .   5
     4.1.  Receiver Advertised Window Size . . . . . . . . . . . . .   5
     4.2.  MinBandwidthWND and MaxBandwidthWND . . . . . . . . . . .   5
     4.3.  Congestion Avoidance  . . . . . . . . . . . . . . . . . .   6
     4.4.  Fast Retransmit and Fast Recovery . . . . . . . . . . . .   7
     4.5.  Timeout . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.6.  Idle Recovery . . . . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The original IP protocol suite was designed to support best-effort
   data transmission.  With the development of the Internet, congestion
   became a real problem.  To avoid congestion in the Internet, TCP uses
   congestion-avoidance algorithms to keep hosts from pumping too much
   traffic into the network.  Over the past 40 years there have been
   various algorithms and optimizations proposed to solve this problem,
   including TCP-RENO [RFC5681], TCP-NewReno [RFC6582] [RFC6675], TCP-
   Cubic [RFC8312] and BBR [I-D.cardwell-iccrg-bbr-congestion-control]
   etc.

   In bandwidth guaranteed networks, network resources are reserved
   before transmitting data.  This draft proposes a new congestion
   control algorithm that should be used in bandwidth guaranteed
   networks to improve TCP throughput.  The following is a list of key
   differences between this new algorithm and classic TCP congestion
   control [RFC5681]:

      It doesn't have a slow start, after a TCP session is successfully
      initiated its congestion window (cwnd) jumps to CIR and the host
      is allowed to transmit data.  This is based on the assumption that
      network resources have been reserved in bandwidth guaranteed
      networks.




Han, et al.             Expires September 4, 2018               [Page 2]


Internet-Draft           New Congestion Control               March 2018


      During congestion avoidance, cwnd stays between CIR (Committed
      Information Rate) and PIR (Peak Information Rate).  If there is no
      packet loss due to congestion, cwnd has a flat top rate as PIR.

      OAM is used together with duplicate ACKs to detect whether a
      packet loss is due to congestion or random failure.

   This draft is organized as follows.  Section 2 defines terminologies
   used in this draft.  Section 3 provides background information for
   Bandwidth Guaranteed Networks.  Section 4 explains the details of the
   new congestion control algorithm.

2.  Terminology and Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Some of the following terms are defined the same as [RFC5681], and
   they are copied here for readability.

      FULL-SIZED SEGMENT: A segment that contains the maximum number of
      data bytes permitted (i.e., a segment containing SMSS bytes of
      data).

      RECEIVER WINDOW (rwnd): The most recently advertised receiver
      window.

      CONGESTION WINDOW (cwnd): A TCP state variable that limits the
      amount of data a TCP can send.  At any given time, a TCP MUST NOT
      send data with a sequence number higher than the sum of the
      highest acknowledged sequence number and the minimum of cwnd and
      rwnd.

      Sender Maximum Segment Size (SMSS): The SMSS is the size of the
      largest segment that the sender can transmit.  This value can be
      based on the maximum transmission unit of the network, the path
      MTU discovery [RFC1191, RFC4821] algorithm, RMSS (see next item),
      or other factors.  The size does not include the TCP/IP headers
      and options.

      RECEIVER MAXIMUM SEGMENT SIZE (RMSS): The RMSS is the size of the
      largest segment the receiver is willing to accept.  This is the
      value specified in the MSS option sent by the receiver during
      connection startup.  Or, if the MSS option is not used, it is 536
      bytes [RFC1122].  The size does not include the TCP/IP headers and
      options.




Han, et al.             Expires September 4, 2018               [Page 3]


Internet-Draft           New Congestion Control               March 2018


      INITIAL WINDOW (IW): The initial window is the size of the
      sender's congestion window after the three-way handshake is
      completed.

      RESTART WINDOW (RW): The restart window is the size of the
      congestion window after a TCP restarts transmission after an idle
      period.

      ssthresh: Slow Start Threshold.

      OAM: Operations, Administrations, and Maintenance.

      RTT: Round-Trip Time.

      CIR: Committed Information Rate.

      PIR: Peak Information Rate.

3.  Bandwidth Guaranteed Network

   With the development of new applications, such as AR/VR, the network
   is required to provide bandwidth guaranteed services.  There have
   been various solutions, including out-of-band signaling protocols
   such as RSVP [RFC2205] and NSIS [RFC4080], and in-band-signaling as
   proposed in [I-D.han-6man-in-band-signaling-for-transport-qos].  The
   common objective of all these solutions is to have network resources/
   bandwidth reserved before data is transmitted.  The details of how
   the resource is reserved are out of the scope of this draft, however
   it is assumed that in bandwidth guaranteed networks there have been
   network resources (bandwidths, queues etc.) dedicated to the TCP
   flows, and data is guaranteed at CIR rate.  When data rate is between
   CIR and PIR shared resources are used, and traffic above CIR rate is
   not guaranteed.  No traffic above PIR rate will be allowed to enter
   the network.

   The proposed congestion control also requires that OAM (Operations,
   administration and management) is used to constantly report on the
   network condition parameters.  Before a TCP session is started,
   important network parameters need to be detected by OAM, such as
   number of hops, Round Trip Time (RTT).  This might be done through
   setting up a measuring TCP connection.  The measuring TCP connection
   does not have user data, and it is only used to measure the key
   network parameters.  As the network status is constantly changing,
   after a TCP session is established, these parameters need to be
   updated.  This requires a sender to periodically or consistently
   embed TCP data packet with OAM
   [I-D.han-6man-in-band-signaling-for-transport-qos]
   [I-D.ietf-ippm-ioam-data] to detect current buffer depth, RTT etc.



Han, et al.             Expires September 4, 2018               [Page 4]


Internet-Draft           New Congestion Control               March 2018


   It is important that OAM needs to be able to detect if any device's
   buffer depth has exceeded the pre-configured threshold, as this is an
   indication of potential congestion and packet drop.  When this
   happens, OAM should send a possible congestion alarm to the TCP
   sender.  In case the retransmit timer expires on this TCP sender, if
   a possible congestion alarm has been received it means a packet is
   dropped due to congestion.  Otherwise it is possible that this packet
   drop might due to some physical failure.  The OAM details are out of
   the scope of this draft.  Please refer to other related drafts.

   In summary, in bandwidth guaranteed networks resources are reserved
   before transmitting data, and OAM is used to get network statistics.
   The new congestion control proposed in this draft is to be used in
   this kind of bandwidth guaranteed networks.

4.  New Congestion Control

   [RFC5681] defines a set of TCP congestion algorithms: slow start,
   congestion avoidance, fast retransmit and fast recovery.  The
   proposed congestion control in this draft is an extension to RFC
   5681, and it only differs in the congestion control algorithm on the
   sender side.

4.1.  Receiver Advertised Window Size

   Receiver's advertised window (rwnd) is a receiver-side limit on the
   amount of outstanding data, so a sender should not send data more
   than this window size.  It is calculated as the following:

     rwnd = AdvertisedWND = MaxRcvBuffer - (LastByteRcvd - LastByteRead)

4.2.  MinBandwidthWND and MaxBandwidthWND

   Same as [RFC5681], on the sender side, the congestion window (cwnd)
   is the sender-side limit on the amount of data that the sender can
   transmit before receiving an acknowledgement (ACK).  Considering both
   the sender and the receiver side, the effective sending window is
   always the minimum of cwnd and rwnd:

      EffectiveWND = min(cwnd, rwnd)

   A TCP sender MUST NOT send data more than the minimum of cwnd and
   rwnd.

   Slow-start is commonly used in TCP at the beginning of a transfer or
   after a loss repair as the network conditions are unknown, hence this
   slow probing is necessary to determine the available network capacity
   in order to avoid inappropriately sending large burst of data into



Han, et al.             Expires September 4, 2018               [Page 5]


Internet-Draft           New Congestion Control               March 2018


   the network and cause congestion.  A detailed discussion about
   initial window setting is provided in [RFC3390].

   RTT is the time taken to send a packet to the destination plus
   receiving a response packet(ACK).  Since the network status is
   constantly changing, RTT also varies.  [RFC6298] specifies how RTT
   should be sampled and updated.  In this new algorithm RTT is updated
   using the following formula:

      RTT = a* old RTT + (1-a) * new RTT   (0 < a < 1)   (1)

   The initial RTT can be achieved using a measure TCP connection, or
   configured based on historical data.

   In bandwidth guaranteed network since resources are already allocated
   and the network status is known through OAM
   [I-D.han-6man-in-band-signaling-for-transport-qos], it is safe to
   remove slow-start and allow a host to start sending traffic at the
   rate of CIR after the TCP session is established.

   There are two important window sizes, the MinBandwidthWND and the
   MaxBandwidthWND are calculated as below:

      MinBandwidthWND = CIR * RTT/MSS    (2)
      MaxBandwidthWND = PIR * RTT/MSS    (3)

   In bandwidth guaranteed networks, after a TCP session is established,
   the sender can start transmitting data at an initial window size,
   which is equal to MinBandwidthWND:

      cwnd = MinBandwidthWND
      IW = min (cwnd, rwnd)

   If the receiver window (rwnd) is not a limiting factor, the sender
   will start sending data at CIR rate.  This is a key difference from
   the classic TCP slow-start, which usually starts from sending one or
   two packets [RFC5681].

4.3.  Congestion Avoidance

   In TCP-Reno, a TCP enters congestion avoidance mode after slow-start.
   In bandwidth guaranteed networks, there is no slow-start, so a TCP
   enters congestion avoidance mode right after the initial start.

   During congestion avoidance, for approximately per round-trip time
   when a valid ACK packet is received, cwnd is increased by one until
   it reaches MaxBandwidthWND.




Han, et al.             Expires September 4, 2018               [Page 6]


Internet-Draft           New Congestion Control               March 2018


     If (cwnd < MaxBandwidthWND) {
       cwnd +=1;
     } else {
       cwnd = MaxBandwidthWND;
     }

   Once the cwnd reaches MaxBandwidthWND , it stays constant at
   MaxBandwidthWND until packet loss is detected.  This is another major
   difference from [RFC5681].  In [RFC5681] congestion avoidance period,
   the cwnd keeps increasing until a TCP sender detects segment loss.
   However, in this new congestion control algorithm, the cwnd stays
   constant at MaxBandwidthWND until there is packet loss detected.

   This means a TCP sender is never allowed to send data at a rate
   larger than PIR, and it's different from TCP Reno.

4.4.  Fast Retransmit and Fast Recovery

   Same as defined [RFC5681], a TCP receiver SHOULD send an immediate
   duplicate ACK when an out-of-order segment arrives.  The TCP sender
   detects and repair loss based on incoming duplicate ACKs.  If 3
   duplicate ACKs are received, the sender uses it as an indication that
   a segment has been lost, and will perform a retransmission of the
   lost segment.

   In TCP-Reno [RFC5681], after the fast retransmit of what appears to
   be the lost segment, fast recovery is used to continue to transmit
   new segments at a reduced rate ssthresh.

   In the new congestion control algorithm, upon receiving duplicate
   ACKs the fast retransmit and fast recovery follow the below rules:

   o  When a sender receives the first and second duplicate ACKs, same
      as [RFC5681], the cwnd is not changed, and the sender continues to
      send traffic.

   o  When a sender receives the third duplicated ACK, if the
      retransmission timer has not expired and a previous OAM congestion
      alarm has been received it is likely a segment is lost due to
      congestion.  The sender will perform a retransmission of the lost
      segment, and the cwnd is set to be MinBandwidthWND.

   o  When a sender receives the third duplicated ACK, but no previous
      OAM congestion alarm has been received, then it is considered that
      a segment is lost due to random failure not congestion.  In this
      case the cwnd is not changed.





Han, et al.             Expires September 4, 2018               [Page 7]


Internet-Draft           New Congestion Control               March 2018


   Compared to [RFC5681], where in case of network congestion the new
   cwnd is set to be ssthresh, which is usually half of the old cwnd.
   In this new congestion control, in case there is a segment loss
   detected as described above, the new cwnd is set to be MinBandwithWND
   as in equation (2).

4.5.  Timeout

   If a retransmission timer [RFC6298] in a TCP sender expires, in
   bandwidth guaranteed networks no matter duplicate ACK received or
   not, this most likely indicates a physical failure.

   In this case, the cwnd is set to be one, and the TCP sender will
   retransmit the lost segment.  This packet also services the function
   of probing network status.  If there is really a network failure, no
   ACK will be received and the retransmission timer will expire again.
   Upon receiving an expected ACK after the retransmission, it means the
   network has recovered, and the cwnd will be set to be MinBandwidthWND
   as in equation (2).

4.6.  Idle Recovery

   It is defined in [RFC5681] that a TCP session should use slow start
   to restart transmission after a long idle period more than one
   retransmission timeout, and the RW (Restart Window) is the minimum of
   IW and cwnd.

   In this proposal, the same rule is still followed.  However due to
   the fact that there is no slow start needed in bandwidth guaranteed
   networks, and the IW in this new congestion control is set to be
   MinBandwidthWND, a TCP sender can start transmitting data at CIR rate
   after a long idle.

5.  IANA Considerations

   NA.

6.  Security Considerations

   This proposal makes no change to the underlying security of TCP.
   More information about TCP security concerns can be found in
   [RFC5681].

7.  References







Han, et al.             Expires September 4, 2018               [Page 8]


Internet-Draft           New Congestion Control               March 2018


7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC3390]  Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
              Initial Window", RFC 3390, DOI 10.17487/RFC3390, October
              2002, <https://www.rfc-editor.org/info/rfc3390>.

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, DOI 10.17487/RFC4080, June 2005,
              <https://www.rfc-editor.org/info/rfc4080>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <https://www.rfc-editor.org/info/rfc5681>.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,
              <https://www.rfc-editor.org/info/rfc6298>.

   [RFC6582]  Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
              NewReno Modification to TCP's Fast Recovery Algorithm",
              RFC 6582, DOI 10.17487/RFC6582, April 2012,
              <https://www.rfc-editor.org/info/rfc6582>.

   [RFC6675]  Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
              and Y. Nishida, "A Conservative Loss Recovery Algorithm
              Based on Selective Acknowledgment (SACK) for TCP",
              RFC 6675, DOI 10.17487/RFC6675, August 2012,
              <https://www.rfc-editor.org/info/rfc6675>.





Han, et al.             Expires September 4, 2018               [Page 9]


Internet-Draft           New Congestion Control               March 2018


   [RFC8312]  Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
              RFC 8312, DOI 10.17487/RFC8312, February 2018,
              <https://www.rfc-editor.org/info/rfc8312>.

   [I-D.cardwell-iccrg-bbr-congestion-control]
              Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,
              "BBR Congestion Control", draft-cardwell-iccrg-bbr-
              congestion-control-00 (work in progress), July 2017.

   [I-D.han-6man-in-band-signaling-for-transport-qos]
              Han, L., Li, G., Tu, B., Xuefei, T., Li, F., Li, R.,
              Tantsura, J., and K. Smith, "IPv6 in-band signaling for
              the support of transport with QoS", draft-han-6man-in-
              band-signaling-for-transport-qos-00 (work in progress),
              October 2017.

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields
              for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in
              progress), October 2017.




























Han, et al.             Expires September 4, 2018              [Page 10]


Internet-Draft           New Congestion Control               March 2018


Acknowledgments

   The authors wish to thank xxxx for their helpful comments and
   suggestions.

Authors' Addresses

   Lin Han
   Huawei
   2330 Central Expressway
   Santa Clara  CA 95050
   USA

   EMail: lin.han@huawei.com


   Yingzhen Qu
   Huawei
   2330 Central Expressway
   Santa Clara  CA 95050
   USA

   EMail: yingzhen.qu@huawei.com


   Thomas Nadeau
   Lucid Vision
   Hampton  NH 03842
   USA

   EMail: tnadeau@lucidvision.com




















Han, et al.             Expires September 4, 2018              [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/