[ih] STD 7, RFC 9293 on Transmission Control Protocol (TCP)
Ole Jacobsen
olejacobsen at me.com
Wed Aug 24 05:59:35 PDT 2022
Hi,
It might be interesting to look at several articles written by Craig
(and one by Phil Karn) under the heading "Improving Your TCP" published
in ConneXions--The Interoperability Report as follows (snipped from the
ASCII index files):
* Volume 1, No. 3, July, 1987:
Improving Your TCP: Look at the Timers Craig Partridge 13
* Volume 1, No. 7, November 1987:
Improving Your TCP: Handling Source Quench Craig Partridge 13
* Volume 2, No. 6, June 1988:
Improving Your TCP: Look under the hood! Craig Partridge 15
* Volume 2, No. 10, October 1988:
Improving Your TCP: "Karn's Algorithm" Phil Karn 23
ConneXions – The Interoperability Report was published monthly from
1987 through 1996. The Charles Babbage Institute at the University
of Minnesota has scanned the complete collection of ConneXions (117
issues) and it is now available here:
https://cse.umn.edu/cbi/hosted-publications
Then scroll down to “Outside Authors” and select: “ConneXions–The
Interoperability Report (1987-1996) Edited by Ole Jacobsen.”
Ole
> On Aug 24, 2022, at 00:58, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
>
> As notes have pointed out, summarizing TCP evolution wasn't the point of
> this document. But given the question is a fun one, here's my rough and
> ready 40 years evolution.
>
> Broadly, evolution in the following areas:
>
> * Window management for error recovery. Key point here, TCP uses sliding
> windows to acknowledge data as it is received - confusingly it is used for
> both flow control [is the receiver ready for more data?] and error recovery
> [what TCP segments have reached the receiver?]. TCP did not specify a
> retransmission approach (go-back-N, selective go-back-N, something else)
> and the community had to feel its way forward. Current practice is that,
> unless using extended ACKs, only retransmit the oldest outstanding
> segment. Extended ACKs (which are negotiated with an option) make it
> possible to better understand the state of the receiver's window and
> retransmit multiple outstanding/lost segments concurrently. These issues
> were mostly solved in the 1980s and 1990s.
>
> * Window management for flow control. Various dysfunctions, most notably
> "Silly Window Syndrome", if the receiver does not update the window
> intelligently. (Another example is reducing the window from the right).
> Issues were found and solved in the 1980s.
>
> * The TCP sequence and window spaces were far too small. The sequence
> space was expanded using PAWS in the 1990s.
>
> * TCP suffers from retransmission ambiguity. The sender cannot tell if an
> ACK is for the original transmission or a retransmission. As a result,
> round-trip estimation can fail catastrophically. Karn's algorithm provides
> a workaround solution. If PAWS is enabled on a connection, PAWS solves
> this problem. Solved in late 1980s/early 1990s.
>
> * TCP's round-trip time estimator was not very good. Solved in 1988 by
> Jacobson.
>
> * Congestion control. TCP's interaction with IP routers to manage
> congestion was poorly understood when TCP was specified. Aspects of the
> problem remain open, but the core solution remains some form of
> Additive-Increase-Multiplicative-Decrease -- solved semi-independently by
> Jain & Ramakrishnan and Jacobson in papers presented in 1988. Elements
> remain a vexing problem -- cf. buffer bloat.
>
> * A wide range of ways to attack TCP have been discovered. Core issues
> include the ability to guess sequence numbers to break into connections and
> to create partial connections (consuming resources). I have not tracked
> closely in a while but believe that we haven't seen a new attack in over 10
> years and that various TCP tweaks have dealt with these issues. Solutions
> include random starting sequence numbers and various ways to mitigate
> half-open connections.
>
> This is off the top of my head and I've likely forgotten a few items. I
> also note that some challenges overlap whereas I've treated them separately.
>
> Craig
>
> On Fri, Aug 19, 2022 at 8:37 PM Toerless Eckert via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> I don't think this is the internet-history-working-group mailing list ;-))
>> aka: sounds like a real research work project, but certainly would have
>> been
>> interesting to hear a nice historical summary of TCP/IP evolution for the
>> 40 year birthday.
>>
>> Cheers
>> Toerless
>>
>> On Fri, Aug 19, 2022 at 07:52:23AM -0400, John Day wrote:
>>> ;-) Interesting point.
>>>
>>> Just out of curiosity.
>>>
>>> Question: How many RFCs were there between RFC791 and RFC2460 that
>> directly relate to the use of RFC791?
>>>
>>> And
>>>
>>> How many RFCs were there between RFC2460 and RFC8200 that directly
>> relate to the use of RFC2460?
>>>
>>>
>>>
>>>> On Aug 18, 2022, at 17:22, Toerless Eckert via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>>>
>>>> Indeed.
>>>>
>>>> Does RFC8200 qualify as an equal amount of improvements from RFC791 ?
>>>>
>>>> ;-) (yes unfair comparison).
>>>>
>>>> On Fri, Aug 19, 2022 at 09:07:20AM +1200, Brian E Carpenter via
>> Internet-history wrote:
>>>>> I'm thinking this is a big deal, historically:
>>>>>
>>>>> -------- Forwarded Message --------
>>>>> Subject: STD 7, RFC 9293 on Transmission Control Protocol (TCP)
>>>>> Date: Thu, 18 Aug 2022 06:58:27 -0700 (PDT)
>>>>> From: rfc-editor at rfc-editor.org
>>>>> To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org
>>>>> CC: rfc-editor at rfc-editor.org, drafts-update-ref at iana.org,
>> tcpm at ietf.org
>>>>>
>>>>> A new Request for Comments is now available in online RFC libraries.
>>>>>
>>>>> STD 7
>>>>> RFC 9293
>>>>>
>>>>> Title: Transmission Control Protocol (TCP)
>>>>> Author: W. Eddy, Ed.
>>>>> Status: Standards Track
>>>>> Stream: IETF
>>>>> Date: August 2022
>>>>> Mailbox: wes at mti-systems.com
>>>>> Pages: 98
>>>>> Obsoletes: RFC 793, RFC 879, RFC 2873, RFC 6093,
>>>>> RFC 6429, RFC 6528, RFC 6691
>>>>> Updates: RFC 1011, RFC 1122, RFC 5961
>>>>> See Also: STD 7
>>>>>
>>>>> I-D Tag: draft-ietf-tcpm-rfc793bis-28.txt
>>>>>
>>>>> URL: https://www.rfc-editor.org/info/rfc9293
>>>>>
>>>>> DOI: 10.17487/RFC9293
>>>>>
>>>>> This document specifies the Transmission Control Protocol (TCP). TCP
>>>>> is an important transport-layer protocol in the Internet protocol
>>>>> stack, and it has continuously evolved over decades of use and growth
>>>>> of the Internet. Over this time, a number of changes have been made
>>>>> to TCP as it was specified in RFC 793, though these have only been
>>>>> documented in a piecemeal fashion. This document collects and brings
>>>>> those changes together with the protocol specification from RFC 793.
>>>>> This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
>>>>> 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs
>>>>> 1011 and 1122, and it should be considered as a replacement for the
>>>>> portions of those documents dealing with TCP requirements. It also
>>>>> updates RFC 5961 by adding a small clarification in reset handling
>>>>> while in the SYN-RECEIVED state. The TCP header control bits from
>>>>> RFC 793 have also been updated based on RFC 3168.
>>>>>
>>>>> This document is a product of the TCP Maintenance and Minor
>> Extensions Working Group of the IETF.
>>>>>
>>>>> This is now an Internet Standard.
>>>>>
>>>>> STANDARDS TRACK: This document specifies an Internet Standards Track
>>>>> protocol for the Internet community, and requests discussion and
>> suggestions
>>>>> for improvements. Please refer to the current edition of the Official
>>>>> Internet Protocol Standards (https://www.rfc-editor.org/standards)
>> for the
>>>>> standardization state and status of this protocol. Distribution of
>> this
>>>>> memo is unlimited.
>>>>>
>>>>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>>>>> To subscribe or unsubscribe, see
>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>>>
>>>>> For searching the RFC series, see https://www.rfc-editor.org/search
>>>>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>>>>>
>>>>> Requests for special distribution should be addressed to either the
>>>>> author of the RFC in question, or to rfc-editor at rfc-editor.org.
>> Unless
>>>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>>>> unlimited distribution.
>>>>>
>>>>>
>>>>> The RFC Editor Team
>>>>> Association Management Solutions, LLC
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> IETF-Announce mailing list
>>>>> IETF-Announce at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>> --
>>>>> Internet-history mailing list
>>>>> Internet-history at elists.isoc.org
>>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>>
>>>> --
>>>> ---
>>>> tte at cs.fau.de
>>>> --
>>>> Internet-history mailing list
>>>> Internet-history at elists.isoc.org
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>> --
>> ---
>> tte at cs.fau.de
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell: +1 415-370-4628
Web: protocoljournal.org
E-mail: olejacobsen at me.com
E-mail: ole at protocoljournal.org
Skype: organdemo
More information about the Internet-history
mailing list