Skip to content

Commit

Permalink
update documents
Browse files Browse the repository at this point in the history
  • Loading branch information
github-actions committed Oct 10, 2023
1 parent 984e0d8 commit 4789e23
Show file tree
Hide file tree
Showing 85 changed files with 2,109 additions and 1 deletion.
25 changes: 25 additions & 0 deletions data/RFC2861.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<reference anchor="RFC.2861" target="https://www.rfc-editor.org/info/rfc2861">
<front>
<title>TCP Congestion Window Validation</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="J. Padhye" initials="J." surname="Padhye">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2000" month="June"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC2861"/>
<seriesInfo name="RFC" value="2861"/>
<seriesInfo name="IETF"/>
</reference>
28 changes: 28 additions & 0 deletions data/RFC2883.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
<reference anchor="RFC.2883" target="https://www.rfc-editor.org/info/rfc2883">
<front>
<title>An Extension to the Selective Acknowledgement (SACK) Option for TCP</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="J. Mahdavi" initials="J." surname="Mahdavi">
<organization/>
</author>
<author fullname="M. Mathis" initials="M." surname="Mathis">
<organization/>
</author>
<author fullname="M. Podolsky" initials="M." surname="Podolsky">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2000" month="July"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC2883"/>
<seriesInfo name="RFC" value="2883"/>
<seriesInfo name="IETF"/>
</reference>
22 changes: 22 additions & 0 deletions data/RFC2988.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
<reference anchor="RFC.2988" target="https://www.rfc-editor.org/info/rfc2988">
<front>
<title>Computing TCP's Retransmission Timer</title>
<author fullname="V. Paxson" initials="V." surname="Paxson">
<organization/>
</author>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2000" month="November"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC2988"/>
<seriesInfo name="RFC" value="2988"/>
<seriesInfo name="IETF"/>
</reference>
25 changes: 25 additions & 0 deletions data/RFC3042.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<reference anchor="RFC.3042" target="https://www.rfc-editor.org/info/rfc3042">
<front>
<title>Enhancing TCP's Loss Recovery Using Limited Transmit</title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<author fullname="H. Balakrishnan" initials="H." surname="Balakrishnan">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2001" month="January"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3042"/>
<seriesInfo name="RFC" value="3042"/>
<seriesInfo name="IETF"/>
</reference>
25 changes: 25 additions & 0 deletions data/RFC3168.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<reference anchor="RFC.3168" target="https://www.rfc-editor.org/info/rfc3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="D. Black" initials="D." surname="Black">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2001" month="September"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="IETF"/>
</reference>
22 changes: 22 additions & 0 deletions data/RFC3309.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
<reference anchor="RFC.3309" target="https://www.rfc-editor.org/info/rfc3309">
<front>
<title>Stream Control Transmission Protocol (SCTP) Checksum Change</title>
<author fullname="J. Stone" initials="J." surname="Stone">
<organization/>
</author>
<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization/>
</author>
<author fullname="D. Otis" initials="D." surname="Otis">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2002" month="September"/>
<workgroup>tsvwg</workgroup>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3309"/>
<seriesInfo name="RFC" value="3309"/>
<seriesInfo name="IETF"/>
</reference>
22 changes: 22 additions & 0 deletions data/RFC3390.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
<reference anchor="RFC.3390" target="https://www.rfc-editor.org/info/rfc3390">
<front>
<title>Increasing TCP's Initial Window</title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="C. Partridge" initials="C." surname="Partridge">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2002" month="October"/>
<workgroup>tsvwg</workgroup>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3390"/>
<seriesInfo name="RFC" value="3390"/>
<seriesInfo name="IETF"/>
</reference>
25 changes: 25 additions & 0 deletions data/RFC3436.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<reference anchor="RFC.3436" target="https://www.rfc-editor.org/info/rfc3436">
<front>
<title>Transport Layer Security over Stream Control Transmission Protocol</title>
<author fullname="A. Jungmaier" initials="A." surname="Jungmaier">
<organization/>
</author>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<author fullname="M. Tuexen" initials="M." surname="Tuexen">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2002" month="December"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3436"/>
<seriesInfo name="RFC" value="3436"/>
<seriesInfo name="IETF"/>
</reference>
28 changes: 28 additions & 0 deletions data/RFC3448.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
<reference anchor="RFC.3448" target="https://www.rfc-editor.org/info/rfc3448">
<front>
<title>TCP Friendly Rate Control (TFRC): Protocol Specification</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="J. Padhye" initials="J." surname="Padhye">
<organization/>
</author>
<author fullname="J. Widmer" initials="J." surname="Widmer">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2003" month="January"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3448"/>
<seriesInfo name="RFC" value="3448"/>
<seriesInfo name="IETF"/>
</reference>
28 changes: 28 additions & 0 deletions data/RFC3517.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
<reference anchor="RFC.3517" target="https://www.rfc-editor.org/info/rfc3517">
<front>
<title>A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP</title>
<author fullname="E. Blanton" initials="E." surname="Blanton">
<organization/>
</author>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<author fullname="K. Fall" initials="K." surname="Fall">
<organization/>
</author>
<author fullname="L. Wang" initials="L." surname="Wang">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2003" month="April"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3517"/>
<seriesInfo name="RFC" value="3517"/>
<seriesInfo name="IETF"/>
</reference>
22 changes: 22 additions & 0 deletions data/RFC3522.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
<reference anchor="RFC.3522" target="https://www.rfc-editor.org/info/rfc3522">
<front>
<title>The Eifel Detection Algorithm for TCP</title>
<author fullname="R. Ludwig" initials="R." surname="Ludwig">
<organization/>
</author>
<author fullname="M. Meyer" initials="M." surname="Meyer">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2003" month="April"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3522"/>
<seriesInfo name="RFC" value="3522"/>
<seriesInfo name="IETF"/>
</reference>
25 changes: 25 additions & 0 deletions data/RFC3540.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<reference anchor="RFC.3540" target="https://www.rfc-editor.org/info/rfc3540">
<front>
<title>Robust Explicit Congestion Notification (ECN) Signaling with Nonces</title>
<author fullname="N. Spring" initials="N." surname="Spring">
<organization/>
</author>
<author fullname="D. Wetherall" initials="D." surname="Wetherall">
<organization/>
</author>
<author fullname="D. Ely" initials="D." surname="Ely">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2003" month="June"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3540"/>
<seriesInfo name="RFC" value="3540"/>
<seriesInfo name="IETF"/>
</reference>
19 changes: 19 additions & 0 deletions data/RFC3649.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
<reference anchor="RFC.3649" target="https://www.rfc-editor.org/info/rfc3649">
<front>
<title>HighSpeed TCP for Large Congestion Windows</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2003" month="December"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3649"/>
<seriesInfo name="RFC" value="3649"/>
<seriesInfo name="IETF"/>
</reference>
22 changes: 22 additions & 0 deletions data/RFC3708.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
<reference anchor="RFC.3708" target="https://www.rfc-editor.org/info/rfc3708">
<front>
<title>Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions</title>
<author fullname="E. Blanton" initials="E." surname="Blanton">
<organization/>
</author>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2004" month="February"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3708"/>
<seriesInfo name="RFC" value="3708"/>
<seriesInfo name="IETF"/>
</reference>
19 changes: 19 additions & 0 deletions data/RFC3742.xml
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
<reference anchor="RFC.3742" target="https://www.rfc-editor.org/info/rfc3742">
<front>
<title>Limited Slow-Start for TCP with Large Congestion Windows</title>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author>
<organization>RFC Series</organization>
</author>
<date year="2004" month="March"/>
<workgroup>tsvwg</workgroup>
<abstract>
<t>This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="DOI" value="10.17487/RFC3742"/>
<seriesInfo name="RFC" value="3742"/>
<seriesInfo name="IETF"/>
</reference>
Loading

0 comments on commit 4789e23

Please sign in to comment.