Internet DRAFT - draft-sallantin-iccrg-initial-spreading

draft-sallantin-iccrg-initial-spreading



 



INTERNET-DRAFT                                               R.Sallantin
Intended Status: Proposed Standard                         CNES/TAS/TESA
Expires: September 13, 2014                                    C.Baudoin
                                                                 F.Arnal
                                                     Thales Alenia Space
                                                                E.Dubois
                                                                    CNES
                                                                E.Chaput
                                                                A.Beylot
                                                                    IRIT
                                                          March 12, 2014


               Safe increase of the TCP's Initial Window
                        Using Initial Spreading
               draft-sallantin-iccrg-initial-spreading-01


Abstract

   This document proposes a new fast start-up mechanism for TCP that can
   be used to speed the beginning of an Internet connection and then
   improved the short-lived TCP connections performance. 

   Initial Spreading allows to safely increase the Initial Window size
   in any cases, and notably in congested networks.

   Merging the increase in the IW with the spacing of the segments
   belonging to the Initial Window (IW), Initial Spreading is a very
   simple mechanism that improves short-lived TCP flows performance and
   do not deteriorate long-lived TCP flows performance.


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

 


Sallantin, et al.        Expires September 2014                 [Page 1]

INTERNET DRAFT             Initial spreading              March 12, 2014


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3  Initial Spreading mechanism . . . . . . . . . . . . . . . . . .  4
   4  Spreading Time Choice . . . . . . . . . . . . . . . . . . . . .  5
     4.1  Considerations  . . . . . . . . . . . . . . . . . . . . . .  5
     4.2  Burst impact on losses  . . . . . . . . . . . . . . . . . .  5
     4.3  Tmax  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.4  Algorithm . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5  Implementation considerations . . . . . . . . . . . . . . . . .  6
     5.1  Timers  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2 Pacing in AQM  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3  TSO/GSO . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.4  Delayed Ack . . . . . . . . . . . . . . . . . . . . . . . .  7
   6  Open discussions  . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1  Increasing the upper bound TCP's IW to more than 10
          segments  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2  Initial Spreading and LFN . . . . . . . . . . . . . . . . .  8
   7  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2  Informative References  . . . . . . . . . . . . . . . . . .  9
 


Sallantin, et al.        Expires September 2014                 [Page 2]

INTERNET DRAFT             Initial spreading              March 12, 2014


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10



1  Introduction

   Whether due to a long delay (e.g. Long Fat Networks) or a large
   queuing latency, a long Round Trip Time (RTT) deteriorates regular
   slow-start performance. This particularly impacts the short-lived
   connections[FA11]. Several protocols and even new network
   architectures have been proposed to deal with this issue. 

   The original idea of Initial Spreading [SB13] was to consider a long
   RTT as a resource to exploit, rather than as a constant to bypass. As
   soon as the RTT is larger than a few milliseconds, it can therefore
   be used as an opportunity to safely send a large amount of data
   during the first RTT after the connection has opened. Spacing the
   data along the RTT would in fact hopefully guarantee a high
   independent probability that each segment is successfully received.

   This approach resembles a combination of 2 TCP mechanisms: Pacing and
   Increase in the Initial Window. Both mechanisms have then been
   studied in depth to design Initial Spreading as an efficient fast
   start-up TCP mechanism, and notably avoid their respective flaws or
   weaknesses.

   The original Pacing idea is to space the segments of a same window
   along an RTT to prevent generating bursts as far as possible. Hence,
   each segment arrives separately at the buffer and the impact on its
   queue is minimized. The bit rate can then reach its maximum. However,
   [AS00] has pointed out that this lack of bursts is responsible for
   poor performance. Pacing has a tendency to overload the network, and
   then cause a synchronization of the flows, that seriously damages
   both individual and global performance. 

   RFC 6928 [RFC6928] suggests to enlarge the IW size up to ten
   segments. Several articles and studies demonstrated that this would
   allow transmission of 90% of the connections in one RTT [DR10]. In
   most cases, and when the network is not congested in particular, this
   solution is probably the best one for dealing with short-lived TCP
   flows. However, in a congested environment, sending a large IW in one
   burst is likely to impact the buffers and then deteriorate the
   individual connection. Correlation between the segments of a same
   burst is responsible for major impairments when regarding the short-
   lived connections, and in particular for the connections that can be
   sent in one RTT (number of segments to be transmitted inferior to the
   upper bound value of the TCP's IW):

 


Sallantin, et al.        Expires September 2014                 [Page 3]

INTERNET DRAFT             Initial spreading              March 12, 2014


   o  a decrease of the probability to successfully transmit the entire
      window.

   o  an increase of the probability of successive segment losses.

   o  a significant reduction of the number of potential Duplicated
      Acknowledgements that are necessary to trigger fast loss recovery
      mechanisms and avoid to wait for a Retransmission Time Out. 
      For the peculiar case of short-lived connections,  experiments
      have shown that the loss of one segment of the Initial burst could
      not be recovered using Recovery mechanisms.

   In favor of a conservative approach, [RFC3390] recommended the use of
   an IW equal to 3.

   Both mechanisms therefore suffer from a burst-related phenomenon, but
   in opposite ways.

   Initial Spreading has been designed to tackle previous burst issues.
   Simulations and experimentations show that Initial Spreading is not
   only efficient in case of LFNs but also for other networks with small
   RTT.


2  Terminology

   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 RFC 2119 [RFC2119].


3  Initial Spreading mechanism

   Initial Spreading [SB13] mechanism uses  the permitted upper bound
   value of the TCP's IW (e.g; RFC 6928 [RFC6928] suggests to use 10 for
   this value). Initial Spreading spaces out a number of segments
   inferior or equal to this value across the first RTT before letting
   the TCP algorithm continue conventionally:

   (1) The RTT is measured during the SYN-SYN/ACK exchange.

   (2) According to the RTT value, a Spreading Time (Tspreading) is
       computed (cf. section 5). Depending on the number of segments to
       be sent, until n segments are sent every Tspreading.  

   (3) After the transmission of the IW, the regular TCP algorithm is
       used.

 


