Internet DRAFT - draft-sallantin-tcpm-initial-spreading
draft-sallantin-tcpm-initial-spreading
INTERNET-DRAFT R.Sallantin
Intended Status: Proposed Standard C.BaudoinE.bouttier
Expires: October 25, 2015 F.Arnal
Thales Alenia Space
E.Dubois
CNES
E.Chaput
A.Beylot
IRIT
E.Bouttier
CNES/TAS/IRIT
April 23, 2015
Safe increase of the TCP's Initial Window
Using Initial Spreading
draft-sallantin-tcpm-initial-spreading-01
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 Oct 2015 [Page 1]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 2]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 3]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 4]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 5]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 6]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 7]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 8]
INTERNET DRAFT Initial spreading April 25, 2015
[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
[SB14] R.Sallantin, C.Baudoin, E.Chaput, F.Arnal, E.Dubois and A-
L.Beylot, An end-to-end alternative to tcp peps: Initial
spreading, a tcp fast startup mechanism," International
Journal of Satellite Communications and Networking, paper
to appear (IJSCN), 2015.
[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.
Sallantin, et al. Expires Oct 2015 [Page 9]
INTERNET DRAFT Initial spreading April 25, 2015
[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.
[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
Sallantin, et al. Expires Oct 2015 [Page 10]
INTERNET DRAFT Initial spreading April 25, 2015
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 Oct 2015 [Page 11]
