Diff: rfc9002v3.xml - rfc9002.xml

	rfc9002v3.xml	rfc9002.xml

	skipping to change at line 1036 ¶	skipping to change at line 1036 ¶
	Markings can be treated as equivalent to loss <xref target="RFC3168" format="default"/>, b ut other	Markings can be treated as equivalent to loss <xref target="RFC3168" format="default"/>, b ut other
	responses can be specified, such as <xref target="RFC8511" format="default"/> or <xref tar get="RFC8311" format="default"/>.</t>	responses can be specified, such as <xref target="RFC8511" format="default"/> or <xref tar get="RFC8311" format="default"/>.</t>
	</section>	</section>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>
	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="QUIC-TRANSPORT">	<reference anchor="QUIC-TRANSPORT" target="https://www.rfc-editor.org/info/rfc9000 ">
	<front>	<front>
	<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>	<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
	<author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">	<author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">
	<organization>Fastly</organization>	<organization>Fastly</organization>
	</author>	</author>
	<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor ">	<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor ">
	<organization>Mozilla</organization>	<organization>Mozilla</organization>
	</author>	</author>
	<date year="2021" month="May"/>	<date year="2021" month="May"/>
	</front>	</front>
	<seriesInfo name="RFC" value="9000"/>	<seriesInfo name="RFC" value="9000"/>
	<seriesInfo name="DOI" value="10.17487/RFC9000"/>	<seriesInfo name="DOI" value="10.17487/RFC9000"/>
	</reference>	</reference>

	<reference anchor="QUIC-TLS">	<reference anchor="QUIC-TLS" target="https://www.rfc-editor.org/info/rfc9001">
	<front>	<front>
	<title>Using TLS to Secure QUIC</title>	<title>Using TLS to Secure QUIC</title>
	<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor ">	<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor ">
	<organization>Mozilla</organization>	<organization>Mozilla</organization>
	</author>	</author>
	<author initials="S." surname="Turner" fullname="Sean Turner" role="editor">	<author initials="S." surname="Turner" fullname="Sean Turner" role="editor">
	<organization>sn3rd</organization>	<organization>sn3rd</organization>
	</author>	</author>
	<date year="2021" month="May"/>	<date year="2021" month="May"/>
	</front>	</front>
	<seriesInfo name="RFC" value="9001"/>	<seriesInfo name="RFC" value="9001"/>
	<seriesInfo name="DOI" value="10.17487/RFC9001"/>	<seriesInfo name="DOI" value="10.17487/RFC9001"/>
	</reference>	</reference>

	<reference anchor="RFC8085">	<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085">
	<front>	<front>
	<title>UDP Usage Guidelines</title>	<title>UDP Usage Guidelines</title>
	<author fullname="L. Eggert" initials="L." surname="Eggert">	<author fullname="L. Eggert" initials="L." surname="Eggert">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="G. Shepherd" initials="G." surname="Shepherd">	<author fullname="G. Shepherd" initials="G." surname="Shepherd">
	<organization/>	<organization/>

	skipping to change at line 1088 ¶	skipping to change at line 1088 ¶
	<t>The User Datagram Protocol (UDP) provides a minimal message-passing trans port that has no inherent congestion control mechanisms. This document provides guideline s on the use of UDP for the designers of applications, tunnels, and other protocols that u se UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox trav ersal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Poi nts (DSCPs), and ports.</t>	<t>The User Datagram Protocol (UDP) provides a minimal message-passing trans port that has no inherent congestion control mechanisms. This document provides guideline s on the use of UDP for the designers of applications, tunnels, and other protocols that u se UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox trav ersal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Poi nts (DSCPs), and ports.</t>
	<t>Because congestion control is critical to the stable operation of the Int ernet, applications and other protocols that choose to use UDP as an Internet transport mu st employ mechanisms to prevent congestion collapse and to establish some degree of fairne ss with concurrent traffic. They may also need to implement additional mechanisms, depend ing on how they use UDP.</t>	<t>Because congestion control is critical to the stable operation of the Int ernet, applications and other protocols that choose to use UDP as an Internet transport mu st employ mechanisms to prevent congestion collapse and to establish some degree of fairne ss with concurrent traffic. They may also need to implement additional mechanisms, depend ing on how they use UDP.</t>
	<t>Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t>	<t>Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t>
	<t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP us age.</t>	<t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP us age.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="BCP" value="145"/>	<seriesInfo name="BCP" value="145"/>
	<seriesInfo name="RFC" value="8085"/>	<seriesInfo name="RFC" value="8085"/>
	<seriesInfo name="DOI" value="10.17487/RFC8085"/>	<seriesInfo name="DOI" value="10.17487/RFC8085"/>
	</reference>	</reference>

	<reference anchor="RFC2119">	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
	<front>	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>	<title>Key words for use in RFCs to Indicate Requirement Levels</title>
	<author fullname="S. Bradner" initials="S." surname="Bradner">	<author fullname="S. Bradner" initials="S." surname="Bradner">
	<organization/>	<organization/>
	</author>	</author>
	<date month="March" year="1997"/>	<date month="March" year="1997"/>
	<abstract>	<abstract>
	<t>In many standards track documents several words are used to signify the r equirements in the specification. These words are often capitalized. This document define s these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and s uggestions for improvements.</t>	<t>In many standards track documents several words are used to signify the r equirements in the specification. These words are often capitalized. This document define s these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and s uggestions for improvements.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="BCP" value="14"/>	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>	</reference>

	<reference anchor="RFC8174">	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
	<front>	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author fullname="B. Leiba" initials="B." surname="Leiba">	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>	<organization/>
	</author>	</author>
	<date month="May" year="2017"/>	<date month="May" year="2017"/>
	<abstract>	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protocol specifi cations. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usa ge of the key words have the defined special meanings.</t>	<t>RFC 2119 specifies common key words that may be used in protocol specifi cations. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usa ge of the key words have the defined special meanings.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="BCP" value="14"/>	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>	</reference>

	<reference anchor="RFC3168">	<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168">
	<front>	<front>
	<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>	<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
	<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan">	<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="S. Floyd" initials="S." surname="Floyd">	<author fullname="S. Floyd" initials="S." surname="Floyd">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="D. Black" initials="D." surname="Black">	<author fullname="D. Black" initials="D." surname="Black">
	<organization/>	<organization/>

	skipping to change at line 1169 ¶	skipping to change at line 1169 ¶
	<organization/>	<organization/>
	</author>	</author>
	<author initials="C." surname="Partridge">	<author initials="C." surname="Partridge">
	<organization/>	<organization/>
	</author>	</author>
	<date year="1991" month="November"/>	<date year="1991" month="November"/>
	</front>	</front>
	<seriesInfo name="DOI" value="10.1145/118544.118549"/>	<seriesInfo name="DOI" value="10.1145/118544.118549"/>
	<refcontent>ACM Transactions on Computer Systems</refcontent>	<refcontent>ACM Transactions on Computer Systems</refcontent>
	</reference>	</reference>

	<reference anchor="RFC3465">	<reference anchor="RFC3465" target="https://www.rfc-editor.org/info/rfc3465">
	<front>	<front>
	<title>TCP Congestion Control with Appropriate Byte Counting (ABC)</title>	<title>TCP Congestion Control with Appropriate Byte Counting (ABC)</title>
	<author fullname="M. Allman" initials="M." surname="Allman">	<author fullname="M. Allman" initials="M." surname="Allman">
	<organization/>	<organization/>
	</author>	</author>
	<date month="February" year="2003"/>	<date month="February" year="2003"/>
	<abstract>	<abstract>
	<t>This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the i ncrease on the number of previously unacknowledged bytes each ACK covers. This change imp roves the performance of TCP, as well as closes a security hole TCP receivers can use to i nduce the sender into increasing the sending rate too rapidly. This memo defines an Experi mental Protocol for the Internet community.</t>	<t>This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the i ncrease on the number of previously unacknowledged bytes each ACK covers. This change imp roves the performance of TCP, as well as closes a security hole TCP receivers can use to i nduce the sender into increasing the sending rate too rapidly. This memo defines an Experi mental Protocol for the Internet community.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="3465"/>	<seriesInfo name="RFC" value="3465"/>
	<seriesInfo name="DOI" value="10.17487/RFC3465"/>	<seriesInfo name="DOI" value="10.17487/RFC3465"/>
	</reference>	</reference>

	<reference anchor="RFC2018">	<reference anchor="RFC2018" target="https://www.rfc-editor.org/info/rfc2018">
	<front>	<front>
	<title>TCP Selective Acknowledgment Options</title>	<title>TCP Selective Acknowledgment Options</title>
	<author fullname="M. Mathis" initials="M." surname="Mathis">	<author fullname="M. Mathis" initials="M." surname="Mathis">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="J. Mahdavi" initials="J." surname="Mahdavi">	<author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="S. Floyd" initials="S." surname="Floyd">	<author fullname="S. Floyd" initials="S." surname="Floyd">
	<organization/>	<organization/>

	skipping to change at line 1206 ¶	skipping to change at line 1206 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="October" year="1996"/>	<date month="October" year="1996"/>
	<abstract>	<abstract>
	<t>This memo proposes an implementation of SACK and discusses its performanc e and related issues. [STANDARDS-TRACK]</t>	<t>This memo proposes an implementation of SACK and discusses its performanc e and related issues. [STANDARDS-TRACK]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="2018"/>	<seriesInfo name="RFC" value="2018"/>
	<seriesInfo name="DOI" value="10.17487/RFC2018"/>	<seriesInfo name="DOI" value="10.17487/RFC2018"/>
	</reference>	</reference>

	<reference anchor="RFC6298">	<reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298">
	<front>	<front>
	<title>Computing TCP's Retransmission Timer</title>	<title>Computing TCP's Retransmission Timer</title>
	<author fullname="V. Paxson" initials="V." surname="Paxson">	<author fullname="V. Paxson" initials="V." surname="Paxson">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="M. Allman" initials="M." surname="Allman">	<author fullname="M. Allman" initials="M." surname="Allman">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="J. Chu" initials="J." surname="Chu">	<author fullname="J. Chu" initials="J." surname="Chu">
	<organization/>	<organization/>

	skipping to change at line 1229 ¶	skipping to change at line 1229 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="June" year="2011"/>	<date month="June" year="2011"/>
	<abstract>	<abstract>
	<t>This document defines the standard algorithm that Transmission Control Pr otocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a <bcp14>SHOULD</bcp14> to a <bcp14>MUST</bcp14>. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t>	<t>This document defines the standard algorithm that Transmission Control Pr otocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a <bcp14>SHOULD</bcp14> to a <bcp14>MUST</bcp14>. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="6298"/>	<seriesInfo name="RFC" value="6298"/>
	<seriesInfo name="DOI" value="10.17487/RFC6298"/>	<seriesInfo name="DOI" value="10.17487/RFC6298"/>
	</reference>	</reference>

	<reference anchor="RFC8985">	<reference anchor="RFC8985" target="https://www.rfc-editor.org/info/rfc8985">
	<front>	<front>
	<title>The RACK-TLP Loss Detection Algorithm for TCP</title>	<title>The RACK-TLP Loss Detection Algorithm for TCP</title>
	<author fullname="Y. Cheng" initials="Y." surname="Cheng">	<author fullname="Y. Cheng" initials="Y." surname="Cheng">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="N. Cardwell" initials="N." surname="Cardwell">	<author fullname="N. Cardwell" initials="N." surname="Cardwell">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati">	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
	<organization/>	<organization/>

	skipping to change at line 1252 ¶	skipping to change at line 1252 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="February" year="2021"/>	<date month="February" year="2021"/>
	<abstract>	<abstract>
	<t>This document presents the RACK-TLP loss detection algorithm for TCP. RAC K-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has t wo parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based infer ences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) ev ents. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RA CK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternati ve to the DupAck threshold approach.</t>	<t>This document presents the RACK-TLP loss detection algorithm for TCP. RAC K-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has t wo parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based infer ences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) ev ents. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RA CK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternati ve to the DupAck threshold approach.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="8985"/>	<seriesInfo name="RFC" value="8985"/>
	<seriesInfo name="DOI" value="10.17487/RFC8985"/>	<seriesInfo name="DOI" value="10.17487/RFC8985"/>
	</reference>	</reference>

	<reference anchor="RFC5682">	<reference anchor="RFC5682" target="https://www.rfc-editor.org/info/rfc5682">
	<front>	<front>
	<title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retra nsmission Timeouts with TCP</title>	<title>Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retra nsmission Timeouts with TCP</title>
	<author fullname="P. Sarolahti" initials="P." surname="Sarolahti">	<author fullname="P. Sarolahti" initials="P." surname="Sarolahti">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="M. Kojo" initials="M." surname="Kojo">	<author fullname="M. Kojo" initials="M." surname="Kojo">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="K. Yamamoto" initials="K." surname="Yamamoto">	<author fullname="K. Yamamoto" initials="K." surname="Yamamoto">
	<organization/>	<organization/>

	skipping to change at line 1276 ¶	skipping to change at line 1276 ¶
	</author>	</author>
	<date month="September" year="2009"/>	<date month="September" year="2009"/>
	<abstract>	<abstract>
	<t>The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimen tal status. See Appendix B for the differences between this document and RFC 4138.</t>	<t>The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimen tal status. See Appendix B for the differences between this document and RFC 4138.</t>
	<t>Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This documen t describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeou ts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate . After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether th e timeout was spurious. It then decides whether to send new segments or retransmit unackn owledged segments. The algorithm effectively helps to avoid additional unnecessary retran smissions and thereby improves TCP performance in the case of a spurious timeout. [STANDA RDS-TRACK]</t>	<t>Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This documen t describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeou ts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate . After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether th e timeout was spurious. It then decides whether to send new segments or retransmit unackn owledged segments. The algorithm effectively helps to avoid additional unnecessary retran smissions and thereby improves TCP performance in the case of a spurious timeout. [STANDA RDS-TRACK]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="5682"/>	<seriesInfo name="RFC" value="5682"/>
	<seriesInfo name="DOI" value="10.17487/RFC5682"/>	<seriesInfo name="DOI" value="10.17487/RFC5682"/>
	</reference>	</reference>

	<reference anchor="RFC5681">	<reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5681">
	<front>	<front>
	<title>TCP Congestion Control</title>	<title>TCP Congestion Control</title>
	<author fullname="M. Allman" initials="M." surname="Allman">	<author fullname="M. Allman" initials="M." surname="Allman">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="V. Paxson" initials="V." surname="Paxson">	<author fullname="V. Paxson" initials="V." surname="Paxson">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="E. Blanton" initials="E." surname="Blanton">	<author fullname="E. Blanton" initials="E." surname="Blanton">
	<organization/>	<organization/>
	</author>	</author>
	<date month="September" year="2009"/>	<date month="September" year="2009"/>
	<abstract>	<abstract>
	<t>This document defines TCP's four intertwined congestion control algorithm s: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>	<t>This document defines TCP's four intertwined congestion control algorithm s: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="5681"/>	<seriesInfo name="RFC" value="5681"/>
	<seriesInfo name="DOI" value="10.17487/RFC5681"/>	<seriesInfo name="DOI" value="10.17487/RFC5681"/>
	</reference>	</reference>

	<reference anchor="RFC5827">	<reference anchor="RFC5827" target="https://www.rfc-editor.org/info/rfc5827">
	<front>	<front>
	<title>Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP )</title>	<title>Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP )</title>
	<author fullname="M. Allman" initials="M." surname="Allman">	<author fullname="M. Allman" initials="M." surname="Allman">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="K. Avrachenkov" initials="K." surname="Avrachenkov">	<author fullname="K. Avrachenkov" initials="K." surname="Avrachenkov">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="U. Ayesta" initials="U." surname="Ayesta">	<author fullname="U. Ayesta" initials="U." surname="Ayesta">
	<organization/>	<organization/>

	skipping to change at line 1322 ¶	skipping to change at line 1322 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="May" year="2010"/>	<date month="May" year="2010"/>
	<abstract>	<abstract>
	<t>This document proposes a new mechanism for TCP and Stream Control Transmi ssion Protocol (SCTP) that can be used to recover lost segments when a connection's conges tion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigge r a fast retransmission. This allows the transport to use fast retransmit to recover segm ent losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRAC K]</t>	<t>This document proposes a new mechanism for TCP and Stream Control Transmi ssion Protocol (SCTP) that can be used to recover lost segments when a connection's conges tion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigge r a fast retransmission. This allows the transport to use fast retransmit to recover segm ent losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRAC K]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="5827"/>	<seriesInfo name="RFC" value="5827"/>
	<seriesInfo name="DOI" value="10.17487/RFC5827"/>	<seriesInfo name="DOI" value="10.17487/RFC5827"/>
	</reference>	</reference>

	<reference anchor="RFC6675">	<reference anchor="RFC6675" target="https://www.rfc-editor.org/info/rfc6675">
	<front>	<front>
	<title>A Conservative Loss Recovery Algorithm Based on Selective Acknowledgmen t (SACK) for TCP</title>	<title>A Conservative Loss Recovery Algorithm Based on Selective Acknowledgmen t (SACK) for TCP</title>
	<author fullname="E. Blanton" initials="E." surname="Blanton">	<author fullname="E. Blanton" initials="E." surname="Blanton">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="M. Allman" initials="M." surname="Allman">	<author fullname="M. Allman" initials="M." surname="Allman">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="L. Wang" initials="L." surname="Wang">	<author fullname="L. Wang" initials="L." surname="Wang">
	<organization/>	<organization/>

	skipping to change at line 1351 ¶	skipping to change at line 1351 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="August" year="2012"/>	<date month="August" year="2012"/>
	<abstract>	<abstract>
	<t>This document presents a conservative loss recovery algorithm for TCP tha t is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm pr esented in this document conforms to the spirit of the current congestion control specific ation (RFC 5681), but allows TCP senders to recover more effectively when multiple segment s are lost from a single flight of data. This document obsoletes RFC 3517 and describes ch anges from it. [STANDARDS-TRACK]</t>	<t>This document presents a conservative loss recovery algorithm for TCP tha t is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm pr esented in this document conforms to the spirit of the current congestion control specific ation (RFC 5681), but allows TCP senders to recover more effectively when multiple segment s are lost from a single flight of data. This document obsoletes RFC 3517 and describes ch anges from it. [STANDARDS-TRACK]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="6675"/>	<seriesInfo name="RFC" value="6675"/>
	<seriesInfo name="DOI" value="10.17487/RFC6675"/>	<seriesInfo name="DOI" value="10.17487/RFC6675"/>
	</reference>	</reference>

	<reference anchor="RFC6582">	<reference anchor="RFC6582" target="https://www.rfc-editor.org/info/rfc6582">
	<front>	<front>
	<title>The NewReno Modification to TCP's Fast Recovery Algorithm</title>	<title>The NewReno Modification to TCP's Fast Recovery Algorithm</title>
	<author fullname="T. Henderson" initials="T." surname="Henderson">	<author fullname="T. Henderson" initials="T." surname="Henderson">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="S. Floyd" initials="S." surname="Floyd">	<author fullname="S. Floyd" initials="S." surname="Floyd">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="A. Gurtov" initials="A." surname="Gurtov">	<author fullname="A. Gurtov" initials="A." surname="Gurtov">
	<organization/>	<organization/>

	skipping to change at line 1374 ¶	skipping to change at line 1374 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="April" year="2012"/>	<date month="April" year="2012"/>
	<abstract>	<abstract>
	<t>RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 568 1 explicitly allows certain modifications of these algorithms, including modifications tha t use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that re spond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstan ding when loss was detected) in the absence of SACK. This document describes a specific a lgorithm for responding to partial acknowledgments, referred to as "NewReno". This respon se to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RF C 3782. [STANDARDS-TRACK]</t>	<t>RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 568 1 explicitly allows certain modifications of these algorithms, including modifications tha t use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that re spond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstan ding when loss was detected) in the absence of SACK. This document describes a specific a lgorithm for responding to partial acknowledgments, referred to as "NewReno". This respon se to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RF C 3782. [STANDARDS-TRACK]</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="6582"/>	<seriesInfo name="RFC" value="6582"/>
	<seriesInfo name="DOI" value="10.17487/RFC6582"/>	<seriesInfo name="DOI" value="10.17487/RFC6582"/>
	</reference>	</reference>

	<reference anchor="RFC8312">	<reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8312">
	<front>	<front>
	<title>CUBIC for Fast Long-Distance Networks</title>	<title>CUBIC for Fast Long-Distance Networks</title>
	<author fullname="I. Rhee" initials="I." surname="Rhee">	<author fullname="I. Rhee" initials="I." surname="Rhee">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="L. Xu" initials="L." surname="Xu">	<author fullname="L. Xu" initials="L." surname="Xu">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="S. Ha" initials="S." surname="Ha">	<author fullname="S. Ha" initials="S." surname="Ha">
	<organization/>	<organization/>

	skipping to change at line 1403 ¶	skipping to change at line 1403 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="February" year="2018"/>	<date month="February" year="2018"/>
	<abstract>	<abstract>
	<t>CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In par ticular, it uses a cubic function instead of a linear window increase function of the curr ent TCP standards to improve scalability and stability under fast and long-distance networ ks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have b een used for many years. This document provides a specification of CUBIC to enable third- party implementations and to solicit community feedback through experimentation on the per formance of CUBIC.</t>	<t>CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In par ticular, it uses a cubic function instead of a linear window increase function of the curr ent TCP standards to improve scalability and stability under fast and long-distance networ ks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have b een used for many years. This document provides a specification of CUBIC to enable third- party implementations and to solicit community feedback through experimentation on the per formance of CUBIC.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="8312"/>	<seriesInfo name="RFC" value="8312"/>
	<seriesInfo name="DOI" value="10.17487/RFC8312"/>	<seriesInfo name="DOI" value="10.17487/RFC8312"/>
	</reference>	</reference>

	<reference anchor="RFC8311">	<reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8311">
	<front>	<front>
	<title>Relaxing Restrictions on Explicit Congestion Notification (ECN) Experim entation</title>	<title>Relaxing Restrictions on Explicit Congestion Notification (ECN) Experim entation</title>
	<author fullname="D. Black" initials="D." surname="Black">	<author fullname="D. Black" initials="D." surname="Black">
	<organization/>	<organization/>
	</author>	</author>
	<date month="January" year="2018"/>	<date month="January" year="2018"/>
	<abstract>	<abstract>
	<t>This memo updates RFC 3168, which specifies Explicit Congestion Notificat ion (ECN) as an alternative to packet drops for indicating network congestion to endpoints . It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IET F document stream is required to take advantage of any of these enabling updates. In addi tion, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and fo r the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rati onale for reclassification of RFC 3540 from Experimental to Historic; this reclassificatio n enables new experimental use of the ECT(1) codepoint.</t>	<t>This memo updates RFC 3168, which specifies Explicit Congestion Notificat ion (ECN) as an alternative to packet drops for indicating network congestion to endpoints . It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IET F document stream is required to take advantage of any of these enabling updates. In addi tion, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and fo r the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rati onale for reclassification of RFC 3540 from Experimental to Historic; this reclassificatio n enables new experimental use of the ECT(1) codepoint.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="8311"/>	<seriesInfo name="RFC" value="8311"/>
	<seriesInfo name="DOI" value="10.17487/RFC8311"/>	<seriesInfo name="DOI" value="10.17487/RFC8311"/>
	</reference>	</reference>

	<reference anchor="RFC6928">	<reference anchor="RFC6928" target="https://www.rfc-editor.org/info/rfc6928">
	<front>	<front>
	<title>Increasing TCP's Initial Window</title>	<title>Increasing TCP's Initial Window</title>
	<author fullname="J. Chu" initials="J." surname="Chu">	<author fullname="J. Chu" initials="J." surname="Chu">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati">	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="Y. Cheng" initials="Y." surname="Cheng">	<author fullname="Y. Cheng" initials="Y." surname="Cheng">
	<organization/>	<organization/>

	skipping to change at line 1440 ¶	skipping to change at line 1440 ¶
	<organization/>	<organization/>
	</author>	</author>
	<date month="April" year="2013"/>	<date month="April" year="2013"/>
	<abstract>	<abstract>
	<t>This document proposes an experiment to increase the permitted TCP initia l window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discu sses the motivation behind the increase, the advantages and disadvantages of the higher in itial window, and presents results from several large-scale experiments showing that the h igher initial window improves the overall performance of many web services without resulti ng in a congestion collapse. The document closes with a discussion of usage and deploymen t for further experimental purposes recommended by the IETF TCP Maintenance and Minor Exte nsions (TCPM) working group.</t>	<t>This document proposes an experiment to increase the permitted TCP initia l window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discu sses the motivation behind the increase, the advantages and disadvantages of the higher in itial window, and presents results from several large-scale experiments showing that the h igher initial window improves the overall performance of many web services without resulti ng in a congestion collapse. The document closes with a discussion of usage and deploymen t for further experimental purposes recommended by the IETF TCP Maintenance and Minor Exte nsions (TCPM) working group.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="6928"/>	<seriesInfo name="RFC" value="6928"/>
	<seriesInfo name="DOI" value="10.17487/RFC6928"/>	<seriesInfo name="DOI" value="10.17487/RFC6928"/>
	</reference>	</reference>

	<reference anchor="PRR">	<reference anchor="PRR" target="https://www.rfc-editor.org/info/rfc6937">
	<front>	<front>
	<title>Proportional Rate Reduction for TCP</title>	<title>Proportional Rate Reduction for TCP</title>
	<author fullname="M. Mathis" initials="M." surname="Mathis">	<author fullname="M. Mathis" initials="M." surname="Mathis">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati">	<author fullname="N. Dukkipati" initials="N." surname="Dukkipati">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="Y. Cheng" initials="Y." surname="Cheng">	<author fullname="Y. Cheng" initials="Y." surname="Cheng">
	<organization/>	<organization/>
	</author>	</author>
	<date month="May" year="2013"/>	<date month="May" year="2013"/>
	<abstract>	<abstract>
	<t>This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorit hms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery wi ll be as close as possible to the ssthresh, as determined by the congestion control algori thm.</t>	<t>This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorit hms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery wi ll be as close as possible to the ssthresh, as determined by the congestion control algori thm.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="6937"/>	<seriesInfo name="RFC" value="6937"/>
	<seriesInfo name="DOI" value="10.17487/RFC6937"/>	<seriesInfo name="DOI" value="10.17487/RFC6937"/>
	</reference>	</reference>

	<reference anchor="RFC7661">	<reference anchor="RFC7661" target="https://www.rfc-editor.org/info/rfc7661">
	<front>	<front>
	<title>Updating TCP to Support Rate-Limited Traffic</title>	<title>Updating TCP to Support Rate-Limited Traffic</title>
	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">	<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="A. Sathiaseelan" initials="A." surname="Sathiaseelan">	<author fullname="A. Sathiaseelan" initials="A." surname="Sathiaseelan">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="R. Secchi" initials="R." surname="Secchi">	<author fullname="R. Secchi" initials="R." surname="Secchi">
	<organization/>	<organization/>
	</author>	</author>
	<date month="October" year="2015"/>	<date month="October" year="2015"/>
	<abstract>	<abstract>
	<t>This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the applica tion rather than the congestion window. It provides an experimental update to TCP that al lows a TCP sender to restart quickly following a rate-limited interval. This method is ex pected to benefit applications that send rate-limited traffic using TCP while also providi ng an appropriate response if congestion is experienced.</t>	<t>This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the applica tion rather than the congestion window. It provides an experimental update to TCP that al lows a TCP sender to restart quickly following a rate-limited interval. This method is ex pected to benefit applications that send rate-limited traffic using TCP while also providi ng an appropriate response if congestion is experienced.</t>
	<t>This document also evaluates the Experimental specification of TCP Conges tion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to add ress important issues but failed to deliver a widely used solution. This document therefo re reclassifies the status of RFC 2861 from Experimental to Historic. This document obsol etes RFC 2861.</t>	<t>This document also evaluates the Experimental specification of TCP Conges tion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to add ress important issues but failed to deliver a widely used solution. This document therefo re reclassifies the status of RFC 2861 from Experimental to Historic. This document obsol etes RFC 2861.</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name="RFC" value="7661"/>	<seriesInfo name="RFC" value="7661"/>
	<seriesInfo name="DOI" value="10.17487/RFC7661"/>	<seriesInfo name="DOI" value="10.17487/RFC7661"/>
	</reference>	</reference>

	<reference anchor="RFC8511">	<reference anchor="RFC8511" target="https://www.rfc-editor.org/info/rfc8511">
	<front>	<front>
	<title>TCP Alternative Backoff with ECN (ABE)</title>	<title>TCP Alternative Backoff with ECN (ABE)</title>
	<author fullname="N. Khademi" initials="N." surname="Khademi">	<author fullname="N. Khademi" initials="N." surname="Khademi">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="M. Welzl" initials="M." surname="Welzl">	<author fullname="M. Welzl" initials="M." surname="Welzl">
	<organization/>	<organization/>
	</author>	</author>
	<author fullname="G. Armitage" initials="G." surname="Armitage">	<author fullname="G. Armitage" initials="G." surname="Armitage">
	<organization/>	<organization/>

End of changes. 21 change blocks.
	21 lines changed or deleted	21 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/