Sallantin, et al.        Expires September 2014                 [Page 4]

INTERNET DRAFT             Initial spreading              March 12, 2014


   Thus, bursts do not downgrade the transmission of short-lived
   connections, but continue to prevent an overload of the network in
   the case of long-lived connections. 

4  Spreading Time Choice

4.1  Considerations

   It has been observed that most of the savings enabled by the Initial
   Spreading in congested environments comes from the independence of
   the segments sent during the first RTT. Indeed, experimentations have
   shown that preventing the bursts, Initial Spreading enables each
   segment of the IW to have an independent loss probability. 

   This reduces the latency variance and then, the average latency. But,
   precautions should be taken to not deteriorate the performance in un-
   congested network.

   To be efficient, Initial Spreading should therefore take the best of
   several constraints:

   o  Tspreading MUST be large enough for the losses to be un-
      correlated.

   o  Tspreading SHOULD be the shortest possible to not add an un-
      necessary delay (notably in un-congested network).

   o  Implementation MUST be light and respects Kernel constraints.

4.2  Burst impact on losses

   It has been observed that 2 segments are belonging to one burst if
   they do encounter the same bottleneck buffer state, and that the
   minimal spreading depends on the bottleneck throughput. Segments
   spread with Tspreading < BottleneckThroughput/MSS will face the same
   buffer state, and then will not be spread enough for the losses to be
   un-correlated.

4.3  Tmax

   Tmax is the upper bound value of Tspreading. It has two main
   purposes:

   o  it enables Initial Spreading to be not dependent of the RTT
      measurement. This last introduces some uncertainty in the
      mechanism and increases the latency variance. 

   o  it reduces the mean latency.
 


Sallantin, et al.        Expires September 2014                 [Page 5]

INTERNET DRAFT             Initial spreading              March 12, 2014


   Tmax's choice results then in a trade-off. Indeed, a larger Tmax
   would enable the Initial Spreading to be efficient with lower
   bottleneck throughput (cf. section 4.2), when a lower value would
   reduce the impact of the Initial Spreading on un-congested networks,
   but also decreased the benefits of the Initial Spreading. 
   In case Tspreading would not be large enough to insure a loss
   independence, Initial Spreading does not introduce additional delay
   but performs in a similar way than RFC6928. 

   The authors RECOMMEND the use of a Tmax equal to 2 ms. This value
   enables to enhance the performance of network with a bit-rate greater
   than 6 Mb/s, and introduces a maximal additional latency of 2*n ms.  


4.4  Algorithm

   Tspreading is computed as follows:

          1. RTT/n is compared to Tmax, the maximal value of spreading,
          with n the permitted upper bound value of the TCP's IW.
          2. If RTT/IW < Tmax,
                    Tspreading = RTT/IW
          3. If RTT/IW >= Tmax,
                    Tspreading = Tmax




5  Implementation considerations

   In this section, we discuss a number of aspects surrounding the
   Initial Spreading implementations.

