INTERNET-DRAFT R.Sallantin Intended Status: Proposed Standard E.bouttier Expires: April 30, 2015 CNES/TAS/TESA C.Baudoin F.Arnal Thales Alenia Space E.Dubois CNES E.Chaput A.Beylot IRIT October 27, 2014 Safe increase of the TCP's Initial Window Using Initial Spreading draft-sallantin-tcpm-initial-spreading-00 Abstract This document proposes a new fast start-up mechanism to improve 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 does 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 April 2015 [Page 1] INTERNET DRAFT Initial spreading October 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Initial Spreading mechanism . . . . . . . . . . . . . . . . . . 4 4 Spreading Time design . . . . . . . . . . . . . . . . . . . . . 4 4.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Burst impact on losses . . . . . . . . . . . . . . . . . . 5 4.3 Tmax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 Implementation considerations . . . . . . . . . . . . . . . . . 6 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 Pacing in AQM . . . . . . . . . . . . . . . . . . . . . . . 6 5.3 Delayed Ack . . . . . . . . . . . . . . . . . . . . . . . . 7 6 Open discussions . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Increasing the upper bound TCP's IW to more than 10 segments . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2 Initial Spreading and LFN . . . . . . . . . . . . . . . . . 7 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Sallantin, et al. Expires April 2015 [Page 2] INTERNET DRAFT Initial spreading October 27, 2014 1 Introduction The increase in the Initial Window size is a key topic that keeps the IETF community active since many years. In order to best fit to the evolution of the Internet tendencies, it is thus frequently proposed to enlarge the IW size. Lately, [RFC6929] has therefore updated [RFC3390] and proposed an IW of 10 segments instead of 3. Several articles and studies have demonstrated that this small change would allow the transmission of 90% of the connections in one RTT [DR10]. If this is without any doubt the best way to deal with short-lived TCP flows in an un- congested environments, the consequences of the release of a large initial burst in a congested network is still an open question in the community. In [SB14], we showed that enlarging the IW impacts the buffers and then deteriorates the individual connection in a congested environment. Correlations between the segments sent in a same burst are therefore responsible for major impairments when regarding the short-lived connections: 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 not wait for a Retransmission Time Out. Moreover, regarding the peculiar case of the connections that could be sent in one RTT (number of segments to be transmitted inferior or equal to the upper bound value of the TCP's IW), experiments showed that the loss of one segment of the Initial burst could not be recovered using recovery mechanisms [SB14]. Initial Spreading has been designed to tackle previous burst issues and enable a safe increase in the Initial Window [SB13]. Initial Spreading uses the best of Pacing and Increase in the Initial Window [RFC6928] to enable the transmission of a large number of segments in the first RTT and ensure that each segment is received with a high independent probability. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Sallantin, et al. Expires April 2015 [Page 3] INTERNET DRAFT Initial spreading October 27, 2014 document are to be interpreted as described in RFC 2119 [RFC2119]. 3 Initial Spreading mechanism Initial Spreading[SB13] spaces out a number of segments inferior or equal to the permitted upper bound value of the TCP's IW (e.g; RFC 6928 [RFC6928] suggests to use 10 for 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. 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 design 4.1 Constraints It has been observed that most of the savings enabled by Initial Spreading in congested environments comes from the independence of the segments sent during the first RTT. Indeed, experimentations [SB13] and analytical model [SB14] showed that Initial Spreading, by preventing the initial burst, 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 not to be dependent of a false measurement of the initial RTT during the SYN-SYN/ACK exchange or to deteriorate the performance in un-congested network. To be efficient, Initial Spreading should therefore take the best of several constraints: o Tspreading MUST be bounded to not be dependent of the RTT measurement. o Tspreading MUST be large enough for the losses to be un- correlated. Sallantin, et al. Expires April 2015 [Page 4] INTERNET DRAFT Initial spreading October 27, 2014 o Tspreading SHOULD be the shortest possible to not add an un- necessary delay (notably in un-congested network). o Implementation MUST be light. 4.2 Burst impact on losses It has been observed [SB14] 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. As the bottleneck throughput is unknown and can not be known before the transmission of the Initial Window, Tspreading should be selected to offer the best performance whatever the throughput. 4.3 Tmax Tmax is the upper bound value of Tspreading. It has two main purposes: o it enables Initial Spreading not to be dependent on the RTT measurement. This last introduces some uncertainty in the mechanism and increases the latency variance. o it reduces the mean latency. Tmax's choice results then in a trade-off. A larger Tmax would enable the Initial Spreading to be efficient with lower bottleneck throughput (cf. section 4.2) in congested networks, but would decrease the benefits of a large Initial Window in un- congested network. On the opposite, a lower Tmax would reduce the additional delay in un-congested network but would decrease the benefits of Initial Spreading in congested network. 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 enable Initial Spreading to perform well in all cases: o In case of short RTT (ie <20 ms), Tspreading is set to RTT/IW. o In case of large RTT, Tspreading is set to Tmax. If the duration of the RTT is due to the delay and not to the congestion, then the additional delay would be low in comparison with the RTT duration. Sallantin, et al. Expires April 2015 [Page 5] INTERNET DRAFT Initial spreading October 27, 2014 Otherwise, if the large RTT is due to the congestion, our numerous experiments showed that whatever the considered Tmax, using Initial Spreading outperforms the regular performance of a large Initial Window without Initial Spreading. 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 The authors RECOMMEND to apply the pacing in the Active Queue Management (AQM). For example, an implementation based on the new FQ/pacing would enable: o to apply the Initial Spreading algorithm and select the optimal Tspreading for each flow, even in the case of multiple TCP flows. Sallantin, et al. Expires April 2015 [Page 6] INTERNET DRAFT Initial spreading October 27, 2014 o to not suffer from the TSO/GSO limitations. o to reduce the overload in the TCP stack. 5.3 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. 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 the use of a larger IW. Further studies are still needed to assess the impact of a higher IW on the network, notably in term 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 Sallantin, et al. Expires April 2015 [Page 7] INTERNET DRAFT Initial spreading October 27, 2014 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 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. [RFC6928] J. Chu, N. Dukkipati, Y. Cheng, and M. Mathis, "Increasing tcp's initial window," RFC 6928, IETF, Experimental, Jan. 2013. [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. Sallantin, et al. Expires April 2015 [Page 8] INTERNET DRAFT Initial spreading October 27, 2014 [SB13] R.Sallantin, C.Baudoin, E.Chaput, F.Arnal, E.Dubois and A- L.Beylot, "Initial spreading: A fast Start-Up TCP mechanism," Local Computer Networks (LCN), 2013 IEEE 38th Conference on , vol., no., pp.492,499, 21-24 Oct. 2013 [SB14] R.Sallantin, C.Baudoin, E.Chaput, F.Arnal, E.Dubois and A- L.Beylot, "A TCP model for short-lived flows to validate initial spreading," Local Computer Networks (LCN), 2014 IEEE 39th Conference on , vol., no., pp.177,184, 8-11 Sept. 2014 [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. [RFC5532] T. Talpey, C. Juszczak, "Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement," RFC 5532, IETF, Informational, May 2009. 9.2 Informative References [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. [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 (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- Sallantin, et al. Expires April 2015 [Page 9] INTERNET DRAFT Initial spreading October 27, 2014 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. [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 Fabrice Arnal Thales Alenia Space Email: fabrice.arnal@thalesaleniaspace.com Emmanuel Dubois Centre National des Etudes Spatiales (CNES) 18 Avenue Edouard Belin Sallantin, et al. Expires April 2015 [Page 10] INTERNET DRAFT Initial spreading October 27, 2014 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 April 2015 [Page 11]