draft-ietf-tcpm-newcwv-09.txt   draft-ietf-tcpm-newcwv-10.txt 
TCPM Working Group G. Fairhurst TCPM Working Group G. Fairhurst
Internet-Draft A. Sathiaseelan Internet-Draft A. Sathiaseelan
Obsoletes: 2861 (if approved) R. Secchi Obsoletes: 2861 (if approved) R. Secchi
Intended status: Experimental University of Aberdeen Intended status: Experimental University of Aberdeen
Expires: September 7, 2015 March 6, 2015 Expires: October 15, 2015 April 13, 2015
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-09 draft-ietf-tcpm-newcwv-10
Abstract Abstract
This document provides a mechanism to address issues that arise when This document provides a mechanism to address issues that arise when
TCP is used to support traffic that exhibits periods where the TCP is used to support traffic that exhibits periods where the
sending rate is limited by the application rather than the congestion sending rate is limited by the application rather than the congestion
window. It provides an experimental update to TCP that allows a TCP window. It provides an experimental update to TCP that allows a TCP
sender to restart quickly following a rate-limited interval. This sender to restart quickly following a rate-limited interval. This
method is expected to benefit applications that send rate-limited method is expected to benefit applications that send rate-limited
traffic using TCP, while also providing an appropriate response if traffic using TCP, while also providing an appropriate response if
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2015. This Internet-Draft will expire on October 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Standards Status of this Document . . . . . . . . . . . . 4 1.1. Implementation of new CWV . . . . . . . . . . . . . . . . 4
1.2. Standards Status of this Document . . . . . . . . . . . . 5
2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Initialisation . . . . . . . . . . . . . . . . . . . . . 8 4.1. Initialisation . . . . . . . . . . . . . . . . . . . . . 8
4.2. Estimating the validated capacity supported by a path . . 8 4.2. Estimating the validated capacity supported by a path . . 8
4.3. Preserving cwnd during a rate-limited period. . . . . . . 9 4.3. Preserving cwnd during a rate-limited period. . . . . . . 9
4.4. TCP congestion control during the non-validated phase . . 9 4.4. TCP congestion control during the non-validated phase . . 10
4.4.1. Response to congestion in the non-validated phase . . 10 4.4.1. Response to congestion in the non-validated phase . . 11
4.4.2. Sender burst control during the non-validated phase . 12 4.4.2. Sender burst control during the non-validated phase . 12
4.4.3. Adjustment at the end of the non-validated phase . . 12 4.4.3. Adjustment at the end of the non-validated phase . . 13
4.5. Examples of Implementation . . . . . . . . . . . . . . . 13 4.5. Examples of Implementation . . . . . . . . . . . . . . . 14
4.5.1. Implementing the pipeACK measurement . . . . . . . . 13 4.5.1. Implementing the pipeACK measurement . . . . . . . . 14
4.5.2. Implementing detection of the cwnd-limited condition 14 4.5.2. Implementing detection of the cwnd-limited condition 15
5. Determining a safe period to preserve cwnd . . . . . . . . . 15 5. Determining a safe period to preserve cwnd . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Other related work . . . . . . . . . . . . . . . . . . . 16 9.1. Other related work . . . . . . . . . . . . . . . . . . . 17
10. Revision notes . . . . . . . . . . . . . . . . . . . . . . . 18 10. Revision notes . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
TCP is used to support a range of application behaviours. The TCP TCP is used to support a range of application behaviours. The TCP
congestion window (cwnd) controls the number of unacknowledged congestion window (cwnd) controls the number of unacknowledged
packets/bytes that a TCP flow may have in the network at any time, a packets/bytes that a TCP flow may have in the network at any time, a
value known as the FlightSize [RFC5681]. A bulk application will value known as the FlightSize [RFC5681]. A bulk application will
always have data available to transmit. The rate at which it sends always have data available to transmit. The rate at which it sends
is therefore limited by the maximum permitted by the receiver is therefore limited by the maximum permitted by the receiver
skipping to change at page 3, line 40 skipping to change at page 3, line 46
streaming, applications that support query/response type protocols, streaming, applications that support query/response type protocols,
network file sharing, and live video transmission. Many such network file sharing, and live video transmission. Many such
applications currently avoid using long-lived (persistent) TCP applications currently avoid using long-lived (persistent) TCP
connections (e.g. [RFC2616] servers typically support persistent connections (e.g. [RFC2616] servers typically support persistent
HTTP connections, but do not enable this by default). Such HTTP connections, but do not enable this by default). Such
applications often instead either use a succession of short TCP applications often instead either use a succession of short TCP
transfers or use UDP. transfers or use UDP.
Standard TCP does not impose additional restrictions on the growth of Standard TCP does not impose additional restrictions on the growth of
the congestion window when a TCP sender is unable to send at the the congestion window when a TCP sender is unable to send at the
maximum rate allowed by the cwnd. In this case the rate-limited maximum rate allowed by the cwnd. In this case, the rate-limited
sender may grow a cwnd far beyond that corresponding to the current sender may grow a cwnd far beyond that corresponding to the current
transmit rate, resulting in a value that does not reflect current transmit rate, resulting in a value that does not reflect current
information about the state of the network path the flow is using. information about the state of the network path the flow is using.
Use of such an invalid cwnd may result in reduced application Use of such an invalid cwnd may result in reduced application
performance and/or could significantly contribute to network performance and/or could significantly contribute to network
congestion. congestion.
[RFC2861] proposed a solution to these issues in an experimental [RFC2861] proposed a solution to these issues in an experimental
method known as CWV. CWV was intended to help reduce cases where TCP method known as CWV. CWV was intended to help reduce cases where TCP
accumulated an invalid (inappropriately large) cwnd. The use and accumulated an invalid (inappropriately large) cwnd. The use and
skipping to change at page 4, line 40 skipping to change at page 4, line 44
methods (such as "padding") solely to maintain a large cwnd for methods (such as "padding") solely to maintain a large cwnd for
future transmission. future transmission.
o To incentivise the use of long-lived connections, rather than a o To incentivise the use of long-lived connections, rather than a
succession of short-lived flows, benefiting both flows and network succession of short-lived flows, benefiting both flows and network
when actual congestion is encountered. when actual congestion is encountered.
Section 5 describes the rationale for selecting the safe period to Section 5 describes the rationale for selecting the safe period to
preserve the cwnd. preserve the cwnd.
1.1. Standards Status of this Document 1.1. Implementation of new CWV
The method specified in this document is a sender-side only change to
the the TCP congestion control behaviour of TCP.
The method creates a new protocol state, and requires a sender to
determine when the cwnd is validated or non-validated to control the
entry and exit from this state (see Section 4.3). It specifies how a
TCP sender manages the growth of the cwnd using the set of rules
defined in Section 4.
Implementation of this specification requires an implementor to
define a method to provide a measure for the volume of recently
acknowledged data (pipeACK). The details of this measurement are
implementation-specific. An example is provided in Section 4.5.1,
but other methods are permitted. A sender also needs to provide a
method to determine when it becomes cwnd-limited. Implementation of
this may require consideration of other TCP methods (see
Section 4.5.2).
A sender is also recommended to provide a method that controls the
maximum burst size (see Section 4.4.2). However, implementors are
allowed flexibility in how this method is implemented and the choice
of an appropriate method is expected to depend on the way in which
the sender stack implements other TCP methods (such as TCP Segment
Offload, TSO).
1.2. Standards Status of this Document
This document was produced by the TCP Maintenance and Minor This document was produced by the TCP Maintenance and Minor
Extensions (tcpm) working group. Extensions (tcpm) working group.
The document updates and obsoletes the methods described in The document updates and obsoletes the methods described in
[RFC2861]. It recommends a set of mechanisms, including the use of [RFC2861]. It recommends a set of mechanisms, including the use of
pacing during a non-validated period. The updated mechanisms are pacing during a non-validated period. The updated mechanisms are
intended to have a less aggressive congestion impact than would be intended to have a less aggressive congestion impact than would be
exhibited by a standard TCP sender. exhibited by a standard TCP sender.
skipping to change at page 9, line 42 skipping to change at page 10, line 19
threshold ensures a sender does not further increase the cwnd as long threshold ensures a sender does not further increase the cwnd as long
as the FlightSize is less than (1/2*cwnd). Furthermore, a sender as the FlightSize is less than (1/2*cwnd). Furthermore, a sender
with a FlightSize less than (1/2*cwnd) may in the next RTT be with a FlightSize less than (1/2*cwnd) may in the next RTT be
permitted by the cwnd to send at a rate that more than doubles the permitted by the cwnd to send at a rate that more than doubles the
FlightSize, and hence this case needs to be regarded as non-validated FlightSize, and hence this case needs to be regarded as non-validated
and a sender therefore needs to employ additional mechanisms while in and a sender therefore needs to employ additional mechanisms while in
this phase. this phase.
4.4. TCP congestion control during the non-validated phase 4.4. TCP congestion control during the non-validated phase
A TCP sender MUST enter the non-validated phase when the pipeACK is A TCP sender implementing this specification MUST enter the non-
less than (1/2)*cwnd. validated phase when the pipeACK is less than (1/2)*cwnd.
A TCP sender that enters the non-validated phase SHOULD preserve the A TCP sender that enters the non-validated phase SHOULD preserve the
cwnd (i.e., this neither grows nor reduces while the sender remains cwnd (i.e., the cwnd neither grows nor reduces while the sender
in this phase). If the sender receives an indication of congestion, remains in this phase). If the sender receives an indication of
it uses the method described below. The phase is concluded after a congestion, it uses the method described below. The phase is
fixed period of time (the NVP, as explained in Section 4.4.3) or when concluded after a fixed period of time (the NVP, as explained in
the sender transmits sufficient data so that pipeACK > (1/2)*cwnd Section 4.4.3) or when the sender transmits sufficient data so that
(i.e., the sender is no longer rate-limited). pipeACK > (1/2)*cwnd (i.e., the sender is no longer rate-limited).
The behaviour in the non-validated phase is specified as: The behaviour in the non-validated phase is specified as:
o A sender determines whether to increase the cwnd based upon o A sender determines whether to increase the cwnd based upon
whether it is cwnd-limited (see Section 4.5.2): whether it is cwnd-limited (see Section 4.5.2):
o
* A sender that is cwnd-limited MAY use the standard TCP method * A sender that is cwnd-limited MAY use the standard TCP method
to increase cwnd (i.e., a TCP sender that fully utilises the to increase cwnd (i.e., a TCP sender that fully utilises the
cwnd is permitted to increase cwnd each received ACK using cwnd is permitted to increase cwnd each received ACK using
standard methods). standard methods).
* A sender that is not cwnd-limited MUST NOT increase the cwnd * A sender that is not cwnd-limited MUST NOT increase the cwnd
when ACK packets are received in this phase. when ACK packets are received in this phase (i.e., needs to
avoid growing the cwnd when it has not recently sent using the
current size of cwnd).
o If the sender receives an indication of congestion while in the o If the sender receives an indication of congestion while in the
non-validated phase (i.e., detects loss), the sender MUST exit the non-validated phase (i.e., detects loss), the sender MUST exit the
non-validated phase (reducing the cwnd as defined in non-validated phase (reducing the cwnd as defined in
Section 4.4.1). Section 4.4.1).
o If the Retransmission Time Out (RTO) expires while in the non- o If the Retransmission Time Out (RTO) expires while in the non-
validated phase, the sender MUST exit the non-validated phase. It validated phase, the sender MUST exit the non-validated phase. It
then resumes using the standard TCP RTO mechanism [RFC5681]. then resumes using the standard TCP RTO mechanism [RFC5681].
skipping to change at page 11, line 4 skipping to change at page 11, line 28
standard method to increase the cwnd. (Note, if the sender succeeds standard method to increase the cwnd. (Note, if the sender succeeds
in sending these new segments, the updated cwnd and pipeACK variables in sending these new segments, the updated cwnd and pipeACK variables
will eventually result in a transition to the validated phase.) will eventually result in a transition to the validated phase.)
4.4.1. Response to congestion in the non-validated phase 4.4.1. Response to congestion in the non-validated phase
Reception of congestion feedback while in the non-validated phase is Reception of congestion feedback while in the non-validated phase is
interpreted as an indication that it was inappropriate for the sender interpreted as an indication that it was inappropriate for the sender
to use the preserved cwnd. The sender is therefore required to to use the preserved cwnd. The sender is therefore required to
quickly reduce the rate to avoid further congestion. Since the cwnd quickly reduce the rate to avoid further congestion. Since the cwnd
does not have a validated value, a new cwnd value must be selected does not have a validated value, a new cwnd value needs to be
based on the utilised rate. selected based on the utilised rate.
A sender that detects a packet-drop MUST record the current A sender that detects a packet-drop MUST record the current
FlightSize in the variable LossFlightSize and MUST calculate a safe FlightSize in the variable LossFlightSize and MUST calculate a safe
cwnd for loss recovery using the method below: cwnd for loss recovery using the method below:
cwnd = (Max(pipeACK,LossFlightSize))/2. cwnd = (Max(pipeACK,LossFlightSize))/2.
The pipeACK value is not updated during loss recoverySection 4.2. If The pipeACK value is not updated during loss recoverySection 4.2. If
there is a valid pipeACK value, the new cwnd is adjusted to reflect there is a valid pipeACK value, the new cwnd is adjusted to reflect
that a non-validated cwnd may be larger than the actual FlightSize, that a non-validated cwnd may be larger than the actual FlightSize,
skipping to change at page 14, line 44 skipping to change at page 15, line 21
necessarily require a new timer to be implemented. An alternative is necessarily require a new timer to be implemented. An alternative is
to record a timestamp when the sender enters the NVP. Each time a to record a timestamp when the sender enters the NVP. Each time a
sender transmits a new segment, this timestamp may be used to sender transmits a new segment, this timestamp may be used to
determine if the NVP period has expired. If the period expires, the determine if the NVP period has expired. If the period expires, the
sender may take into account how many units of the NVP period have sender may take into account how many units of the NVP period have
passed and make one reduction (as defined in Section 4.4.3) for each passed and make one reduction (as defined in Section 4.4.3) for each
NVP period. NVP period.
4.5.2. Implementing detection of the cwnd-limited condition 4.5.2. Implementing detection of the cwnd-limited condition
A method is required to detect the cwnd-limited condition (see A sender needs to implement a method that detects the cwnd-limited
Section 4.4. This is used to detect a condition where a sender in condition (see Section 4.4. This detects a condition where a sender
the non-validated phase receives an ACK, but the size of cwnd receives an ACK in the non-validated phase, but the size of cwnd
prevents sending more new data. prevents sending more new data.
In simple terms this condition is true only when the TCP sender's In simple terms, this condition is true only when the FlightSize of a
FlightSize is equal to or larger than the cwnd. However, an TCP sender is equal to or larger than the current cwnd. However, an
implementation must consider other constraints on the way in which implementation also needs to consider constraints on the way in which
cwnd variable is used, for instance the need to support methods such the cwnd variable can be used, for instance implementations need to
as the Nagle Algorithm and TCP Segment Offload (TSO). This can support other TCP methods such as the Nagle Algorithm and TCP Segment
result in a sender becoming cwnd-limited when the cwnd is nearly, Offload (TSO) that also use cwnd to control transmission. These
rather than completely, equal to the FlightSize. other methods can result in a sender becoming cwnd-limited when the
cwnd is nearly, rather than completely, equal to the FlightSize.
5. Determining a safe period to preserve cwnd 5. Determining a safe period to preserve cwnd
This section documents the rationale for selecting the maximum period This section documents the rationale for selecting the maximum period
that cwnd may be preserved, known as the non-validated period, NVP. that cwnd may be preserved, known as the non-validated period, NVP.
Limiting the period that cwnd may be preserved avoids undesirable Limiting the period that cwnd may be preserved avoids undesirable
side effects that would result if the cwnd were to be kept side effects that would result if the cwnd were to be kept
unnecessarily high for an arbitrary long period, which was a part of unnecessarily high for an arbitrary long period, which was a part of
the problem that CWV originally attempted to address. The period a the problem that CWV originally attempted to address. The period a
skipping to change at page 16, line 44 skipping to change at page 17, line 21
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
9.1. Other related work 9.1. Other related work
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
There are several issues to be discussed more widely: There are several issues to be discussed more widely:
o There are potential interactions with the Experimental update in o There are potential interactions with the Experimental update in
[RFC6928] that raises the TCP initial Window to ten segments, do RFC 6928 that raises the TCP initial Window to ten segments, do
these cases need to be elaborated? these cases need to be elaborated?
This relates to the Experimental specification for increasing This relates to the Experimental specification for increasing
the TCP IW defined in RFC 6928. the TCP IW defined in RFC 6928.
The two methods have different functions and different response The two methods have different functions and different response
to loss/congestion. to loss/congestion.
RFC 6928 proposes an experimental update to TCP that would RFC 6928 proposes an experimental update to TCP that would
increase the IW to ten segments. This would allow faster increase the IW to ten segments. This would allow faster
skipping to change at page 21, line 39 skipping to change at page 22, line 16
not clear that this document should specify a usage of a mechanism not clear that this document should specify a usage of a mechanism
that has not been fully defined. Accurate ECN may lead to that has not been fully defined. Accurate ECN may lead to
different congestion responses and these will need to be defined different congestion responses and these will need to be defined
in the CC specifications for using Accurate ECN. in the CC specifications for using Accurate ECN.
WG draft 09 contained: WG draft 09 contained:
o Removed update to RFC 5681 - the status of the present document is o Removed update to RFC 5681 - the status of the present document is
Experimental, and hence this document does not update RFC 5681. Experimental, and hence this document does not update RFC 5681.
WG draft 10 contained edits following WGLC:
o Section 1.1 Implementation of new CWV: New section added to
introduce the places where there are implementation flexibility.
o Section 4.4: Clarified that the MUST is to satisfy the goal to
avoid a TCP sender growing a large "non-validated" cwnd, when it
has not recently sent using the current size of cwnd, and fixed
format of bullet 2 in 4.4.
o Section 4.5.2: rewritten section text.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", September
793, September 1981. 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000. Window Validation", RFC 2861, June 2000.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control, RFC 5681", September 2009.
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
and Y. Nishida, "A Conservative Loss Recovery Algorithm and Y. Nishida, "A Conservative Loss Recovery Algorithm
Based on Selective Acknowledgment (SACK) for TCP", RFC Based on Selective Acknowledgment (SACK) for TCP", RFC
6675, August 2012. 6675, August 2012.
11.2. Informative References 11.2. Informative References
[All05] Allman, M. and E. Blanton, "Notes on burst mitigation for [All05] Allman, M. and E. Blanton, "Notes on burst mitigation for
transport protocols", March 2005. transport protocols", March 2005.
skipping to change at page 23, line 6 skipping to change at page 23, line 44
[Liu07] Liu, D., Allman, M., Jiny, S., and L. Wang, "Congestion [Liu07] Liu, D., Allman, M., Jiny, S., and L. Wang, "Congestion
Control without a Startup Phase, 5th International Control without a Startup Phase, 5th International
Workshop on Protocols for Fast Long-Distance Networks Workshop on Protocols for Fast Long-Distance Networks
(PFLDnet), Los Angeles, California, USA", February 2007. (PFLDnet), Los Angeles, California, USA", February 2007.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June "Computing TCP's Retransmission Timer, RFC 6928", June
2011. 2011.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, April 2013.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen, Scotland AB24 3UE Aberdeen, Scotland AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
 End of changes. 24 change blocks. 
52 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/