5.1  Timers

   High resolution timers MUST be used instead of Jiffy timers to
   implement the Initial Spreading.

   Using a jiffy timer may therefore result in the transmission of new
   bursts and reduce Initial Spreading benefits: emissions of multiple
   TCP flows are synchronized via the Jiffies timer, so when m parallel
   flows are sent, a burst of m segments may be transmitted.

   Finally, using HRTimer enables to keep the Initial Spreading
   algorithm simple (cf. section 4.4), and notably to not use a lower
   bound value for Tspreading. 

5.2 Pacing in AQM
 


Sallantin, et al.        Expires September 2014                 [Page 6]

INTERNET DRAFT             Initial spreading              March 12, 2014


   The authors RECOMMEND to apply the pacing in the Active Queue
   Management (AQM). This would enable to reduce the overload in the TCP
   stack.


5.3  TSO/GSO

   TSO/GSO is used to reduce the CPU overhead of TCP/IP on fast
   networks. Instead of doing the segmentation in the kernel, large
   packets are sent to the Network Interface Card (NIC). The
   segmentation is then achieved by the NIC or just before the entry
   into the driver's xmit routine.

   In its current design, Initial Spreading is not working when TSO or
   GSO are activated, but using Initial Spreading with an inactive
   TSO/GSO still enables better performance.

   Two options can be foreseen for the joint use of Initial Spreading
   and TSO/GSO:

   (1) disable TSO/GSO for the first RTT, with no impact on performance
       since the throughput is limited by the IW. 

   (2) implement Initial Spreading using the TCP Offload Engine (TOE)
       [RFC5522].



5.4  Delayed Ack

   The use of Delayed Ack (Del Ack) does not downgrade Initial Spreading
   efficiency.

   Regarding long-lived connections and notably TCP's steady state, the
   effects of Del Ack are lessened by new TCP's flavors (such as TCP
   Cubic or Compound TCP [HR08][TS06]) which tend to adapt their
   congestion algorithm to take into account whether the receiver uses
   the Del Ack option or not. In doing so, they can prevent the
   connection from being too slow, and still continue to reduce
   acknowledgments traffic. In the event of short-lived connections, the
   use of Del Ack does not modify the transmission of the IW. There is
   then no change in the burst propagation. 


6  Open discussions

   In this section, we introduce possible improvements for Initial
   Spreading and new perspectives. 
 


Sallantin, et al.        Expires September 2014                 [Page 7]

INTERNET DRAFT             Initial spreading              March 12, 2014


6.1  Increasing the upper bound TCP's IW to more than 10 segments

   [DR10] have shown that an IW of 10 segments enables to send more than
   90% of the web objects in one RTT. So the authors recommend to use
   Initial Spreading as a complement to [RFC6928].

   If the average size of the web objects continues to evolve, Initial
   Spreading can be used to raise the IW size. Simulations and
   experiments showed even better results with an IW equal to 12.

   Thus, Initial Spreading paves the way for larger IW. Further studies
   are  needed to assess the impact on the networks, notably in terms of
   individual performance, fairness, friendliness and global
   performance.

6.2  Initial Spreading and LFN

   The space community designed middleboxes to mitigate poor TCP
   performance for network with large RTT [FA11]. Proxy Enhancement
   Performance (PEP) are generally used in LFN and in particular in
   satellite communication systems [RFC3135] and offer very good TCP
   performance.

   Nevertheless, some recent studies have emphasized major impairments
   occasioned by the use of satellite-specific transport solutions, and
   notably TCP-PEPs, in a global context. The break of the end-to-end 
   TCP semantic, which is required to isolate the satellite segment, is
   notably responsible for an increased complexity in case of mobility
   scenarios or security context. This strongly mitigates PEPs benefits
   and reopens the debate on their relevance[DC10].

   Many researchers have outlined that new TCP releases perform well for
   long-lived TCP connections, even in satellite environment [SC12], but
   continue to suffer from very poor performance in case of short-lived
   TCP connections.

   Initial Spreading enables to reduce the RTT consequences for short-
   lived TCP connections and could be an end-to-end alternative to PEP.

7  Security Considerations

   The security considerations found in [RFC5681] apply to this
   document.  No additional security problems have been identified with
   Initial Spreading at this time. 


8  IANA Considerations

 


Sallantin, et al.        Expires September 2014                 [Page 8]

INTERNET DRAFT             Initial spreading              March 12, 2014


   This document contains no IANA considerations.


9  References

