--- 1/draft-ietf-tcpm-2140bis-03.txt 2020-04-29 10:13:10.236877898 -0700 +++ 2/draft-ietf-tcpm-2140bis-04.txt 2020-04-29 10:13:10.272878377 -0700 @@ -1,19 +1,19 @@ TCPM WG J. Touch Internet Draft Independent Intended status: Informational M. Welzl Obsoletes: 2140 S. Islam Expires: October 2020 University of Oslo - April 24, 2020 + April 29, 2020 TCP Control Block Interdependence - draft-ietf-tcpm-2140bis-03.txt + draft-ietf-tcpm-2140bis-04.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow @@ -34,21 +34,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on October 24, 2020. + This Internet-Draft will expire on October 29, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -80,50 +80,50 @@ Table of Contents 1. Introduction...................................................3 2. Conventions Used in This Document..............................4 3. Terminology....................................................4 4. The TCP Control Block (TCB)....................................4 5. TCB Interdependence............................................5 6. Temporal Sharing...............................................6 6.1. Initialization of the new TCB................................6 6.2. Updates to the new TCB.......................................7 - 6.3. Discussion...................................................8 + 6.3. Discussion...................................................7 7. Ensemble Sharing...............................................9 7.1. Initialization of a new TCB..................................9 7.2. Updates to the new TCB......................................10 7.3. Discussion..................................................11 8. Compatibility Issues..........................................12 - 8.1. Traversing the same network path............................13 + 8.1. Traversing the same network path............................12 8.2. State dependence............................................13 - 8.3. Problems with IP sharing....................................14 - 9. Implications..................................................14 + 8.3. Problems with IP sharing....................................13 + 9. Implications..................................................13 9.1. Layering....................................................14 - 9.2. Other possibilities.........................................15 + 9.2. Other possibilities.........................................14 10. Implementation Observations..................................15 11. Updates to RFC 2140..........................................16 - 12. Security Considerations......................................17 + 12. Security Considerations......................................16 13. IANA Considerations..........................................17 - 14. References...................................................18 - 14.1. Normative References....................................18 + 14. References...................................................17 + 14.1. Normative References....................................17 14.2. Informative References..................................18 - 15. Acknowledgments..............................................21 - 16. Change log...................................................21 - Appendix A : TCB Sharing History.................................24 - Appendix B : TCP Option Sharing and Caching......................25 + 15. Acknowledgments..............................................20 + 16. Change log...................................................20 + Appendix A : TCB Sharing History.................................23 + Appendix B : TCP Option Sharing and Caching......................24 Appendix C : Automating the Initial Window in TCP over Long - Timescales.......................................................27 - C.1. Introduction.............................................27 - C.2. Design Considerations....................................27 - C.3. Proposed IW Algorithm....................................28 - C.4. Discussion...............................................31 - C.5. Observations.............................................32 + Timescales.......................................................26 + C.1. Introduction.............................................26 + C.2. Design Considerations....................................26 + C.3. Proposed IW Algorithm....................................27 + C.4. Discussion...............................................30 + C.5. Observations.............................................31 1. Introduction TCP is a connection-oriented reliable transport protocol layered over IP [RFC793]. Each TCP connection maintains state, usually in a data structure called the TCP Control Block (TCB). The TCB contains information about the connection state, its associated local process, and feedback parameters about the connection's transmission properties. As originally specified and usually implemented, most TCB information is maintained on a per-connection basis. Some @@ -248,71 +248,71 @@ old_RTTvar old_RTTvar old_option (option specific) old_ssthresh old_ssthresh old_snd_cwnd old_snd_cwnd The table below gives an overview of option-specific information that can be shared. Additional information on some specific TCP - options and sharing is provided in 0. + options and sharing is provided in Appendix B. TEMPORAL SHARING - Option Info Initialization Cached New - ---------------------------------------- + ------------------------------------ old_TFO_Cookie old_TFO_Cookie old_TFO_Failure old_TFO_Failure 6.2. Updates to the new TCB During the connection, the associated TCB can be updated based on particular events, as shown below: TEMPORAL SHARING - Cache Updates Cached TCB Current TCB when? New Cached TCB - ------------------------------------------------------ - old_MMS_S curr_ MMS_S OPEN curr MMS_S + ---------------------------------------------------------- + old_MMS_S curr_MMS_S OPEN curr_MMS_S old_MMS_R curr_ MMS_R OPEN curr_MMS_R old_sendMSS curr_sendMSS MSSopt curr_sendMSS old_PMTU curr_PMTU PMTUD curr_PMTU old_RTT curr_RTT CLOSE merge(curr,old) old_RTTvar curr_RTTvar CLOSE merge(curr,old) - old_option curr option ESTAB (depends on option) + old_option curr_option ESTAB (depends on option) old_ssthresh curr_ssthresh CLOSE merge(curr,old) old_snd_cwnd curr_snd_cwnd CLOSE merge(curr,old) The table below gives an overview of option-specific information that can be similarly shared. TEMPORAL SHARING - Option Info Updates Cached Current when? New Cached - ---------------------------------------------------------------- + --------------------------------------------------------- old_TFO_Cookie old_TFO_Cookie ESTAB old_TFO_Cookie old_TFO_Failure old_TFO_Failure ESTAB old_TFO_Failure 6.3. Discussion - There is no particular benefit to caching MMS_S and MMS R as these + There is no particular benefit to caching MMS_S and MMS_R as these are reported by the local IP stack. Caching sendMSS and PMTU is trivial; reported values are cached, and the most recent values are used. The cache is updated when the MSS option is received in a SYN or after PMTUD (i.e., when an ICMPv4 Fraqmentation Needed [RFC1191] or ICMPv6 Packet Too Big message is received [RFC8201] or the equivalent is inferred, e.g. as from PLPMTUD [RFC4821]), respectively, so the cache always has the most recent values from any connection. For sendMSS, the cache is consulted only at connection establishment and not otherwise updated, which means that MSS options do not affect current connections. The default sendMSS @@ -380,85 +380,84 @@ cumulative values and the number of connections (N). 7.1. Initialization of a new TCB TCBs for new connections can be initialized using context from concurrent connections as follows: ENSEMBLE SHARING - TCB Initialization Cached TCB New TCB - -------------------------------- + ------------------------------------------ old_MMS_S old_MMS_S old_MMS_R old_MMS_R old_sendMSS old_sendMSS old_PMTU old_PMTU old_RTT old_RTT old_RTTvar old_RTTvar - old ssthresh sum f(old ssthresh sum, N) - - old snd_cwnd sum f(old snd cwnd sum, N) + sum(old_ssthresh) f(sum(old_ssthresh), N) - old_option (option-specific) + sum(old_snd_cwnd) f(sum(old_snd_cwnd), N) +_ + old_option (option specific) The table below gives an overview of option-specific information that can be similarly shared. ENSEMBLE SHARING - Option Info Initialization Cached New - ---------------------------------------- + ------------------------------------ old_TFO_Cookie old_TFO_Cookie old_TFO_Failure old_TFO_Failure 7.2. Updates to the new TCB During the connection, the associated TCB can be updated based on changes to concurrent connections, as shown below: ENSEMBLE SHARING - Cache Updates Cached TCB Current TCB when? New Cached TCB - ----------------------------------------------------- + --------------------------------------------------------------- old_MMS_S curr_MMS_S OPEN curr_MMS_S old_MMS_R curr_MMS_R OPEN curr_MMS_R old_sendMSS curr_sendMSS MSSopt curr_sendMSS - old_PMTU curr_PMTU PMTUD curr_PMTU - /PLPMTUD + old_PMTU curr_PMTU PMTUD curr_PMTU / PLPMTUD old_RTT curr_RTT update rtt_update(old,curr) old_RTTvar curr_RTTvar update rtt_update(old,curr) - old ssthresh curr ssthresh update adjust sum as appopriate + old_ssthresh curr_ssthresh update adjust sum as appropriate - old snd_cwnd curr snd_cwnd update adjust sum as appopriate + old_snd_cwnd curr_snd_cwnd update adjust sum as appropriate - old_option curr option (depends) (option specific) + old_option curr_option (depends) (option specific) The table below gives an overview of option-specific information that can be similarly shared. ENSEMBLE SHARING - Option Info Updates Cached Current when? New Cached - ---------------------------------------------------------------- + ---------------------------------------------------------- old_TFO_Cookie old_TFO_Cookie ESTAB old_TFO_Cookie old_TFO_Failure old_TFO_Failure ESTAB old_TFO_Failure 7.3. Discussion For ensemble sharing, TCB information should be cached as early as possible, sometimes before a connection is closed. Otherwise, opening multiple concurrent connections may not result in TCB data sharing if no connection closes before others open. The amount of @@ -646,54 +645,52 @@ optimization is to make that implicit feedback explicit, via extended information associated with the endpoint IP address and its TCP implementation, rather than per-connection state in the TCB. 10. Implementation Observations The observation that some TCB state is host-pair specific rather than application-pair dependent is not new and is a common engineering decision in layered protocol implementations. Although now deprecated, T/TCP [RFC1644] was the first to propose using - caches in order to maintain TCB states (see Appendix A for more - information). + caches in order to maintain TCB states (see Appendix A). The table below describes the current implementation status for some - TCB information in Linux kernel version 4.6, FreeBSD 10 and Windows - (as of October 2016). In the table, "shared" only refers to temporal - sharing. + TCB temporal sharing in Linux kernel version 4.6, FreeBSD 10 and + Windows as of October 2016. Ensemble sharing is not yet implemented. CURRENT IMPLEMENTATION STATUS (as of 2016) TCB data Status - ----------------------------------------------------------- - old MMS_S Not shared + ------------------------------------------------------------ + old_MMS_S Not shared - old MMS_R Not shared + old_MMS_R Not shared old_sendMSS Cached and shared in Linux (MSS) - old PMTU Cached and shared in FreeBSD and Windows (PMTU) + old_PMTU Cached and shared in FreeBSD and Windows (PMTU) old_RTT Cached and shared in FreeBSD and Linux old_RTTvar Cached and shared in FreeBSD - old TFOinfo Cached and shared in Linux and Windows + old_TFOinfo Cached and shared in Linux and Windows old_snd_cwnd Not shared - old_ssthresh Cached and shared in FreeBSD and Linux: - FreeBSD: arithmetic - mean of ssthresh and previous value if - a previous value exists; - Linux: depending on state, - max(cwnd/2, ssthresh) in most cases + old_ssthresh Cached and shared in FreeBSD and Linux* + + *Note: In FreeBSD, new ssthresh is the mean of curr_ssthresh and + previous value if a previous value exists; in Linux, the calculation + depends on state and is max(curr_cwnd/2, old_ssthresh) in most + cases. 11. Updates to RFC 2140 This document updates the description of TCB sharing in RFC 2140 and its associated impact on existing and new connection state, providing a complete replacement for that document [RFC2140]. It clarifies the previous description and terminology and extends the mechanism to its impact on new protocols and mechanisms, including multipath TCP, fast open, PLPMTUD, NAT, and the TCP Authentication Option. @@ -899,29 +896,38 @@ received funding from a collaborative research project between the University of Oslo and Huawei Technologies Co., Ltd. and were partly supported by USC/ISI's Postel Center. This document was prepared using 2-Word-v2.0.template.dot. 16. Change log This section should be removed upon final publication as an RFC. + ietf-04: + + - Fix internal cross-reference errors that appeared in ietf-02 + - Updated tables to re-center; clarified text + + ietf-03: + + - Correction of typographic errors, minor rewording in appendices + ietf-02: - Minor reorganization and correction of typographic errors - Added text to address fingerprinting in Security section - Now retains Appendix B and body option tables upon publication ietf-01: - - Added Appendix C to address long-timescale temporal adaptation. + - Added Appendix C to address long-timescale temporal adaptation ietf-00: - Re-issued as draft-ietf-tcpm-2140bis due to WG adoption. - Cleaned orphan references to T/TCP, removed incomplete refs - Moved references to informative section and updated Sec 2 - Updated to clarify no impact to interoperability - Updated appendix B to avoid 2119 language 06: @@ -950,22 +956,22 @@ implementation overview table. - Marked entries that are considered safe to share with an asterisk (suggestion was to split the table) - Discussed correct host identification: NATs may make IP addresses the wrong input, could e.g. use HTTP cookie. - Included MMS_S and MMS_R from RFC1122; fixed the use of MSS and MTU - - - Added information about option sharing, listed options in 0 + - Added information about option sharing, listed options in + Appendix B Authors' Addresses Joe Touch Manhattan Beach, CA 90266 USA Phone: +1 (310) 560-0334 Email: touch@strayalpha.com @@ -1096,22 +1103,22 @@ MSS TFO negotiation failure (to avoid negotiation retries) Safe and necessary to keep state: TFP cookie (if TFO succeeded in the past) Appendix C: Automating the Initial Window in TCP over Long Timescales - Note: this section is taken verbatim from [To12], updated to refer - to itself as an appendix. + Note: this section is imported from [To12], updated only to refer to + itself as an appendix. C.1. Introduction TCP's congestion control algorithm uses an initial window value (IW), both as a starting point for new connections and after one RTO or more [RFC2581][RFC2861]. This value has evolved over time, originally one maximum segment size (MSS), and increased to the lesser of four MSS or 4,380 bytes [RFC3390][RFC5681]. For typical Internet connections with an maximum transmission units (MTUs) of 1500 bytes, this permits three segments of 1,460 bytes each.