9.1  Normative References

   [RFC3390] A. Allman and S. Floyd, "Increasing tcp's initial window,"
              RFC 3390, IETF, Proposed Standard, 2002.

   [RFC5532] T. Talpey, C. Juszczak, "Network File System (NFS) Remote
              Direct Memory Access (RDMA) Problem Statement," RFC 5532,
              IETF, Informational, May 2009.

   [RFC6928] J. Chu, N. Dukkipati, Y. Cheng, and M. Mathis, "Increasing
              tcp's initial window," RFC 6928, IETF, Experimental, Jan.
              2013.

   [AH98] A. Allman, C. Hayes, and S. Ostermann, "An evaluation of TCP
              with Larger Initial Windows," ACM Computer Communication
              Review, 1998.

   [AS00] A. Aggarwal, S. Savage, and T. Anderson, "Understanding the
              performance of TCP pacing," in INFOCOM, vol. 3, mar 2000,
              pp. 1157-1165.

   [DR10] N. Dukkipati, T. Refice, Y. Cheng, J. Chu, T. Herbert, A.
              Agarwal, A. Jain, and N. Sutin, "An Argument for
              Increasing TCP's Initial Congestion Window," SIGCOMM
              Comput. Commun. Rev., vol. 40, no. 3, pp. 26-33, Jun.
              2010.

   [SB13] R. Sallantin, C. Baudoin, E. Chaput, E. Dubois, F. Arnal, and
              A. Beylot, "Initial spreading: a fast start-up tcp
              mechanism," proceedings of LCN, 2013.

9.2  Informative References

   [RFC3135] J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby,
              "Performance Enhancing Proxies Intended to Mitigate Link-
              Related Degradations," RFC 3135, IETF, Informational, June
              2001.

   [DF10] E. Dubois, J. Fasson, C. Donny, and E. Chaput, "Enhancing tcp
              based communications in mobile satellite scenarios: Tcp
              peps issues and solutions," in Proc. 5th Advanced
              satellite multimedia systems conference (asma) and the
              11th signal processing for space communications workshop
 


Sallantin, et al.        Expires September 2014                 [Page 9]

INTERNET DRAFT             Initial spreading              March 12, 2014


              (spsc), pages 476-483, 2010.

   [FA11] A. Fairhurst, G. Arjuna, H. Cruickshank, and C. Baudoin,
              "Transport challenges facing a next generation hybrid
              satellite internet," in International Journal of Satellite
              Communications and networking,  2011.

   [HR08] S. Ha, I. Rhee, and L. Xu, "CUBIC: A New TCP-Friendly High-
              Speed TCP Variant," SIGOPS Oper. Syst. Rev., vol. 42, no.
              5, pp. 64-74, Jul. 2008.

   [LC09] R. Lacamera, D. Caini, C. Firrincieli, "Comparative
              performance evaluation of tcp variants on satellite
              environments," in ICC'09 Proceedings of the 2009 IEEE
              international conference on Communications, pages Pages
              5161-5165, 2009.

   [SC12]  R. Sallantin, E. Chaput, E. P. Dubois, C. Baudoin, F. Arnal,
              and A.-L.Beylot, "On the sustainability of PEPs for
              satellite Internet access," in ICSSC. AIAA, 2012.

   [TS06] K. Tan, J. Song, Q. Zhang, and M. Sridharan, "Compound TCP: A
              Scalable and TCP-friendly Congestion Control for High-
              speed Networks,"  in 4th International workshop on
              Protocols for Fast Long-Distance Networks (PFLDNet), 2006.


Authors' Addresses

   Comments are solicited and should be addressed to the working group's
   mailing list at iccrg@irtf.org and/or the authors:


   Renaud Sallantin
   CNES/TAS/TESA
   IRIT/ENSEEIHT 2, rue Charles Camichel BP 7122
   31071 Toulouse Cedex 7
   France
   Phone: +33 6 48 07 86 44
   Email: renaud.sallantin@gmail.com


   Cedric Baudoin
   Thales Alenia Space (TAS)
   26 Avenue Jean Francois Champollion,
   31100 Toulouse
   France
   Email: cedric.baudoin@thalesaleniaspace.com
 


Sallantin, et al.        Expires September 2014                [Page 10]

INTERNET DRAFT             Initial spreading              March 12, 2014


   Fabrice Arnal
   Thales Alenia Space 	
   Email: fabrice.arnal@thalesaleniaspace.com


   Emmanuel Dubois
   Centre National des Etudes Spatiales (CNES)
   18 Avenue Edouard Belin
   31400 Toulouse
   France
   Email: emmanuel.Dubois@cnes.Fr


   Emmanuel Chaput
   IRIT
   IRIT / ENSEEIHT 2, rue Charles Camichel BP 7122
   31071 Toulouse Cedex 7
   France
   Email: emmanuel.chaput@enseeiht.fr


   Andre-Luc Beylot
   IRIT	
   Email: andre-Luc.Beylot@enseeiht.fr



























Sallantin, et al.        Expires September 2014                [Page 11]